McKinsey just published a new report, Why business needs should shape IT architecture, which speaks to taking a new approach to Enterprise Architecture programs.  An approach that is business-driven, capability centric, and change aware.  In other words, McKinsey echoes my mantra, “The ultimate outcome of enterprise architecture is change-friendly capability delivery.”

My ego aside, the McKinsey report is very good.  It sets the context for Enterprise Architecture Management, provides a CIO checklist for revolutionizing Enterprise Architecture Management, and walks through an example of EAM revolution at a diversified global investment bank. 

From my perspective, the most important point on the CIO Checklist is the first one:

“Focus on transformation.  Educate leaders at the highest level to help them understand that EAM is about change management and not simply a new IT initiative.”

Ultimately, the goal of your enterprise architecture program is to enable your organization to adapt to, and introduce, change.  Challenge your thinking with the following.  How can your architecture, or architecture program, be ‘intrinsically adaptable’?

Returning to the McKinsey article, the case study has many good insights.  I’m calling out two here.  For the rest, read the article.  [Emphasis is mine.]

The first is the use and business payback of capability analysis:

“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

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.”

The second is EA communication techniques, and therefore, EA sales success:

“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…Now that everyone was on the same page, the merits of the program could be discussed robustly, and it won the board’s approval.”

As you pursue your own EA work, consider your role in business change.  Is your EA a change catalyst, or change impediment?  If it’s the latter, how will you revolutionize your EAM?