Monday, June 1, 2009

How often does the ARB say 'No'

Albert Einstein was once asked what would happen if an irresistible force met an immovable object. He replied that, by definition, in a universe where one exists the other cannot. I was once asked how often the Architecture Review Board (ARB) says "no" to a proposed solution. I think the interviewer was surprised to hear me say, very, very seldom. After all, if we seldom say no, doesn't that by definition mean that the ARB is just a rubber stamp for any project that comes for review?

Since this is my entry, you won't be surprised when I say, no, the ARB is not a rubber stamp. You wouldn't expect me to say anything less, but let me go further and explain how a seldom-say-no review process can, and does, yield the kinds of forward-looking, desired-state architectures you would want to see in a large organization.

To begin with, our company supports a diverse set of technologies and the reason we support such a diverse set is because we are driven to meet business expectations. For example, we have staff, equipment, licenses, and support contracts to enable enterprise level implementations of Oracle, DB2, and SQL Server database solutions. If a proposed application needs a relational database, one would be hard pressed to find a reason why one of these three products won't meet the needs. This is only one example, but suffice to say, we are prepared as an enterprise to support more than one product / solution for any given technology.

Next, we don't just buy and deploy, we take the time to understand, integrate, and document our preferred implementations. You can call these standards, but we prefer the term operating practices because that's what they are. Anyone wanting to know our operating practices relative to database, network, web hosting, or other common technology asset need only consult our internal wiki to learn of the processes, technologies, and desired implementations. There are no secrets and the information is readily available.

Anyone can attend an Architecture Review Board meeting, but the core members are the most trusted individuals in the technology organization. Have a question about application security? The most trusted individuals in the company attend the ARB. Not sure about a database configuration - come to the ARB. And so it goes with network, messaging, middleware, desktop, and on and on. Disagreements just don't happen very often because everyone knows that the primary ARB speaker for any given topic is "The Voice" for that topic for the company.

Also attending the ARB, are the lead developers and architects from all of the corporation's lines of business. They hear week in and week out how the operating practices (standards) are being consistently applied application after application. Quite frankly, we very seldom see a proposal that is out of sync with our desired operating practices, because ... well, who would bring it? The same individuals who are trusted with new solutions are the same ones who regularly attend the ARB - and these folks generally know how to accomplish their business objectives within the well-communicated operating practices. Now, we do hear requests and requirements that cause us to grow our operating practices - that is a perfectly valid expression of innovation. The ARB is receptive to innovative solutions to advance our business capabilities.

Lastly, we have adopted an agenda that begins every conversation with a description of the business problem or opportunity with an eye and ear towards 'how' to accomplish the goal rather than looking for reasons to say 'no.' So, our philosophy is to make sure that any proposals that might not be in line with our desired-state architecture are properly examined, vetted, and made visible to all key stakeholders. It's not about right and wrong, it's about choice and consequence. We're not the 'No' folks, we're the 'Know' folks (<- I made that up just now).

1 comment:

  1. By the time a decision proposal is sent to an Architecture Review Board (ARB) it should have been fully analysed, argued, socialised and all options, constraints, dependencies etc. documented.
    In my experience the ARB will rarely decline outright, but may ask for rework for later approval, or defer until a later date when a budget has been agreed, or some other condition has been reached.


Follow by Email