I shared my thoughts on Architecture Review Boards in yesterday’s blog. Related to that topic I often got the question on what decision rights my Enterprise Architecture (EA) team should have. My answer always was a question “why should I care?”
Your company’s architecture is changed thru projects that require new or changes to IT enabled capabilities. As EA you should only be engaged in the larger ones or you’ll quickly run out of bandwidth. Those projects should have a governance structure where an enterprise architect or the chief architect is on the steering committee/senior stakeholder group. There the architect can voice concerns and if needed escalate even higher up the chain.
If the architect had the decision rights on some RACI or DICE chart for the project’s solution architecture would the behavior and process change? No. E.g. Architect disagrees with a procurement leader on the procurement software vendor we should use for a purchasing transformation. Does the procurement leader just go “I disagree with you but, yes sir, you decide what my team will use”. No they escalate to their boss and the architect escalates to their boss. The bosses meet and they make a decision or they escalate even higher. It might not work exactly that way in your company but I bet it looks awfully similar.
The EA team should have decision rights on architecture standards, but don’t confuse that with EA having decision rights to enforce them. If a given architecture standard looks to get in the way of someone achieving their business goal get ready to escalate.
That sounds kind of inefficient. I happen to agree with that statement. It’s very inefficient. EA should have decision rights on IT architecture and not be challenged. Unfortunately, that seams to only be reality in a Chief Architect’s dream world.