Architecture frameworks are the bread and butter of archicteture activity. TOGAF recently celebrated 25 years of existence. That is an impressive record for anything in the information technology arena. In this post, I talk about my experiences as a practitioner of TOGAF, arguably, the most popular framework for carrying out Enterprise Architecture (EA) activity.
Let’s start by reviewing the purpose of Enterprise Architecture – the alignment of business and IT strategies. TOGAF is one of the popular approaches to acheive this critical outcome. Two key definitions from TOGAF are worth mentioning:
Architecture:
Definition 1: The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution. (ISO/IEC/IEEE 42010:2011)
Definition 2: The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
Framework:
A conceptual structure used to plan, develop, implement, govern, and sustain an architecture.
In essence, TOGAF provides a structure to the EA activities in an organisation. I have seen in my own EA work, TOGAF approach bringing a sense of consistency and structure around what used to be a number of unstructured processes, activities, and deliverables. Below I summarise a few observations.
Explicit Practice: I came across TOGAF way back in 2008 and since then worked in organisations with no EA practice to ones with fornal EA teams and activity. I have noticed that EA work, whether done formally done through an EA practice or not, has always been relevant and will continue to be in the foreseeable future. Who can argue with the proposition that business and IT strategies must be aligned? The disagreement, if any, seems to be around how it should be done. Where EA is not carried out through an explicit practice is done implicity through the non-EA roles – CIO/CTO, Delivery heads and managers, and designers – in consultation with equivalent business stakeholders: CEO/CFO/Functional Directors and Business Owners / Managers.
TOGAF has highlighted the need for giving EA practice the attention it deserves. At the minimum, such a practice provides a governance structure and (hopefully!) objective and independent set of eyes to cast over technology choices the organisation is making. Moreover, the operational teams – both in the business and IT – do not have the time or intent to weigh technology options to the same level of objective detail that an EA governance can drive.
Layered View: The next thing that stands out to me with TOGAF is the mental model of thinking about architecture (whether enterprise, program, project, or solution level) in terms of its four core layers – Business, Application, Data and Technology (and, in recent times, through an additional Security lens to apply across all these layers). Most programs and projects face avoidable delays and rework because one or more of these layers have not be addressed at the appropriate time and in a coherent way. On the other hand, there may have been so-called successful IT projects that ultimately failed to deliver business value as the project/solution objectives were not explicitly aligned to the organisational strategy.
Sure TOGAF was not the first to introduce the concept of this layered approach (see EAP, for example) and may have been at the right place and at the right time for making it a popular paradigm. It doesn’t matter to me as a practitioner that TOGAF may have borrowed ideas that worked well earlier. In fact, it would bother if it didn’t as all EA is about reusability of what works!
Views and Viewpoints: A related TOGAF concept is one of different stakeholders having different expectations from architecture. Very rarely we can produce one artefact that is suited to all the audiences – business and technical. Each stakeholder needs a different language and depth – e.g. motiviation and capability models at the CXO level vs a sequence diagram for the designer. This also leads into the idea of having the right level of modelling activity so various levels of presentation can be addressed.
ADM Cycle: TOGAF is known most for its Architecture Development Method (ADM), which is described as an iterative cycle applied to any vertical or horizontal slice across the organisation. In this sense it is not an ontology (a representation of the structure of the enterprise, that Zachman Framework, for example, claims to be) but a methodology for implementation. Archimate – a complementary modelling method fills this ontological requirement to a certain extent.
Reference Architectures and Reusability: TOGAF asks us to look at is the idea of resuability – both of the architecture itself as well as the solutions that are built – ultimately to speed up delivery of IT change initiatives but also to stop reinventing the wheel. For example, industry process and data models help speed up architecture work as well adopting off-the-shelf solutions for common services such as CRM. Also reference architectures developed ahead of the implementation phase speed up the delivery.
Architecture Modelling and Repository: TOGAF also brought home to me the idea of having a central architecture repository that, not surprisingly, results from a consistent modelling activity (through a standard modelling language such as Archimate). Typically there is waster time and effort in organisations that collate the same component information again and again for each implementation project; most of this can be avoided with a central (and up-to-date) repository under the custodianship of the EA practice.
Having extolled the virtues of TOGAF I want to now focus briefly on the frequent criticisms of the methodology and my take on the potential situations driving such views.
Too academic to be of practical use: I can see where this may be a problem. If EA practices and architects resort to following the framework by the letter without taking into consideration the organisational maturity and its culture (of formality, etc.) they are unlikely to succeed. EA has to be means to an end (strategic alignment of IT, faster delivery) not an end in itself. TOGAF recommends some form of customisation of the methodology to suit the needs of the organisation (and the budget!). Going back to the point above of Views and Viewpoints, the way the architecture output is customised to various audience needs also can make it less academic.
Strong on the how but weak on the what: There is some truth in this in the sense the ADM gives a solid lifecycle of how a typical architecture initiative should be run. But the what – the specific deliverables of each layer – are only mentioned in passing. Archimate to a certain extent addresses this gap in providing meat around what should we focus on as we model each layer. Also there is an art and a science part to the work at each layer including consulting alternative bodies of knowledge specific to each layer (e.g. BIZBOK for business architecture, data modelling and MDM concepts for data architecture, integration patterns for application architecture, etc).
Not agile enough: This is the next gripe against not only TOGAF but architecture in general. They are seen as a hindrance to agile development and implementation practices, not an aid. My experience is quite the contrary. Very rarely software projects in business organisations have the freedom to start from scratch, which is typical of a startup environment. They need to, at the minimum, integrate with other platforms and systems that the organisations already run. There are a host of decisions that need to be made on how the new works with the old – decisions if explored early on and the right level of detail (i.e. B-D-A-T and Security) will only mean less blockers for the agile team. I have seen a number of scrum teams come to a grinding halt (and even wind up) as the builders landed without a master plan of what is being built.
More practical alternatives are out there: This criticism typically acknowedges the need for EA itself but asserts there are better alternatives to TOGAF. Being a serious practitioner I am always looking for cheaper, faster, better ways of doing my stuff and ultimately adding more value to my customers. I am yet to find approaches that match the breadth and depth of TOGAF and if you take all angles into consideration you land up with something similar to TOGAF anyway, in which case you are reinventing the wheel!
Practice of EA 