Mike is writing a great series on TOGAF: TOGAF Demystified Blog. My commentary begins.
I’ll join the conversation. First, a disclosure – I’m one of the people who wrote the tome. My fingerprints are all over TOGAF 9.1. I’m Chair of the Open Group Architecture Forum (the body that author’s TOGAF); I worked on TOGAF 9, worked very hard on the team that created TOGAF 9.1, and have worked on most of the integration whitepapers released in the last few years; I am very active on the next release of TOGAF.
So, I’ll start – TOGAF doesn’t suck.
Is it as good as I want it to be? Not a chance. Can I change it? Of course; all I have to do is obtain a consensus of a project team. The Architecture Forum then reviews this consensus, and then the member companies of The Open Group review it. At every point, comments, concerns, objections and improvements must be addressed by consensus. I live Mike’s challenge.
Now a few points that rattled my cage:
I do not understand the charge that TOGAF fails because it focuses on requirements? All I can assume is that special meaning is carried into TOGAF. Wherever possible in TOGAF we try to use a concept that can carry a range of specific detail – requirements is one of my favorite examples. TOGAF defines requirement as “a statement of need that must be met by a particular architecture or work package.”
TOGAF’s requirements are a nice broad concept – a statement of need that must be met by the architecture. What else am I going to find in the strategy, goals, objectives, hopes, fears, dreams, courses of action, and constraints other than requirements? They represent the set of needs that must be met by the architecture.
Further, there’s no weaseling in TOGAF. If we follow the thread in requirements and stakeholders, TOGAF highlights that best practice is to provide a name. No hiding behind vague assertions like ‘shareholder value’, or ‘the strategy’. Instead we take those requirements and trace them back to a stakeholder. Show me who wants something and then I can perform trade-off between that stakeholder’s requirements and the requirements of the other stakeholders. I can weigh, assess, rank, and refine. And, following best practice, I can review with my stakeholders and use the governance process to provide assurance. My only escape from this tyranny is to get one or more stakeholders to change the requirement, at which point I have a different set that must be met. No wonder TOGAF talks about iteration.
Doing real architecture is hard because of this point – it must address the complete set of requirements. No hiding. Get out in the open and show your work. Describe a target that best addresses the complete set of requirements and deliver a roadmap that will move the organization from where it is to where it wants to be within the capability of the organization to change. (Phase A, B, C, D, E & Requirements Management)
Second, I cannot see how TOGAF’s ADM can be considered a solution approach. If I’m doing solution architecture, why would I develop an architecture vision (Phase A), develop a roadmap (Phase E) then integrate the Implementation & Migration Plan into the organization’s portfolio (Phase F) and manage the lifecycle of my architecture (Phase H)? I’ve heard of many ways people wrap a solution approach, complete with proof-of-concept and RFPs into the ADM, but, in my opinion, it’s a stretch.
Now, doing EA – I can see the point of Phase A, E, F, G and H.
Do TOGAF or do EA? Sorry I don’t do TOGAF. I get paid to either deliver useful architecture or improve the capability of an EA team. TOGAF is a tool, not a goal. It is an EA framework that provides scaffolding for capability, content and method. To quote TOGAF Part I, “the purpose of enterprise architecture is to optimize across the enterprise the often fragmented legacy of processes (both manual and automated) into an integrated environment that is responsive to change and supportive of the delivery of the business strategy.”
In my opinion, too many words. In essence, darned good i.e. optimize across the enterprise the activity of the enterprise to create an integrated environment that is agile and supports current strategy… That’s worth getting out of bed for.
Lastly, you contend TOGAF fails because it isn’t hand-in-glove with Archimate. Here, I may run into trouble at the next set of member meetings. Archimate is a subset of the concepts required to completely describe an enterprise architecture.
This is not a slur on Archimate; by being a subset, it allows me to use a reasonable set of entities, perform traceability between the entities and have a graphical notation I can learn quickly. Beautiful. Truly beautiful.
But, if I need to describe organizational culture, fully map strategy, associate capital allocation, integrate the participation of multiple third parties, achieve return on equity and taxation, identify information entities by provenance and usage restriction, clouds and account for last mile connectivity to a specific restricted platform – I find Archimate limited. When I pull out the complete set of modeling techniques to describe these entities I may have the richness of a half dozen domain-specific modeling techniques and have to perform acrobatics to link them. There never is a free lunch. Don’t forget, I enjoy aerobatics.
When I do EA I need the freedom to describe what I need to describe to address the problem at hand. I will never let the toolset be constrained to a general-purpose saw. Sometimes a spoke shave, or coping saw or Mintzburg’s Organigraphs are needed. By the same token, I am very glad that I have a general-purpose tool that works reasonably well most of the time.
TOGAF aligns to my need for freedom and my expectation for a comprehensive toolset; there is a reasonable content-meta-model that provides a reasonable set of entities. I can read the mapping papers to Archimate. Or, I can roll my own and use Mintzburgh’s Organigraphic, Osterwalder’s Business Model Canvas and the OMG’s Business Motivation Model: exquisite richness and an integration challenge. Clearly a job for daveML. Or, use Archimate, and have a reasonable set that provides pre-defined end-to-end traceability. TOGAF is clear: use the tool needed. Describe what is necessary to understand, create a target that meets the set of stakeholder requirements, create a roadmap to traverse the gap and govern the builders to keep them on the path of goodness.
Regardless of my tooling, if I have the elements TOGAF calls for – governance, appropriate team, integration with corporate process, consistent method to develop an architecture and roadmap, stakeholders and requirements – I have the underpinning to create a very good understanding of how the enterprise ‘works’. Then I can do my job and optimize the future against the complete set of requirements. Good thing TOGAF is general purpose and provides a scaffold so I can address the problem I have in a manner consistent with the guy in the next office. When we use a minimum set of consistent entities we can even use each other’s work – although the guy in the next office does look askance at Organigraphics and Goal Structuring Notation.
I’d be happier if TOGAF was crisp on the distinction between concept and instantiation. Today I sometimes read an instantiation and have to derive the concept so I can re-instantiate appropriate to my problem. Perhaps the next release will make me happier.
I’ll re-iterate Mike’s challenge. Want to make the EA world better? Join us in the Architecture Forum. But, be prepared to work to consensus with many of the world’s leading enterprise architects. It’s a tough crowd. Specialist boutique consultants, global consulting practices and some of the most advanced in-house architects will review your work. You will be challenged to find what consistently works for a very broad set of problems. Not just mine, or yours, or Mike’s.
Sunday, January 23rd at The Open Group’s Newport Beach conference, I had 23 people from 3 continents in a workshop looking at EA capability – we started at 9:00 AM. I look forward to seeing you at the next member meeting or a TOGAF next release call (your employer must be a member of The Open Group).
Managing Partner, Conexiam
Chair, Open Group Architecture Forum