The Relationship Between Enterprise Architecture and IT Governance

I’ve been at the Meta/DCI Enterprise Architecture conference all this week. The conference coincided with the appearance of a big March 1 story package I wrote with my colleague Ben Worthen on enterprise architecture. So when they handed out our magazine at the conference it had enterprise architecture splashed all over the cover (completely by accident, though it looked like perfect coordination). It was a great opportunity to get feedback from practitioners of the art (I don’t use that term lightly) while the research I had done was still somewhat fresh in my mind—and literally in their laps.

EA has been around for more than 20 years, but it has only recently begun to transform from an IT-centric exercise in mapping, controlling, standardizing and consolidating into something new—a function (it will emerge as a function on its own, either within or outside of IT) entrusted with creating a permanent process for alignment between IT and the business. This piece is brand new, and almost all of the companies and architects I spoke with were just beginning to move beyond the IT architecture umbrella (which usually includes the data and infrastructure architectures; see my March 1 story A New Blueprint for the Enterprise for an explanation) and into the business architecture (applications and process architectures).

The conference reminded me why I don’t get tired of writing about technology and technology people—first and foremost, they are friendly, down-to-earth, unassuming types who want to change the world (though quietly). Except architects seem to have an extra dose of the gene that makes them want to change the world.

I hope they won’t be disappointed. I’m struck by what they are up against inside their companies. I think at the most basic level it goes to governance. This new, renaissance EA is never going to fly if the CIO hasn’t established institutionalized, repeatable governance processes that promote IT and business alignment at the highest level.

The first of these, of course, is reporting relationships. The CIO has to report to the CEO for EA to be an alignment force. The research—our research, anyway—is conclusive. In our 2004 State of the CIO survey (300 CIOs and their equivalents surveyed), we found that CIOs who report to CFOs spend:

• Less time interacting with company CXOs
• Less time on strategic planning
• More time running projects
• More time meeting with vendors

If CIOs can’t get access to strategic discussions, they can’t follow through on the next governance prerequisite to the new EA: IT investment prioritization. If IT doesn’t get access to the business at the highest level, IT is not going to get a clear idea of what the business really wants from IT. Another survey, this one by the folks at the Center for Information Systems Research (CISR) at MIT, surveyed both business and IT people about their IT practices and correlated them to profitability. CISR found that in companies that were profitable, the only practice that both IT and business people agreed they did well was investment prioritization. In other words, profitable companies that are good at IT are good at prioritization. As CISR researcher Jeanne Ross puts it, “These companies are good at picking three or four IT investment areas that relate most closely to the strategic business goals of the company,” and deemphasizing the rest. You can’t do this if the CIO doesn’t report to the CEO, or doesn’t have access through a governance mechanism like an executive IT council.

And you can’t do it without a sustainable, repeatable process for discussing IT and business strategy and for making investment decisions. As CISR Director Peter Weill has pointed out to me, “This all can’t hinge on a single person, or a relationship, because then if the CEO changes or the CIO changes you have to start all over again.” An executive committee composed of the CEO, CIO and other Os needs to be institutionalized at the company, as does a reasonable investment decision process that cuts across business and IT. Portfolio management is the best method yet developed for creating an IT investment process that business people can understand and that mirrors their own view of investment, because it brings the concept of risk into the equation. (See our story on portfolio management, Do the Math.)

With a reasonable IT investment process in place at the highest level, EA has a chance to move beyond IT architecture. But only if those who are part of the highest-level vestment process are comfortable ceding some power and control to the architects. They need to make architecture review a condition for investment approval. The executive committee holds the carrot (money) and they wave the stick, which is that before you come to us asking for money, you need to go through the architecture review process first. It’s the only way to get mid-level business people to care about EA. They don’t care about IT architecture efforts that consolidate infrastructure or standardize applications because the savings don’t impact them personally. They are focused on process. If the architects control investment and project review, they will start to care. Then it’s up to the CIO to make sure that business people don’t wind up hating the architects. The EA function can’t become an ivory tower that gets a reputation only for blocking investments.

And EA can’t become yet another effort to gain credibility for IT with the business. I spoke to one chief architect at the show who said that he decided to focus the EA effort on IT architecture first before tackling the business and application architectures (i.e., before getting the business involved) because the business wanted proof that IT could deliver before giving up business people’s time to the effort. “We’ve had some architecture efforts that failed before and we didn’t want to be seen as crying wolf again,” he said. Though he was optimistic (everybody was at this conference), he could not hide his frustration that he essentially had to make up for the sins of the past before being allowed to move forward. I think it points more to a failure in governance than a failure in EA—IT becomes like the child of the bad parent, never trusted to do anything beyond her known capabilities.

That’s why I think EA has to offer more products and benefits to be accepted by the business. Architecture alone is not a viable sell. I get into this in more detail in our story, but I think SOA is a great way to build enthusiasm for architecture among business people because it reduces IT to a vocabulary they can understand. ERP, CRM, legacy systems and integration are hidden beneath composite applications with names like “get credit rating” and “get customer record.” Reuse becomes real and starts to impact mid-level business people directly because they can see how much faster they get new functionality from IT since “get customer” became a service in a repository that any developer can access when the need arises.

The architects have the opportunity to become the face of IT to the organization, consulting with business people to help them better articulate functional specifications. With these kinds of interactions, the EA group becomes a built-in recruiting organization. Business people begin to see the architecture group as a viable career path. I met a number of these people at the conference. They are process experts, not IT people. They are part of an EA team that contains IT specialists and process specialists.

There is a place for these business people in the new EA, but not in the old. They can’t be much help in mapping, or consolidating, or standardizing, and they will quickly lose interest and leave if EA devolves into its traditional focus.

CIOs seem to be making that a foregone conclusion. A study released by Forrester recently found that 69 percent of EA groups don’t even report to the CIO. They report one or even two levels down from the CIO. Not sure why any business person would be interested in EA under that model. It virtually assures that EA will be nothing but an IT infrastructure effort. And this totally ignores what many are saying about the future of EA that, done right, it may not report to IT at all someday, but will become its own independent entity or report into the strategic planning group or the COO. Keeping EA hidden deep inside IT cuts off that evolutionary possibility before it can even be tested.

The excitement and optimism at the conference were palpable and wonderful to see. EA is finally becoming exciting, and the technologies that support it (like middleware, Web services, EA tools and BPM tools) are maturing to the point where architects can have a real strategic impact on the business and on IT. But not if governance hasn’t been tackled first. CIOs need to do more to support their architects—the people who represent the future of the IT. What do you think?