Enterprise Architecture Matters

Adrian Grigoriu

Training in TOGAF, my unorthodox findings

user-pic
Vote 0 Votes

I studied TOGAF at my own pace, along the years. The lush 800+ page were always a challenge. I also listened to and participated in many discussions. Still, last week I decided to go onto a formal training course. 

The trainer proved to be experienced in many matters and in the training process itself.   When matters were foggy, he often came with answers springing from own experience. And that saved the course in many ways.

The best definition of TOGAF, I came out with at the end of it, is that it is a process (ADM) coming with a plethora of guidelines and techniques. Most of them were almost unnecessary in the context, in that they could be referenced rather than described as part of TOGAF.

Guidelines and techniques about Risks, Security, Governance, Contracts... do not really belong to the architectural discipline alone. Architectural contract ...., have you ever used that?

TOGAF is not a framework, in the sense that artifacts or building blocks plug into, to give an EA. Can one arrive at an EA by following a process and a set of guidelines, if the object the process develops, is not specified either as structure or behaviour? I'll let you answer this.

The ADM circle specifies phases. But Business, Information Systems and Technology are domains/tiers of an EA, rather than EA development phases.  

In the first place, there is no clarity around the As-Is and To-Be EA states. They don't really exist in fact. It looks like their analysis and design happens inside each of the Business, IS and Technology architectural "phases". So be it. 

Following, there is an Opportunity and Solutions phase after the architectural phases, that seems to consolidate facts discovered in the gaps analysis hidden in the architectural analysis. 

The ADM moves then to the Migration Planning where the notion of roadmap, so often associated with technology and architecture, is missing. Planning is also not an activity associated with EA team, normally. But in the general training rush from one section to another the audience doesn't even notice. 

Where is the Design phase of the ADM though? 

There is the Implementation (Governance)  phase which is about executing the migration in which yet again the EA architect is engaged to observe conformity to EA rather than perform it, that is implement or govern it. That should be clearly stated to avoid confusion.

The Change Request phase, that I would call, business as usual enterprise operation, is involving the EA architect solely in assessing and resolving the impacts of change in conformity with the EA. Maybe the the ADM circle describes only the involvement of the architect in a delivery process. The process should equally then apply to Planners, Implementors etc. But do they use it?

The ADM goes around in circles.

The strategy which execution, many claim is enabled by EA, is rarely mentioned, if at all!

While the Preliminary is an One Off phase, it appears though in the iteration cycles described later on in the ADM!

In exchange, the ADM circle shows requirements in a middle disk, affecting all phases. But architecture requirements are few; anyway they should probably look more like architecture principles. And requirements are typically specified in relation to solution and their delivery process rather than in conjunction with the EA. That leads me to believe that the TOGAF ADM attempts to describe a solution rather than an EA development process.  

Technology is solely IT. Non-IT technology is ignored! 

Business architecture is not really approached except in lumping people and process together in the non-IT part of the enterprise, which is not good. People organisation is really a separate discipline as it is BPM but both are equally important parts of EA and the enterprise and as such they deserve more from TOGAF.

As an input, there is an Architecture Request document which has to be signed of by stakeholders; but who ever had seen or signed such a doc?

As a delivery from a phase, there is also an Architecture Description Document. But what is the audience of such a document? It looks like a big tome consisting of all architectural artifacts. How would one use that? Where is the linked set of architecture artifacts, navigable at that, where each stakeholder can readily discover the blueprint and component of interest?

Architecture views are in general innumerable. As a matter of fact any stakeholder has or should have an own view (printing, file sharing....). TOGAF limits them to a few, described in a table. Does the resulting EA, if any, cover the whole enterprise then? No.

TOGAF describes deliveries only as lists, matrices, diagrams but then later on it introduces the Architecture Description Document. This is one of the many inconsistencies of TOGAF.

The Architecture repository (the organisation of EA artifacts and information related to team and process), is incomplete and little related to the Content Metamodel or the ADM process.

The metamodel mentions capabilities which are just hanging there in a corner, not connected to anything. 

Also the presence of service oriented business services in the metamodel, characterised by a defined interface..., gives you the impression that SOA or service orientation is already the norm in the enterprise. It is not.

The Technical Reference Model and the Standards Information Base are obsolete apparently, for many years now. Why aren't they removed or updated?

Pictures/Diagrams seem to be inconsistent all along the course. It is also hard to understand the relationships between main TOGAF constructs and diagrams.

Also, TOGAF makes no clear distinction between capabilities, building blocks,  business functions, components and so on. Every section seems to come with a different interpretation reusing little from the ones before. In fact, every section seems to be designed more or less in isolation with weak efforts of integration taking probably place as an afterthought. 

Was there a capability map? Not that I can remember. But a Capability Framework is part of TOGAF to define the team capabilities necessary to develop an EA. 

Both TOGAF designers and audience come, perhaps, from the IT world. That may explain the ardour they put in describing some well known business techniques and discover the "complexities" of TOGAF which abounds in loose detail.

There are many things to be said. It is not a light training since everybody tries to make sense and think how to glue concepts together. But things were not integrated in the first place.

I am trying to remember what was good about it. Can you tell me the TOGAF follower? Of course, the certification is the best good thing for many.

But how can you use TOGAF to built an EA? What TOGAF parts do you use?  Do you use TOGAF at all? Or you just pay lip service.

7 Comments

| Leave a comment

Hi Adrian,

I think that every true enterprise architect who uses TOGAF9 will recognise all these issues with it. There is certainly much to be desired, but this is only to be expected with its 'designed by committee' legacy. The people who contributed to TOGAF9 obviously didn't try to iron out the inconsistencies in their rush to publish.

I also think that most practitioners will use TOGAF9 just as a general reference, or only use bits of it. Although organisations frequently put knowledge of TOGAF on their job specifications, in the past 10 years I've not come across any who have made it mandatory to use.

regards, Adrian

I concur with you. TOGAF as a framework, practice, or methodology, is too loose. Trying to follow its guidelines is confusing and one get lost; reason why its acceptance is limited. A "one-size" fits all is not true. As a guideline is not specific enough and as a methodology it has too many practices. Trying to model EA with it, leaves you with too many loose ends; how to tie them up? It is left up to you.

hey,

Earlier this year, I followed a 5 day TOGAF course as well described here:http://blog.line20.be/2011/05/togaf-training.html.

6 months later, I'm not using much of it. I believe there are several reasons, like company maturity around an EA practise, but more importantly; I couldn't find a way to scale it down into an agile approach.

However, as a young EA, it did give me scope and context, let's say I get the big picture, unfortunately it was an expensive exercise to acquire it.

Hopefully I'll be able to do more EA stuff and reach back to the TOGAF book but for now, it is gathering dust...

Very nice post. What EA course or learning materials can you recommend to supplement those who learned only TOGAF in order to help someone develop into an EA? (Of course real experience is important).

Someone must say the un-sayable. Thanks Adrian.

I agree with most of what you say - which also illustrates that TOGAF is not so much EA as large scale SA or EITA.

Adrian

Aargh! How you have struggled to find out what you could have found in a few minutes by looking around "TOGAF in a nutshell" at avancier.co.uk!

Graham

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

Blogs

ADVERTISEMENT