29 August 2009

To Be, or Not To Be

This post addresses the relative merits of a 'to-be' architecture versus an 'as-is' architecture. I am assuming for the purposes of this post that the task to be performed actually requires an architecture exercise to be performed (I will cover this topic in a later post).

Where to begin?
Common wisdom seems to state that all Enterprise Architecture exercises must begin with the creation of a fully inclusive 'as-is' model, describing all elements of the business to be transformed. It is suggested that this 'as-is' model should be completed before any attempt can be made to formulate the target 'to-be' architecture.

I prefer a different approach.

The Never Ending Story
The main problem with the development of an 'as-is' model is that by the time such a model is complete the business by necessity has moved on, and the model is out of date. The model then needs to be revisited in an endless cycle. A second problem is that the 'as-is' model carries little value as it simply tells the business what they already know (and if they do not know it how is an architect going to create a correct model).

Know your Destination
My architecture activities always begin with the development of a 'to-be' Enterprise Architecture that clearly articulates the future vision and strategy of the Business and sets the direction of travel for all development activities. Such an architecture adds value quickly by converting the ambiguities of strategic vision into specific decisions. It communicates the vision to all interested parties and allows transformation activities to progress in a much shorter timescale than would be possible if time were first taken examining the status quo.

Be Pragmatic
Just like an 'as-is' architecture, a 'to-be' architecture runs the risk of becoming a cottage industry. To avoid this, focus first on the breadth ensuring that an overall framework is put in place describing the entire vision at a high level. This sets the context within which development activities can take place. Depth can then be developed on a piecemeal basis driven by specific demand according to business priorities.

Live and let Live
Always remember that the 'to-be' architecture is a living model that should be allowed to develop over time, and should be agile enough to adapt to the ever-changing business vision. Be concerned if a month has passed with no changes being required to the 'to-be' model.

Clear as Crystal
Engineering discipline is essential in the creation of the model (I would say that - I am an engineer by training after all). Remember that the purpose of the architecture is to remove ambiguity, Use of an unclear diagramming notation, or failure to use the notation in a consistent manner will simply replace one form of ambiguity with another. I will post further on what constitutes a good architecture in the future.

So When do I do an 'As-Is' Architecture?
If a business absolutely wants a high detail 'as-is' architecture, and as an Enterprise Architect you cannot convince them of the alternative approach, then you have a choice. Walk away and seek more constructive work, or develop the desired 'as-is' architecture and guarantee yourself a healthy income for the next few years - but don’t expect at the end to be heralded as an agent of change and an asset to the organisation.

The Enterprising Architect


  1. Jon,
    Some interesting points made, but isn't there value in an 'as-is' architecture. Doesn't it for the basis of how you move to the 'to-be' ? Informing the technology what needs to be done and through them the business in how much needs to be spent and how long it's going to take ?

  2. Fair point, Dave, but this, IMO, is the difference between the theory of EA and the practice. In theory, if we could stop time, it would make sense to develop a full as-is model and a to-be model, and from this calculate the overall cost and benefit of the change. In reality this will give us an excellent picture in three or four years time of how much it would have cost to get to where we needed to be last year. The as-is will develop naturally as projects are initiated to deliver priority elements of the to-be vision - and this will be the as-is at the time the project starts - the as-is we really need. This is, I believe, the pragmatic and realisable approach.

  3. I understand the approach and to some extent agree. However I prefer the "just in time" As-Is creation approach. This is creating parts of the As-Is to complement and understand the To-Be you are creating.

    Thus you have a basis to create a roadmap and are creating both the As-Is and To-Be in parallel. You do need to produce the As-Is in order identify reuse, rationalization and redundancy.

    I do agree that there should already be an understanding of the As-Is of the Enterprise. When you create it to understand the To-Be you may need to look outside of the scope of To-Be. But no need to detail the As-Is of the entire enterprise.

    I have used this approach successfully and added real value to an organisation.

  4. Malcolm - this goes to the heart of my preferred approach - develop the as-is by implication but derive funding for this activity from active projects and in return add value and save time, thus creating a win-win. I will submit a post on this subject in the near future.

  5. Every job interview I've attended has always had that fateful question: "And where do you see yourself in 5yrs time?"... I.E. If you can't plan your own future, how can you help with ours?

    Having a destination should be seen as an imperative for all journeys, otherwise how do you know where you are going to?

    In large 'Agile' organisations the As-is picture is very likely to change day on day, through acquisitions / mergers and the vagaries of the economy. And the inability to remember just how legacy systems were strapped together in the past. Thus, the idea of a 'Just-in-time' As-is Architecture covers all starting points and makes Financial scene in only doing what's needed when it's needed. Save the effort of creating a White-Elephant As-Is, that will require constant re-working, and utilize the expertise in defining individual project's areas only when it's needed to plan the journey...