Most companies have a dedicated enterprise-architecture (EA) department that oversees the entire systems architecture, including business processes and IT infrastructure, and helps establish technology-enabled processes across business units so companies can deliver goods and services effectively. But not all companies agree on what constitutes best practice in EA management. Some are focused on continually measuring IT performance and adjusting business processes and systems as needed. Others tout the importance of aligning the overall IT architecture with those of the individual business units. And some companies say good governance can happen only if they have empowered EA leaders who promote collaboration and accountability among teams in IT and business functions.
In our work with large global organizations and in our conversations with senior IT leaders across multiple industries, we’ve heard anecdotal evidence supporting all those beliefs and more. So which approach is right? What makes for world-class organization and governance of corporate IT systems?
To this point, there has been little agreement, but to help answer these questions, a team from McKinsey and colleagues at the Henley Business School is undertaking a survey of IT professionals and senior IT and business leaders. The goal is to help create some consensus—specifically, to create a fact-based perspective on best practices in EA governance and the degree to which these practices contribute to successful digital transformations.
Empirical evidence is required because there are currently very few benchmarks companies can use to build a world-class IT organization and governance program. Informally, we’ve seen companies realize performance improvements when implementing one or several of the following ten principles.
1. The organization of enterprise architecture should reflect the organization of the business.
The EA department exists to regulate processing activities among business groups; the nature of its work is to assess and account for varying system and process requirements across the company. A retailer’s e-commerce division, for instance, would likely require certain digital capabilities that are less relevant for the retailer’s physical stores, and the EA group could anticipate the potential system interdependencies and incompatibilities. It is in the best position to oversee and help implement any proposed changes to the IT architecture. Hence, a centralized enterprise architecture is usually the preferred option.
Some companies, however, have opted to divide responsibilities for enterprise architecture among business units. The main rationale for doing this is that the company anticipates only limited synergies between business groups. For instance, there is likely no need for a central EA department for a financial holding company that owns a telecommunications company and a retail bank. In fact, trying to harmonize the technologies and processes across these very different businesses would likely create more inefficiencies than solutions.
2. The company should be clear about who is accountable for EA decisions.
When it comes time to implement new technologies or IT-enabled processes, most companies tend to bring all relevant stakeholders to the table. They assemble leaders in the EA department and members of the finance department and the strategy team, as well as the software-development group, to vet options and come to a decision about which changes to make and how. This approach is useful for ensuring that all perspectives are heard and that all system requirements are accounted for. But when disagreements occur, those around the table will tend to deflect blame onto the EA department and absolve themselves of responsibility—particularly when multimillion-dollar IT infrastructure updates and system replacements are at stake. To prepare for disagreements and discourage such finger-pointing, companies need to establish clear accountability for architecture-related issues—for instance, giving the chief architect in the EA department the final decision on and accountability for any changes relating to technology standards.
3. The EA department should collaborate closely with the business and the IT organization.
The work of the EA department is conceptual in nature. Teams of system architects and software developers are charged with designing complex technology frameworks, the success of which may hinge upon multiple interdependent criteria—for instance, different types of input data, myriad business processes, time and talent required for delivery of software and services, overall business objectives, and scope of individual IT projects. As the members of the EA department immerse themselves in making sense of these details, they commonly become isolated from the rest of the organization. The result is typically a comprehensive system map, with lots of boxes, dotted lines, and labels in small font sizes—information that addresses all the requirements but is almost impossible for the IT organization and the business to interpret. To ensure that the business can live with its new architecture and that the IT organization can support it, the EA department needs to collaborate closely with both by bringing them into the design process and translating complex ideas into digestible action plans.
4. The EA department should keep strategy-related tasks separate from operational ones.
For all the big-picture work they do, EA departments can also end up taking over immediate tasks from the business and the IT department—for instance, helping the supply-chain group build the business case for undertaking a large IT-transformation project or helping the IT group manage a systems-migration project. This is often because of the mix of skills required by the typical team member in an EA group. Because of the nature of the work they do, these individuals tend to have a unique knowledge profile—one that encompasses not just technology expertise but also an understanding of business processes and problem-solving techniques. As a result, members of this group can be plugged into any project and hit the ground running. Still, members of the EA department must take care to walk a fine line: they should certainly fill in where they can on critical tasks and stay connected to day-to-day operations, but they must also remember to devote time and attention to longer-term strategic issues, not letting the urgent overwhelm the important. EA leaders can facilitate a balance between short-term and long-term tasks by dedicating a subset of team members to perform continual pulse checks on the current architecture and assess how it should develop over the next three to five years.
5. The company should give the EA department approval rights.
The perception in many companies is that the EA department can have only limited impact on overarching corporate initiatives, particularly compared with other technology-oriented groups (application development, for instance) that tend to have bigger budgets and direct responsibility for core operational areas. Companies should give EA departments more responsibility for certain big-picture decisions—for instance, approving new IT-related projects or changes to the technology landscape. Otherwise, the policies and guidelines the EA department develops may never gain traction across the company. Perhaps even more important, the greater responsibility may help the EA group attract the operations and leadership talent it needs to design and support IT systems effectively. For many EA staffers, being seen as a valuable contributor to the bottom line may be more of an incentive than receiving incremental monetary rewards.
6. The company should keep accountability for elements of the enterprise architecture in one group.
Different business units may interpret elements of the enterprise architecture in different ways, which has the potential to create communication issues. In one bank, for instance, the IT department and the business were working with two different capability maps that were only loosely related, and no one person was assigned to merge them. Processes were inefficient; there were duplicate efforts in some areas and tasks going undone in others. The EA department should retain control over the entire IT landscape but can cede responsibility for various elements of the enterprise architecture to individual business units—provided that responsibilities are formally captured and communicated widely. Otherwise, inefficiencies will continue to emerge.
7. The company should analyze and measure the effects of enterprise architecture on the business.
In a perfect world, the EA department would be able to show the impact of the work it is doing by relying on a series of key performance indicators that are linked to higher-level profit-and-loss objectives, anchored in operational tasks, and not dependent on contributions from outside the department. In reality, it is difficult for EA groups to determine their direct contribution to overall corporate performance because so much of their day-to-day work depends on input from individual business units, ever-changing strategy and budget decisions, and other interdependencies. There is no simple formula for measuring absolute impact, but one feasible approach might be to analyze the effects of enterprise architecture within a small pilot project, using business-specific metrics that account for interdependencies—for instance, how many applications and how many point-to-point interfaces are involved in the project, how many applications are demonstrating overlapping functionally, what portion of the overall application-development effort is dedicated to integration testing, and whether management tasks are easier and less costly as a result of the pilot project. Using those findings as proof points, EA departments and other stakeholders in the business and in IT can assess and agree upon specific key performance indicators that are aligned with the company’s overarching strategy. They can set joint targets and continually adjust them as corporate and IT strategies evolve.
Would you like to learn more about our Business Technology Practice?
8. The EA department should keep it simple.
As mentioned previously, the work EA departments do is complex and sometimes confusing to the rest of the organization. But implementing clear accountability, establishing lean processes, and defining who has the final decision rights increase the likelihood that EA departments will be perceived as supporters of, not obstacles to, business growth. Still, staffers in EA groups should strive to communicate their work effectively—not just to business units but all the way up to the board level. Our conversations with EA professionals suggest that most are still focused inward; they tend to spend twice as much time talking with suppliers, for instance, as they do with C-suite and other business leaders. Instead, they should develop new ways to translate difficult concepts for the latter group—for instance, framing a discussion of potential changes to the enterprise architecture in the context of the new business capabilities enabled or new efficiencies gained.
9. The company should use one tool to rule all elements of the architecture.
Managing complexity in enterprise architecture is challenging not because of the number of elements within a system, but because of the number of connections between and among those elements. Even a set of just ten applications could have hundreds of interfaces among them and would need to incorporate hundreds of process steps and elements of the enterprise architecture. To manage these interconnections effectively and efficiently, the EA department must deploy one consistent operating model and a single management tool throughout the entire company—for instance, visualization software that can provide a comprehensive diagnostic view of the landscape, or a means by which to track project portfolios.
10. The company should invest in EA leaders.
Finding EA leaders can be challenging. That’s because the individuals who take on EA-management responsibilities need a combination of deep smarts in business strategy and expertise on IT trends and technologies, integration patterns, business-process steps, and running a closed IT environment. These people do not need to be experts in coding or supply-chain planning or store operations, but they do need basic knowledge of all those things—and more.
Clearly, pursuing any of these success factors would provide a great start for today’s technology leaders, but to what degree do each of these ten points resonate? How can IT and business leaders determine the best way to combine and weight each of these factors, given industry context? And as new technologies emerge, how will these success factors change? The survey data we plan to collect may inspire other insights and can inform our understanding of the ten principles discussed in this article. More important, the feedback may suggest innovative ways to manage enterprise architecture and create greater network efficiencies that may make it easier for companies to seize digital business opportunities.
To participate in the enterprise-architecture survey, please visit easurvey.org. Participation is free, and results will be shared with all respondents.
