Diana Stobart Wild’s other question on the LinkedIn business
architecture forum was about frameworks:
What is Business Architecture? What does a Business Architecture Framework look like?
I think of Business Architecture as a subset of Enterprise Architecture that describes the business from the Strategy down to the enterprise business models (process, data, business rules, etc.). Business parts of the
Zachman Framework? Thoughts? Comments?
My response was as follows:
I’d agree that Business Architecture is a subset of Enterprise Architecture, as long as you don’t fall for the TOGAF-style trap of thinking that enterprise-architecture is only about IT!
Business-architecture proper is the strategy layer (Zachman row-2
and upward, also bridging down into row-3).
The jumbled mess of what’s otherwise called ‘business architecture’
only exists because TOGAF and the other IT-centric ‘EA’ frame-works essentially used the term as a generic dumping-ground for
‘everything not-IT’. Instead, think of the remainder of what TOGAF
calls ‘business architecture’ as two distinct layers: the logical or
integration layer – the equivalent of TOGAF’s ‘Information Systems Architecture’, Zachman row-3 to row-4 – and the physical or
implementation layer – the equivalent of TOGAF’s Technology /
Infrastructure Architecture, Zachman row-4 to row-5.
Zachman’s structure of layers still works fairly well for this – the
only essential change is an extra ‘row-zero’ for compatibility with
the Vision layer of ISO-9000:2000. But it does need some serious
rework on the columns: for a start, there’s an entire dimension
missing, to handle distinctions between physical assets (things),
virtual assets (data etc), relational (what your CRM is all about!),
aspirational assets (morale and the like), and abstract (such as the
financials that your business people do want in their models!); the
same for locations (physical, virtual, relational etc) and so on. Still
a month or a so away from finishing my book on this, “Bridging
the Silos”, but see the ‘Framework’ chapters in the current draft at
http://tetradianbooks.com/silos/.
One point that Zachman did get right, but most of the EA-toolset
vendors seem to have forgotten, is the key distinction between
primitives and composites. As Zachman says, architecture is about
primitives (TOGAF’s ‘Architecture Building Blocks’, or ‘ABBs’),
whilst solutions come from composites or patterns (TOGAF’s ‘Solution Building Blocks’, or ‘SBBs’). The Zachman Framework is a taxonomy of primitives – root-level entities, some of them fairly abstract; composites are structured collections of primitives that straddle the columns, making up patterns for re-use.
Composites are usable to the extent that they’re architecturally
‘complete’ – i.e. straddle all of the columns – but are re-usable to
the extent that they’re incomplete: for example, a BPMN process-model says nothing about ‘Where’ or ‘Why’, so can be re-used in different locations and (in principle) for different purposes. At the mid-layer of the framework, you need to be able to describe a process in abstract terms, to identify KPIs and CSFs and so on; you’d define different SLAs as you go down towards different
implementations – manual, machine, IT, etc, but they should all use the same KPIs etc. This is important because if you’re not able to anchor the detail-layer composites into their component sub-composites, all the way down to their root-primitives, you won’t be able to see options for redesign, such as for disaster-recovery or process-reengineering. Think of the classic IT-centric blunder of assuming that every problem must always have an IT-based
solution… your only way to avoid that trap is to use a non-IT centric framework that covers the true whole-of-enterprise space.
Over the past few years I’ve done quite a bit of work on a
‘service oriented enterprise’ framework, based on the classic
Stafford Beer ‘Viable System Model’ – see the Wikipedia summary
at http://en.wikipedia.org/wiki/Viable_System_Model. We extended this at Australia Post and elsewhere to include support for quality-systems, security-management and so on. Again, there’s still some way to go, and the book is probably at least six months away, but there’s a summary in my article on the service-oriented enterprise in the current itSMF “IT Service Management
Global Best Practices” book (see http://www.vanharen.net) and in my presentation to the TOGAF Glasgow conference back in April.
Originally written 2008 by Tom Graves
Leave a Reply