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

Part IV – Architecture Content Framework

This section is really about two things – how we describe the components and configuration of architectures; and how we describe them in artifacts or deliverables.

The architecture content framework, the metamodel and the building blocks all work together. The metamodel is the formal way of describing the types of building blocks, and the content framework provides various ways of visualizing the various components and how they work together. This part of TOGAF is frequently ignored by practitioners – for a number of reasons. The chief reason is that many large EA teams use a dedicated EA repository tool to manage information about architectures, and these tools often come with their own metamodel, as well as having the ability to generate reports and diagrams. Some of these tools base their metamodel on TOGAF, or have an option to use the TOGAF metamodel; others have a different metamodel.

So here are two key points, which are currently overlooked by TOGAF. Firstly, a good metamodel is crucial to developing good enterprise architectures; the metamodel needs to be the right one (not one dictated by TOGAF or a tool vendor). Secondly, the metamodel must be capable of representing the views and viewpoints of all stakeholders. Instead, the TOGAF metamodel is presented as something that is much more rigid and dogmatic.

In TOGAF 10 I would like to see more guidelines on how to create and how to use an Enterprise Architecture metamodel. This would need to include the concept of different meta layers, and explain the use of an EA metametamodel.

It would also need to show how a metamodel can, and must, cover different views and viewpoints. For example, the current configuration of an architecture might be quite radically different from the target state – so both options need to be contained within the metamodel.

These issues and problems are not unique to TOGAF: most consultancies and tool vendors present metamodels that reflect their origins in IT, enforce pre-defined structure, or allow only single-views and viewpoints. This renders them unsuitable for many contemporary EA needs.

I would also like to see more guidelines on how to use frameworks in general, and content frameworks in particular, as these are a vital tool for visualizing, managing, and reusing EA artifacts. There are far too many EA teams that create a separate document for each project, and then miss out on the opportunity to reuse both artifacts and building blocks.

Which brings me to the next two points about improving Part III:

• TOGAF 9.1 refers to many of the deliverables as if they are documents (the Architecture Definition Document is one good example). A document should only ever be used as a vehicle to package EA artifacts and arguments for a specific audience at a specific time. Enterprise architectures are very complex and change rapidly – and it is impossible to update documents at the same pace. Instead, TOGAF 10 could emphasize that many deliverables are transient containers of information, and that the real value lies in the more modular artifacts.

TOGAF Series #43 | ATL002:43

© 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

• The example artifacts in TOGAF 9.1 are often dated or oriented towards technical or IT audiences. Instead, TOGAF 10 should include examples of artifacts that genuinely present architectural information. It would also be useful to know when example artifacts are appropriate and when they are not. For example, TOGAF refers to value chain diagrams – which are relevant to reflect a supply chain business model, but which don’t help understand the underlying architecture of a value network of business capabilities.

Finally, the Content Framework in TOGAF 10 should include the organization domain, and domains that lie beyond the traditional enterprise boundary, such as environmental and social architectures.

What will actually happen in TOGAF 10? This I am not sure about. The Open Group are also responsible for other standards that include metamodels – such as ArchiMate – and it would make sense for them to have an integrated overview showing how these various metamodels relate to one another. Although it would be nice to see a greater focus on how EA metamodels are created and used in the next release, it is more likely that TOGAF 10 will simply be a rationalization of existing materials drawn from TOGAF 9.1 and ArchiMate.

Part V – Enterprise Continuum and Tools

This is a section in the TOGAF documentation that often causes confusion among students, which is a pity because it includes some useful, if misunderstood, concepts.

The Enterprise Continuum is basically about reusing EA artifacts and components that are produced outside the enterprise boundaries. This is a really important concept – and it will become increasingly so as enterprises are based on, and rely more and more on, external components. For example, why would an enterprise create its own architectural data model if there was a common, industry data model that it could use instead? This is covered by the enterprise continuum.

But the enterprise continuum in its current form doesn’t explain how you reuse external resources, how you maintain a trace to them, or how you synchronize any enterprise-specific variations or customizations based on external resources.

TOGAF 10 could do a much better job of explaining the vital role of the enterprise continuum. It could also show how the enterprise continuum extends within an enterprise, to include business divisions, segments, domains, or projects. Also – a more sophisticated version of the enterprise continuum could show how geographic, cultural or other social components fit into the bigger picture.

The chapter on Architecture Partitioning can come across as complicated and theoretical. Instead this could be rewritten to explain exactly how and why architects partition an enterprise architecture, and then, how they manage these partitions as part of the whole.

Finally, there is often confusion about how to use chapter 41, Architecture Repository. There is actually a lot of useful material here, but it needs to be better integrated with the concept of an Content Framework and the material on the metamodel – which is currently in a different section of the documentation.

Part V is also closely related to Part VI.

Part VI – Reference Models

TOGAF 9.1 includes two reference models, and they meet with varying degrees of approval. Some EA teams think they are a great basis for developing their own enterprise-specific versions, while others feel that they are outdated.

Both models provide something that isn’t normally emphasized in the TOGAF documentation, or in training courses, which is that they are examples of how to document a reference model. It would be useful if TOGAF 10 had a separate description of the comment elements and possibly a template for documenting a reference model. For example, the key elements included in the Technical Reference Model (TRM) and the Integrated Information Infrastructure Reference Model (III-RM) are a taxonomy and graphics that show architectural layers and configuration.

© 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

Why would it be so useful to explain reference models at this higher template or meta layer? Well the key reason is that there are already many, many reference models – apart from the two provided in TOGAF. They are produced by vendors, consultancies, consortia, and others. Some are domain-specific, while others have a more general scope. But the dilemma is that each of these reference models has been produced in isolation. (The two reference models in TOGAF are an exception, and one of their strengths is that it is easy to see the structural similarity between the two models.) This isolation makes it very difficult to combine or integrate two or more reference models. TOGAF 10 could describe templates, guidelines and best practice to show to integrate various reference models from different sources.

The enterprise continuum provides some of the key concepts for this but they are not very clearly explained in the current documentation. TOGAF 10 could explain the enterprise continuum in the context of a more widespread use of reference models and patterns.

Because there are so many reference models, it would also be very useful if TOGAF 10 included a list of the most important or useful. This could be classified into the various categories of the Enterprise Continuum. For example, this would include a range of industry architecture reference models categorized into industry sectors, such as banking and financial services, travel, or healthcare.

Once again, because this is a rapidly evolving area for enterprise architecture, it might be better if this resource was provided online, rather than something included in a particular release of TOGAF. The problem with including a list like with a particular release is that practitioners then have to wait a long time for the next release, and update, of the list.

A potential role for TOGAF 10 is therefore in providing clear guidelines for creating, integrating and using reference models, together with links to the wide-range of models that are currently available.

What is likely to happen in TOGAF 10? I expect that TOGAF 10 will retain the existing two reference models, and possibly add some additional reference models, but I am not so sure that it will provide the overview that is sadly lacking.

Part VII – Architecture Capability Framework

Which brings me to the final Part of the current documentation – the Architecture Capability Framework. Establishing the capabilities of an EA team, embedding the discipline of EA within an organization, making sure that changes comply with architectural guidelines, having the appropriate governance in place… all of these are very important for a successful EA practice.

The material in TOGAF 9.1 is good as far as it goes, but there are some significant gaps that could be addressed in TOGAF 10, and there are some areas that are confusing which need to be updated.

For example, it is important to establish the right governance and compliance procedures to ensure that architectural guidance and directives are followed; but the explanation of the terms used in compliance (Section 48.2 Terminology: The Meaning of Architecture Compliance) befuddles many students, while the approach to architecture compliance reviews is unwieldy.

To rectify this TOGAF 10 would need to explain the difference between versioning at the building block level and versioning at the level of patterns or architectural states. TOGAF 10 could also explain exactly how compliance works, through worked examples that showed the trace from concerns and requirements through to individual building blocks and patterns.

The current documentation largely talks about ensuring the compliance of individual projects. While this is necessary, too much focus at this level alone can mean losing sight of the bigger architectural picture.

Furthermore, when compliance is undertaken as a process of reviewing solutions for conformance through checklists and policing, it can quickly gobble up all of the EA team’s resources. Instead it is better to switch things around, so that instead of the EA team policing changes, the change teams are required to justify exceptions from the defined architecture. At the very least, TOGAF 10 should describe both options and explain why the traceability and exception approach is more effective than the continuous monitoring approach.

The maturity framework could also be improved with TOGAF 10. For example, nine architectural elements described in the current chapter on architecture maturity; but this list may not cover critical elements, such as the use of architectural thinking and EA techniques. It might be useful to have a more comprehensive list of potential elements, that were then selected according to need for assessing the maturity of a particular enterprise.

© 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

Finally, as mentioned earlier, the Skills Framework does not currently list many of the fundamental skills in EA – such as the ability to describe architectural constraints, the ability to create and use frameworks, or the ability to separate concerns. It would be good to find a more comprehensives list of EA skills in TOGAF 10.

What is likely to change in this Part? There are many other improvements to TOGAF that arguably have a higher priority than the Architecture Capability Framework, so regrettably I do not predict many changes to this section, other than some refinements and minor changes.

Conclusions

I’ve covered a lot of material in this article – so it’s useful to summarize the key points:

• There is plenty that could be updated and improved in TOGAF 10; the new version is likely to have some good new material, and there will be refinements and improvements to existing content. But there will always be more that could be done, and the process of creating a new release of TOGAF is necessarily methodical, but slow.

• Because every enterprise will need to customize TOGAF to meet their exact needs, it would make more sense to view TOGAF 10 as a Body of Knowledge, separated into background information and theory about Enterprise Architecture and useful day-to-day tips, tricks and practice.

• The ADM could be streamlined as a generic architecture development process. Information that is domain-specific could be extracted and built up into a library of topic-specific material.

• Guidelines for using the ADM could be simplified; the existing techniques could be extended to include the basic EA techniques.

• The content framework and metamodel could become a resource that is more easily adapted and customized to specific needs.

• The enterprise continuum and reference models could become a really effective way for architects to collaborate and reuse key artifacts and building blocks.

• The processes for compliance and governance could be simplified. The development of maturity, capability and skills could be extended to cover more EA-specific areas.

When I was very young I remember being disappointed when I didn’t get something that I longed for as a birthday present. Nowadays I am a lot more realistic. And so it will be with TOGAF 10. There is plenty that I, and many others, would like to see in the new Release.

I am sure that when TOGAF 10 appears it will be a mixture: we may get what we would like; we may get something unexpected which is what we needed; and we may be disappointed. But then there will be TOGAF 11….