Why I Still Like TOGAF

Why I Still Like TOGAF

In the Beginning

When I learned about TOGAF sometime in the early 21st Century, I recognised it immediately – even though it was new to me.

I guessed someone had observed my methods for the last 25 years and created a standardised way to apply them. That’s not exactly what happened, of course. But it’s partly true, in the sense that TOGAF aggregated an evolving set of best practices used to plan, design, understand and manage software, especially complex enterprise software at scale, and I was one of the practitioners in that mix in the 1990s.

puzzle piecesIn the decade before TOGAF was being born in 1995, I had led design and delivery of a half dozen first-of-a-kind enterprise systems. As the projects became increasingly large, the value of good holistic, well-documented design became increasingly obvious to me. That value scales up with complexity, and not in a linear manner. This was always the point of the thinking that created TOGAF and other architecture frameworks and methods – or at least the part I recognised as reflecting my own way of working to deliver business change based on IT and OT innovation. It is based partly on the recognition that in a nontrivial enterprise:

  • A holistic, abstract model of the fundamentals of the business as well as its transitory needs for change – and how these fit together – should be the starting point for investing in change and measuring its value.
  • This map of How Everything Fits Together in the enterprise, which is only partly about technology and which belongs to the business, is constantly changing in ways that can never completely align to changes in the technology environment.
  • New system designs that ignore this will create massive, ongoing integration challenges and significant technical debt, and thus will be inherently and increasingly more unstable than holistic design.
  • Almost every deployed system only exists in a matrix of other systems, all of which are changing constantly if only because the lower levels of their tech stacks keep going out of date.

An important job of the enterprise architect was and is to manage those business and IT maps as well as possible, to keep them reasonably aligned and to ensure a holistic, logical investment approach while everything is changing. TOGAF described a formal method for putting these insights into practice in a repeatable, understandable way, adding much value (along with others such as Zachman) as part of the community’s manifestation of the Holistic Architecture meme.

The Old and the New

By 1995 I was working out the IBM Labs in Hawthorne, where our team was trying to understand how a very large IBM data and process model called Insurance Application Architecture could be deployed effectively into the emerging world of OOA, OOD and very interestingly (and mostly disappointingly) OODB.

bunny in birdcage guarded by parrots

Controlling the Wild Coder

Why was our team focused on the transition to object orientation and model-based software design? Partly because OO solved some interesting technical problems that were very difficult and in some cases impossible in the world of procedural code and entity-relationship data modelling. We were fired up about Grady Booch and Hofstadter’s Godel, Escher, Bach: An Eternal Golden Braid and Design Patterns by Gamma, Helm, Johnson and Vlissides).

Partly for market reasons. OO and models and methodologies were important Shiny Objects for CIOs and developers, just like Agile and DevOps today. Vendors needed a story and, if possilble, products. These were popular topics energised by the idea that adoption would reduce the opportunity for developers to create untraceable bugs, integration nightmares, operational vibrations, and undecipherable code (OO code was going to be self-documenting, apparently). Part of the appeal of OO in particular was the idea that by encapsulating code and data, you could somehow encapsulate bad programming in a way that protected everyone else, sort of like imprisoning an immortal demon in a perpetual force field. And OO advocates persuaded many that we could transcend the expensive, slow, rigid, value-blind behaviour of the older generation of developers by freeing developers to just get on with the job and deliver great code overnight.

In the background of this debate was an explosion of development tools, methodology evangelists, and new ways of modelling that could perhaps be plugged into code generators, or at least that could provide traceability between imagined and delivered systems.

The Never-Ending Debate

Two people arguingTwenty years on, we have agile and DevOps and Continuous Integration and Continuous Deployment. We have cloud and more cloud. Low-code and no-code platforms such as SalesForce and ServiceNow and Pega have great traction.

And we have TOGAF 9.2, still part of the conversation. All still attack the same problem – striking the balance between urgently needed quick-and-dirty delivery on the one hand and on the other hand, effective management of security and technical debt and integration and operational stability. Some are fond of saying that Enterprise Architecture is a dead letter and TOGAF is finished.

I disagree. Most of those saying this loudest are making the old mistake of equating EA with software architecture, which is not the same thing. It’s very instructive that fewer EAs and Business Architects report the CIO. This is because while the application of TOGAF-style thinking should govern important IT investments, and can radically improve the ROI of software investments, TOGAF and EA are not ultimately about software development. They are about business value. Without the sort of formal methods and agreed semantics represented by things like TOGAF, there is no real hope of reducing chaos, cost and risk in large-scale IT. This must somehow be done while enabling innovation and artistry in areas where it’s actually valuable and enabling the quick delivery cycles promised by the Agilists.

Many enterprises try to dodge this bullet by outsourcing a lot (or all) of IT. They are outsourcing problems they couldn’t solve themselves (encapsulation) but doing nothing to reduce the world’s supply of friction between the need for agility and the need for governance. And you can’t outsource responsibility for your own bottom line. Increasing the variety in suppliers only makes understanding the holistic design of your own organisation more important. Now you must replace complex communications once based on tribal knowledge with formalised communications codified in contracts. TOGAF still has a lot to offer to all the parties in this game as a way of managing a disciplined holistic view of how things work, how the fit together, and how they might best be changed.

Still in the Game

Man looking at papers on boardThe effects on business strategy and governance of digitization, outsourcing, cloud, mobile, IoT and IT/OT convergence are creating a new context in which it clearer than ever that Enterprise Architecture, using methods like TOGAF, is a fundamental business discipline for managing disruption and value. There are flaws in TOGAF and its extended family (MODAF, PEAF and all the rest). And not all EA efforts succeed. EA practitioners sometimes make themselves irrelevant by embracing absurdly rigid practices or boil-the-ocean-before-we-start approaches. Sometimes organisational culture is so anti-design and anti-systems thinking that the EA has no chance.

But on balance, TOGAF has done much more good than harm, can be used effectively in spite of flaws and is needed in the modern world. So I still like TOGAF, in spite of its weaknesses (yes, some are significant). We need this kind of thing to help us make sense not just of IT but of most businesses. I liked it before I knew about it, and still do.

What is TOGAF Essentials 2018?

What is TOGAF Essentials 2018?

Be Sure Your TOGAF 9 Certification Is Up To Date

The release of the TOGAF® Standard, Version 9.2 left people asking whether a TOGAF 9 certification earned many years ago is still valid. The answer is yes. But employers and customers may well ask whether the practitioner is actually up to date. That’s where the TOGAF Essentials credential comes in. The Open Group‘s TOGAF® Essentials 2018.credential is designed to let you answer that question in the affirmative. The half-day training is a quick bridge to TOGAF v9.2 knowledge. It is available to all current TOGAF 9 certified individuals and covers the key differences between versions 9.1 and 9.2. After the training you receive a link to the Open Group’s 20-question online assessment. A passing score earns the TOGAF® Essentials 2018 badge, demonstrating your commitment to staying current with TOGAF. The badge shows you are up to date on newer TOGAF features, and adding the badge to your CV, LinkedIn profile, etc. demonstrates your achievement. TOGAF Essentials certification supports career advancement, whether in your own firm or in others. Instructors for accredited TOGAF 9 training are required have the TOGAF® Essentials 2018 credential.

TOGAF Essentials Covers New TOGAF v9.2 Features

These include a wide range of changes including:

  • Refactoring the TOGAF Body of Knowledge structure
  • Changes to support modern DevOps, agile, cloud and platform-based environments.
  • Significant extensions (such as Capability, Value Stream and more) and updates to the content metamodel
  • Updated and simplified definitions of key terms, more aligned with other EA standards
  • Restructure of the TOGAF Body of Knowledge

CC&C’s TOGAF® Essentials 2018 training is live online instruction.that includes the standard course backed up by professional insights from one of our experienced architects. CC&C training also includes after-course support from the facilitator should you have questions about the content or the certification process. All of our TOGAF Essentials students have passed the exam and now have the updated credential. More importantly they are up to date when using TOGAF on the job, aligned with current tools, definitions and ADM changes.

Changes to Risk and Security Guidance

This includes much-expanded and updated Security Architecture guidance, which is found in the new TOGAF Series Guide,Integrating Risk and Security within a TOGAF® Enterprise Architecture.

Enterprise and Security Architectures

TOGAF 9.2 view of Enterprise Architecture, InfoSec and Risk Management (c) The Open Group

Value Streams and Business Capabilities

TOGAF 9.2 also fully supports the use of business capabilities and value streams in Business Architecture modeling. This moves TOGAF in line with modern practice, which often prefers this approach to process modeling as a starting point. TOGAF value stream stages This illustration is an example of mapping business capabilities to value stream stages. It adds a heat map overlay as a way of showing which capabilities need attention in order to support the value stream. The TOGAF Essentials training explains how these concepts fit into the updated TOGAF ADM, and where to go for more in-depth information on using these in business architecture work.