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\u2019s using the same PC."Architecture is the most powerful governance tool CIOs have under their personal control. It\u2019s 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\u2019s standard architecture. "Vendors are less likely to try to sell our businesspeople something that they know won\u2019t 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\u2019s not a hard stop if projects don\u2019t conform, just a plea for changes. That\u2019s 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\u2019t 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\u2019t 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\u2019t be achieved there, the aggrieved parties can go to the CEO. "That\u2019s a great thing because it raises the stakes," says Peter Weill, director of the MIT Sloan School Center for Information Systems Research. If you\u2019re taking your case for skirting the corporate architecture to the CEO, you\u2019d better have a good reason. Indeed, very few appeals?one or two per year?get to State Street CEO David Spina\u2019s 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\u2019s accountable, it has to understand the rules. It doesn\u2019t hurt to explain the architecture to businesspeople often. An e-mail from IT with an attachment listing approved technologies won\u2019t 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\u2019s top 100 executives through it. (It didn\u2019t 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\u2019s intranet.