Inside-in, inside-out, outside-in, outside-out

I’ve been brewing how to describe some key distinctions about the way we view our architecture, about how we see its role, and its relationship with everything else in its context.

Seems to me that there’s a simple two-axis matrix we can use for this:

• where we focus – inside (centred on our own internal context) or outside (from the broader context, where everything is ‘the centre’, all at the same time)
• where we look for the business-drivers – in (looking inward to our own context) or out (looking outward to the broader context)

This gives us four types of perspectives onto the architecture(s):

• inside-in
• inside-out
• outside-out
• outside-in

Note that each of these perspectives is valid in its own way. But if we use an inappropriate perspective for a given task, things can go very badly wrong – so we do need to be clear which perspective we’re using at any time, and why.

Inside-in is where we focus on a single specific context, and assess it in its own terms. Within this perspective, we assume that the external business-drivers remain the same: it’s solely about the internal view, about enhancing internal consistency, internal efficiency and effectiveness. This is the kind of perspective we need for re-factoring code and the like so as to reduce technical-debt, or for the ‘clean up the mess’ type of architecture-work that must be done to create stable foundations for subsequent strategic development.

Inside-out is where we focus on a single context, and assess the impact of changes in the external business-drivers on that context. Everything external is viewed solely in terms of that context – such as in TOGAF‘s ‘Business Architecture’, which in essence is ‘anything not-IT that might affect IT’, as a precursor to strategic review of IT-requirements and IT-architectures. This is a perspective that we do need for domain-architectures, such as TOGAF’s focus on IT, in ITIL‘s focus on IT-service-management, and in many aspects of BPM business-process management.

Outside-out is about understanding the broader context in its own terms, regardless of how our own organisation acts within the context; everywhere and nowhere is ‘the centre’ of the architecture, all at the same time. In other words, it’s about the ‘big-picture’ of the ‘extended-enterprise’ or ‘shared-enterprise’ context, independent of any of the specific actors within that context – a kind of ‘logical view’ of the context as a whole. These are the sets of views that we would develop in layers 0-2 (‘Enterprise’, ‘Scope’ and ‘Business-services’) in Enterprise Canvas, and usually form an essential precursor for an ‘outside-in’ view. Typical examples elsewhere in business include futures-development through methods such as causal layered analysis, and strategic-conversation such as in the long-running series of Shell Scenarios.

Outside-in is about understanding our choices in how our own context can play a valued part within the broader shared-enterprise context. Typical examples of views used within this perspective include customer-journey mapping, value-network analysis and whole-supply-chain modelling. Note, though, that this perspective is as much about our own organisation’s vision, values and policies in relation to those touchpoints and value-flows, as it is to the touchpoints etc themselves: the business-drivers for the overall shared-enterprise are described more within the ‘outside-out’ perspective, whereas this is more about that broader context interacts with our concerns and choices.

Implications in EA practice

For viable enterprise-architectures, all of these perspectives will be required: inside-in, inside-out, outside-out and outside-in.

A full-scope architecture-development would typically use these perspectives in the following sequence:

• inside-in: develop a broad understanding of what clean-up would be required within each domain in scope
• outside-out: develop a broad understanding of the overall business-ecosystem, in its own terms, independent of our own organisation
• outside-in: develop a broad to detailed understanding of how others would interact and transact with our organisation, from their perspective
• inside-out (usually together with a detailed inside-in): develop a detailed architecture for each domain, each from its own perspective, drawing on each of the previous perspectives for guidance

In practice, there will always be some iteration between these perspectives, and ‘inside-in’ and ‘outside-out’ can be switched-over if preferred. In effect, though, this sequence above defines the precursor-order: an ‘outside-in’ perspective will depend on clarity about the overall context, as described by ‘outside-out’; and an ‘inside-out’ perspective will only be viable if all of the other views are already in place.

A narrow-scope domain-architecture development will often need to use only an ‘inside-out’ and/or ‘inside-in’ perspective. (This applies to all domain-architectures: IT, business-of-the-business, HR, environment, security, safety and so on.) This will be valid if the broad-context work has already been done and is available to guide the selection of relevant ‘external’ business-drivers. If the broad-context work has not been done, a narrow-scope development is almost guaranteed to cause architecture-fragmentation problems such as the infamous ‘business-IT divide’.

Very few current architecture-frameworks cover the full set of perspectives: TRAK is one of the rare examples here, though DoDAF/MoDAF also sort-of comply. Most other current mainstream ‘enterprise’-architecture frameworks – such as TOGAF, CapGemini IAF and FEAF – are actually domain-architectures, typically focussed primarily or exclusively on IT, and incorporating only either ‘inside-in’ and/or ‘inside-out’ perspectives. They can and usually do work well as guides for domain-architectures; but without the ability to create or use ‘outside-out’ and/or ‘outside-in’ views, they are all but guaranteed to be problematic if attempts are made to use those frameworks for true whole-of-enterprise architectures.

For example, as currently specified, TOGAF 9 Phase B ‘Business Architecture’ is actually an ‘inside-out’ view from an IT-specific perspective: in effect, ‘anything not-IT that might affect IT’. It does not include anything that does not directly affect IT. Given that IT typically represents some 3-5% of overall budget, and rarely more than 10% even in information-centric industries, the ‘anything that does not affect IT’ may well be a very large proportion of the organisation’s business. Since interdependencies between the non-IT items are likely to be at least as business-critical as those within IT and/or between the IT and non-IT items, this implies that TOGAF and similar frameworks should at present be used only for IT-specific domain-architectures. They should not be used for whole-enterprise architectures, and cannot be used for business-architectures and other non-IT domain-architectures without extensive domain-specific adaptation – the methods for which are not described in the current framework-specifications.

[Again, TOGAF and suchlike are very good enterprise-IT-architecture frameworks, but they are not suitable for usage outside of that quite narrow scope. Describing them as enterprise-architecture frameworks is highly misleading: is there a risk that doing so could be an offence under the Trade Descriptions Act? 🙂 ]

Again, a quick summary:

• for domain-architectures, inside-in and inside-out perspectives will usually suffice
• for full-scope enterprise-architecture, all four perspectives will be needed: inside-in, inside-out, outside-out and outside-in

Hope this is useful, anyway – comments or questions, anyone?

Update:

For further ideas on ‘outside-in’ architectures, see:

• John Hagel: ‘Unanswered Questions at Supernova 2007‘ (June 2007)
• Richard Veryard: ‘Outside-In Architecture‘ (August 2007)
• Fred Cummins: ‘Outside-In Business Architecture with VDML‘ (January 2012)