A few days ago my colleague John Polgreen posted an article of mine Adapting the ADM for Government Architectures on his ‘TOGAF for Feds’ blog on the (US) Government Technology Research Alliance (GTRA.org) website. The main theme was that to make TOGAF work well for non-information-centric government agencies and similar organisations, we need to do some significant changes to TOGAF’s Architecture Development Method cycle (the ADM). I summarised the modified ADM and taxonomy-framework, and illustrated all of this with a fairly lengthy case-study of the use of this modified framework in a government agency in the social-services sector.
The problem is that for many TOGAF practitioners, those changes are often too much of a jump from standard ADM practice. For example, in an unattributed comment on the blog, John’s colleague ‘GB’ complained:
One can transform TOGAF into any process one wants.
Is this really TOGAF for government? Or even for enterprise architecture?
Or is it TOGAF for business consultants dealing with a government department?
There are actually two separate points here. One is the implicit assertion that ‘enterprise architecture’ is still solely the architecture of the enterprise-IT; as John also mentioned in a comment, that notion is at last becoming more generally acknowledged as unworkable, and that we must extend the architecture out to the full scope of the enterprise. (Importantly, this extended ‘architecture of the enterprise’ is not the same as business-architecture.) The other is that many TOGAF folks are still uncomfortable with the idea of dumping the existing phases B, C and D – ‘Business Architecture’, ‘Information-Systems Architecture’ and ‘Technology Infrastructure Architecture’ respectively – even though they don’t work in practice for anything other than IT strategy-development and implementation. (In the re-worked version of the ADM they’re replaced entirely by a separate focus on as-is, to-be and gap-analysis for the selected scope – similar to the structure of the ADM in the earlier TOGAF 7.)
The core problems here are that the TOGAF 9 ADM is usable only for top-down strategy development (the sequence of the phases B, C and D), and only for IT-systems and IT-delivery (the current content of B, C and D). The enterprise-architecture method needs to cover a broader range of development types – overview, horizontal optimisation, top-down, bottom-up and spiral-out – and to address any scope in the enterprise. Hence the reason for suggesting some fairly fundamental changes to the ADM structure. But as long as we’re comfortable with sticking solely to top-down development, we can still retain something very close to the existing B, C and D, but capable of covering any enterprise scope. To do this, we rename the Phases as follows:
- Phase B: ‘Business Big-picture’
- Phase C: ‘Communication and Common’
- Phase D: ‘Domain Detail’
Phase B: Business Big-Picture
In this layer we explore the strategic imperatives for the business – what we might call ‘business-architecture proper’ – and the business drivers that impact on strategy. This is all at the big-picture level, and would typically include vision, values, business-role, business-missions and suchlike, and whole-of-organisation reference-models such as the Functional Business Model, and the FEAF Business Reference Model (BRM) and Performance Reference Model. This would be similar to the high-level components in the TOGAF 9 ‘Business Architecture’, though would not necessarily focus solely on strategic themes that would impact on IT.
What it would not contain is any tactical or operational themes: so-called ‘manual’ bsuiness-processes and the like. The tendency of TOGAF practitioners to bundle together everything ‘not-IT’ as ‘business architecture’ is a common cause of friction between IT units and the rest of the business, and also a common cause of architectural design-failures at the implementation stage.
Phase C: Communication and Common
In this layer we explore what needs to be shared with domains other than the primary domain in scope. For IT, applications and data are what are shared with other business domains – hence the two subsidiary components in TOGAF’s ‘Information Systems Architecture’. But here we need to make this more general, because the primary domain in scope may be any part of the business – HR, for example, or security, or manufacturing, or marketing. Typical deliverables here would be the domain equivalents of FEAF’s Service Reference Model (SRM) and Data Reference Model (DRM).
A service-oriented analysis of the enterprise will usually be the most appropriate tactic here: define everything as services, and summarises the structure and content for interfaces, service-contracts and SLAs, qualititative criteria, success-factors (CSFs) and performance-indicators (KPIs). This is also where trade-offs between different implementations should be assessed.
Phase D: Domain Detail
In this layer we explore the fine detail that’s specific to the ‘primary domain in scope’, and which should in general not be of any active concern for other domains (‘black-box encapsulation’, in service-oriented terms). For IT, this is the detail about network infrastructures, configuration-management, life-cycle management and so on – the TOGAF Technology Infrastructure Architecture’. Typical deliverables here would be the domain-equivalent of FEAF’s Technical Reference Model (TRM), and else capability-architecture models that cover IT-based, human-based and machine-based capabilities.
This layer in particular is where the often-idealised top-down strategy needs to connect with the bottom-up constraints of real-world operations. Architecture governance becomes extremely important here, with cross-linkages to ITIL, CoBIT, Six Sigma and other detail-level process-management and quality-management disciplines, as appropriate to the respective domain.
Anyway, try this in your TOGAF practice: see what you think, see how it works in practice. It’s not as versatile as the full amended-ADM, but it’s a useful ‘halfway-house’ that’s easier for existing TOGAF practitioners – and because it is truly generic, rather than IT-centric, and consistent across all domains, it should also help to bridge the chasms of the dreaded ‘IT-business divide’.