Complexity is rife in any growing business. As companies innovate, add new business lines and products, or expand their international presence, processes proliferate, and the discipline around them can go out the window. Meanwhile, the IT that underpins these processes can also become more entangled as aging legacy systems jostle with new applications to support the needs of the business. Over time, this kind of complexity can unravel technology standards and undermine the coherence of the architectural blueprint. As application volumes grow in response to a fast-changing economic, regulatory, and business environment, the issue of complexity is becoming acute for many organizations. Enterprise architecture management (EAM), a framework to manage IT architecture and ensure that both the business and IT are well aligned, aims to restore order to this landscape.
Too often, efforts to fix architecture issues remain rooted in a company’s IT practices, culture, and leadership. The reason, in part, is that the chief architect—the overall IT-architecture program leader—is frequently selected from within the technical ranks, bringing deep IT know-how but little direct experience or influence in leading a business-wide change program. A weak linkage to the business creates a void that limits the quality of the resulting IT architecture and the organization’s ability to enforce and sustain the benefits of implementation over time.
A new approach to EAM lifts such change programs out of the exclusive preserve of the IT department and places them more squarely within the business. It starts with an effort to define the architectural design in a language the business can understand, with outcomes that serve its needs more fully and efficiently, thus improving communication and helping the business and IT leadership to collaborate in developing the IT architecture (see sidebar, “Revolutionizing architecture management: A CIO checklist”). The wider engagement puts ownership in the hands of the end users—the business professionals—and therefore makes it easier for the required changes to stick and improves overall governance. Companies that have taken this approach to EAM have lowered their need for architecture-development labor by as much as 30 percent and reduced times to market for new applications by 50 percent.
A close look at how one bank employed EAM in a transformation effort offers lessons to other organizations facing similar management and IT issues.
Complexity and a lack of leadership
A diversified global investment bank found itself wrestling with an unwieldy IT environment. Acquisitions, international expansion, and a raft of new products created a network of poorly integrated and, in some cases, redundant systems over the years. The absence of an enforced architecture framework for developing IT worsened the problem, giving rise to varying technology standards across the business.
Each major business line operated more or less autonomously and viewed its IT needs as specialized, even in areas such as HR and finance, where shared-services models are now considered best practice. The investment-banking division, for instance, saw itself as having little in common with other units in its core activities, such as securities settlement and online transactions, even though underlying capabilities turned out to be similar across the business.
As demand for custom application development spiraled, so did complexity. System upgrades—a frequent occurrence in light of fast-changing regulatory and marketplace conditions—proved a major headache, given the inadequate IT architecture landscape. Although the bank had embarked on several separate EAM initiatives, these struggled to gain a footing amid perceptions that they were too IT-driven and bore only limited relevance to overall business requirements. Responsibility for the projects was left to a consortium of architects across the company’s global organization. Although supported by senior leadership, the architecture group lacked peer-level representation in the ranks of top management. With costs and resource constraints increasing, the bank’s central IT department struggled to make the case for change.
Rethinking the approach
The bank eventually realized that its EAM drive to streamline, simplify, and standardize global IT had gotten off to a rocky start, with an overly technical skew that seemed removed from business objectives. It therefore began a series of reforms, and three guidelines emerged.
Appoint the right person
An excessively technical orientation and a lack of wider organizational clout among those in architecture leadership positions ruled out appointing a chief architect to lead the EAM campaign. Instead, the bank defined the role more broadly, appointing its highly regarded business line CTO, who already had a seat at the table in setting strategy, as well as the budgetary and decision-making authority needed to lead the EAM effort.
The CTO was well known within the financial-services industry, where he had spent most of his career, and understood the business issues very well. Most important, he had the political skill and clout to carry out the needed changes, the business acumen to articulate user wants and needs, and the technical expertise to negotiate trade-offs between them—such as expanding the bank’s online-services portfolio without overcommitting the organization to new or unproven technologies. He also understood the IT integration challenges in this large and diversified banking institution.
Place business capabilities at the center
The bank’s merger history meant that the current organization comprised very different corporate cultures and a portfolio of independent IT fiefdoms. Unifying and improving the underlying group architecture became the EAM program’s primary objective. To achieve it and avoid past problems, the CTO conducted a series of workshops in which he brought together architecture teams from all the business units to develop an architecture that would not only support local needs but also serve as an optimal solution for the company at large (exhibit).
A well-tuned EAM effort concentrates on a core set of business capabilities, such as payroll, payments, or automated statement processing, where efficiencies and improvements can have the widest and most lasting impact. As a first step in the reform campaign, the IT department mapped the bank’s current state, charting the jumble of platforms, hardware, software, and network applications in use at the time. To winnow them, the department needed to understand the key requirements for each business line.
The new approach redefined the application architecture by using business domains, which regrouped the bank’s IT—data, processes, and applications—according to the business capabilities each business line needs. The chosen domains ranged from client services and product management to transaction processing, HR, and legal. The product-management department, for instance, must be able to examine account information on an integrated basis to see how well a given product is being received in different geographies and customer segments. It must also access credit, deposit, and payment data to calibrate margins, set pricing, and fulfill its reporting obligations. Within the overall product-management domain, subdomains for accounts, credits, payments, and settlements were established to consolidate, house, and manage those programming requirements efficiently.
By using domains and subdomains as building blocks, the architecture team reorganized the bank’s architecture around core capabilities, pooling shared applications and carving out any remaining requirements that needed customized support. To the surprise of the banks’ leaders, of the 100 or so domains the team identified at the outset, only 20 percent required applications specific to business lines. The rest—core functions such as settlements, payments, and central IT—were shareable. Rather than having different systems for securities processing in each business line, for example, one domain could centralize and maintain a standardized program for all business units. This approach freed developer and support-staff time for other high-value initiatives. The simplified framework cascaded downward through the entire architectural framework, allowing for a more efficient use of infrastructure.
Make change sustainable
A good EAM program uses plain business terminology to guide the development process and create a sense of business ownership. Otherwise, the program may confuse or, worse, alienate the business audience that its changes are intended to support. In the case of one bank unit, an initiative to develop a new payments environment was rejected by the board leadership. Marking the culmination of a three-year effort, the proposal contained 300 gigabytes of detailed architecture information. Despite that bulk, the presentation lacked the one thing that would have made the project intuitively understandable to top managers: an executive summary telling them the overall program goals and laying out the financial and nonfinancial benefits.
Determined to correct the problem, the IT team put aside the small print and binders and turned to simplified graphics that highlighted key management questions. Managers in the bank’s payments businesses had been uneasy about restructuring domestic, regional, and cross-border transactions, so the IT team described the new architecture design’s business benefits in a succinct executive summary. Using a simple before-and-after graphic, the team showed how a fragmented architecture with over 200 different payments systems could be streamlined into a more integrated, cross-border IT environment (see interactive, “Enterprise architecture management: Before and after”). Now that everyone was on the same page, the merits of the program could be discussed robustly, and it won the board’s approval.
Enterprise architecture management: Before and after
Toggle between exhibit 1 and exhibit 2 in the interactive to see an example of enterprise architecture management at work.
By breaking the group architecture into three application layers—shared, standardized, and customized—the team made the bank’s structure more efficient and adaptable, allowing for different degrees of business unit autonomy. Some domains, such as credit card–payment processing, will be deployed centrally across all business units. Others, such as checking, allow individual business units to customize elements of the core application suite.
The new structure helped the bank establish a network of governance boards, led by the CTO, across its global organization. This structure not only provided greater transparency but also made it easier to manage ongoing improvements and overall project performance. Although the program is still being rolled out, the move to a more standardized IT environment has reduced the number of applications in use and related labor and support costs.
EAM provides a governance model for IT change. Like any other change initiative, it must be led from the top. To get the most out of EAM programs, organizations must define architecture standards, establish a rigorous and stable governance process, and appoint people with the right skills for the lead roles.
About the Authors
Helge Buckow is a consultant in McKinsey’s Berlin office, and Stéphane Rey is a principal in the Zurich office.