Welcome to GTRA

Today we have a guest post from Tom Graves, a UK-based EA consultant who has frequently commented on this blog. His post is a case study in the use of TOGAF in a social services agency. Thanks, Tom!

TOGAF makes immediate sense for architectures in information-centric industries and agencies. But when the business itself must focus more on people or on physical ‘things’, TOGAF’s over-emphasis on IT can become a problem. This article explores some practical experiences and lessons-learned in using TOGAF for enterprise architecture in a state-government agency in the social-services sector.

The agency has four major business strands: statutory intervention, long-term care, regulation and monitoring of service-provision, and community education on social-work and social-care issues. It employs about 3000 full-time staff, but also supervises and monitors the activities of tens of thousands of social-workers and care-workers in commercial and volunteer service-providers throughout the state.

To maintain commercial confidentiality, some details have been intentionally suppressed in this description: please contact the author if further details are required.

Business purpose for architecture

Classically, an enterprise architecture is described as being composed of four subsidiary architectures:

• business architecture
• applications architecture
• data architecture
•  technology-infrastructure architecture

For this agency, the technology and applications architectures were already complete, with transforms between data architecture and business information undergoing extensive review and restructure. What was needed was a true ‘architecture of the enterprise’, to support:

• improved communication and alignment between business and IT
• improved coordination and communication between all the agency’s workstreams and business units
• improved information-sharing, task-sharing and end-to-end coordination with partner agencies
• improved communication, relations and trust with the agency’s stakeholders in the broader community

One crucial insight arising from this is that ‘the enterprise’ in scope for any architectural assessment may be any subset or superset of the organization, and in some cases could well extend far beyond the formal boundaries of the organization. And neither the agency’s IT, for example, nor the agency itself, will exist in isolation: so a key role of an enterprise architecture here is to describe the broader context within which they operate, in order to clarify the reasons and overall impacts for each structural decision. In practice, the enterprise architecture may need to extend at least three layers beyond the scope of the organization:

• end-to-end processes shared with business-partners and partner-agencies, such as volunteer and commercial service-providers, other social-work agencies, health, education, police and justice, emergency-services, natural-disaster management and others
• direct stakeholders, including social-work clients and their families, oversight agencies, policy-makers and government
• indirect stakeholders and the broader community, as ‘concerned citizens’

This necessary ‘whole of enterprise’ view is far larger than that described in conventional IT-centric enterprise-architectures. In almost all cases, it will also be far too large a scope to cover in any single architecture project, and far too expensive to ever attempt to ‘complete’. To make this feasible, usable and useful within our agency’s context, we needed to rethink our overall approach to enterprise architecture.

Whole-of-enterprise architecture with TOGAF

It was clear that our architecture-development methodology would need to support projects of any scope and any scale. It would need to be iterative, with consistent governance throughout – conceptually similar to Agile software-development, although iterations might also be nested recursively to manage governance at varying scales. Every iteration would need to address an explicit business problem or business question, yet also each contribute to the knowledge of the whole.

The overall purpose would be to create and maintain a body of knowledge about the intersection of structure and purpose across the whole enterprise, describing dependencies, impacts and implications of changes in any type of structure – physical, organizational, information, business relations, whatever. This would aid decision-making for strategy, tactics and day-to-day operations.

As standard, TOGAF’s ADM (Architecture Development Method) is not sufficient to satisfy these requirements. Even the new Version 9 is still centred almost exclusively on IT – its view of business-architecture, for example, in essence only describes ‘anything not-IT that might impact on IT’ – and its structure implies that every assessment will always lead to a major program of works, resulting in a tendency towards ‘governance overkill’. Its handling of governance is inconsistent in places – especially in its management of iterations. And its structure seems best suited to ‘horizontal’ optimisation of systems, or for top-down implementation of strategy, both of which are typical for the middle stages of architecture maturity – yet with no clear guidelines as to what to do either before or after that work.

However, the TOGAF specification does also include sections on adapting the ADM to the specific business context. Using these guidelines, one can legitimately change ADM content and structure – quite radically, if need be – and still retain the overall ‘look and feel’ of a TOGAF architecture.

For our purposes, the breakthrough was a realisation that each of the TOGAF ‘architectures’ – business, application, data, technology – was actually an architecture iteration in its own right. Each had a prepackaged scope, and followed the same assessment sequence: assess or define the architectural context for the primary time-horizon (either as-is or to-be); assess the architecture for one or more secondary time-horizons (to-be, as-is or intermediate ‘transition-state’); and then do a gap-analysis between each pair of time-horizons to develop change-requirements. All of these occurred within a larger architecture cycle that actually had the same overall structure. So to break out of the IT-centric constraints of the standard ADM, we could restructure the ADM phases as follows:

• Phase A: identify business purpose and architecture scope and required time-horizons for iteration
• Phase B: assess architecture for primary time-horizon (‘to-be’ or ‘as-is’)
• Phase C [optional]: assess architecture for secondary time-horizon(s)
• Phase D [optional; usually applies only if Phase C exists]: do gap-analysis to derive change-requirements
• Phase E [optional]: provide architectural guidance in assessment and definition of high-level solution-designs
• Phase F [optional]: provide architectural guidance in detailed solution-design
• Phase G [optional]: provide architectural guidance and governance in solution-implementation
• Phase H: do benefits-realisation and lessons-learned review for the iteration 

Figure 1: Amended TOGAF-style ADM

Crucially, the phase-boundaries are delineated by governance events – typically a key end-of-activity review (see Figure 1). Phases also typically have different stakeholders – particularly in the implementation phases E to G. (For further details on this, see the books Doing Enterprise Architecture: process and practice in the real enterprise at tetradianbooks.com/2009/03/doing-ea/ or Bridging the Silos: enterprise architecture for IT-architects at tetradianbooks.com/2008/04/silos/, or the summary reference-sheet at tetradianbooks.com/2008/10/silos-method-ref/.)

We also expanded the central core-reference to include shared repositories for issues, risks, change-requests, glossary and thesaurus, and for models, drawings, reports and other architecture artefacts.

This structure can be applied not just to the standard TOGAF ‘four architectures’, but to any scope. The ADM Preliminary Phase, for example, is actually an architecture iteration where the scope is the architecture capability itself, and in which the implementation phases embed that capability within the organization. Recursive nesting of iterations allows the same structure to be used consistently for any architecture-related project, with consistent governance at any scale.

The simplest architecture cycle would consist of a brief assessment of a defined context, followed by a quick review to incorporate any lessons-learned back into the repositories; the whole process might last only a couple of hours, perhaps even less. On the other hand, a project could also resemble the classic TOGAF architecture cycle, encompassing a huge change-program that would take a couple of years or more to complete. This amended ADM can cover each of those extremes, and anything in between.

Linking architecture to enterprise taxonomy Project scope is defined in terms of an extended version of the Zachman framework (see Figure 2). This variant uses a ‘clean-up’ of the columns to provide better alignment with modeling notations such as BPMN and UML. It also resolves a key problem in Zachman, by providing explicit distinctions between asset-types, decision-types etc, in an additional dimension referred to as ‘segments’. (For further details, see Doing Enterprise Architecture, or the summary reference-sheet at tetradianbooks.com/2008/12/silos-frame-ref/.) Distinctions between segments often have little relevance at the ‘higher’ or more abstract levels of the framework, but become steadily more important as we move down towards real-world action. For example, at the ‘Business’ layer, information is just information, but at the ‘Operations’ layer there are often fundamental differences in the processes to manage that information on paper (physical), as electronic data (virtual) or via person-to-person conversations (relational).

Figure 2: Extended Zachman-style framework

Unlike the Zachman original, this provides a taxonomy that can cover every aspect of the enterprise – not just the agency’s IT. It can therefore act as the base-skeleton for a single ‘holographic’ model of the entire enterprise, to which each architecture-iteration would add further detail. Different combinations of columns and segments provide different views into that whole, typically defined as ‘model-types’: for example, a logical-to-physical data-model references only virtual assets, whereas a business-information model would also encompass functions, capabilities and decisions (business-rules) for transforms, and probably also the events that trigger them. Defining iteration-scope in terms of the framework identifies the model-types most likely to be developed during the assessments. The layers or rows also help to identify the stakeholders for an architecture iteration.

Another use of the taxonomy is to help identify content for the FEAF Reference Models. For example, services are combinations of function and capability: ‘Customer Services’ link such combinations to relational-assets (links to real people), whilst ‘Digital Asset Services’ link function / capability combinations to virtual-assets (data).

One of the key responsibilities of the agency was disaster-recovery management, so a practical application for the framework here was in development of business-continuity plans. We mapped the cross-dependencies of IT services at the abstract layer (the ‘System’ layer of the framework, or Zachman row-3), identifying the information and transforms that these services would manage. We then linked these back down to the real-world (‘Develop’ and ‘Deploy’) IT-systems (‘virtual’ segment) that at present implemented those services. Using those crosslinks, we could then define manual (‘relational’ segment) functions and capabilities that could implement the exact equivalent services, but using information in physical (paper) or relational (person-to-person message) rather than virtual (IT-based) forms, and then restore and revert back to the more efficient IT-based services once the emergency had passed.

Architecture development sequence

The standard ADM assumes that each architecture iteration will repeat the same cycle, with business-architecture providing the base for all subsequent assessment. The priority of business-architecture is correct in principle, but the way that it’s described in the TOGAF specification is often muddled and misleading – frequently failing to distinguish between high-level strategy, design-decisions at a tactical level, or manual or machine-based processes at operational levels, because all of it is bundled together as “not-IT, therefore must be ‘business’”.

To resolve the resultant mess, we turned to the CMMI-style maturity-model in the TOGAF specification. We then re-viewed these not as maturity-levels but as clusters of related activities that would lead to the respective maturity-levels. We summarized these as follows: -Prepare (and maintain) the foundations

• Step 1: Build an overview of the business
• Step 2: Do horizontal optimization to clean up the mess (and keep it clean) 
• Step 3: Use top-down views to guide and manage strategic change
• Step 4: Use bottom-up views to ensure robust resilience, continuity
• Step 5: Identify ‘pain-points’ and spiral-out to service the business’ deeper needs -Maintain and extend as an enterprise-wide shared capability

Figure 3: Stepping-stones of enterprise-architecture

We describe these as ‘stepping stones’ (see Figure 3), because each set of activities builds on those from the previous levels, and extends the ‘palette’ of architecture capabilities and views. (For more detail on this, see Doing Enterprise Architecture, or the slide-deck “Stepping-stones of enterprise-architecture”.)

In practice, the standard TOGAF ADM covers only Step-2 of this sequence, with some extensions to Step-3. Crucially, it does not adequately cover Step-1: in effect, it is presumed to exist already before TOGAF starts – which in our experience is rarely the case. It became evident that our existing IT-oriented architectures represented Step-2 optimisations, but were not anchored in a Step-1 shared overview of the agency’s overall business – a direct cause of conflict with everyone else in the agency. Without that Step-1 overview, we also had nothing to anchor the required Step-3 implementation of strategy: in fact, architecturally speaking, any implementation of IT-strategies would – and again, clearly did – further sour the already strained relations with the rest of the business. From this, it was clear that rebuilding the Step-1 foundations – identifying the real ‘architecture of the business’ – was an urgent priority for the architecture team.

The architecture of the business

Techniques that we used to describe this high-level overview included the ‘Vision / Role / Mission / Goal’ stack, the Results Logic diagram, and the Functional Business Model. All of these describe aspects of the business that remain relatively stable over time, and can thus act as an anchor for the remainder of the overall architecture of the enterprise.

The Results Logic is a variant of Vision / Role / Mission / Goal which is popular with state-government agencies. When used properly, the diagram makes it easy to see what each part of the agency aims to do, and why. It consists of a ‘tree’ of interdependencies, linking each service-group upward through the reasons and metrics to the core anchor of the overall business purpose for the agency:

• overall priority or Vision for the broader community (‘government priority’)
• client result – outcomes for the end-clients (‘services to citizens’)
• enterprise result – measure that would indicate that the agency outcomes and the client outcomes have been achieved
• intermediate result – tree of linked outcomes of subsidiary Missions
• premise – the core assumptions defining the Role of a service-group
• service-group – the groups delivering specific Missions

This can then be linked to other tools such as the Business Motivation Model, which supported as standard in many enterprise-architecture toolsets. The one danger with a Results Logic is that it can misused to justify whatever structures already exist. Some care needs to be taken to start from an idealised ‘to-be’, and work backwards from there.

The Functional Business Model is a layered description of the overall enterprise that is organized in terms of functions or services rather than current reporting-relationships or business silos. The aim is to be able to portray a concise overview on a single page – hence the model’s nickname of ‘Agency On A Page’. To identify the high-level functions, we trawled for subject-headings in standard business-references such as the Annual Report and the agency intranet; telephone-numbers and postal-addresses and public URLs all implied business channels; and so on. We structured the result (see Figure 4) as a two-layer matrix, using categories from the Viable System Model as the vertical axis (see the book The Service Oriented Enterprise: enterprise architecture and viable services at tetradianbooks.com/2008/12/services/ and Visio template and instructions at tetradianbooks.com/2009/01/services-model/). The two main layers represented the customer-facing and internal-support functions respectively – the key distinction being that the latter did not need external contact functions.

Figure 4: Structure of high-level Functional Business Model

These models were presented to and approved by members of the agency’s executive, who authorized the team to take the business architecture to the next level.

However, the enterprise-architecture unit was still managed from within the IT department – a fact which had unfortunate consequences. In a management reshuffle, the existing business-oriented manager was replaced by someone who came from a strict IT background, and who regarded enterprise architecture solely as a subset of IT governance. The EA team were formally forbidden to contact anyone outside of IT; relations with the wider business, which had just been rebuilt at last, instantly collapsed to an all-time low. Soon after this, the EA project was abandoned, and the team disbanded. Various reports in the trade press and general media suggest that serious problems still exist in the agency, in terms of its IT, its relations with other agencies, and its overall cross-enterprise coordination, all of which can be traced directly to those decisions. The simple lessons-learned from this incident is that enterprise-architecture is a business capability that belongs to the entire enterprise – not the IT department.

Summary

In its standard form, the TOGAF ADM is likely to be too IT-centric for the needs of many government agencies. However, with minor structural changes, in accordance with the TOGAF guidelines, the ADM can be adapted to match any required scope or scale of enterprise architecture – including aspects of the architecture which may not connect with IT at all. This article provides descriptions of how to do such adaptations, and examples of how the amended ADM can be used in practice.

Tom Graves has been an independent consultant for more than three decades, in business transformation, enterprise architecture and knowledge management. His clients in Europe, Australia and the USA cover a broad range of industries including banking, utilities, logistics, engineering, media, telecoms, research, defence and government. He has a special interest in architecture for non-IT-centric enterprises, and integration between IT-based and non-IT-based services. Contact: -Email: tom [at] tetradian [dot] com -Weblogs: weblog.tomgraves.org and sidewise.biz -Twitter: @tetradian -Slideshare: tetradian -Publications: tetradianbooks.com Thanks, Tom! Please download the full version of TOGAF 9 at theopengroup.org. You can also contact me at john.polgreen@architecting-the-enterprise.com or at 410-980-6287 for information on TOGAF certification courses - one will be held at 1101 Pennsylvania Ave. NW, Washington, DC from September 8-11. What are your thoughts? Do you have some TOGAF or TOGAF-like experiences in your agency? I'd very much like to hear your opinion.