We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

TOGAF misconception

Vote 0 Votes

This post comes as a response to TOGAF Misconceptions blog by Mike Walker citing Dave Hornford which responds to some misgivings I have about the method.

How does TOGAF serves your effort to develop an Enterprise Architecture? Let's have a look at the ADM.

ADM Phases B, C and D are part of an Architecture Development Method (ADM) indeed. But the rest of the phases such as F,G and H are rather part of a different sort of process, an enterprise Transformation process which is not the responsibility of an Enterprise Architect, except perhaps in an advisory role, because the focus of the whole process is not to design or even implement the architecture itself but to transform the enterprise, eventually employing an architecture.

ADM should perhaps clearly state that for these phases there is latitude to employ alternative and proper business methods. 

The name ADM (Architecture Development Method) is a misnomer as such, not suitable for these phases.

Nevertheless, businesses don't use ADM as the enterprise transformation process and probably they never will.

It is debatable whether B, C and D, layers of a standard EA stack (Business and Information Technology tiers), should be made separate phases. If their activities and deliverables are similar, and they are, they shouldn't be separate. Moreover, would you include as phases of an entity development process, all the elements of its decomposition tree?

About TOGAF's focus on requirements. Neither an EA nor an enterprise transformation process need requirements.

The current architecture development process in phases B, C and D does not use requirements. I think we could all agree that because the task in these phases is to discover and document the EA, the requirements have no role to play.  

Moreover, the Architecture Vision in phase A should be essentially based on the enterprise vision, enterprise strategy and goals rather than requirements, because these constitute, if you like, the requirements for the target enterprise and its architecture. 

Even in practice, the EA team has been never known or asked to collect all requirements for the transformation of an enterprise. That is a matter for individual solution projects. The transformation roadmap, strategy, planning and target architecture would consider the outcomes of these projects rather than their requirements.

In any case, there cannot be an Architecture Vision in phase A  Before  one discovers and documents the current architecture in the phases B, C and D, because the vision has to be rooted in the current reality. One has to follow an evolutionary approach (rather than revolutionary) that starts with the current state and continues to build on it. The business though would be thrilled to hear that the EA team wishes to start from "tabula rasa", to re-design their enterprise from scratch.

On top, this architecture vision should have the same components as the architecture layers (mentioned in phases B, C...). Otherwise how can one later assess and fill in the gaps? 

One can clearly see that the architecture phases C and D cover only the Information technology. If TOGAF claims to cover the whole enterprise, then IT should not be the only technology included. But that would obviously would increase the ADM phases (B,C D...) to the whole alphabet.

ADM is indeed more of a solution development process, as it was also stated in one of the early TOGAF releases, because

 * any solution starts with the requirements collection and analysis and takes into account their changes at each iteration

 * a solution development process includes indeed implementation phases like F, G and H 

Besides, as above, there is nothing in the ADM that makes it applicable at the enterprise level. On the contrary, phases F,G and H do not apply as explained above.

I can only assume that a solution development process was applied to EA without considering the implications.

One does TOGAF and not EA because the TOGAFer attempts to deliver according to TOGAF's phases lists of deliverables (which are in fact small and prescriptive subsets out of an unlimited number of potential EA artifacts), rather than to deliver the integrated EA, the linked set of blueprints of the enterprise, made possible by a modeling framework. TOGAF doesn't cover modeling, as it was proudly stated. The outcome of TOGAF, is not an integrated EA but a number of independent and disjoint enterprise artifacts listed in a table. These artifacts, disjoint as they are, used to exist in the enterprise long before the advent of TOGAF or the EA for that matter. 

On top, the ADM demands such a thing as a "Request for Architecture work". Once the work has been approved, no EA requires such a formality. It is usually the architect that has to sell the work product to the business rather than compelling the business to make formal requests for ADM phases. And, who would consent to issue the EA team with formal "Request for Architecture Work" at each architecture phase?

Archimate and TOGAF. To my knowledge, they still have, after a long time, different if not conflicting metamodels. One reason is that TOGAF has different and even variable definitions for concepts such as for Functions, never mind a plethora of alternative concepts such as building blocks, capabilities, services which are not sufficiently differentiated to be properly modeled. 

Even the training for TOGAF or Archimate is done independently. It may be even the case that the two compete. It looks to me like a marriage of convenience rather than an integrated method.

TOGAF was said to be a set of tools too. Can TOGAF specify then what these tools are? Then that you may add any tool you like. For what purpose though? What are we trying to achieve? And yet again, what tools, for what and when to use them? What is missing in TOGAF that we have to come up with? How much does TOGAF cover out of this plethora of methods? What other frameworks does TOGAF recommend? Do we need TOGAF at all if we have all these tools? 

In any case shouldn't TOGAF have included value chains, business and operating models and, at the very least, a modeling method? But TOGAF does not even offer the models that TM Forum's Frameworx does: Process, Applications and Information maps. TOGAF does not offer a business architecture model or modeling guidelines at all.

Now, if anyone wishes to join the Open Group to attempt to derail TOGAF from its path, please do that. There is just the small matter of cost, time spent and nice travel, just to render TOGAF usable to the community. But you are not paid to do theoretical framework work but rather the EA of your company. You might be interested to use your good methods for your own development rather than surrendering it to TOGAF and even pay for that good deed. Then, in my experience, it's easier to move a mountain than an organization with such a legacy cash cow or the people of the many and various member companies who have their own vested interests, which sometimes aim to preserve the status quo.

In any case, I take the opportunity to let you know that I just published the book "The Enterprise Architecture matters blog" in Kindle at 


The book consists of a selection of blogs posted over the past seven years. The articles are grouped in categories to render your finding answers to your questions quick and easy. Here is the contents page:

The enterprise problem and the EA promise
What EA is and Frequently Asked Questions (FAQ)
The scope of EA
EA benefits and the value it returns
EA deliverables and its purpose
What EA does or should do
The EA design and visualisation
The EA Business Architecture, capabilities, value chains & streams
The EA IT architecture
The people architecture, the EA organization layer and culture
EA governance, principles and budgeting
How to create, market and communicate EA
The EA role in the enterprise and its transformation
On the relation of EA to strategy, transformation, innovation...
Who does EA, the architect role, skills and recruitment
EA training, certification and higher education
EA politics
EA roadblocks and myths
The EA framework definition, categorisation and patterns
EA frameworks and tools
The critique of illuminated EA approaches
The state of Enterprise Architecture and its future
SOA and Enterprise Architecture
The Cloud and the enterprise
The GODS business architecture and one page EA
The GODS-FFLV Framework
The EA development framework book and training course
EA papers, presentations and book

The book is priced low because it is aimed to be widely accessible. 

1 Comment

| Leave a comment

Thank you for the information you give

Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives