What TOGAF is and is not

Well done! ?That's right! ?Agree with it. ?Well said. ?Loved your article. ?Very well written Graham!! ?Great article! ?Absolutely spot on.?Well-considered [and agree wrt] SAFe.

A comprehensive architecture framework offers advice on processes, products and people. TOGAF offers a large menu of processes and products, and says a little about the roles of people. I say more about the processes and products below. This article starts with ten things that TOGAF is not.

Ten things TOGAF is not

1 TOGAF not = TOGEAF

TOGAF is a general architecture framework, rather than purely an enterprise architecture framework.

Enterprise architecture is work to define and advance the architecture of an enterprise’s business activity systems, in coordination with business planning.

The enterprise is the scope of business activity you are sponsored to address by business directors.

The architecture is the structure and behavior of systems in which regular activities create and use business data, and are enabled and integrated by information flows.

Systems are described at a reasonably high level in EA, and in more detail in particular solution/project architectures.

TOGAF version 9 was generalized for use at three levels:

• enterprise/strategic architecture
• segment architecture
• capability/solution architecture.

Since the ADM is often used at the capability/solution architecture level, using it does not imply making radical “enterprise transformation”. It does however imply designing and planning substantial changes to one or more business activity systems.

For more, see this article "EA today ".

2 TOGAF is not prescriptive

You aren't meant to "implement TOGAF" as a whole. TOGAF gives you a menu of processes and products to select from. It is a framework for many things its many contributors have found useful - some of which you might choose to do. You are supposed customize it, select what you need, and merge them into your processes for PMO, Business Change and IT Services Management.

3 TOGAF is not strictly sequential

The Architecture Development Method (ADM) looks sequential. Without iteration, the process might be distilled as.

1. Phase A: Envision target - as in a feasibility study.
2. Phases B, C, D: Design target system(s) - wrt baseline systems.
3. Phases E and F: Plan system development and implementation.
4. Phase G: Govern system development and implementation.
5. Phase H: Govern changes to system(s) in operation.

But the ADM is in fact highly iterative - between cycles, within a cycle and within a phase of each cycle. Overlaid on the process there is:

• Continual iterative requirements change management.
• Iteration of Design (B-C-D) and inside each phase of it.
• Iteration of Planning (E-F).
• Iteration of Governance (G-H).
• Iteration of the whole process (A-H).

4 TOGAF is not an education in architecting

It is a management framework for programs and projects in which architects play a leading role. The core is the ADM process (above) for architecture-intensive "transformation" work, which incorporates most of Herbert Simon "design thinking" principles.

5 TOGAF is not limited to architecture definition

It touches on management topics such as stakeholder management and risk management. It addresses architects’ roles in planning change projects (phase F) governance of system development (G) and steering of subsequent change requests (H).

6 TOGAF is not only about IT

For several years, TOGAF was an IT architecture framework, focused on rationalizing a messy estate of infrastructure technologies.

TOGAF 7: "to be clear about what kind of architecture TOGAF is aimed at supporting. [Of] four subsets of an overall Enterprise Architecture [business, data/information, applications and IT], TOGAF is designed to support the last." TOGAF version 7 FAQS

Today however, TOGAF is about business roles and processes that create and use business data, and are or can be supported and enabled by IT, the business application portfolio is a central artefact.

TOGAF 8: shifted its focus to business, data and applications architectures. It told you to address business goals, roles and processes (phase B), before data and applications (C) and platform technologies (D). In each phase, you map the deliverable back to the overarching business mission, vision, drivers and goals.

TOGAF 9: revised some phases and boosted the content framework. Version 9.2 dropped most of what remained from TOGAF 7, and inserted content (adapted from BIZBOK) into the Architecture Vision and Business Architecture phases. This created a hodgepodge of terms, concepts and techniques, and obscured the structured analysis and service-oriented principles formerly used.

TOGAF 10: Modularised TOGAF and extended related guides in the TOGAF library. Various elements were renamed for compatibility with ArchiMate and other sources.

7 TOGAF does not differentiate architecture from design

Higher-level architecture is done in phases B, C, D; lower-level is done in phase G. However, what higher and lower mean depends on the scope and level you are working at. Architects working to different visions, at different levels of abstraction, may produce very different products.

8 TOGAF does not necessarily deliver “an EA”

Unless you do what it suggests, which is to define your EA meta model and extend your EA repository incrementally in each ADM cycle. Your CASE tool vendor can advise on that.

For more on EA meta models, read this article on EA vision and reality.

9 TOGAF certification is not a passport to a job

Though it might help you to get an interview, since recruiters use it as a filter. Like similar certification schemes, the examination tests your knowledge of TOGAF itself, rather than your skill or experience.

10 TOGAF is not entirely consistent and coherent

It is a framework for contributions written by the members of the Architecture Forum hosted by The Open Group. The quasi-democratic crowd-sourced process for developing content leads to inconsistencies and incoherencies. If you want consistency and coherence, then see "Further reading" below.

Criticisms of TOGAF often reveal naive customer expectations. TOGAF is a menu of processes and products that some individual member of The Open Group Architecture Forum has found useful, and some other members have voted as acceptable.

TOGAF is free to read. Nobody gets paid for contributing. Nobody imposes a consistent and coherent ontology on contributors. Users are supposed to be architects who select and tailor processes and products relevant to their work.

BTW, TOGAF certification does not require you to spend a lot. For guidance on self-study try the advice you can find behind a link on the Training Calendar at https://avancier.website .

The process

To simplify the picture, the ten ADM phases are grouped below under 4 broad headings. You may treat phases A to F as a “big up front” design and planning process, but how much time and money you invest in each phase, and the level of detail produced, are scoping decisions made at the start, and revisited as need be.

Initiation – produces requests for architecture work and outlines of what is to be done

• Preliminary phase
• A: Architecture vision
• Requirements management (continues throughout).

Architecting – produces architecture definition documents

• B: Business architecture
• C: IS (data and applications) architecture
• D: Technology (platform/infrastructure) architecture

Planning – produces architecture road maps and PMO-type plans

• E: Opportunities and solutions (badly named)
• F: Migration planning

Governance – monitoring and steering of delivery and change

• G: Implementation governance
• H: Architecture change management

The graphic below positions TOGAF's ADM process in a wider context.

The products

TOGAF suggests many products by way of deliverables and artefacts, which may be produced during the ADM process. The products are classified as

• deliverables (documents), which contain
• artefacts (catalogs, matrices and diagrams), which contain and relate
• building blocks (architectural entities).

The reduced and simplified version of the TOGAF meta model below includes and relates some core architectural entities.

Service-orientation

In TOGAF, "architecture requirements" include business and application service contracts. In the layered client-server structure outlined above, in each layer, components perform processes to deliver services to each other and to components in the layer above.

• Business layer: External actors invoke business services that result from business processes performed business components. More logical business components (functions/capabilities and roles) are realized by more physical business components (organization units and actors).
• Applications layer: Business components invoke application services (use cases that store and retrieve data) provided by application components.
• Technology/infrastructure layer: Application components invoke platform technology services (transaction start and commit, http get/put/post/delete, encryption, etc) provided by technology (generic infrastructure, software or hardware) components of which users are unaware.

Note: since TOGAF does not entirely conform to ISO 42010 (and that is a little confused anyway) the words “viewpoint” and “view” are often confused with “model kind and “model”.

Note: there is no explicit attempt to coordinate the artefacts, or pin down how they are documented (UML, ArchiMate, IDEF, whatever). However, if you tidy up the meta model, you can map the artifacts to sections of that meta model, as I show in this article on EA/BA terminology .

Remarks

Herbert Simon wrote of design as a science or way of thinking in “Sciences of the Artificial” (1969). Most of Simon’s "design thinking" principles appear in most modern design methods. TOGAF is no exception, as discussed in EA principles applied in TOGAF

Yes, TOGAF is overblown and frustrating in several ways, but it can still be used as a vehicle for teaching architects. Comments from a private course include:

• "Thanks for the very enjoyable course last week - a refreshing change from my first experience of TOGAF training a few years ago. You did help to make this much clearer and more tangible for me."
• "I enjoyed it. Even though I have been doing a lot of the right things over the last few years the course and TOGAF framework brought it all together. So I was able to not only pass the exam but better appreciate how we can apply TOGAF going forward. A very good course structured to convey the subject in an interesting and practical way."

In my view, EA work sits at a higher level than much of TOGAF. So if I was to write an EA-specific framework it would be shorter and higher level. And I might well advise against unrealistic expectations of what EA can achieve in what is often a volatile political or business environment.

Further reading

If you want to read this article in the context of a book, watch this space. Related articles include:

• EA method history
• On Zachman's framework
• On TOGAF
• On the ISO 42010 standard

My other Linkedin articles include an article on an architecture value stream that gives an alternative way to map TOGAFs ADM to enterprise and solution architecture.

If you want consistent, coherent and practically useful framework for enterprise and solution architecture, I am far from convinced that SAFe is the answer. You may look instead at Avancier Methods on?https://avancier.website . I don't expect anybody to apply it end to end. I use its ADM-like process as a vehicle for teaching solution architects more than enterprise architects.

?