The over-reaction architecture governance anti-pattern
There are a couple of avoidable behaviors that architects sometimes adopt that generally annoy project teams.
The first is “nick picking” – identifying an apparent issue and then drilling down into it to minute detail. It appears to be an exercise in demonstrating how clever the architect is and how dumb the project team is. The effect often is the reverse. It tends to destroy the credibility of the architect as a business steward that is safeguarding the interests of the enterprise.
Architects do develop a set of useful instincts that allow them to “sniff out” issues embedded in designs. But unfortunately, some architects act like the dog in the park that gets a whiff of food and very shortly afterwards is seen tucking into a stranger’s picnic hamper.
The second behavior is "panicking about nothing” – hearing a rumor of non-compliance and initiating large scale projects reviews, post-mortems and escalations. Often the scale of the intervention is excessive leaving the architect having to justify why it was so important to “cry wolf”.
This behavior is a symptom of architects being disconnected from delivery. The solution architecture will be wrong because it is based on limited information, the project will discover awkward facts that change the original solution. Formal and informal feedback are necessary.
A disciplined approach is necessary to avoid these anti-patterns…
The first rule is focus on what is important – architectural governance must begin with a triage process that identifies high risk activities. Restrict governance to those activities. Yes, you will miss stuff but it is the less important stuff.
The second rule is advise. You have seen the issue coming through the triage process, so give the project the right advice up front so they don’t make the mistake.
The third rule is support. When the project team gets to the critical activity, be there! Make sure they understand your advice and, equally important, that your advice is still fit for purpose. From a process perspective, there needs to be a mechanism for projects to provide feedback on their decisions.
The fourth rule is communicate. Write it down - an architect’s instinct should be captured as a principle, a policy, a guideline or a standard. The triage process should be documented. You must get the knowledge out there, continually – do you have an ongoing communications plan?
The fifth rule is be humble! There is never a need for arrogance. The project team are the people that give architecture worth because they are the ones that deliver. You have succeeded when you have helped them deliver business value. You need their goodwill