Architecture: To-be is top-down, as-is is bottom-up

A few folks in the enterprise-architecture community have been talking recently about ‘as-is’ versus ‘to-be’, and how in general we should aim to do the ‘to-be’ architectural-assessment first rather than drown in the detail of the ‘as-is’.

For design purposes I would agree with them: although I’ve had a few cases where we needed to start with the ‘as-is’, it’s a good general rule to do the ‘to-be’ first, otherwise there’s a real risk that what we currently have becomes set in stone as ‘the requirement’.

It struck me, though, that there’s another way we could look at this, using the extended-Zachman layering:

The extended-Zachman layers are also a perspective of time: as we move down through the layers, we also move from future to past.

The ‘Enterprise’ layer, row-0, extends indefinitely into the future – in other words, the extreme end of ‘to-be’. The enterprise-vision at this layer is ‘the requirement’: everything below this level is just an alterable implementation of that overall desire.

The ‘Action-record’ layer, row-6, is about the immediate ‘Now’ and further into the past – in other words, the ‘as-is’ or ‘as-was’. Everything above that level is an aspiration – a ‘would-like-to-be’ – or an abstraction of what is or was.

Most of an architect’s work takes place in the mid-range, between row-2 ‘Business-model’ and row-4 ‘Design-model’. It’s about the relatively-near-future, moving downward from strategy to tactics, through project-plans to project-implementations – aiming always towards enhancing real-time operations, the brief moment of transition from the aspirations of the row-5 ‘Action-plan’ to the unchangeable reality of the row-6 ‘Action-record’. And it’s always an abstraction, a meeting-point somewhere between top-down aspirations and bottom-up constraints from the real-world.

Hence anything about the to-be will always be top-down in some sense. Anything about the as-is will always be bottom-up.

We then link this with another theme that comes up often in architectures:

  • things are usable to the extent that they’re architecturally complete
  • things are re-usable to the extent that they’re architecturally incomplete

By definition, everything in the real world – the as-is – must be architecturally ‘complete’ in order to work: in extended-Zachman terms, everything real must consist of a complete composite of assets, functions, locations, capabilities, events and decisions. Hence some of the key architectural activities consist of finding abstract components or ‘building-blocks’ in the as-is, and then creating new configurations of those abstract components to make something real – in other words, respectively moving bottom-up and top-down, from as-is to a new to-be, and from the abstract to-be to a new real as-is.

Hence the extended-Zachman layers, and the transitions between those layers, also tell us whether we’re moving top-down or bottom-up, from to-be or as-is. So whenever we’re talking about something that already exists – even if it’s a new technology that we haven’t applied yet in our own organisation – we are always moving bottom-up. Whenever we use an existing ‘architecture’ from a vendor, we are always moving bottom-up. In other words, it’s a constraint that we need to match up to our own top-down requirements: and we should never use any existing pre-packaged components without assessing carefully, top-down, that they do match our requirements – otherwise we end up with some vendor defining our business for us, which is not a good idea.

The inverse is also always true: whenever we come top-down, the technology or processes or whatever to implement that ‘vision’ may not actually exist. Everything above the real-world of the ‘Now!’ is just an abstraction: not only does it not actually exist, it may never exist. Coming top-down, we always need to look for ways to make it achievable – which means we always need to explore and negotiate with the real-world constraints and options coming from the world of as-is.

The direction we come from tends to define our perceived requirements. Hence in general it is best to come top-down, in order to derive the requirements from that which is actually desired, rather than merely that which is possible. If we anchor the requirements right back to the row-0 enterprise-vision, we know that we can change them in the future, and we know too the direction in which we need to change them. But if we focus too much on bottom-up, we’re much more likely to make the mistake of thinking that the past is the future, ‘the only possible future’ – that ‘that which exists’ is also inherently ‘that which is desired’, regardless of whether it actually aligns with the overall enterprise-vision at all.

Hence in general it’s always advisable to come top-down rather than bottom up; and hence, in turn, it’s usually best to start from to-be rather than as-is, such that our gap-analysis – our roadmap for change – actually works backward to ‘there’ (to-be) from ‘here’ (as-is). If we start from as-is, we also often end up doing little more than trying to find ways to justify the as-is, rather than creating whatever it is that we actually need. This is a very common problem with technology-driven or vendor-driven ‘architectures’.

There is one very good reason to start from as-is: it’s a necessary part of early-maturity enterprise-architectures, and a practice-ground for architects to learn how to create architectural abstractions. In reality, everything starts and ends at row-6, the present and the past: everything else is just an abstraction. But those abstractions are what we use as our ‘building-blocks’ for architecture: so we need to develop our skill in working upward from the ‘architecturally-complete’ real-world composites, deconstructing them into partial-composites or primitives for reconfiguration and re-use.

As I explained in my book Doing Enterprise Architecture, our very first action in developing a new enterprise-architecture should be  to identify and clarify the enterprise vision and overall context. But once that’s established, the next action is ‘clean up the mess’: find out what’s happening in the current business context, clean it up, find common factors, reduce unnecessary duplication, improve cross-silo communication, and so on. We can’t do that unless we start from an acceptance that the as-is is the as-is – that it is the current reality – and work our way outward from there. That clean-up gives us a solid foundation foundation for any future architectural changes – and those redesigns generally do need to be done top-down, starting from a to-be.

So to-be is top-down, as-is is bottom-up; and in general, doing to-be first is the better way to go.

All of this applies to all forms of architectures, by the way: from building-architecture to IT-infrastructure architecture to naval-architecture to enterprise-architecture and beyond.

Comments/suggestions, anyone?

7 Comments on “Architecture: To-be is top-down, as-is is bottom-up

  1. Hi Tom,
    I don’t suppose you’ll be surprised to hear that this is very closely aligned with where I’m going with the 5Di ‘Business Change Design’ style which now includes ‘Commander’s Intent’ (TD), ‘Workforce Day-In-The-Life’ (BU) and Customer’s Experience (middle-out) story lines. I think we have similar views on the over simplistic AS-IS-TO-BE perspectives – I think we need AS-WAS, AS-IS, AS-DESIRED and TO-BE-WITH-PRAGMATIC-TRADEOFFS 🙂 – perhaps something a bit snappier but I think you get the drift! Thanks for the continued input! Nigel

  2. My 10c worth – ‘To be’ is a great place to start so long as the end result becomes ‘as is’ as an asset for the business from which ‘To be’ implications can be considered by the many (and not just architects).

  3. Yes. Yes. Yes.

    🙂

    Good insight.

    I’d also add another dimension: strategy formation (envisioning) to strategy execution (delivering).

    The architect’s job is to match the delivery to the vision ([from]the as-is to the to-be). You have to start from where you want ‘to-be’, what the vision is – and then work out (systematically) what you can use from what already exists, to set off from the as-is.

  4. Many thanks, folks. Not much I can add to that, though I’d certainly agree with Nigel’s comments about ‘as-was’ and ‘to-be-with-pragmatic-tradeoffs’ etc, and Peter’s and Ian’s points about usable execution rather than abstract but unusable-in-practice ‘clever design’.

    Glad it’s been useful to so many folks, anyway. 🙂

Leave a Reply to peter_t Cancel reply

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

*