Straits of IT: An Arb Doesn't Have to Be a Blockade

The Governance Paradox

IT departments are frequently buffeted by whiplash projects, thrown back and forth between proactive and reactive, while often balancing capacity. Eventually someone will propose some form of Architecture Review Board (ARB).

The IT goal - prevent the sprawl of technology, get visibility into projects before IT resources are needed or committed, maintain a strong security posture, reduce technical debt and prevent integration problems or redundancies.

The business often hears brakes being slammed on through yet another approval process.

Both sides have valid concerns and honestly both sides are ultimately seeking the same thing. They’re just not speaking the same language.

Add to that one other thing, ARB has a mixed reputation - you may have heard it described as the board of NO!

The truth is both sides are right. The organization absolutely needs strong IT and technical governance in the form of an Architecture Review Board or similar function (you can name it whatever you can stomach) and the business absolutely needs to be agile and able to move fast.

The problem is not governance; the problem comes down to design and execution of the governance.

Falling into a few common temptations is the difference between enabling profitable business and technology partnerships, and creating an organizational bottleneck. The temptations fall into three categories.

1. Control over coordination - which can delay initiatives or increase opportunity costs
2. Process over purpose - which creates admin overhead without risk reduction
3. Compliance over learning - which creates recurring losses, technical debt, and repeat offenses for remediation.

Governance isn’t just a cost of doing business, but poor governance is definitely a cost of doing business.

The Hidden Governance

I want to explore an example of a high governance process you don’t even realize is happening 99% of the time. One that works at speed, scales, and deals with potentially catastrophic danger daily - all with moderate to no training to end users.

The modern gas station is ARB in motion.

Pull up to the pump, swipe a card, pump gas, complain about the price, go on your merry way. Countless times a day, all across the world, in hundreds of different types of cities from the smallest to the largest.

Now you may think that doesn’t look much like an ARB, and I agree - but it should. What about approvals and meetings? Those happen as invisibly to the customer as possible. For most customers, the approval happens when the card is swiped - no big meetings needed; a pre-existing set of conditions was determined ahead of time under which any end user could self-service their fuel needs. The consumer responsibility? They have to know which type of gas their vehicle needs, and they decide which level of service they want to pay for.

What if the consumer doesn’t have a credit card? There’s an exception rule in place - the consumer must pay in advance for a specified amount of fuel. That’s it one exception policy, and a little more responsibility on the consumer - they now must also know how much fuel is needed.

What if one group wants to pay for fuel of many consumers. There’s a fleet management path for that, one time setup of the fleet manager, then enroll the consumers in the fleet.

What happens if the consumer doesn’t know how much fuel to use, can’t they overfill? Automatic shutoffs are put into place to prevent over-filling.

What happens if a consumer decides to be stupid and fill up a rusty can while smoking? Emergency shut off valves are in place and any employee may trigger it at any time

What an ARB Actually Does

Good governance enables speed and agility for the organization by providing strategic guidance that both guards and enables technology investment decisions. This includes the infrastructure needed to make the whole process work: underground storage tanks (more on that later), credit card pre-authorization systems, the pumps themselves, shutoff decisions and capabilities. All of the things that enable you to pull up to a pump, pump your gas and drive off without a question or delay are architectural decisions - not made when you arrived, made in anticipation of your arrival.

Going back to the gas station, an ARB’s primary job is to present pre-approved options to the business; 87, 88, or 91 octane, and critically workers at the pump don’t stop someone from putting 91 octane in their 1978 brown Toyota Tercel, that’s a job for their spouse (finance). An ARB should be able to map out technical capabilities that the organization already provides so that the business just has to select the solution that they need.

Say someone pulls up in a premium vehicle, like a Ferrari looking for 98 octane premium fuel. This is getting closer to what most people think of when they think of an ARB - a meeting right? Except not quite yet. Is this a one-time fill up with just five gallons needed? The attendant can helpfully (and quickly) point the customer to a station that already sells 98 octane. However, if it’s part of a new route, and several Ferraris are going to be coming through frequently, it’s time for the ARB to meet and figure out how to add 98 octane to the options served. This will be discussed further in the Three Lanes section.

There are five key functions of an ARB and three phases that an ARB should go through from inception to long-term operation. The first function of ARB we have already discussed - providing a menu of technological capabilities in business terms. The second function is to review requests for new business capabilities. The third is to provide architectural references for IT teams; architectural references are the blueprints that allow IT teams to build and maintain those capabilities without having to reinvent the station every time someone wants to add a pump. The fourth is to ensure that security and compliance are integrated into the process. The fifth and perhaps the most crucial is to provide end-user education and refine the end user experience.

There are three levels of maturity that an ARB should progress through. The first level, initiation, the ARB would meet frequently to identify and organize the existing business capabilities and publish the menu. In the intermediary phase, the ARB meets at about the same frequency and is at about a 50/50 mix between reviewing new requests, and developing standards, references, and providing education. The final maintenance phase the ARB meets less frequently to review new requests and most of the work goes toward education and curation of existing capabilities.

Three Lanes

An ARB needs three lanes to be successful. The lanes should be clearly marked and easy to access. The first lane is an express lane - the customer has a well-defined need to the point they are able to browse or quickly be directed to the menu of existing business capabilities. No meetings are required in this lane and the goal should be to get most of the traffic through this lane.

The second lane is the exception lane - when the 98 octane request comes through, or the customer doesn’t have a credit card to pre-authorize at the pump. There is one exception process: go into the store, talk to an attendant who is empowered to direct the customer through the appropriate process. Document the exception and the exception decision - is this a one-time thing, or something we need to build for future use. Then these notes should be scheduled for review and if needed a lessons learned session.

The third lane is the slowest lane, and the goal should be to make it the lane with the least traffic as the ARB matures. This is the lane for truly new business capability discussions. This is for requests that can’t be handled by existing capabilities or the exception path. Think large scale or highly niche needs for the organization.

Summary

An Architecture Review Board should enable the organization to go faster, scale easily, and do so securely. In order to accomplish this the general idea of ARB needs to flip on its head. The goal of ARB should be to be invisible, and critically the mandate of the ARB is to enable business velocity, not deter it.