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