Towards a whole-enterprise architecture standard – Worked-example

Blog: Tom Graves / Tetradian

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.

This is a follow-on to a six-part series on proposals towards an enterprise-architecture framework and standard for whole-of-enterprise architecture:

This part explores a worked-example of how to use all of the previous material in the series: the core-concepts from Part 2, the metamethod from Part 3, the metaframework from Part 4, the practices and requirements for toolsets and suchlike from Part 5, and the skills and training outlined in Part 6.

Yet what can we use for a worked-example? I spent quite a while exploring the long list of business-questions back in the post ‘Selling EA – What do EA clients want?‘, and developing step-by-step processes and scripts for each of them. But it became clear that whilst all of those questions – such as ‘What can and can’t we automate?‘, or the old classics such as ‘How do we make more money?‘ – are all certainly valid, they’re also all a bit too much high-level for where most architects are likely to start. What we needed for here was something that was quite a bit closer to the immediate needs of our likely initial clients for architecture – and preferably quite a bit more pressing as a question. And whilst we do need to emphasise that whole-enterprise architecture extends far beyond IT, it’s probably worthwhile starting with something IT-oriented, in classic ‘enterprise’-architecture territory, to show a clear path for migration to the broader-scope way of working.

So the example I’ve chosen for here – adapted from real case-work – is a variant on “Should we adopt Gartner’s ‘Bimodal IT’?” – an immediate concern right now for many CIOs and others in the architecture-space. And we’ll do this step-by-step, in accordance with the metamethod outlined in Part 3 of the series:

As per the metamethod, we begin with Purpose, or ‘Why’.

Phase 1: Purpose, ‘Why?’

Every architecture iteration must start with an explicit business-question, to provide the initial ‘Why?’ for the work, and also usually to identify the person requesting (and paying for!) the work.

In this case, we’d started from a somewhat fuzzy, indeterminate question from the organisation’s CIO, around ‘What should we do about so-called ‘Bimodal-IT’?’” – a concept currently much-promoted by the IT-consultancy-firm Gartner. She’d come across the term in various journal-articles and at a Gartner conference, and wanted the architecture-team’s advice before making any strategic decisions on that theme.

(A common assertion we may come across is that architecture must always be subordinate to strategy. But in this case, as in many others, architecture is used to guide assessment for subsequent strategy – that architecture may come before strategy as much as after it. In other words, it’s more an interdependent relationship between them, rather than that one always follows the other.)

For this phase, one of the key tasks is gain clarity on the question. To do this, we’d likely apply a technique such as Five Whys – repeatedly asking ‘Why?’ to dig deeper into the real concerns behind the initial question. This leads to a more clear and explicit summary of the underlying concerns:

“Gain a better balance between innovation and routine ‘keeping the lights on’ within the IT-organisation”
“Provide faster time-to-market for new IT products and services”
“Rein in the proliferation of uncontrolled or undocumented shadow-IT”

And the desired-outcome of the architecture-assessment, which also imply its criteria for success:

“Clear policy for action on all of these themes”

Using these statements as a guide, the next task is to identify the respective stakeholders for this context.

Phase 2: People, ‘Who?’

To identify and map out the stakeholders and their respective drivers, we’ll use part of the Tetradian toolkit, the Service Context model from the Enterprise Canvas suite – often nicknamed the holomap because it maps out the overall broader context for any given service or organisation. In its abstract generic form, it looks like this:

For the purposes here, we’d instantiate a context-specific version, centred around the CIO’s IT-organisation, which would look something like this:

From discussion around this, we can identify and partition the stakeholders into the following groups – first, ‘internal’:

IT-organisation: operations, developers, service-management and others – service-providers
Marketing: running its own IT-operations, centred primarily around social-media – parallel service-providers
PMO (Portfolio/Program/Project Management Office): responsible for governance and change-management

…and ‘external’:

IT-vendors, big-consultancies and trade-journals – nominally responsible for providing equipment and advice
Other IT-practitioners and enterprise-architects, either independent or in other organisations – probable sources of real-world experience

The ‘internal’ stakeholders should be asked about probable needs, requirements and actions.

Of the ‘external’ stakeholders, the vendors and consultancies are acknowledged as having vested interests in over-promoting ‘Bimodal IT’ – in other words, are likely to be indulging in ‘solutioneering’, trying to force-fit each client’s needs to fit their predefined ‘solution – and hence their advice needs to be treated with caution. Some of the trade-journals are likewise regarded as more interested in feeding the ‘hype-machine’ around ‘Bimodal IT’, whether or not the advice is of any value. Other practitioners and enterprise-architects are considered to be more reliable sources of advice, even if sometimes harder to reach.

These assessments provide the guiding-policies for more in-depth exploration of the organisation’s needs around the concerns identified earlier.

Phase 3: Preparation, ‘How?’

The first step here is to do a more in-depth version of what started the CIO off in the first-place – a literature-review. A brief search turns up various articles by Gartner consultants on ‘bimodal-IT’, but also extending the ‘bimodal’ concept into other areas such as supply-chain management. The same search also returns an unusually high level of criticism and critique, not just from other big-consultancies, but from other independents whose only vested-interest is in getting it right – or at least in avoiding disasters for their own organisations.

(For more detail on this, see the section on ‘Bimodal-IT’ in my post ‘Big-consultancies and getting it right‘.)

What can be gleaned from the literature-review is that:

Gartner is correct in asserting that there is no ‘one size fits all’ for IT-management and IT-governance.
Gartner’s proposal to resolve this is a simple binary split of the entire IT-organisation into two distinct, separate parts: ‘Mode 1′, focussed on ‘keeping the lights on’, and ‘Mode 2′, focussed on rapid innovation.
One key group of critiques focus on the psychological and other impacts of splitting an organisation into two parts that are, metaphorically, labelled as ‘Fast’ (‘Mode 2′) and ‘Slow’ (‘Mode 1′).
Another key group of critiques question the binary split itself – Simon Wardley, for example, arguing that the proven practical minimum is a trimodal split, into what he labels ‘Pioneers’, ‘Settlers’ and ‘Town Planners’.

Another theme implied in the literature-review – such as in Wardley’s concept of the role of the ‘Settlers’ group – is the question of migration: about how innovations developed in ‘Mode 2′ would migrate to the ‘Mode 1′ core.

In short, adoption of ‘bimodal-IT’ does not seem to be the all-purpose panacea that the Gartner hype-machine presents: it will definitely need further investigation…

To do this, we turn to another visual-checklist from the Tetradian toolkit, called Backbone and Edge:

Which in turn is based in part on Tetradian’s SCAN framework on complexity, sensemaking and decision-making:

A parallel example to the ‘Bimodal-IT’ context is where we would use SCAN to map out activities for a surgical operation in terms of certainty versus uncertainty (horizontal-axis) and time-before-the-event (vertical-axis):

In this example of the surgical operation:

items toward the left are best handled by some form of automation
items in the middle can use IT for decision-support, but probably not for decision-making
items toward the right can perhaps only be handled by human skill

For the context of ‘Bimodal-IT’, we might use the vertical-axis on SCAN to map out time-criticality such as MTBF (Mean Time Before Failure) or, more usefully, MTTR (Mean Time To Recovery). For the horizontal-axis, though, we have a whole plethora of possible factors, all interweaving with each other, such as:

central control (by IT-organisation) versus control by other domain (HR, marketing etc) versus uncontrolled (‘shadow-IT’)
current governance-mechanism, such as Waterfall, Six Sigma, Lean, Agile, ITIL or whatever – including none
criticality or dependency – in effect, number of stakeholders, and criticality to each stakeholder-group
failure-mode, from fail-safe to brown-out / graceful-failure to safe-fail to allowed-to-fail
pace-layering – rates of change of data, process and/or underlying technology, from decades to days
Wardley-evolution – commodity from product from custom from genesis

On top of this, we could also use SCAN and/or Backbone & Edge to map out the dynamics of change – for example:

how Wardley-evolution takes place over time
how data or processes from experiments ‘out on the edge’ become more business-critical over time, and need to migrate towards the backbone

From this, it becomes clear that Gartner’s ‘Bimodal-IT’ conflates all of this complexity down to a simple binary split – Waterfall for the backbone, Agile for the edge – with no middle-ground and no concept of migration or dynamics at all:

From an architectural perspective, this seems so simplistic and so incomplete as to be downright dangerous… – in some ways actually worse than than the old delusion of ‘one-size-fits-all’. And applied not just to IT, but supply-chain management and other areas as well? Not A Good Idea…

In short, Gartner’s ‘Bimodal-IT’ addresses a valid question, but to which it delivers a ‘solution’ that is at best unwise, or even unusable, for real-world practice.

Yet the concerns with which we started this architecture-exploration still remain:

“Gain a better balance between innovation and routine ‘keeping the lights on’ within the IT-organisation”
“Provide faster time-to-market for new IT products and services”
“Rein in the proliferation of uncontrolled or undocumented shadow-IT”

And if Gartner’s ‘Bimodal-IT’ does not give us a usable answer to these concerns, what else can we use?

The first clue to a usable answer seems to be that, given the range of factors identified in that backbone-and-edge review above, each of those factors implies the need for some distinct form of governance.

Which suggests that, rather than trying to force each context to fit into a single preefined governance-framework, what’s needed instead is an explicit meta-governance, or ‘governance-of-governance’. through which we can create any number of context-specific governance-frameworks, each aligned to the needs of the context in terms of those factors outlined above. This approach would provide us with both adaptability and consistency, because the respective guidance-factors are fully known and understood for each of context. This also reduces the risk of apparent ‘unfairness’, or psychologically-risky labelling such as ‘fast’ versus ‘slow’, and likewise reduces the risk of complaints or backlash when ‘shadow’-type projects necessarily need to brought under firmer governance as their outcomes become more business-critical.

To complete the ‘Preparation’ or planning-phase of this architecture-cycle, we rough out a preliminary proposal for decision on ‘Bimodal-IT’ – based on this concept of meta-governance – and prepare it for review by the respective stakeholder-groups.

Phase 4: Process, ‘What? Where? When?’

This phase is the main doing for architecture-work, and in this case, as is quite typical for whole-enterprise architecture, the real work here is mostly about engaging with people, to act on a question or required change. Sometimes – as in classic IT-centric ‘enterprise’-architecture – the work here might be more technical than human-oriented, but in each case the aim would be:

to apply and test the thinking – and designs, if any – from the previous Preparation phase
with at least some of the stakeholders identified in the People phase
to collectively address and/or resolve the business-concern identified in the Purpose phase

For here, the practical task is to review the outcome of the previous work:

there needs to be a practical solution to the operations/change-governance problem of ‘one-size-fits-none’
Gartner’s ‘Bimodal-IT’ (and ‘Bimodal Supply-Chain-Management’) offers a simple solution, but one that in practice seems so simplistic as to be downright dangerous
the practical answer appears to be a more nuanced meta-governance (‘governance of governance’), with each governance-mode derived from explicit trade-offs across clear criteria (and of which Gartner’s ‘Bimodal-whatever’ would be perhaps the most simple example)

…leading to the question we need to test with each stakeholder-group:

is such meta-governance feasible in practice, or would it be too complicated for people to use?

Armed with the Backbone & Edge visual-checklist and the list of key factors for selection of governance-mode (criticality, dependability, pace-layering, failure-mode etc), we first review the meta-governance proposal with key stakeholders currently active in governance-concerns:

PMO (portfolio/program/project-management office) – for impact on change-governance
legal and compliance – for impact on and alignment with mandated standards and regulatory compliance
data-architects and process-architects – for impact of and on migration of data and/or processes between governance-modes
supply-chain managers and process-designers – for cross-comparison between change-management in the CIO domain and supply-chain domain

From this, it becomes clear that the concept or principle of meta-governance is acceptable to all, and the emphasis on ‘fairness’ based on clear criteria also helps to make it more palatable. The sticking-point for many, though, is that governance-modes are likely to change over time, in line with Wardley-evolution and the like: there is a concomitant need for review processes that provide clear warning of when and why governance-modes would change.

On the basis of this feedback, we adapt the proposals – again, still only in exploratory form at this point – and then do further road-tests with stakeholders likely to be affected directly by a shift from fixed governance-models to a more fluid meta-governance. These include:

IT and process developers – acceptability of criteria-based meta-governance
operations managers, supervisors and staff – clarity on how meta-governance would apply in the operations space
trainers and organisational-development staff – impact on training etc of a shift to meta-governance
shadow-IT developers and users in marketing, sales, operations, logistics, supply-chain and elsewhere ‘out on the edge’ – impact of mandated governance-models, and migration between modes over time

This last group – shadow-IT users and developers – remain the most skeptical about the need for meta-governance, or any form of governance at all. Many are fiercely protective of their supposed ‘independence’, and fearful or dismissive of anything that resembles ‘control by outsiders’ or of “anything that might slow us down”. However, they do – if grudgingly – accept the need for some form of governance for data or processes that become business-critical to others: this may be a key point of leverage to engage them in meta-governance in the future.

With these results in hand, we move on to the wrap-up phase of the architecture-cycle.

Phase 5: Performance, ‘Success’

In this phase, we should:

finalise the architecture response to the initial business-question
identify business-benefits from the work undertaken
identify and set up to act on any lessons-learned
identify further business-questions that need to be resolved, and probable business-sponsors for architecture-work on those questions in potential future architecture-cycles

For practical purposes, we would probably guide this phase with another item from the Tetradian toolkit, xAAR or ‘Extended After Action Review’:

On the CIO’s initial business-question of “Should our IT-organisation adopt Gartner’s Bimodal-IT?”, the architectural-response is a clear and unequivocal ‘No‘. The evidence available both from beyond and within the organisation indicates that the concept of ‘Bimodal-IT’, and the parallel ‘Bimodal Supply-Chain-Management’, is at best overly-simplistic, and almost certainly fatally flawed. Our firm architectural recommendation about ‘Bimodal-IT’ is – to use an old-fashioned phrase – “do not touch it with a bargepole”…

(And yes, worrying questions perhaps do need to be asked as to why a concept that’s so long been known to be so dysfunctional should now be so actively promoted by a reputable consultancy and others. Some observers are openly cynical – such as Simon Wardley, who wryly Tweeted, “It’s a great wheeze for consultants, they’ll flog you a bimodal transformation and in 4-5 years they’ll flog you a trimodal one to fix it.” Fortunately for us, however, such questions are mostly beyond the scope of enterprise-architecture itself…)

We also answer the CIO’s derived business-questions that we uncovered during the Purpose phase – better balance, faster time-to-market, and better management of shadow-IT – by identifying that a more nuanced form of meta-governance than Gartner’s ‘Bimodal-IT’ would be able to address and resolve all of those concerns.

The direct business-benefit is mostly negative, more in terms of what doesn’t now happen rather than what does – namely that the CIO does not commit her IT-organisation to a very expensive, very disruptive restructure that would be all but guaranteed to collapse into acrimonious failure over the medium to longer term.

The indirect business-benefit is that there is now a clear path to define and develop a form of meta-governance that more closely supports the organisation’s needs – the whole organisation, not just the IT-domain. This can be done mostly in-house, by existing governance-related staff, with little to no need for external consultants – again representing considerable cost-avoidance, in many senses of ‘cost’.

The key lessons-learned take the form of a further reminder to be wary of fads and hype, even (or perhaps especially?) from the big-consultancies and big system-vendors. Instead, we need to take note of new ideas, but rely far more on the existing knowledge and experience of our own staff, rather than relying on the sometimes questionable advice of expensive consultancies. We also need to apply whatever meta-governance we develop, via interactive engagement rather than by imposition of ‘rules from above’.

The further business-questions for possible future architecture-iterations consist mainly of exploring, with the various stakeholder-groups, exactly what meta-governance we need, how and by whom it should be applied, and what form it should take. For example, should it be a simple trimodal structure such as Wardley’s ‘Pioneers, Settlers and Town-Planners’, or should it be something more nuanced, yet still simple enough for people to use in real-world practice? The architectural-exploration will also, by definition, need sponsors for the respective business-questions: the CIO has said she’s keen to see this happen, but also accepts that it needs a scope and remit far broader than IT alone.

…and moving on

As can be seen from the last phase, each cycle is likely to elicit further business questions that would need architectural attention. This is one of the key reasons why whole-enterprise architecture must not be viewed as ‘a project’, but as an ongoing capability and discipline that can be called on to assess whole-enterprise implications, impacts and needs for any context within the business and enterprise.

It’s important also to note the timescales here: how it long it takes – or, rather, doesn’t take – to deliver genuine business-value. Answering that one question above would have taken an experienced enterprise-architect probably no more than one or two days’-worth of time – and most of that would have been spent in dialogue with various stakeholders. In other words, a cumulative cost of at most of perhaps a couple of thousand dollars, allowing for the high effective cost of some of the more senior stakeholders’ time. But the potential savings for the CIO, from avoiding the ‘Bimodal-IT’ trap, could well be in the tens to hundreds of millions of dollars – a very significant return-on-investment for architecture!

(This isn’t an arbitrary exaggeration: I’ve had first-hand experience where a two-hour discussion from a whole-enterprise perspective identified and resolved key architecture-flaws in a one-billion-dollar transformation-project. Unfortunately those same flaws were then reintroduced two years later, on the big-fee advice of yet another big-IT consultancy, causing exactly those failures and excess-costs that we’d warned about – but that’s another story for another time…)

There’s much more we could go into here – the fractality of the Five Element process, for example, which also leads to multiple architecture-cycles all proceeding in parallel at different timescales, ranging from minutes to years. But that’s enough for now, I think? Over to you for comments, anyway.