Myth: Formal Architecture Reviews Improve Architecture

Architecture reviews help identify issues and get insights, only prioritized executed actions improve architecture. Issues to actions is easier said than done. The impediments to actions are several (mostly cultural).

I like architecture reviews. Call them audits, evaluations, or discussions. If done well (*) it does give good insights. No architecture is perfect. There is always something to find – a security issue, an extensibility issue, a technology choice issue, and/or an interoperability issue.

* Most of the times reviews are smelly. Typical smells – too many reviewers, done after most decisions are made and the goal is to defend, too broad and not targeted for any specific quality attribute, calendar (process) driven, and non-accountable reviewers.

The output of an architecture review is a formal report with problems and actions owners. Sometimes, this report is too big to read and is very negative (full of criticisms). The output of such reviews leads to:

1. De-motivated team OR
2. Architect blamed for not being able to defend, loss of credibility both ways OR
3. First impressions amplified to senior leadership (call-2-action), leading to micro-management of the team/architect.

This is the reason, that consultants are generally disliked in the industry. Even when the advice they provide is genuine, useful and helpful.

The two (less than three) things that have worked for me, to provide inputs are:

1. Don’t provide too many inputs at a time. LESS THAN THREE IMPROVEMENT AREAS is statistically good. Provide this input with MORE THAN THREE AREAS OF STRENGTH. Evolve the architecture incrementally.
2. Use offline collaboration platforms to provide inputs. Early peek & influence into the thought process, before it gets cemented.

Being non-judgmental, avoiding early escalation and engaging with a clear goal to be accountable is critical. A litmus test of success, is when the team/architect volunteer for a review, and are not driven to review by process.

A downside of this approach is the chance of loosing credibility with the management team. An audit is supposed to find all issues, so that we are perfect. However, my experience with software projects tells me that it’s better to lose credibility with the management team, than to fail in the project. Failure in software projects is not just architectural, but also due to:

1. Lack of a good problem statement.
2. Sponsorship for the project in the organization
3. Project Management
4. Team Skills
5. …and many more.

Therefore, as an architect, its necessary to:

1. Manage negative attitude towards architecture & architects.
2. Improve communication with development teams, involving and engaging them.
3. Improve communication with management teams, listening and engaging them.
4. Selling architecture – value selling or solution selling. Adopting the right approach.

Small. Focused. Engaged. Incremental. Action Oriented….is the way to improve architecture.

Nobody reads multi-page critical review reports. Those who do, pray that their intent is genuine & not political.