TOGAF – A Practitioner’s View

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! 

Examples of Business Architecture Principles

Architecture Principles are a key component of Enterprise Architecture. They essentially help navigate to the Target State from the Current State. They are the guidelines component of Architecture.

Principles can and should exist for each of the Architecture Domains – Business, Data, Application, and Technology (and Security if you want to give the attention it is increasingly deserving).

It is easier to develop – or find and adapt – principles in the Data, Application, and Technology domains. For example, the “Reuse before buy before build” is a well-known Application Architecture principle, and rightly so. It has tremendous impact in terms of application choices, both and Enterprise and Solution Architecture levels. It is a pithy aphorism – arguably, even a cliché – that is very practical and translates to a very practical decision tree.

However, a quick search, does not really throw any good examples of Business Architecture principles. TOGAF does provide a list of “business principles”, that are useful but not in the real practical sense. While some provide and overarching guidance (“Primacy of principles” and “Compliance with Law”) others really do not belong in the business domain (“Common use applications”, which is actually reuse before buy/build).

So, what should good Business Architecture principles do? As we alluded to in the opening statement, they should guide the enterprise and solution architectures move towards (and validate) the desired target state business architecture elements.

And what are these elements? Archimate modelling language offers a good choice of these Business Architecture elements: Channels, Services/Capabilities, Processes and Functions, Roles and Actors, Information, Products. In other words, these are the choices we have to make as part of defining the Target State of Business Architecture and this is where we need guidance from related set of principles that guide the choice.

We could hence develop guiding principles around the various business architecture elements. Some examples are provided below.

Example 1

Business Architecture Element: Business Capability

Related Business Architecture Principle

Statement: We will build core sales and marketing capabilities in house and outsource manufacturing and distribution capabilities.

Rationale: Sales and marketing is our strength, and this is where we can differentiate ourselves in the marketplace.

Implications: Hiring more sales and marketing personnel; outsource supply chain functions to service providers.

Comments: Business capabilities are services that the enterprise offers to its external customers and partners and its internal employees. This principle is talking about which capabilities the enterprise will build in house and which it will outsource (as a business). This is the “buy before build” equivalent in the business domain, comparable to the application services choice in the application domain. This principles also provides guidance on roles/actors element – which remain in house and which are outsourced. Presumably from IT architecture perspective, we will have to spend a lot more effort and focus on sales and marketing capabilities rather than supply chain. How can IT drive competitive advantage in sales and marketing (build most likely) and cost reduction in supply chain (buy before build, and minimal customisation)?

Example 2

Business Architecture Element: Business Process

Related Business Architecture Principle

Statement: Where possible, we will use simplified, standardised, and shared business processes across the enterprise.

Rationale: Ease of doing business for both external and internal partners; reduce duplication and optimise costs.

Implications: Shared service processes for finance, procurement, and IT.

Comments: Business processes realise the delivery of business capabilities.  Business process design is the first step in the capability realisation (including building IT components, where required). The guidance is very clear; if we see two different procurement processes in two different business units, for example, we have a mandate to standardise them unless there is a strong business justification.

Example 3

Business Architecture Element: Business Channels

Related Business Architecture Principle

Statement: We will differentiate ourselves in the market place through exception customer service, delivered anytime, anywhere, and through any device.

Rationale: Retain and grow customers through exceptional customer service.

Implications: Build in-person, over the phone, and digital channels.

Comments: Business channels are the avenues through which the customers access the organisation’s services. This principle though ambitious is very clear in stating what channels need to be built. From IT architecture perspective, building digital channels – web and mobile, including chat – are clear standouts. Perhaps, this principle could do with a bit more clarity on what will be offered through digital channels vs phone-in / in-person, the latter have significant business costs.

Conclusion

As we can see these Business Architecture principles – when defined in collaboration with the business stakeholders – provide practical guidance for IT programs (through Enterprise Architecture) and projects (through Solution Architecture) to deliver the expected business outcomes.

Exploring Architecture Principles – Buy Before Build

One of the two pillars of “doing” Enterprise Architecture is the establishment of a set of architecture principles that guide design of systems in the organisation (the other pillar is understanding the system elements or components and their interplay). However, most organisations struggle to establish a coherent set of principles that are practical for interpretation on IT projects. In this and other blog posts I explore such principles; the one for today is the oft loved (and hated) principle of buying before building.

What is the principle?

The principle, in essence, declares the intent that the organisation in question will attempt to buy IT solutions “off the shelf” before starting to build.

Why is it useful?

At the outset this principle appears to be a “no brainer”. Why would anyone want to build an IT system from scratch when one can “plug and play” so to speak, especially considering the horrendous failure rate of custom development projects? While the strategic intent of this view is commendable, the implementation of this guideline is not so straightforward.

Digging deeper

As one starts to look at the application of this principle, several questions start popping up. Should this be applied in all situations? When might build be a better idea than buy? Gartner’s pace-layered application strategy, for example, can be used to answer this question: it makes obvious sense to build the so-called systems of innovation, buy systems of record (with minimal customisation), and customise an off-the-shelf solution for systems of differentiation.

The other angle to this principle is to explore what additional guidance needs to be applied for the kind of buy or build? For example:

Buy

aPaas vs SaaS vs On-Premise

Within aPaas: Multi-tenant vs dedicated instance

Build

Choice of development frameworks / languages / toolsets

Containerised/serverless vs traditional applications

Obviously, the answers for these questions will largely depend on the organisation’s business and IT strategy and the drivers behind these strategies. And it will also depend on other architecture principles such as the appropriate hosting strategy (which cloud?).

A final point to explore in the case of buy-and-customise scenario is how much of customisation to do. For example, if you are customising more than 50% of the product (“bending it out of shape”) then alarm bells should start going off: perhaps the business sponsor had a system of innovation in mind and IT thought they were signing up for a system of record? Or perhaps the choice of SaaS / aPaaS was not a good fit. Also how do you estimate percentage of customisation before the project commences (topic for a future blog post)?

A body, such as the Architecture Review Board – with appropriate representation from business and IT – can deliberate on the specific circumstances of the organisation and arrive at a more practical interpretation of the principle to guide the project or solution in question.

Enterprise Architecture is Dead, Long Live Enterprise Architecture!

Okay, at the outset let me admit the title was a clickbait! Now that I have your interest, I will in this article argue that Enterprise Architecture (EA) long from being dead, is just about maturing into a discipline of strategic importance to all organisations, and I hope the best of EA is yet to come!

I first heard about EA way back in 2006 when I attended a couple of workshops including the one on TOGAF. I remember concluding at the end of these explorations that the field appears promising, but its time has not yet come – at least for me. For, I was working in manufacturing industry and the then IT landscape in such organisations had only a few boxes on the diagram (typically an ERP at the middle).  In hindsight, I would argue EA was relevant even if you had a simple landscape (and ERP by no means is simple, being a core system for a manufacturing organisation). The challenge was mainly seen as a technical implementation of a so-called off-the-shelf software, and that there was nothing there to design (and the rest, as they say, is history).

Fast forward 15 years and the number of organisations seeking EAs is growing, and rightly so, with all the complexities arising out multiple clouds, data proliferation, business complexity, and the speed of change in general. And yet there is scepticism in some quarters around the value of EA. Here are I wish to point out that the issue is not EA itself but our understanding of what it means and more importantly where, when, and how it is done, and also who does it. If the terms why, what, where, when, how, and who do not ring a bell, they are the so called “primitives” that the Zachman Framework for EA advocates. And what better way to explain EA than its own framework? So here we go.

What: So what is EA? As explained in my earlier post, EA as it is commonly understood in the IT world, is the alignment of IT strategy with the business strategy and guiding the IT systems development to align with this overall organisational objectives. However, purists like Zachman treat EA as literally architecting the enterprise – the all of it not just the IT part – essentially as a framework for representing and guiding the design of an enterprise.

Why: So why architect when you can build? I think the Why already follows from the What. Who would not want to align their IT strategy and delivery to the overall objectives of the organisation? Everyone has limited resources and the best outcome from IT spend comes from aligning with – and one could argue, leading – the business strategy.

How: This is where the EA rubber hits the road and this is also where it often skids off the road. EA is best done by understanding the constituent elements (business, application, data, technology) and defining principles that guide the evolution of these elements – the focus is on overall benefit of the organisation not just the individual product, project, or solution.

Who: It is tempting to say that the Enterprise Architect architects the enterprise. However, the reality is much more complex. I have seen in my over two decades of work at the coalface of IT projects, that there are varying levels of design and different domain expertise that can contribute to the overall EA objectives. In effect EA is a team effort. Often a full time Enterprise Architect role can bring these differing perspectives together, but at times it is not affordable (or necessary) as long as there is a mechanism equivalent of the Architecture Review Board to guide the design.

When: The short answer is all the time. But there are some critical points in organisational journey when it is most effective. Core systems replacement programmes are the typical territory of EA. So are times when several interdependent projects are in flight with the need to ensure cross-project design alignment. Finally, any major IT project would benefit from (and will benefit the organisation in turn) aligning to EA before, during, and at the end of the project. Special callouts to agile projects that prefer to “design on the fly” that may result in “operation successful, patient dead” outcomes.

Where: EA is a function that typically sits in IT under the sponsorship of the CIO, which makes sense considering that the bulk of EA’s attention is on getting the design right for all the IT programmes. However, in not so distant future I am predicting it will sit under the sponsorship of the CEO as more organisations see the blurring of the distinction between technology and business – particularly in service-based organisations.

What is Enterprise Architecture?

Enterprise Architecture (EA) is often seen as too complex and academic to be of practical use in business settings. Sure, a formal vocabulary is unavoidable when describing a generic framework, but at the core of EA is alignment of IT strategy to the business strategy.

So let us start with some basic definitions. What is an Enterprise in the context of EA? It can be anything – a single business unit, a collection of business units or just a single department. Preferably it is the “entire” organisation, but in practice, it can be whatever the organisation in question wants to apply the EA rigour to. As for Architecture, I think the best definition is the one provided by TOGAF: “A formal descripton of a system, or a detailed plan of a system at a component level to guide its implementaton.”

So what then is EA? Again TOGAF gives a simple definition: “Enterprise Architecture provides a conceptual blueprint that defines the structure and operation of an organisation.” The intent of EA is to provids a strategic context for IT to evolve and support the business strategy.

Whether organisations formally embrace EA or not, the reality is that their IT is always evolving to its business strategy and needs. But instead of leaving this evolution to chance and point decisions, EA can provide a framework to avoid the “spaghetti” state. In this context, EA is often cited as analogous to town planning. A well planned town is a delight to visit and live in. On the other hand a collection of badly built (even with a few individually well designed) buildings often results in a mess that prevents the growth of a city from evolving into what it could potentially have been.

With this strategic intent, the EA becomes more of an investment than a cost. The EA outputs are no longer a necessary evil but valuable foundation for a sound enterprise. The business strategy is formally defined first (Business Architecture) which defines and drives IT Strategy (Application, Data and Technology Architecture). The principles and guidelines drive the solution designs in individual IT projects, reusing the building blocks already delivered. Also by following a formal architectural development method (like the TOGAF ADM) and a governance structure (Architecture Review Board), organisations further increase the chance of a coherent IT evolution that is not left to chance.