The goal of creating an IT architecture that supports the business and adds real value, is shared by technical architects and most CIOs alike.
Achieving that goal means being able to manage the difference between breadth and depth; we have already argued (in IT Architecture in a disjointed world) that architecture can only be done effectively by a team of business and technical people capable of making appropriate trade-offs.
Here we are going to argue that the same principle applies within an organisation’s community of technical architects. No-one knows it all (not even Bill Gates knows everything there is to know about Microsoft products) so you need a well organised and knowledgeable team. Otherwise it’s going to be tough and fruitless.
Businesses don’t stand still because markets and competition doesn’t; so keeping up – or ahead – requires constant change, large or small, simple or complex. Change is challenging for the CIO because the parts of the business and technology systems interact; so it’s not just about identifying what to change to reach the required result – it’s also about predicting the changes you didn’t want and avoiding their consequences.
One brain isn’t enough
Steve Martin aka Dr. Michael Hfuhruhurr knew that. Big systems are too complex to be understood by just one person, and even if Einstein were on the team his explanations and justifications might take too long for most people. But big systems get built, and (most of them at least) managed. How is this possible?
The architect’s conundrum
In this real world, architects don’t understand everything: something has to give. If an architect sacrifices the breadth of an end-to-end view in favour of detail, he won’t understand parts of the system; If he sacrifices a deep understanding of the technology it’s possible he will become overly theoretical and practically useless, foregoing an understanding of what could actually be built.
This ‘breadth’ vs ‘depth’ challenge often results in architects and developers not understanding each other leading to wars (or at least tension) between the enterprise and the solution architects and between the solution architects and the infrastructure architects. This can get really heated if third parties with SLAs to hit and service credits to pay are involved!
Team work makes the dream work
The Chief Architect must take the broad end-to-end view and rely on technical experts to provide the depth. However, in many organisations the technical architects have been dispersed into projects or support teams which may be aligned to business departments or technologies. This creates two problems:
- Firstly architectural support is aligned to systems, not to end to end processes; this is likely to fragment both design and support, and may even result in the need to reduce licence costs as one of the key architectural drivers
- Information flows are impeded between the solution architects and the enterprise architects, particularly if they are physically apart
The architects in an organisation should best be managed as a Practice, by all means retaining distinct focus and responsibilities, but as part of the same virtual team, with a clear responsibility towards the Chief Architect. They may speak with different accents but they must all contribute to the team developing a common understanding the consequences of change on the overall operating model.
Getting the architecture team properly organised is the real secret behind a successful partnership with the business.