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.
Ashridge on Operating Models 
TOGAF always seemed to me too IT-driven and not enough flexible for my projects. When designing an operating model I usually go back to the good old McKinsey’s 7S, with some changes, for instance:
– I replace some “S’s” by generally accepted words (such as capabilities instead of skills). I then use Hamel & Prahalad definition and Porter activity map
– I break down “systems” into processes & IT
– I can add or delete an S if need be, etc…
Also when working for small and medium sized firms (I’m a consultant) I always take into account that the business strategy does not always guide the other components of the “operating model” but that capabilities (or to be more specific the lack of core competences) constrain the possible strategy a SME can pursue. For large firms that’s a different story. If they lack a capability they deem key to their strategy they can acquire or build it. Often SME don’t have the resources (finance, people…) to do it
Good post Oliver. Sorry for the delay in approving it … but I have been swamped by spam posts. Frustrating! I too have worked with the 7Ss because I spent time with McKinsey. I think that the Enterprise Architecture people make operating model work seem rather complex, while at the same time leaving out some things that are included in the 7Ss.
Hi Andrew,
Thank you for your kind comment. I worked with McKinsey too.
I totally agree with you regarding the unnecessary complexity some people add to the topic of operating model. I believe this is because they tend to re-invent the wheel. I’m always astonished to read about operating model as if it was a new issue that came from a vacuum. Ok the 7S is probably outdated (that’s why I have a lot of expectations from your research!), but organization design has been around here for a long time.
Also people tend to use different words for very similar concepts, which only add to the confusion. For instance what’s the difference between an operating model and a business architecture? I’ve looked at the ”business architecture body of knowledge” and they define business architecture as “A blueprint of the enterprise that provides a common understanding of the organization and is used to align strategic objectives and tactical demands”. Its key components are: capabilities, organization (structure), value streams (processes) and information. I even found a presentation from a practitioner that concluded that “Business architecture is an effective way to describe an organization’s operating model”. Looks to me like the serpent is eating its own tail.
We are pretty much in agreement Oliver. Yet I find that I always learn something from those who are taking a different perspective. So yes I have learned things from Enterprise Architecture. But my quest is to create a fully rounded understanding of operating models, a language for the ideas that works for senior managers and an understanding of how to use operating models to help both create strategy and align the organisation’s participants.
Hi Andrew,
You’re absolutely right when you mention perspectives. I guess people using TOGAF have different perspectives than me/us (notably an IT bias).
I have some experience in so-called transformation programmes and believe me it is extremely difficult to translate strategic objectives into functional specifications for the IT. That’s why when IT programme directors have to take key decisions they rely on IT criteria (budget, risks, planning, etc…) and not on whether option 1 will allow the IT to be more aligned to the strategy than option 2.
I like very much Roger Martin’s concept of cascading strategic choices. Maybe we should view entreprise architecture as an operating model but at a lower level of granularity? We would have at the top the corporate strategy, then the business strategy, the operating model (some like to add in between the business model) and finally the entreprise architecture that would ensure that the IT is aligned with the organisation’s goals.
Whatever I look forward to reading your blog. I’ve also joined the operating model group on LinkedIn where I’ve already glimpsed some fascinating discussions about capabilities.
As an Enterprise Architecture practitioner ( I’ll declare my bias early 🙂 ), I agree with many of the points above. The different EA frameworks have different uses; they’re tools for certain jobs. Their main benefit is to provide a common language in which all architects can converse. This allows consistency and, given the different types of architect that need to collaborate, that’s important.
At the end of the day, these frameworks are just tools. They don’t solve business problems by themselves, they need experienced pacticioners to wield them. However, anything that encourages people to use a common language is to be welcomed …..
As is your comment Peter. Thank you.