Mike is writing a great series on TOGAF: TOGAF Demystified Blog. My commentary continues.
If we are to converse we may need to narrow the field. I’ll start on on three points: structure, extending TOGAF and a single model.
First, structure – I have no idea how the TM Forum works so I cannot compare the chief architect’s role in TM Forum’s Frameworx with my role in the Architecture Forum. The Open Group is a consortia of member companies who join and participate in one or more forums. My company, Conexiam, is a member.
Chair of the Architecture Forum is a volunteer position. Annually elected by the members of the Architecture Forum, I have a limited ability to lead. Everything we do is by consensus. I even need approval for the agenda at the quarterly member meetings. In the projects, I have one voice – in fact, one of my participation values is testing my experience with my peers.
TOGAF is a standard published by The Open Group, created through The Open Group’s standards process. The core is member consensus about member work. Sadly, Newport Beach wasn’t sunny on the two days my consulting commitments allowed me to attend.
The upside: the members represent a very board range of industries, regions, and approaches. I am comfortable when we send a draft of TOGAF to some 3,000 people on the Architecture Forum mailing list, many of whom represent more people, we are hitting a significant cross section. Last time, we got more than 500 substantive comments. Are we hitting everyone possible? No.
Frankly, I don’t lose any sleep.
The downside is significant. People outside the process don’t understand it. Like Mike, they try and talk to ‘The Open Group’. In this blog, Mike invited people into the process. A few years ago I invited him to attend the framing meeting for the next release of TOGAF and represent his own ideas. While we are all influenced by our experience and learning, a member has to carry the influence in. We also do everything under non-disclosure.
Second: extending. Since I have been Chair we worked consistently on integration and extension. The Architecture formally created joint projects with TM Forum, SABSA, BAIN, DAIMA, DODAF and, interestingly, The Open Group’s SOA Work Group, Cloud Work Group, Security Forum, Real-time & Embedded Systems Forum and Archimate Forum. The last five may sound odd, but every Forum or Work Group is an independent entity under the umbrella of The Open Group, and has a different set of members.
Staying with TM Forum, SABSA and BAIN (the whitepapers are published and available), my intention was three-fold:
- Clarify how the special needs of telecommunication, enterprise security and financial services are served with a general purpose framework. We use a clear phrase: ‘TOGAF and’. A general-purpose framework should not have the depth, specificity and richness of a focused body of work.>
- Extend TOGAF without the Architecture Forum having to pretend it knew everything and wrote everything.<
- Informally, learn where TOGAF may have used unduly specific concepts where a general purpose concept could allow the specialist’s richness and specificity.
What I personally took away from the work and conversations, and from my work enabling effective EA teams as a consultant, informed my proposal on the next release of TOGAF. I saw a need for TOGAF to be conceptually clear, internally consistent, easier to consume and easier to extend; the framework needed to be separated from guidance on how to use it.
Third: adopting single models. This can be a conversation – structure I can explain, but we can’t change how TOGAF is created.
I am working on the next release and am interested in learning. In fact, the trade-off this evening was a draft of TOGAF or replying.
Here, even though I have not had the opportunity to look at your suggested models, I suspect we will part company.
I am inherently suspicious of the perfect model – and run two tests in my head: How about defense, government, financial services, packaged goods, retail and resources? What about coverage for different purposes, archetypes or schools of EA? If it misses one or more, it is not fit for everyone, regardless of fit for some.
TM Forum has a rich set of models in Frameworx I have used in telecommunications and banking; DODAF has a specific set of models I have used in defense, oil and gas, electrical utility and public sector; FEAF has a set of mandated models; Canada’s Government Services Reference Model (GSRM) is one of the best service reference models I have used. I can go on. We can all go on. In my experience, most of us specialize and absorb the inherent foundation of our specialization as universal constructs.
I believe that TOGAF needs to support rich domain, purpose or organizational, specific approaches – without favoring or constraining one, or another, rich approach. Today, I believe it is unnecessarily hard to utilize the available richness because we have confused a specific instantiation, or specific concept for a universal concept.
My real problem is a current need to describe organizational culture, fully map strategy, associate capital allocation, allow 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. When I look at TOGAF’s content meta-model and partially associated viewpoint library there are significant gaps between what is there and what I need. However useful an application/data matrix is, I usually have a problem that needs to be addressed before one of these can be useful.