Meanwhile I know TOGAF for several years but I never found the opportunity to use it in its whole breadth in a customer project. For any actual project situation TOGAF with all its phases and result artifacts always seemed to be just too much to use it straightforward. I always was sort of afraid to frighten off my customers if I would talk about more than a dozen phases and sub phases and lots of result artifacts to be produced. So I usually tended to use a more “lightweight” architecture lifecycle framework consisting of only a few phases and artifacts that fitted the requirements of my customers pretty well.
Then a few weeks ago I had the opportunity to attend the Open Group Conference in Munich, one of the largest gatherings of TOGAF experts worldwide. So I was very curious to talk to these experts, what their experiences were. Did I just have the wrong projects for TOGAF in the past? Did I miss an important point? Or would they share the same experiences I had?
So, when attending the case studies and talking to other people at the conference I always got the same answer: No one of them used TOGAF “pure”. All of them tailored TOGAF according to their specific customer requirements which usually meant simplification: Phases were pooled together, dropped or renamed. The result artifacts were also simplified, dropped or renamed. In one case they compressed the framework down to four phases and did not mention the term “TOGAF” at all, just to avoid discussions about the architectural framework complexity with the customer.
On the other hand everybody agreed that TOGAF is a really good framework which is very well suited to get a grasp of what is important to architecture lifecycle management and to start any non-trivial architectural effort. In the context of an actual project though, the framework usually has to be customized or simplified to suit the projects constraints – even radically if required.
This feedback was very interesting for me since it somehow confirmed my former approach: Do not customize the customer to suit the needs of the framework but select and customize the framework to suit the needs of the customer. And a framework of the size of TOGAF is usually just about a magnitude too large for most customers and projects. Hence most of the time you have to simplify the framework to suit the needs of the customer. Of course there are also projects that require the complete TOGAF in its whole and unlimited beauty. But due to the size of these projects they are quite rare.
By the way this is an experience I had for most non-trivial methods and frameworks – also in different areas: Most of them give you a good idea of what areas you should look at when dealing with the topic they cover but you use them quite rarely in their pure form. Most of the time you have to customize, i.e. simplify and modify them to work with your specific customer and project.
Remember: The goal is to create business value, not establishing methods and frameworks – those are just a means to an end.
Was this post helpful?
More articles
fromUwe Friedrichsen
16.10.2018 Your job at codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
More articles in this subject area
Discover exciting further topics and let the codecentric world inspire you.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog author
Uwe Friedrichsen
CTO
Do you still have questions? Just send me a message.
Do you still have questions? Just send me a message.