There has been a long discussion on LinkedIn about Enterprise Architecture and TOGAF – more than 400 comments! What follows is stolen mainly from a comment by John Tieso – thank you John. For those who do not normally use the word architecture, just use the term operating model (or possibly business model) instead of EA or Enterprise Architecture. For those who do not know what TOGAF stands for, it is The Open Group’s Architecture Framework. This is one of many frameworks that are used mainly by IT people to document the operations of the enterprise.
John commented (I have done a little editing – hopefully without changing the meaning):
Watching this thread (and the ones preceding) for over four years now, I do wonder if we will ever agree on some basic premises. I suggest these are:
1- Development of an enterprise architecture is development of an overall perspective and holistic view of an ENTERPRISE — the organization as a whole. The methods used to develop this view involve a number of models and descriptions of requirements, business rules, data structures, applications (systems), networks, etc, which help document the enterprise-level functions.
2- The vast majority of architectures developed each year are NOT enterprise architectures, but subsets of the enterprise, and may be current state descriptions of that subset/function, or future state maps (e.g. target operating model).
3- In many organizations, the actual EA does not exist — but is simply inferred through brief descriptions. As a result, people create subset architectures, such as business, data, network, communications, or systems views without an agreed and documented enterprise architecture (before everybody jumps in, I am painfully aware there are other views as well – such as organisation, people, buildings/locations, suppliers, etc).
4- There is no single architecture framework which is adequate for the development of ALL EA and subset architectures. More generally, when the decision is made on what type of architecture is needed, the framework will either (1) be chosen from something that has already been developed for that architecture effort, (2) be customized to ‘fit’ the requirements of the project, or (3) combined with other frameworks and techniques to achieve the desired purpose. So, if the architecture work is about systems engineering requirements, one might start with John Zachman’s matrix; if the work is about business or IT views, one might use TOGAF, or another framework. If you are doing architectures for the various governments, you might start with DoDAF, MODAF, NAF, or another framework designed for those military or governmental contexts. Again, you might combine one or more to get the best descriptive results for the requirements identified.
5- An architecture documents the existing state, and/or perhaps some desired future state of the enterprise, or a subset of the enterprise, for some specific purpose. Doing an architecture provides logic, rationality, and a level of understanding shareable by managers, strategists, technical personnel, developers, and others. The purpose may be to provide an agreed view against which “lower level” architecture work can be done.
It may provide a basis from which innovation can be more easily discussed and understood. It may provide a way for those who understand operations to communicate with those developing strategy, both to test the practicality of the strategy and to feed operational insights into the thinking. Teaching architectural terms and methods provides the means to explain otherwise mundane concepts to those that need to understand what the effort is all about.
6- The CEO owns the EA, although, in practice, that is almost never the case. Whoever ‘owns’ it has to be able to manage, maintain, describe, and periodically review it with the full approval of senior management. By default, the CIO often owns the EA because he or she is the function head who most needs the level of detail contained in an EA.
7- The efficacy of an architectural framework is not determined by what software supports it, or the bells and whistles the vendors insist in packing into every new version to justify higher prices. The real efficacy of a framework lies in its ability to help form a plan for development, maintenance, and management of corporate processes and practices, together with their supporting resources and suppliers, over time.