Enterprise Architecture: Depicting a Vision of the Firm

As IT units build solutions, they create the legacy that defines a firm’s IT capability. Intentionally or not, the resulting capability locks in assumptions about internal and external relationships and process definitions. But whose assumptions are being locked in? What business capabilities are these platforms enabling and what possibilities are they constraining? In this briefing we describe the concept of enterprise architecture on one page. We have observed that this tool can coordinate project decisions and facilitate discussions between business and IT management to clarify options for a firm’s IT capability—and then communicate the vision. 

Defining Enterprise Architecture at Delta Air Lines 

In 1997 when Leo Mullin became CEO of Delta Air Lines, he quickly learned that he had acquired an IT capability resulting from a failed outsourcing effort. Unhappy with the outsourcer’s services, each of Delta’s 17 functional units had effectively built its own IT capability. The firm had as many IT platforms as it had functions, and those platforms were not capable of communicating with one another. The predictable outcome was that Delta’s ticket agents, reservation agents, gate agents, baggage handlers, and others often lacked the information they needed to do their jobs— frustrating both customers and employees. 

Mullin brought in Charlie Feld as CIO to help the firm survive Y2k and start to build an enterprise-wide IT capability. Feld started by working with the leadership team to clarify the vision for how the firm would do business going forward. The leadership team described an as-is and a to-be state as follows: 

The to-be state outlined guiding principles for the firm’s enterprise architecture. As a first step in adopting a process view of the firm, the management team defined four core processes: customer experience, operational pipeline, business reflexes, and employee relationship management. The customer experience identified all the ways Delta touched its customers. The operational pipeline was concerned with loading, moving, unloading and maintaining planes. Business reflexes included scheduling, pricing, accounting and related administrative functions. Employee relationship management encompassed all the processes involved in meeting the needs of Delta’s highly mobile workforce. 

Once the team came to agreement on the core processes, they iteratively developed an enterprise architecture graphic capturing the processes, data, and interfaces constituting the essence of the operating model at Delta (Figure 1). At the heart of the model was the Delta Nervous System, which provided real-time access to, and updates of, Delta’s core data. The Delta Nervous System was designed to make data available to customers and employees on a need to know basis through multiple interfaces, including (but not limited to) PDAs, gate readers, laptops, cell phones, reservation systems and others. The software was event-driven in that some changes in data initiated automatic notification to specified applications and individuals.

CIO Feld, who led the development of the enterprise architecture, estimated that the management team needed about 60 iterations before everyone agreed on Delta’s enterprise architecture graphic. IT and business management’s shared understanding of the architecture helped establish development priorities and kept senior management focused on generating benefits from new IT capabilities. Delta focused on building a long-term IT capability while addressing its Y2k crisis and initial process improvement goals. Delta’s enterprise architecture has not saved the firm from the competitive challenges facing hub and spoke airlines or industry downturns, but it has given Delta a reliable, cost-effective IT foundation from which the firm can expand into new products, services or markets. 

Defining Enterprise Architecture at MetLife 

Although IT leaders recognize the importance of senior management leadership in defining IT principles, many business leaders do not enthusiastically embrace a role in defining how IT will contribute to business strategy. The enterprise architecture graphic can force a discussion exposing executives’ assumptions about IT capabilities. Unlike Delta, where the senior management team drew the enterprise architecture graphic, MetLife’s IT unit drew up an enterprise architecture to capture the IT unit’s understanding of the role of IT in achieving strategic objectives. (See Figure 2.) 

As an outgrowth of several large mergers, much data at MetLife is locked into individual IT applications. Nonetheless, MetLife’s current strategic initiatives are focused on more integrated customer service. MetLife’s enterprise architecture graphic reflects the firm’s need for shared data. The integration hub pictured in the enterprise architecture graphic recognizes that it will take some time to extract data from applications and create a fully populated centralized data store. In the meantime, the integrated hub will hold reusable code that accesses data embedded in legacy applications. Stakeholders gain access to the data using a standardized portal architecture, shown on the left-hand side of the diagram. 

MetLife architects use their drawing to communicate with senior managers and business partners the underlying logic for IT development at MetLife. The enterprise architecture guides new application development by explaining how IT will deliver on the firm’s IT principles. For example, MetLife’s enterprise architecture embodies principles of reuse in its portal architecture—every application will apply the same standards for output to stakeholders. In addition to providing a common customer view, the centralized data stores and integration engine enhance information integrity by reducing redundancy. Thus, the enterprise architecture translates IT principles into a clear vision of how IT will enable business objectives. 

A high-level architecture graphic captures decisions resulting from debates on where shared infrastructure stops and applications begin. The MetLife architecture shows that the channels, portal, data stores and integration engine are all shared across applications. The presentation and business logic applications are thus distinguished from infrastructure. Communicating where infrastructure stops and applications begin simplifies future infrastructure and applications decisions and promotes shared understanding of IT capabilities in the enterprise. 

Using the Architecture Graphic to Recognize the Need for Change 

As long as a firm does not change its basic operating model, the enterprise architecture graphic should guide development of business applications and infrastructure. Management may tweak the architecture as new technologies or changing market conditions introduce new opportunities. But the value of the architecture graphic is that it supports management efforts to identify ways to leverage IT in the firm. 

On the other hand, if a firm fundamentally changes its approach to the market, management will want to rethink the design of the IT capabilities—and perhaps redraw the enterprise architecture. For example, Schneider National, a large US trucking firm had a highly effective enterprise architecture in the early nineties. The firm had built mainframe-based systems accessing shared data and providing that data to mostly centralized staff. When Schneider became the first trucking firm to introduce satellite systems to track its tractors, the firm’s existing architecture allowed it to convert the satellite data into enhanced customer service. But when Schneider management determined that intense price competition in the trucking industry made it difficult to grow profitably, the firm expanded into logistics. Management noted immediately that the logistics business demanded a very different architecture—one with powerful desktop capabilities located at customer sites and allowing for segmented data bases. Rather than try to force fit the existing architecture, Schneider designed a new architecture for the logistics business. Starting from scratch and therefore having the freedom to deploy newer technologies allowed Schneider to move rapidly into the logistics business. Schneider management’s understanding of its enterprise architecture helped the firm recognize when it was time to start over just as clearly as it had helped identify opportunities to capitalize on the capability in place. 

Getting Value from an Enterprise Architecture Graphic 

Experiences at Delta, MetLife, Schneider and other firms suggest 4 steps for generating value from an enterprise architecture graphic: 

1. Start by defining the core enterprise-level business processes and the data they depend on. 
2. Iterate the graphic until senior business executives agree on the vision of how the firm will operate. 
3. Use the graphic to facilitate communication between business and IT managers about the role of IT in the firm. 
4. Use top-level understanding of the enterprise architecture to secure a commitment to exploring the impact of all IT-related projects on the enterprise architecture.