Embedded Files
Recently, I participated at the 5th Enterprise Architecture conference in Sydney Australia, which, by the way was informative. It is worth mentioning the fact that many speakers thought that the Enterprise Architects should be more business oriented and become a part of the business decision making process. What was also clear was that many delegates still did not have a clear definition of what Enterprise Architecture is. This is why I would like to return to the basics: what EA is!
But first the dilemma... is it:
an Enterprise state
a document
a set of diagrams
a process
a program
an organization design
strategic planning and Enterprise portfolio management
an Enterprise IT integration program
Business Process Management (BPM) development
an organization alignment to strategy and business objectives
Now a few definitions from reputed organizations...
CIO Definitions from SearchCIO.com, posted October, 2006:
"An enterprise architecture (EA) is a conceptual blueprint that defines the structure and operation of an organization. The intent of an enterprise architecture is to determine how an organization can most effectively achieve its current and future objectives. Purported advantages of having an enterprise architecture include improved decision making, improved adaptability to changing demands or market conditions, elimination of inefficient and redundant processes, optimization of the use of organizational assets, and minimization of employee turnover."
From General Accountability Office (GAO) of the US federal government, August 2006:
"An enterprise architecture is a blueprint for organizational change defined in models [using words, graphics, and other depictions] that describe (in both business and technology terms) how it operates today and how it intends to operate in the future; it also includes a plan for transitioning to this future state".
FEA definition:
"The FEA (Federal Enterprise Architecture) consists of a set of interrelated "reference models" designed to facilitate cross-agency analysis and the identification of duplicative investments, gaps and opportunities for collaboration within and across agencies. Collectively, the reference models comprise a framework for describing important elements of the FEA in a common and consistent way. Through the use of this common framework and vocabulary, IT portfolios can be better managed and leveraged across the federal government."
From TOGAF 8.1 FAQ:
"An EA defines the components or building blocks that make up the overall Enterprise "their interrelationships and guidelines governing their design and evolution"
...
EA was compared to city planning. One needs to plan infrastructure like roads, water and gas pipes tracts, electricity and telephone cables then shopping malls, official buildings, entertainment venues etc. There are blueprints for electricity wires, sewage pipes, road maps and tourist maps... They all together form the city map.
At the same time towns are the result of an organic evolution over centuries of spontaneous building in various fashionable architectural styles. US cities are planned to a degree few other cities are because the rectangular grid was planned early in the city lifecycle. But most cities build around old cities. Few are constructed from scratch. As such architecture is about managing the change from one state to another, in small increments of time and realizations.
What is EA about though? In an Enterprise, we have all these plans for the CRM, datawarehouse, portal, printing and floor maps, networks, manufacturing band, building, locations... Every stakeholder with his own plan. But they are designed taking into account different components, different diagramming techniques, symbols, tools... Each and every map is useful to a small community.
EA relates all these architectures in a whole where one can navigate from one item to another in a logical manner. For instance, track the performance of a process from a step to another from one resource to another from one function to another.
Of course, to get that unique integrated set of views, one needs the frame that holds them together exposing placeholders when the components have not been represented yet. Do the current EA frameworks achieve that?
EA, as a practice, needs to roadmap to change in the Enterprise, facilitate the alignment of the structure to changing ends.
EA is used for many and various purposes, in fact as many as stakeholders. Each would see a part of EA, a plan of concern to own work, but integrated in the whole.
...
So what is Enterprise Architecture?
Let's ask this question again after we talked about and designed or even implemented one. In fact, what have we implemented? How do we define a definition though? What is the anatomy of a definition? Let us try Zachman's approach to this.
The EA is:
What: The structure of an Enterprise and its blueprint describing.
How: How the Enterprise operates and the processes executed by.
Whom: People.
Which: The technology implementing processes.
Where: Showing the location of people and technology.
Why: To streamline, align, blueprint, strategically plan, and confer agility.
When: According to the Enterprise transformation plan to a target state.
Described in artifacts such as:
Business Architecture: Products, Value Chain, stakeholders' use cases, business model, strategy, business processes, rules, orchestration, B2B choreography... artifacts
Technology & IT Architectures: Applications, Infrastructure, email, Content Management, network, SCADA... People & Organization architecture: organization chart with roles and responsibilities, culture, values... views
Information architectures and many other Enterprise views: location, planning, security…
The Enterprise transformation roadmap and its project portfolio artifacts
All mapped and linked through an EA framework.
In short though: The EA is the Enterprise structure and the operation blueprint describing the current and future states of the Enterprise, in terms of Business, Technology, People and Information views, and the transformation roadmap, process, program and portfolio, all linked together by an EA framework.
The EA ultimately will constitute the Enterprise Knowledge DB. But EA is more than the sum of its parts; it is about the governance (mind) and the culture (soul) of the Enterprise (body).
...
"If you have ever watched a house being built, or if you have ever had an addition put onto an existing house, you know that the standard method of communication is a big piece of paper called a blueprint. Blueprinting is the standard method used to copy large architectural and construction drawings. A blueprint used to consist of white lines on a blue background. A more recent process uses blue lines on a white background." from http://science.howstuffworks.com/question321.htm. It is designed by the architect and used by the plumber, electrician, owner, potential buyer...
The blueprint comes with guidance materials, when necessary. A plan of transformation is the result of strategy executed as (a portfolio of) projects transforming the Blueprint components.
The blueprint reflects the structure that changes in time with its purpose. The architecture could be classic or baroque, depending on the architectural style. The relationship between structure and its purpose is shaped by the architectural style.
The blueprint is not static. It should be constantly updated to reflect the change in structure result of all on-going projects in an Enterprise. That may not always happen but this is the role of the EA architect.
The EA blueprint is the base of all conversations on changing the structure to fit the purpose or fitness for purpose, maintenance, renovation and transformation. It should be the basis of change in the Enterprise, be it operational, tactical or strategical. Without a blueprint, the transformation cannot be properly managed; the Enterprise would grow organically until a point when nothing works properly any longer and its decay starts.
But it is not the task of the Enterprise Architect to do strategy. That is more related to markets, customers, financials, environment and regulatory concerns. The architect does not do planning but roadmaps.
The EA, as a blueprint, should be seen as the cornerstone of any Enterprise transformation, as a strategy, as in the title of a well known EA book.
Page updated
Google Sites
Report abuse