Enterprise Architecture has to involve a level of governance, including the need for standards and review of proposed architectures. I’d like to think that this is not a controversial statement for me to make. Enterprise Architecture must involve changing the overall architecture from what it would be in the absence of the program – otherwise, what’s the point?
So, architecture reviews are part of enterprise architecture, and most organizations that I’ve seen have some kind of formal architecture review as part of their overall quality gate process. Whether they’re called the Enterprise Architecture Review Board, or the Technical Steering Committee, or the Architecture Quality Meeting, the purpose (on paper) is the same – to review proposed architectures and, in theory, require changes on occasion.
However, not every architecture review process is actually effective. I’ve seen a few that were effectively a pointless waste of time, in that you could have just not had the meeting each week and achieved exactly the same outcome. Here some symptoms of review processes that have become neutered.
1. Excessive use of delegates
One sign that I’ve seen is where each meeting of the review board has a minimal attendance, with most members begging off and nominating an attendee to vote on their behalf. I’ve sat in meetings where one person has said with a straight face “Dave votes yes. Tom votes yes. Nancy votes yes. Sarah votes yes. Steve votes yes.” If so few people see value in attending, week after week, what does that say about the value of the meeting itself?
2. Zero rejection rate
Implicit in reviewing architecture is that now and then some things will be found wrong and changes required. If this never happens, if the review board is a pure rubber stamp, then what is the point in using up a meeting room for this?
3. No consideration of architecture principles
Part of review is consideration of how well the proposed architecture matches the organization’s established architecture principles. At least… it should be… but in practice, I’ve seen organizations that, even when they review the architecture, it’s more on the basis of technical quality than whether the proposed architecture matches the established architecture principles. Which is arguably a useful exercise – but not the point of an EA review.
4. Woolly principles
Even when reviews check for compliance with architecture principles, there might not actually be any point if the principles are woolly enough to be disputed. One principle that I’ve often seen is “projects should deliver tangible business value to the organization”. Well, thank god that the EA department is here to suggest that. In practice, such principles are pointless because all it needs is for the project sponsor to argue that yes it does (and hopefully, most sponsors would not have approved the project in the first place if they didn’t think that it would add value) – so then it becomes a silly ‘yes it does! No it doesn’t!’ dispute.
5. No cutoff dates for architectural exemptions
A standard technique with architecture review is the use of exemptions – an architecture that doesn’t comply with architecture principles can be approved, but on the understanding that it is non-standard and needs to be revisited. But some organizations grant the exemptions with no cutoff date for revisiting and review… in which case every exemption becomes permanent, and to borrow a line from “Pirates of the Caribbean”, the architecture principles is more what you'd call "guidelines" than actual rules.
If you’re going to spend valuable time in review meetings, it’s important that the review meetings accomplish something. These are five signs that yours aren’t.