Business-architecture frameworks

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’ frameworks 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/2008/04/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 (see PDF at http://www.tetradian.com/download/togaf_ea-soe_apr08_FV.pdf ).