EA on the Baseline
Survey results show the current state of the architecture function in enterprises
by Janaki Akella and Chris Barlow

Posted May 26, 2004

To know where you are headed, it is first necessary to determine where you are. While we have a lot of anecdotal evidence of the status of enterprise architecture, we've found a relative paucity of hard data.

That's why in our last column—"Defining the Role of the Chief Architect" (Enterprise Architect, Spring 2004)—we asked for your input about the typical roles and responsibilities of the architecture group in your company, and also solicited your open-ended opinions about what has worked well and what has not. In addition to the survey, we conducted in-depth interviews with a number of enterprise architects. In this column, we present the preliminary results of the research.

Since our survey sample was not statistically valid, our results cannot be extrapolated. However, the data suggests how the readers of this magazine see the evolution of the enterprise architecture function in 2004.

Three principle conclusions emerged from the survey, and they establish a baseline for the state of enterprise architecture today. We found that enterprise architecture groups, when they exist, are relatively small in size but are high profile in terms of their reporting structure. The major focus of architecture groups is reducing complexity, both by decreasing the number of applications and moving away from legacy systems in a cost-effective manner. The chief architect rarely has a seat in business unit planning, and in reality IT does not participate in a strategic partnership with the business.

The survey respondents represented a variety of industry sectors and company sizes. The most active industries were technology, banking, and pharmaceutical/health care (see Figure 1). Approximately 40 percent of respondents work for enterprises with more than 1,000 employees, but almost half are employed in small businesses with fewer than 100 (see Figure 2).

For almost all companies, the architecture groups were small—2 to 3 percent of the IT group size. When a formal architecture group exists, the chief architect reports directly to executive management in more than half the companies surveyed. Of all respondents, 23 percent indicated that the chief architect reported to the CEO, president, COO, or CTO, with 31 percent reporting to the CIO. The remaining 46 percent reported to a VP or senior VP.

Complexity Reduction
According to our respondents, the major objective of architecture efforts involves reducing complexity, with 73 percent of those surveyed indicating that this was the main focus of the projects their architecture group is actively involved in. This focus appears reasonable given the large number of applications and legacy systems in these companies: 57 percent had at least 3 or more legacy systems that they wanted to sunset, and 54 percent had 50 or more applications in their portfolio.

Reduction in complexity is necessary in most companies because businesses have grown by mergers and acquisitions while little attention has been paid to managing the resulting IT complexity. Decisions on architectural convergenc—which applications to keep and which to retire—tend to become highly contentious. This controversy can be avoided by grounding the decision in rigorous quantification of costs and benefits and considering the business and IT risks. Survey responses concerning costs and benefits are summarized in Figure 3.

Of the models for enterprise architects identified in our last colum—Standards Enforcers, Project Architect, and Emerging Technologis—the most common role for respondents' architecture groups was Project Architect (see Figure 4). The differentiating aspect of this role is its active participation in all major development projects and its concerns with ensuring architectural compliance and promoting reuse. Almost two-thirds of respondents identified this role as a key function of their groups, while half also identified each of the other two roles as important functions.

For those who described their role in whole or in part as an Emerging Technologist, three top technical directions emerged as priorities: grid, utility, or on-demand computing; porting applications to 64-bit architectures; and building enterprisewide data warehouse systems, including real-time information integration.

Perhaps the biggest surprise of the study is that a dominant share of respondents—90 percent—said their chief architects do not play a role in business unit planning. Given the prominent attention given by consultants to business-IT alignment, we would have expected architects to be considered a strategic partner in business planning. However, in by far the most cases, enterprise architects today see themselves as limited to tactical roles in designing solutions to implement strategic plans that they have no hand in developing.

Implications of Outsourcing
If business strategies are not on their radar, the business of IT certainly is reflected in a significant shift to outsourcing and offshoring as a new delivery model for IT services. The respondents cited three main areas that either are already or are under consideration for outsourcing/offshoring: rewriting Cobol-based applications in Java or C++; increasing the robustness and stability of B2B/Internet applications (including EDI transactions, reporting, and portal applications); and maintaining applications where required vendor or industry expertise—Oracle applications, insurance applications, and middleware/integration technologies, for example—dictates that their original development remains in-house.

However, a small but significant number of respondents indicated that the pendulum is beginning to swing in favor of bringing new application development back in-house after taking advantage of outsourced vendors to improve documentation and streamline development processes.

The implications for architecture are favorable whichever way the pendulum swings because the "define-it-as-you-go-along" model of development cannot provide the clarity and formal definition of the desired technical solution that is called for in outsourced or homegrown projects. In the outsource/offshore model, the best practice is for companies to architect the required solution up front and deliver these specifications to the outsourcing vendor. The vendor uses this as the starting-point level of effort (LOE) and cost estimate. In the absence of such an architectural practice, there is no rigorous validation of the appropriateness of the vendor solution, the LOE and cost, or satisfaction of performance and functional requirements.

While enterprise architecture appears to be gaining a foothold in many organizations, our respondents identified many potential missteps that architects or their organizations can encounter (see Figure 5). The critical success factor for architecture groups is to shape and stay relevant to the IT strategy of the company. When this is not the case—either by adopting a policing role, suggesting unsubstantiated standards, or not deploying IT strategically—the architecture group is not successful.

But an even more fundamental error is not having a dedicated architecture function at all, and assuming the architecture that evolves organically on an ad-hoc, project-by-project basis will ever become a coherent enterprise architecture. Beyond this, two overriding issues were cited repeatedly as continuing unsolved issues: funding for architectural initiatives and the need to maintain expertise in emerging technologies.

About the Authors
Janaki Akella and Chris Barlow are in the business technology office of McKinsey & Company, where they focus on counseling senior business leaders on the effective use of technology. Contact Janaki at janaki_akella@mckinsey.com, and contact Chris at chris_barlow@mckinsey.com.