CIO — Architecture?essentially the list of technologies you can and cannot use and the rules for allowing exceptions?is where most companies develop their first vestige of consistent IT governance. "It usually starts with someone in the business saying, How can we save money on IT?" says Jeanne W. Ross, principal research scientist at the MIT Sloan School Center for Information Systems Research. "And IT responds, Well, you can make sure everyone’s using the same PC."

Architecture is the most powerful governance tool CIOs have under their personal control. It’s how CIOs enforce the goals of technology standardization across a diverse company with many different competing interests. Vice President of IT David Drew uses architecture to drive the technology choices inside St. Paul, Minn.-based 3M, but he also uses it as a stick with vendors, who are all required to run their applications through a set of stress and security tests on 3M’s standard architecture. "Vendors are less likely to try to sell our businesspeople something that they know won’t fit with our architecture if they know they have to go through that process," he says.

Yet despite its power as a governance mechanism, architecture plays only a consultative role in most companies. That is, it’s not a hard stop if projects don’t conform, just a plea for changes. That’s no longer the case at Boston-based State Street Corp., where former CIO John Fiore has his Office of Architecture run by an IT senior vice president. (Fiore left State Street last month.) New projects must pass through the office before they can be approved. If the projects don’t match up with the architecture, the office will work with project sponsors to find a compromise.

Architecture may be a powerful tool, but it can also be dangerous. Too strict a policy can turn CIOs into the IT police, stopping more projects than they promote. That can generate resentment among businesspeople, especially at the local level where an overly rigid, slow architecture review process could mean lost revenue. In response, business unit leaders may try to fly below the review radar. For example, if a rule decrees that all projects over $100,000 must go before the board, units may break a big project into sub-$100,000 chunks. That is why governance mechanisms all need an appeals process, a safety valve.

At State Street, for example, projects don’t dead-end in the Office of Architecture. If there was an impasse, the units could appeal to Fiore. Now they can appeal to his successor, Joseph Antonellis. If a compromise can’t be achieved there, the aggrieved parties can go to the CEO. "That’s a great thing because it raises the stakes," says Peter Weill, director of the MIT Sloan School Center for Information Systems Research. If you’re taking your case for skirting the corporate architecture to the CEO, you’d better have a good reason. Indeed, very few appeals?one or two per year?get to State Street CEO David Spina’s desk. More important, the appeals process reinforces the message State Street wants to send: Ultimately, the business is accountable for IT decisions.

And if it’s accountable, it has to understand the rules. It doesn’t hurt to explain the architecture to businesspeople often. An e-mail from IT with an attachment listing approved technologies won’t cut it.

When W.W. Grainger, the Lake Forest, Ill.-based distributor of plant and maintenance supplies, recently developed an enterprise architecture, Tim Ferrarell, senior vice president of enterprise systems, put together an education program and ran Grainger’s top 100 executives through it. (It didn’t hurt that Grainger CEO Richard Keyser required them to attend.) The program focused on explaining why Grainger had an enterprise architecture in the first place, and Ferrarell plans to put an interactive version of the program up on Grainger’s intranet.