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:
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:
Described in artifacts such as:
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.
EA FAQ >