Zachman and TOGAF revisited

Promised some time back that I’d start to document what I’ve done with Zachman and TOGAF in the enterprise-architecture space.

Anyone who’s tried to use either of these ‘standards’ in real-life enterprise-architecture will know that they both have severe limitations which make them all but unusable for anything beyond a strict IT-centric view of the enterprise. Trying to use them for anything outside of that IT-centric scope – in other words, for real enterprise-architecture – is an immediate exercise in extreme frustration. Much of my work for the past year – and particularly for the past four months, for my client down in Sydney – has been to find ways to sort out the resultant mess. But since most enterprise-architects come out of the IT space, and Zachman and TOGAF are what they know, that’s where we need to start.

Zachman has six rows, representing views into the architecture space, and six columns, representing fundamentally different categories of ‘primitives’ or architecturally relevant entities. (Most real-world items are ‘composites’ – combinations of architectural primitives. Creating mappings between theoretical primitives and real-world composites can get very tangled, and way too abstract if we’re not damn careful. But I digress…) The key principle that Zachman introduces is that architecture and governance depend on primitives, whilst real-world solutions are based on composites; or, as Roger Sessions put it in a recent podcast, “the job of a developer is to introduce complexity and the job of an architect is to eliminate it”. The catch is that whilst the Zachman framework is still (just about) usable for IT development, beyond that space many of its ‘primitives’ turn out to be a muddled mess of covert composites. We need much more clarity and granularity to be able to cover the interactions of the whole enterprise, beyond the narrow constraints of IT. We also need to fix a number of subtle but extremely important mis-framings in Zachman’s core descriptions of the framework columns.

I think I’ve cracked that, as I’ll describe in a series of posts over the next few days. As a quick summary, the framework needs one extra row, a fundamental change to the meaning of one of the columns (‘Who’), and an entire new dimension to split each column into segments. More on that later, anyway.

On the TOGAF side, the only real problem is that the ADM (Architectural Design Method) is rigidly IT-centric – so much so that the label ‘Business Architecture’ is used for everything that’s not identifiably IT. And in the present TOGAF spec (version 8.1, “Enterprise Edition”), the ADM sequence of Phases assumes that the only purpose for the Method is to create or review the entire architecture: there’s no means to handle anything smaller or simpler, such as any of the routine day-to-day review and analysis work of the enterprise-architecture team. But we can make it not only usable for any scale of work, but any scope of architecture-work, just by tweaking the definitions of the first four Phases:

  • Phase A:
    • was: Architecture Vision – big-picture view of what the iteration aims to achieve for the entire architecture
    • new: Iteration Scope – identify the core business-question being addressed, and the amended-Zachman scope to be covered in the analysis
  • Phase B:
    • was: Business Architecture – identify business drivers, business processes, everything outside of an IT-centric scope – a muddled mixture of high-level, mid-level and low-level Zachman layers
    • new: Current-State Architecture – establish the current-state for the scope and business-issue identified in Phase A
  • Phase C:
    • was: Information Systems Architecture – a somewhat confused mixture of IT applications-architecture and data-architecture, mostly in the mid-levels of the Zachman framework, without much in the way of links to business concerns on their use, such as in information-architecture
    • new: Future-State Architecture – establish the required future-state for the scope and business-issue identified in Phase A
  • Phase D:
    • was: Technology Architecture – an IT-specific subset of physical objects and functions, mostly down at the low-level regions of the Zachman framework
    • new: Gap Analysis – establish the gaps between the current-state (from Phase B) and desired future-state (from Phase C), and the resultant change-requirements in relation to the scope and business-issue (from Phase A)

We then continue with the rest of the ADM, pretty much as per the original spec, moving on with Phase E “Opportunities and Solutions” to assess the requirements elicited in Phase D – but with whatever scope we needed, and for any appropriate business-issue, rather than only the sledgehammer of ‘redesign the entire architecture in order to do anything’.

The other point is that this modified cycle now maps in well with PRINCE2 and other programme/project management methodologies and governance. For example, we now have just one explicit stakeholder-review at the end of each of the Phases A to D – not the almost-random, largely-implicit stakeholder-reviews that appear from time to time in the original TOGAF spec for those Phases.

Anyway, more later. Probably sounds picky and pedantic to most people, no doubt, but I’m certain it’ll give us a means to open out the entire discipline of enterprise-architecture to a broader, more genuinely enterprise-wide scope.

7 Comments on “Zachman and TOGAF revisited

  1. As a relative newcomer in EA (starting on architecture in the end of the sixties; developing my own EA framework in the eighties and nineties and consolidating this century when working with Gartner clients) I’ve tried those frameworks but to little avail. They serve as paper generators. My criterion for a good architecture is: does my client understand it. If not, it is not architecture. The purpose of architecture is to provide insight to decide, to all stakeholders. And indeed, EA is to serve change initiatives both on the business and the IT-side. I think your phase-tweaking proposal will bring a lot more of the confusion that is already abundant.

    Best regards, Michiel

  2. Thanks, Michiel – much appreciate your comment about “relative newcomer”, this is indeed a lifetime’s game, not “one five-day course and you’re ready”, as the Open Group tend to purport… I’ll admit I haven’t been in the game quite as long as you, but was writing multi-megabyte assembler programs for typesetting-systems as far back as the ’70s, so I do have some appreciation of the trade. ::wrygrin::

    And yes, I’d agree that “does the client understand it?” is an important criterion – but not the only one. “Does it work as architecture?” is also important…

    What I’m aiming for here is to find some way to reuse all the investment (financial, intellectual and otherwise) in Zachman and TOGAF and the like, in ways that will actually work at the full enterprise-wide scope – because as they stand at present, they don’t work for anything other than a pure IT-centric scope (and not all that well even at that, anyway). My point is that architectural analysis should not be about IT-centric academia (your ‘paper generators’), but should always start and end with business-oriented questions, for example:
    – “what is the impact of this change in strategy / legislation / policy etc?” – i.e. top-down strategic analysis
    – “what is the business impact of this component fails?” – i.e. bottom-up risk or failure analysis
    – “how can we reduce costs?” (or, better, “how can we improve overall effectiveness”? – i.e. side-to-side analysis
    – “how can we resolve this business pain-point?” – i.e. start-anywhere-and-spiral-out analysis

    I’d agree that the original Zachman and TOGAF are nearly useless for business questions such as these. But a reworked, non-IT-centric Zachman-type structure really does help in framing the content , context and scope of the analysis, and in drawing the key distinctions between primitives (on which we should base compliance) and composites (on which we shouldn’t, because we would enshrine temporary constraints as permanent requirements). And the reworked TOGAF provides the discipline of governance-frameworks in which to do the analysis and then put it into business practice.

    Once we’ve done the architectural analysis at that abstract level, yes, we do need to translate back into the specific terms and views of the respective audience-group – often many times over, for very different audiences. But we only do that translation when the analysis is complete – not before – otherwise we’ll get completely lost trying to maintain all the different views at once.

    The part I still haven’t fully worked out is how to get any of the damn toolsets (and, for that matter, their vendors) to understand that there is no such things as a fixed ‘future-state’: the world is dynamic, not static. But that’s another story for another post. In the meantime, thanks again for your engagement in this one!


  3. Hi Tom,
    I have just finished my article for the Dutch Architectural Congress. Within my Article I addressed you’re issue also so I agree you’re analyses. What I saw as a lack of support in Togaf is the gap with the ‘Service’ concept. In this service oriented era you can’t afford to neglect this concept
    The service concept is an ideal interface between the business architecture and the application landscape.

    My statement is change Togaf Phase C in Enterprise Service Architecture and position information architecture as a cross domain architecture much like security. Please don’t mix my statement with SOA as a technological thing. I mean enterprise services , the service portfolio that serves and fits strategically with the business architecture.

    If this phase C would be replaced Togaf aligns with more modern languages like the Archimate language that also adopts the service concepts between architectural layers.

    Roland Ettema, Management Consultant LogicaCMG

  4. Thanks Roland
    You’ve reminded me of an earlier version of my attempted restructure of TOGAF, in which I laid out Phases B-D as follows:

    Phase B: ‘Business’ – high-level strategy, policy and structure (primarily Zachman rows 1 and 2)

    Phase C: ‘Common’ (i.e. your “cross domain architecture”) – concept and design-level views across the whole architectural space (primarily Zachman rows 3 and 4)

    Phase D: ‘Detail’ – the detail-level descriptions of implementation and run-time (primarily Zachman rows 5 and 6)

    Doing the cut this way, we end up with a clean way to handle non-IT aspects of cross-domain architecture and implementation – which TOGAF 8 bundles in its entirety into ‘Business Architecture’. Data-architecture and application-architecture become just two of many examples of cross-domain architectural logical and physical designs; as you say, service-architecture (How + Who etc) is another, as is security-architecture (How + Why etc), information-architecture (What + Why etc) and so on.

    But I abandoned that cut, for two reasons.

    The first was that, with this cut, we can only do the kind of massive six-month-plus “review the whole damn architecture of the whole damn enterprise” effort indicated by the standard approach to TOGAF. What we dealt with in architecture practice was often much smaller: often all we needed was a half-hour scan through the repository to assess the impact of some minor change or failure. I wanted a methodology that could be used consistently for every variation of architecture assessment, and that would also align with standard project/programme governance methodologies such as PRINCE2. By rethinking Phase A, as setting the scope for the cycle, and then using Phase B, C and D as as-is, to-be and gap-analysis respectively to assess the architecture of that scope, we end up with something much more flexible, and much more aligned to governance. Service-architecture, security-architecture and so on then change from something we only look at in design-time (your version of Phase C) but become perspectives into the _whole_ architecture, consistently, right the way through all the Zachman levels from ‘universals’ to run-time.

    The other reason was, again, for alignment with PRINCE2. If we do the standard TOGAF cut, we end up with a separate stakeholder-review for the as-is, to-be and gap-analysis in _each section of Phases B to D: that’s a minimum of _twelve_ stakeholder-reviews, often with the same stakeholders. To be blunt, that ain’t gonna fly in any real-world business environment: no-one has that amount of time to spare. With the cut I’ve suggested, we end up with just three reviews, one at the end of each of Phase B to D; and in effect, governance forms the boundary between each Phase. A heck of a lot cleaner; a heck of a lot easier to ‘sell’ to business.

    That’s just my opinion and experience, though: any suggestions on this?

  5. You need to be clear that by – “enterprise-architecture” – I think you mean the design of the enterprise i.e. not the design of ICT systems. Unfortunately I don’t think a lot of people practicing in EA focus beyond ICT. In fact many sadly seem to think EA an extension of CASE (and will immediately start talking design oriented modelling languages like UML, ER).

    Zachman doesn’t have a columns suited presentation/interfacing – because it developed in 1987 (when systems had a very different audiences, purposes and mechanisms for systems and user interfaces). These problems become increasingly acute as ICT systems become increasingly communications oriented, multimodal, ubiquitous and interconnected. Issues arise even in ICT design when using Zachman e.g. NW/platform design resides in the where column (this was valid when the major costs of ICT systems were CPU, bandwitdh and memory – but now platform design is driven by other things i.e. not predomintly by location). Ironically location is becoming more important for other reasons. Likewise the who column is used for most of the control mechanisms (oriented around security) – because in 87 many forms of attacks where essentially not possible on the closed systems of the day.

    TOGAF’s audience and adherents are usually oriented at ICT and don’t usually purport to go beyond it. TOGAF illustrates its orientation by looking a lot like a CASE method (Cf. RUP), and not very much like a business planning method. What TOGAF fails to do most critically is put the control of the primitives and composites under their natural owners (who are almost always not the people doing the EA work) i.e. it doesn’t focus on establishning mechanisms to allow the EA knowledge to be naturally accrete
    with out any additional cost to the enterprise (which is how successful knowlege bases operate). This requires adjustments to processes that produce/consume the knowledge. The result of EA is not an aftefact/document (Cf. Encyclopedia Britannica) – it is really a library (a knowledge base Cf. Wikipedia).

    A related issue is that none of the knowledge above can be managed in documents (Word, Powerpoint, Visio, stone slabs or papyrus etc.). It may be presented as/in documents – but that is a different issue. In well over a decade in this area I have never seen an organisation achieve an EA using documents that is: maintainable, accessible, current, accurate, affordable, etc. No one would today attempt far simpler modelling tasks i.e. with 3-4 primitives e.g. ER modelling, project planning – without the benefit of a knowledge modelling system. Zachman et al suggest not 3-5 primitives (as per project plans) but 30-50+. Another issue is that one uses the term architecture and in all other areas of complex design (PCBs/electronics, planes/trains/cars, cities/buildings, organisations/processes etc.) the need for visual representations is well recognised.

    So in summary – one find the right solution unless one:
    – gets a common definition of EA (i.e. that extends beyond ICT)
    – accepts that Zachman is a useful construct (a taxonomy, primitives, composites) but is out of date.
    – recognizes EA is not CASE (or CASE like) i.e. it is knowledge management and therefore needs to focus on how know accretes (but it must relate to CASE tools, and other tools/knowledge bases)
    – knowledge (e.g. models consisting of aggregates of inter-related primitives) can’t be managed on paper.
    – getting people to share knowledge has its own intrinsic challenges.

  6. Hi all,

    My foucs is on extending TOGAF to include SOA.
    My apporach was to add SOA as a cross-cutting architecture (cutting across BA,ISA,TA & also the governance of TOGAF (since SOA also needs SOA governance).

    Rolland has also suggested a nice approach above of having SOA in place of IA and making IA a horizontal.

    How do you guys compare these 2 approaches and is there any other way around for customizing TOGAF for SOA ?

Leave a Reply to Michiel Malotaux Cancel reply

Your email address will not be published. Required fields are marked *