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-driversin (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:

 

8 Comments on “Inside-in, inside-out, outside-in, outside-out

  1. Great piece Tom. It’s really important that enterprise architects understand these distinctions. That said I will (partially) disagree with you about one thing. I don’t think you can do a proper Enterprise IT Architecture without some significant element of outside-in. I think this awareness is also spreading amongst the TOGAF community (at least the thought leaders therein) and other EITA practitioners. People see the limitations of IT-centrism. But that just makes understanding your four perspectives even more important.

  2. Hi Stuart: “I don’t think you can do a proper Enterprise IT Architecture without some significant element of outside-in” – that’s exactly my point there: TOGAF at present doesn’t really support it.

    (And neither do most other purported ‘enterprise’-architecture frameworks: the problem is by no means specific to TOGAF here. Likewise many other domain-specific frameworks or notations – BPMN, for example. One of the few strongly IT-oriented domains that does understand the real need for outside-in as well as inside-out is security, which I know is a major focus of yours – in fact if TOGAF etc are forced to change, it will probably come more from the need to address whole-of-scope security-concerns than from anything else. But I digress… again… 🙁 🙂 )

    I think it is possible to do a usable IT-architecture using only an inside-in and inside-out view (i.e. solely IT-centric). It won’t be as good – or perhaps as resilient – as one that includes an outside-in perspective, but it’ll probably do the job well enough for many people’s needs. After all, TOGAF does work reasonably well for the specific domain-set for which it was designed – and it’s important that we acknowledge that.

    One of the other useful aspects of this particular taxonomy of perspectives is that it takes some of the heat out of the “is it or is it not a ‘real’ enterprise-architecture” debate. In essence, it can only be usable as a ‘real EA’ framework if it does cover the full set: otherwise it’s either a domain-architecture (a domain-centric inside-in and/or inside-out – as per TOGAF etc), an overview-only frame (outside-out, outside-in – as in some forms of strategy) or a somewhat incomplete-mixture (other combinations of perspectives – as in the outside-in / inside-out of basic customer-journey mapping).

  3. Stuart – another quick comment to (I hope) address your concern about “I don’t think you can do a proper Enterprise IT Architecture without some significant element of outside-in.”

    I do agree with your point there, which is why the “if” in the following quote from article is extremely important:

    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’.

    The ‘broad-context work’ (i.e. to create outside-out and outside-in perspectives) provide the means to “guide the selection of relevant ‘external’ business-drivers”. If that work hasn’t been done, and/or isn’t linked correctly to the inside-out perspective, in essence the business-drivers will be selected on the basis of guesswork and assumptions – not a good idea… :wry-grin:

  4. I was thinking the same thing as Stuart until the if statement. I believe this would be very useful for future EA frameworks and should answer the “What, How, Why, When Who, Where”.

    The perspectives you outlined could direct the following:
    What are the Applicable Assets / Artifacts for each and for the subsequent relations between
    When they should be used, dependencies, related architecture work effort
    Why – you answered this
    Who is responsible
    How they should be used similar or related to when
    Where??

    Just some food for thought…as always good stuff

  5. Adam – very good points.

    The catch is that that kind of detail is highly context-dependent, whereas the perspectives themselves aren’t. (Or aren’t so much context-dependent, anyway.)

    The perspectives are each a direction to look (or, in ISO42010 terms, clusters of viewpoints), whereas what you’ve summarised above is what can be seen from that direction, the content of views from those viewpoints – which is quite a bit different.

    It’s well worth exploring further, though: are you up for that exploration yourself, or are you waiting me to do it first? 🙂

  6. I agree..
    “The catch is that that kind of detail is highly context-dependent” What should be used and when. I believe taking your / a perspective approach allows for the right amount of variability in the what, not so much the when, but it really provides the right thinking. So, if we associate the perspectives with architecture work and each other, choosing what should be come less complicated.

    Today, I constantly walk into architecture practices at companies that are focused on creating artifacts or value offerings based on TOGAF architecture domains vs. taking a perspective approach on top of enterprise layers where by technology is just an enabler of many to set in motion the enterprise’s purpose.

    I really think the “x architecture” taxonomy has screwed this all up. To me its layers of an enterprise which require a certain perspective to support a work effort which drives out the purpose, design, plan and execution or governance of execution.

    Anyhow, that is the approach I tend to take and building the “what” as we work, sometimes it’s reuse of existing artifacts, sometimes building new, sometimes it’s enhancing. I find it really hard to pick up from the existing EA frameworks and subsequent models.

    Hope this makes sense

  7. oops..mis-typed what I meant in the second to last paragraph. “drives out the purpose design, plan and governance of outcomes”

Leave a Reply

Your email address will not be published. Required fields are marked *

*