We're all Architects (aren't we?)
Over the last few years the title "Architect" and its use by individuals and businesses alike to describe a variety of change activities has become increasingly popular (I would go so far as to say ubiquitous). It has therefore become extremely difficult to have a meaningful discussion about what makes a good architecture and what are the best methodologies to employ in its development. For this reason I am posting my thoughts on whether the task to be performed is actually one that requires an architecture, and if so, how complex this architecture really needs to be.
Inspection versus Intuition
It is fair to say that given sufficient time and resources, the production of an architecture that clearly articulates the future vision of the Business will always provide long term benefits. However, in the real world, time and resources are not always available, and businesses will fall back on that age old stalwart, gut feeling.
If asked by the Business to formulate a solution to a specific problem, or make a change that has already been identified as beneficial, feel free to suggest the long term benefits of a more wide reaching enterprise architecture exercise, but be prepared to abandon architecture in favour of a more immediate activity. (After all, the gut feeling of the Business may well be the right answer, and spending their money to prove them right will not be popular).
This brings us to the next question:
Repair, Renovate or Rebuild?
Before embarking on the development of an architecture, establish first of all whether the scale of the activity being commissioned justifies it. A simple bolt-on or fix to existing capability does not justify the cost of a fully fledged Enterprise Architecture. If, however, the goal is to transform the Business over a period of time then a to-be Enterprise Architecture is absolutely essential to ensure that the vision and strategy is properly articulated and all ambiguities and conflicts are resolved.
Builder, Draughtsman or Architect?
Consider carefully the role you are being asked to perform. The questions often asked by the Business require skills other than those of an architect. If asked to document current ways of working to allow others to understand and operate the Business effectively, then do not develop an as-is architecture. It is an instruction manual that is required here, and the role is better suited to technical authorship.
Remember, architecture is not always the answer to every business need.
It’s Not the Size that Counts
Even when it is clear that an architecture is required, develop a to-be architecture first (see my previous post on this matter) and resist the temptation to embark on a fully fledged, detailed model on day one. Instead, establish a skeleton architecture with breadth, and then develop the detail within specific areas to suit the priorities of the Business.
And so in conclusion, I would recommend that all architects consider first not what type of architecture is required, but whether architecture is needed at all.
The Enterprising Architect