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?