Enterprise Architecture: Theory vs. Practice

The primary source for the information related to the “theory” of successful enterprise architecture (EA) contained in this paper is the course text by Jeanne Ross, Peter Weill, David Robertson, Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. In their book, Ross, Weill and Robertson lay out a solid, theoretical foundation for establishing the framework for an enterprise architecture by way of a foundation for execution, which they define as “…the IT infrastructure and digitized business processes automating a company’s core capabilities” (Ross, Weill and Robertson, 4). This foundation for execution is not an instantaneous, complete accomplishment, but rather an evolving status encompassing several stages: first are “basic infrastructure services” such as “…employee hiring and recruiting, purchasing, desktop support, and telecommunications”; second are “basic transaction processes” such as “sales, accounts payable” and finally “unique and distinguishing business capabilities” (Ross, Weill and Robertson, 4). The authors make a profound and interesting point relating to the digitization of core business processes: such digitization makes an individual business process less flexible while at the same time making the company as a whole more flexible (Ross, Weill and Robertson, 4-5).
The traditional approach to the alignment of business and IT objectives resulted in inefficiencies that enterprise architecture seeks to remedy. The authors point out three main reasons the traditional approach often failed to produce the desired outcomes: first, a lack of clarity in business strategies with the result that IT would build IT solutions rather than IT capabilities; second, even in the cases where such strategies were clearly defined, IT would build sequential solutions on top of differing technologies, and third, IT found itself in the position of always reacting to strategic initiatives and thus never became an “asset shaping future strategic opportunities” (Ross, Weill and Robertson, 6).
In order to remedy such inefficiencies, companies need a foundation for execution, which requires mastery of three disciplines: operating model, enterprise architecture, and IT engagement model (Ross, Weill and Robertson, 8-9). The operating model is a level of business process integration required to deliver products and services to the customer. This enables a holistic processing and a “single face” to the customer but also requires everyone understand the data across the various business units (Ross, Weill and Robertson, 8-9). The enterprise architecture is the logic that drives the organization of business processes and IT infrastructure and takes into account the company’s requirements for integration and standardization (Ross, Weill and Robertson, 8-9). The IT engagement model contains the mechanisms by which business and IT projects achieve objectives (Ross, Weill and Robertson, 8-9).
The state of modern business has evolved to a point where this foundation for execution is really no longer optional. The authors point out that companies with a well-crafted foundation for execution have “higher profitability, faster time to market, lower IT costs”, whereas companies without this foundation face serious risks that didn’t exist even in the recent past (Ross, Weill and Robertson, 10).
The authors go on to discuss the four operating models: Coordination, Unification, Diversification and Replication, and the relative strengths and weaknesses of each. For our purposes, the important thing to note is that it is imperative that a business concentrate on its operating model instead of individualistic business strategies as the operating model will provide the company with a better framework for developing both IT and “business process capabilities” (Ross, Weill and Robertson, 43). This is no easy task, however, as it requires tremendous commitment from management on down; the corporate culture including business units must think holistically, and management must commit to identifying which business processes will differentiate the business from competitors (Ross, Weill and Robertson, 43). The authors point out that without such a defined operating model, “management careens from one market opportunity to the next, unable to leverage reusable capabilities” whereas, with such a model, the business can construct capabilities that generate growth (Ross, Weill and Robertson, 44).
Building toward a solid foundation for execution requires the company move to more specifics than the operating model provides, thus the need for enterprise architecture, which spells out the processes, systems and data which represent the heart of the company’s activity (Ross, Weill and Robertson, 46). In fact, enterprise architecture “directs the digitization of the foundation for execution” and includes components different from the operating models (Ross, Weill and Robertson, 47). The whole purpose of EA is to determine which “processes, data, technologies and customer interfaces” convert the operating model into a reality, but these elements differ for each operating model (Ross, Weill and Robertson, 47). Herein lies a key juncture at which reality and theory collide. While identifying these processes…etc. seems like a straightforward proposition, this process requires what the authors call “soft skills” to deal with the people issues that such formalized definitions engender (Ross, Weill and Robertson, 47). For example, people might feel their jobs are threatened by defining, as core to the business, certain processes which may exclude their job functions. In other scenarios, a company may find people that are ‘naysayers’, people who feel empowered by telling management why things won’t work, or who skew what they tell management in an effort to make their job function or department seem more important. Another reason for soft skills, as the authors point out on page 50, is that the theoretical nature of discussing processes, principles and technology may just prove too abstract for management. Another way theory conflicts with reality is in the ‘feel good’ a company derives from the process of EA. The authors point out that in a lot of companies, EA is conducted in a back room by a small IT staff over the course of several months which makes the company feel as though the very process of mapping out their systems and processes will in and of itself reduce complexity and increase efficiency, yet the reality is that most of the EA output winds up shelved as the company really never had the heart to suffer the pangs of implementation (Ross, Weill and Robertson, 65).
Some recommendations made by the authors on page 65 for successful EA include:
1. The EA process should begin with senior executives deciding on both the operating model and what is core to the business. This forces management to develop a general vision;
2. The identification of “the key customer types, core processes, shared data, and technologies to be standardized and integrated” which forces a decision on a course of action;
3. The company must be committed to its people relearning processes once they are redesigned. For some companies, EA begins with redesigning operations and the organization to establish core capabilities, and this can be traumatic for people (Ross, Weill and Robertson, 66).
There are four stages through which EA evolves (Ross, Weill and Robertson, 79-81). They are:
1. Business silos: In this stage, managers control business and IT decisions which makes responding to local market changes fast but changes to global environments are much slower;
2. Standardized technology: business units give up some power but global flexibility is improved;
3. Optimized Core: Organizational change is most notable at this stage for an organization. Managers lose power over many business processes and even over people and systems that perform them.
4. Business Modularity: In this phase both local and global flexibility increases. “With a solid platform of core processes, data and technology, a company can plug and play business modules on either level, and modular interfaces make changes simpler to implement.”
As companies evolve through these four stages, they must acquire learning in the following five areas (Ross, Weill and Robertson, 82):
• Business objectives via a business case;
• Priorities in funding IT initiatives;
• Which management capabilities will best exploit new IT capabilities;
• Managers accepting responsibility for “defining applications”;
• Key issues of IT governance;
It is worth noting that companies are not able to skip stages in this evolution; to do so would doom the EA process to some level of failure (Ross, Weill and Robertson, 82).
On page 88 the authors spell out a list of best practices for EA:
1. The company should focus its EA efforts on key organizational processes;
2. Work through EA in an incremental fashion, not skipping steps;
3. Understand that more complicated organizations will have “enterprise architectures at multiple levels”;
4. Develop the architecture capability in-house;
5. Strive for a modular business structure;
In conclusion, Enterprise Architecture, while clearly defined in theory and best practices, seems to be more of a moving target when applied to real-world scenarios. Those corporations whose top leadership see value in EA and who have the vision to build this capability in-house are much more likely to create a climate in which an Enterprise Architect can build a rock solid foundation for execution, and over which that same architect can maintain solid management to ensure its continued success. Those corporations that think they want EA, yet outsource its establishment to consultants seem much more likely to piecemeal the components they personally view as valuable as opposed to accepting the premise that EA must be implemented in a holistic fashion in order to truly succeed. The experience of having to negotiate with and convince senior executives to accept an EA’s recommendations in toto are most likely common experiences among consulting firms, and hint at a dysfunctional foundational understanding among corporate executives as to what EA entails. Rather than invest in the difficult and traumatic work to build an EA in-house, those corporations that outsource that effort appear, in at least some cases, to view the process as optional, subject to the budget allocated to the consultant and subject to the whims of corporate executives who desire to piecemeal various components of EA. As the authors of our text stated, companies cannot skip stages in the development of EA, and by implication, cannot piecemeal components and still expect to achieve the business outcomes for which they are hoping and paying.

List of Works Cited:
Ross, Jeanne, Peter Weill and David Robertson. Enterprise Architecture As Strategy: Creating a Foundation for Business Execution. Harvard Business School Press, 2006.

Kevin Banks

Geopolitical analyst with extensive background in languages and information technology.
Inline Feedbacks
View all comments