Should an architect act as a guide, a reviewer or both?
First of all, lets conclude that running a larger program without architecture guiding or reviews is a proven recipe for failure. It's like building a large housing complex with many apartments without a blue-print. Just putting together carpenters and other craftsmen does't work.
Architecture review
So lets do reviews in our program at regular intervals in order to assure the quality and adherence to long term goals in the program. This is the method described in TOGAF and implemented as architecture governance in many organizations.
The benefit with this approach is that if things go really wrong, we can delay or stop the program so that they can improve their work and deliverables. It will also put a limited burden on the people in the architecture unit.
However, the issue with this approach is that the business often overrides the architecture team and implements quick solutions. Something that often is bad from a long term perspective. Do you remember the 640kb limit in MS-Dos?
Another issue is that if you are running a program and somebody from the outside tell you that you have to adhere to new rules, the response is often f*ck-off. Quite understandable because they should have known the rules beforehand, before starting the program. So one of the key points for a success is to communicate that there is going to be a review, the scope for the review and what the review will cover for type of questions.
It's neither sufficient to have a list of architecture principles and just answer yes and no if they are fulfilled or not. The program architects, (or the vendor) have to explain how these principles are fulfilled and why there are deviations. There must be some motivation for not following the rules as well as pros and cons with different approaches.
Architecture guiding
The other approach architecture guiding is to act as a dive guide.
For those not familiar with scuba diving, let set some basics first:
If we go for the same approach in program architecture, how would this work?
Worst case scenario for a failure of of large program is a slow death of the company. A company that can't change when there is disruption in the market will disappear. Do you still use Ericsson, Motorola or Siemens phones?
The architects should have a certification to show that they have learned the basics in architecture. Examples of these are TOGAF Certification, IAF level 0 certification or a local certification as from Dataföreningen i Sweden. All these certification shows the the architect have learned the basics, but not that they have experience of running projects on their own.
As an architect, you should always have an other architect to discuss different questions with. It's very hard to design solutions by yourself and evaluate different ideas.
Use an architect with proven experience of the same kind of architecture assignments, unless you have done several times before. This architect will make a plan suited to the program goals and communicate this plan to all people in the team as well as the central architecture team. If the plan doesn't work, raise the concerns to the program manager and the central architecture team.
But don't forget to do the formal review. It will be a piece of cake with your preparations.
Prologe
Yes, I dive without a guide, but only after reaching fifty dives in the dive-log. I'm always diving with a buddy and never alone. If it doesn't feel good, I don't go into the water.
This article was first published internally at Capgemini, Swedish Architecture Community Newsletter #46 in October 2013.