Enterprise Architecture has become a real container term; everyone uses it but means something slightly different. This confusion is not very constructive and certainly does not provide enterprise architecture with a positive image to other stakeholders. I therefore propose to reserve the term enterprise architecture only for the highest-level form of architecture; there where the organisation strategy needs to be made concrete. The enterprise architecture translates the organisation strategic goals into guiding architecture principes and change initiatives. The guiding principles express the most fundamental choices the organisation has made and that have an impact on the design of the organisation, in all its facets. Change initiatives are defined to move the organisation towards compliance to these principles. Top-level models show all facets of the organisation, from organisaction structure to IT infrastructure from a birds-eye view. They help position change initiatives and guide the design of the various aspect areas.
Given my definition of enterprise architecture, you probably wonder what other forms of architecture do not fall under the definition. One important form of architecture is reference architecture. This form of architecture provide architecture principles and models that are not specific to the organisation. Examples are industry specific architectures such as the IBM Insurance Application Architecture, or technical reference architectures such as the Microsoft Application Architecture for .NET. Ideally you just buy them off-the-shelf or select them from the public domain. In practice, reference architectures are not widespread, well-known or readily applicable (with a few good exceptions). This forces organisations to define their own reference architectures, based on what can be found in the market. What is needed is an adult market of reference architectures, that prevents us from inventing the wheel ourselves everytime over again. I see too many enterprise architectures that are mostly reference architectures; they contain a lot of generally applicable information.
Another important form of architecture is project architecture. This is where the enterprise architecture is translated into concrete projects that implement changes, mostly in the form of IT systems. The enterprise architecture and the reference architectures provides the project with principes that need to be implemented. Also, they provide the project with models that can be used for defining the scope, and the outline of the design of the project. The project architecture itself documents the high-level requirements, as well as the most fundamental choices that need to be made; the architecture decisions.
A form of architecture that is less well-known is what I would call the management of the architecture repository. This is basically configuration management of all aspects of the organisation, at a high (architecturally significant) level. This requires separate processes and responsibilities and ensures that the organisation knows its own installed base. Also, within the repository we can document the areas that need change, helping projects in making the proper changes. These changes can be determined based upon the enterprise architecture and reference architectures. The repository should help with impact analysis and propagate changes to all related elements. Based upon the repository we can generate architecture views that show specific elements that are needed in a specific situation. In my view managing the architecture repository is quite different from managing the enterprise architecture, and requires different skills and knowledge.
All these forms of architecture are not defined sequentially; they are defined iteratively and interactively. Iteratively because we must continually focus on what adds the most value. Also, the various forms of architecture influence each other. Interactively since architecture is a people's business; it is all about getting the most out of people and together find means to improve the business. An architect is not a specialist or hero that can do it all himself.
Comments (20)
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 07-05-2008 13:37
Danny, when you talk about the management of the architecture repository does that equate to governance or am I missing something?
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 07-05-2008 21:36
Dear Richard,
Management of the architecture repository is different from architecture governance. It refers to the fact that you have to actually fill the repository, keep it up to date, and expose its contents to relevant stakeholders.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 09-05-2008 07:57
Dear Steven,
In my view Enterprise Architecture is business architecture, as well as IT architecture. I think TOGAF is too much focused on IT. On the other hand, business is strongly relying on IT. Enterprise Architecture is thus a holistic view on the enterprise, comprising business and IT.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 09-05-2008 09:56
Dear Danny,
With Business architecture, do you mean all aspects of COPAFIJTH (http://nl.wikipedia.org/wiki/COPAFIJTH)? IT is only one aspect of this. Creating a true business architecture should involve much more than IT, and should not be done by IT people I think. Therefore I fully agree with the term IT-Enterprise Architecture.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 09-05-2008 14:57
Dear Sjaak,
I am no business architect, but in my opinion business architect is a broad discipline that stops at IT demand. IT architecture is a separate discipline that describes the IT supply and that requires different skills. Enterprise Architecture should encompass business as well as IT; the term IT-Enterprise Architecture does not reflect that. Note that a true Enterprise Architecture thus requires people from different areas and skills; business and IT.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 09-05-2008 15:46
Dear Danny,
Well, that is the problem. (IT-)Enterprise architects, TOGAF or otherwise, are IT-people. Their view on "enterprise" and "business" is an IT-view, not an enterprise view or a business view. Sure, IT is important. But cars and machines are important too. You usually do not form a business based on the view of a car mechanic. IT is convinced investments in and explotation of IT is the basis to form businesses, and this is not the way.
The current way of looking at organisations by enterprise architects is distorted. Sjaak is right; it is a view like from COPAFIJTH or PIOFAH (dutch acronym for a combination of means).
If you look at a business: banking mooney, running trains, selling food etc. strategy is to be based on banking money, running trains or selling food. You'll probably need the whole COPAFIJTH to be able to get this strategy to work. But that is the supply of means. The first step from strategy is to think about your corporate resources, demandside: Labour, Nature/Raw Material and Capital(goods). In recent years I have added Information as a fourth corporate resource because organisations need to know what is happening, internally and externally. Knowledge of Information determines the need for means like IT and other COPAFIJTH elements.
If you look at your pictures in this way, you will see the distortion. An IT-view on an organisation is important, but it cannot be THE view on an organisation. And that is what is wrong with the terms enterprise and business as seen by IT-specialists. This is the reason why IT is at tactical level at most, like the other COPAFIJTH elements.
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 09-05-2008 17:22
Dear Steven,
I think you are misinterpreting my words; I never said that IT should dicate the business. Nor did I say that IT should be the main view on the enterprise. To the contrary; I confirmed that TOGAF is too much focused on IT. I also said business should determine the business architecture part of Enterprise Architecture. Enterprise Architecture is not an IT party!
Written by
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
on 09-05-2008 20:36
Dear Danny,
That is good to hear. Sorry if I have misunderstood your words.
A reason may be your picture. It is very close to TOGAF ADM 8 and/or 9. Another reason may be that I do not see anybody outside IT using terms like enterprise architecture or business architecture. Whether it is Zachman's ZIFA, Capgemini/Sogeti's DYA, OpenGroup's (incl. Capgemini, IBM, HP etc.) TOGAF, GAF/xAF/IAF or one of the other "methods and techniques". All is IT-based, defining processes like SDM has in the 70’s/80’s and looking for IT-projects including IT-design and IT-implementation. All coming from the IT-world.
That is why I really like to have the terms IT-enterprise architect or IT-business architect. These people are about introducing IT into organisations. You are proposing to use the term enterprise architecture exclusively for the highest level of architecture: there where the organisation strategy needs to be made concrete. But what is this highest level? Highest level for IT in an organisation is probably the application landscape/architecture, maybe (or not) designed according to SOA principles and its construction based on a reference architecture. But is this what we may call an enterprise or business architecture. I don’t think so. Do you think the fact an organisation wants to run trains or sell food has much to do with the way we organise supporting functionality in applications? The principles behind creating a business are different from the way we will create COPAFIJTH means to support this business. And: this is not a matter of (de)composition. The built-up of a business cannot be decomposed in its supporting application landscape/architecture. So, there is a highest level of architecture for the business next to highest levels of decomposition of, probably, every one of the COPAFIJTH means. Even further: they should not be the same. If they were we will really lack flexibility in business in such a way an organisation probably cannot survive the next 3 to 5 years.
In my opinion the view/architecture of an enterprise (or business) has, in itself, nothing to do with IT, and should not be part of the work of an IT professional. Decomposing the structure of an enterprise/a business does not result in some ideal application landscape/architecture.
What has happened is that top-IT people adopted the title of enterprise and business architect. This is basically wrong, because, as I described above, they do not architect the enterprise/business but the IT in an enterprise/business. At maximum at tactical level, supplying means =( IT )= to enable the organisation to do its work better, faster etc.
Are we still agreeing? I do hope so….
And we have not been talking about information yet…..
Via Nova Architectura is not responsible for the content of blogs, but authors and readers are asked to adhere the following guidelines. Authors are strongly encouraged to check facts, cite sources, present
balanced views, acknowledge and correct errors. Respect copyright, fair use and financial disclosure laws. Please do not disparage organizations, or individuals. Being critical of someone's practice is acceptable, when it is done in a professional manner. Prevent usage of marketing statements. Comments should be relevant to the specific post they are attached to. Spam, flaming, personal attacks, and off-topic comments are not
permitted. Readers are requested to notify
This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
of any violations. The editor holds the right to remove any statements that, in the editors opinion, infringe the above guideline(s). The author receives a notification of this action.
Given my definition of enterprise architecture, you probably wonder what other forms of architecture do not fall under the definition. One important form of architecture is reference architecture. This form of architecture provide architecture principles and models that are not specific to the organisation. Examples are industry specific architectures such as the IBM Insurance Application Architecture, or technical reference architectures such as the Microsoft Application Architecture for .NET. Ideally you just buy them off-the-shelf or select them from the public domain. In practice, reference architectures are not widespread, well-known or readily applicable (with a few good exceptions). This forces organisations to define their own reference architectures, based on what can be found in the market. What is needed is an adult market of reference architectures, that prevents us from inventing the wheel ourselves everytime over again. I see too many enterprise architectures that are mostly reference architectures; they contain a lot of generally applicable information.
