TOGAF 10 – Conjecture and Hope (Part 1 of 2)by Roger Evernden

What would you like for your birthday? What did you actually get? Sometimes we are lucky and we get what we would like; sometimes we get something completely unexpected which turns out to be just what we needed, even though we hadn’t thought of it; and sometimes we are disappointed.

Speculating about what might be added or changed in the new version of TOGAF, and what we hope will be in the next version (i.e. which areas of TOGAF 9 we think could be improved) reminds me of birthday hopes and disappointments. In this article I’m going to give you my thoughts on what could be improved in TOGAF, and how that could be achieved.

And I’ll also talk about what I think is likely to happen in the next major release of TOGAF - TOGAF 10.

But before I go on, I should emphasize that this article is simply conjecture and hope!

Part I - A Body of Knowledge

I’ll start by looking at what TOGAF is, and what it isn’t. I don’t think many people would argue with the claim that it is a “de facto global standard for Enterprise Architecture” – in the sense that it is well-established and that TOGAF certification is frequently taken as a starting point for training as an enterprise architect. However, it’s important to remember two things here: firstly, it is not the only source of information about EA techniques and practice; and secondly, it must be tailored or customized to meet your exact needs.

In other words, it is not a standard in the same sense as the International System of Units (abbreviated SI) which defines the metric system used in science, industry, and medicine. TOGAF is really more a Body of Knowledge, and so the next version is likely to be equivalent to a new edition of a book. Now I’ve recently gone through the process of writing the second edition of a book [1], and I know that it is a major undertaking. I also know that it takes a lot of effort to restructure and incorporate new material. And the Open Group not only have to go through this process to get a new release of TOGAF, but they also have to take into account inputs from many different authors and sources.

As a Body of Knowledge I therefore expect TOGAF 10 to be very similar to TOGAF 9.1. The core documentation will probably be presented in book format, with similar sections and chapter headings to the current release.

What would I like to see? I would like a separation between the background information – which explains the theory and ideas – and the practical step-by-step guidelines and templates. This would make the distinction between stuff that enterprise architects need to know about and the reminders, checklists, and tips that help in the day-to-day work of architecting. The background information doesn’t change as much, and in many ways it might be better covered by including a recommended reading list. The tips and tricks of the trade would then be more accessible for daily use.

I’ll comment about specific sections of the documentation as you read through the rest of this article.

TOGAF Series #42 | ATL002:42

© Copyright 2016 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd. The Open Group® and TOGAF® are registered trademarks of the Open Group in the United States and other countries

© Copyright 2016 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd. The Open Group® and TOGAF® are registered trademarks of the Open Group in the United States and other countries

Part II - The Architecture Development Method (ADM)

The ADM has always been considered the heart of TOGAF, and it is certainly pervasive throughout the documentation.

It would be great to see a layout that simplified the material here. For example, it is often difficult for newcomers to TOGAF to grasp the flow of artifacts and documents through the phases of the ADM. The existing input / output lists could be supplemented with simple graphics to visualize this flow.

There is also a lot of duplication in the ADM – especially in the core Phases covering development of the architectures – Phases B, C, and D. These 3 Phases cover the bulk of what I would call architectural thinking and understanding; the remaining phases are largely about linking this work to the demand (Preliminary, Architecture Vision, and Requirements Phases) and supply (Phases E to H) side of the value chain.

For example, it is clear that the steps for each of these four phases are almost identical. [Yes – I know that I only listed phases B, C and D – but remember there are separate chapters for Application and Data.] The only major difference between these chapters is that each covers a different architectural domain. Now TOGAF currently refers to the Business, Data, Application and Technology domains, and sometimes to the data and application collectively as Information Systems. In practice, there are additional high-levels domains – the two most common being Organization and Environment; and many sub-domains, such as Process and Product as sub-domains for Business, or Network and Hardware as sub-domains in Technology.

What could TOGAF 10 do to simplify this? Well it could have one chapter that outlined the basic process for analysing any architectural domain, with tips and guidelines for adapting this common process for any architectural domain. Oh, and when I mentioned the four architectural domains currently in TOGAF, a simplified approach like this would also apply to the Security domain that is currently included in TOGAF in another separate chapter.

What would happen to the domain-specific content? Well this could be extracted and documented separately. Reference models for each domain could be provided as checklists, and because of the current fluidity in architectural reference models, this could be maintained more easily as an online resource – rather than hardwiring it into the TOGAF documentation.

I would also like to see a lot more tips and tricks from experienced architects throughout the ADM. The current process tells you what architects typically do, but doesn’t really explain how they do it. For example, in Phase D Technology Architecture the current documentation suggests that we “define a taxonomy of platform services and logical technology components (including standards)”, but TOGAF never explains exactly what a taxonomy is or how to go about creating a good one.

What is likely to happen to the ADM in TOGAF 10? I suspect that there will be little change to the overall structure and content of Part II – ADM, and that what does change is a refinement rather than a significant update.

Part III - ADM Guidelines and Techniques

Most of my clients cite the ADM as providing the most useful part of the current version of TOGAF. Part III of the documentation needs to be used in conjunction with the ADM itself.

I would like to see some improvements in the way that these two sections work together.

The sections about applying iteration to the ADM and about applying the ADM at different enterprise levels are awkward. What they are basically saying is that the processes of architecting an enterprise are often rather random, ad hoc, and iterative, and that architects need to paint a big, holistic, long-term picture and then manage the strategic vectors to achieve this through a wide variety of different projects that may take place simultaneously, sequentially, or in parallel with one another. OK – that was a bit of a mouthful. But put more simply – architecting is not a simple, sequential, waterfall type of process.

How could TOGAF 10 explain this better? Most architects work within a flexible process framework, but they generally govern this process through artifacts and deliverables. It is difficult to show how architects leap from one task or step or phase to another using a process flow. Instead it is easier to visualize and manage these ping-pong activities through a content framework, or using a framework that is a matrix between process and content. This would eliminate much of the confusion that students feel when they learn about iteration and enterprise levels from the current documentation.

© Copyright 2016 Good e-Learning. All rights reserved. No part of this publication may be reproduced, resold, stored in a retrieval system, or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior permission of the copyright owner. Such requests for permission or any other comments relating to the material contained in this document may be submitted to: marketing@goodelearning.com. Good e-Learning is a trading name used by

Educational Systems Ltd. The Open Group® and TOGAF® are registered trademarks of the Open Group in the United States and other countries

Now I mentioned earlier that it would better to have a single, generic ADM process that covered any architectural domain. This would therefore require some additional chapters in Part III, to explain how a single ADM architecture development phase could be adapted for specific domains. I would like to see the Security chapter simplified along these lines, and then to see additional chapters for the core domains: environment, organization, business, data, application, and technology; and for important sub-domains, such as product, process, capability, or service. This latter would be an adaptation of the current chapter 22, Using TOGAF to Define and Govern SOAs.

The next change in Part III would be to include some EA techniques! TOGAF documentation is currently weak on describing even basic EA techniques. For example, it doesn’t explain exactly how you customize or use a framework; it doesn’t explain how you use a large number of frameworks within an overall metaframework; it doesn’t integrate the core concept of patterns; and it doesn’t explain how to create or use a taxonomy or an ontology, how to separate concerns, how to layer or segment an architecture, or how to design for adaptability.

Most of the existing techniques are general management or business techniques, used in an EA process. And there are many more of these that are easily be adapted to EA use. Some of the techniques that are in common use include the Business Model Canvas, or the use of Business Models and Organization Design Models. Enterprise Architects use a wide variety of techniques, drawn from disciplines such as systems thinking, software engineering, information design, change management, and of course, building architecture. Most of these are not included in TOGAF.

In summary, the new TOGAF 10 Part III would be divided into:

• Techniques for Coordinating Multiple Projects Across the Enterprise

• Techniques for Using the ADM with a Content Framework

• EA Techniques

• Other Useful Techniques from Management, Business or other Disciplines

The reality is probably that the new Part III will be somewhat similar to the current documentation, with the possible addition of some new techniques or refinements.

1 http://www.amazon.co.uk/dp/1517364361 - Enterprise Architecture - the Eight Fundamental Factors, by Roger Evernden and Elaine Evernden