Towards a whole-enterprise architecture standard – 1: Introduction
For a viable enterprise architecture [EA], now and into the future, we need frameworks, methods and tools that can support the EA discipline’s needs.
What we need now are tools and techniques that can extend all the way out to a literal ‘the architecture of the enterprise’ – whatever that enterprise might be. The catch is that most of the existing frameworks don’t support those needs very well:
- most enterprise-architecture frameworks are either context-specific – such as DoDAF (defence), TEAF (Treasury), FEAF (government) – or industry-specific – such as eTOM (telecoms) or SCOR (logistics)
- most if not all of the mainstream ‘EA’ frameworks are centred primarily or exclusively around IT
- many of the frameworks – such as DoDAF – consist of little more than a list of required artefacts, without any details as to how (or even why) those artefacts should be developed
- most business-architecture frameworks tend to be either context-specific, or for commercial usages only – such as Business Model Canvas
- TOGAF is almost the only framework with an explicit architecture-development method, but unfortunately it’s structured around an ‘inside-outward‘ view of the enterprise (organisation-centric rather than enterprise-oriented), and inherently drives us towards IT-centrism
- almost none of these frameworks give any guidance on how to adapt the content to other contexts – TOGAF is one of the few that does, if in very limited form
- some if not most of these frameworks are so outdated, or so hardwired against change, or have so many other structural faults, that we can only safely use them if we already know enough enterprise-architecture to not need the framework anyway – which kinda defeats the object of the exercise…
Which in practice means that if we need our architectures to link between industries, or work with any mix of commercial, government and not-for-profit, or develop architectures that centre on anything other than IT, we’re largely on our own.
Which is not exactly helpful…
In short, if we want an enterprise-architecture framework and standard that will actually serve our current and future needs, it looks very much like we need to start again from scratch – and this time, do it properly, from a true whole-of-enterprise perspective, fully fractal, able to work with any scope and at any scale:
Themes we’ll need to to consider would include:
- we need a new core that fully understands enterprise-architecture, not just beyond IT, but all the way out to the whole-enterprise, at any scope, any scale
- we need a new architecture-development method that can work with any architecture context, again at any scope and scale
- we need a new set of content-frameworks that can self-extend to cover any required architecture-context
- we need new toolsets to support new context-adaptive EA practices
- we need new EA training and education to support all of these new functions and requirements
That’s what we’ll explore in subsequent posts in this series.
Looking forward to the subsequent posts, Tom.
Thanks, Peter. They’re comin’ along – I have outlines for all of them now – but it may take a while to get them all out there.
(And all of it is only my own suggestions, of course – any final standard will be up to the community as a whole, not just one person. My job right now is to get the dialogue started – nothing more than that! 🙂 )
Tom, thanks for the post. As always, you provoke my thoughts.
I do wonder about why you suggest taking a greenfield approach to this issue. In your words, “start again from scratch”?
In my experience, “greenfield” situations are rare; it usually is a “brownfield” with existing constraints, implications, etc. Is there another option that we can build upon to come up with an ideal final result? A wholesale change to a new enterprise standard for any enterprise architecture office will be challenging (and I love challenges). I just wonder about the transition steps to move from here to there. I wonder if there is something that can be thought through to make progress in the right direction in practical terms. Or are you an advocate of ripping the bandage off quickly? 😉
Thanks, Fred. Yeah, I’m well aware that in principle we should be in a brownfield situation, and make best use of prior-art and suchlike.
The blunt answer, though, is that TOGAF in particular has poisoned the water so much that really we have very little choice but to start again pretty much from scratch. The crucial distinction is that all of the existing mainstream ‘EA’-framework are content-driven and context-specific; the same applies to most of the non-mainstream frameworks, though with a few notable exceptions – Kevin Smith’s PEAF/POET comes to mind, and likewise Roger Evernden’s work on metaframeworks. The fundamental requirement, in fact, is that for whole-enterprise architecture we need a ‘context-first’ approach, which in turn demands underpinning by a metaframework concept, from which context-specific frameworks can be derived – rather than imposed by unexamined ‘hard-wiring’ of context, as in those mainstream frameworks. It’s the shift from framework to metaframework that in effect makes this a greenfield context, even though its outcome and operating-domain is very much brownfield (often in the worst possible sense…)
As will be seen as we go through the series, I’ve taken a lot of care to support full backwards-compatibility, wherever feasible or practicable. But we don’t want that backwards-compatibility to permanently block all future progress, or at best slow it to a belated-crawl – which is all that TOGAF and the other ‘EA’-frameworks can offer us. In that sense, yes, we really do need to start again from scratch – yet with full respect and inclusion of the past.
Tom
Thanks for all the effort that you have put into developing and publishing this series.
One question which continues to exercise my mind revolves around:
a) the necessity for executives and managers to be (co-)creators of the architecture
b) the implication that for this to eventuate and occur in a widespread manner, the concepts and methods must be relatively plain and simple
Having now done the thinking and published your series, I am interested to hear your perspective on this implication, and what has become a driving goal in my own work in the last year or so.
Another thought in relation to my last comment and question …
Tom has very eloquently summarised EA in one line
“working together better”
This is an expression and explanation that I use in various settings. This, in itself, is a wonderful example of another critical aspect to EA …
“simplicity in the midst of complexity”
for it is simplicity which helps those pursuing enterprise to better understand each other and their shared enterprise, thereby to work together better.