Enterprise Architecture as a Strategy

06th of March 2016

The summer of 2015 marked a trip to Verona for me, and on trips I read books. At this particular trip, I endeavored to read “Enterprise Architecture as a Strategy – Creating a Foundation for Business Execution”. Several of my enterprise architect colleagues had recommended reading this book to really grasp what the discipline was all about. As I have indicated in the past, I am not an enterprise architect, but I felt that increased understanding would allow for a derivation of what could be applied to my fields of expertise. To state it more specifically, as this is not a book specifically on Solution Architecture or Business Process Management, I will not delve too deeply into the subject matter with this review, but rather highlight the choice nuggets of wisdom that caught my eye and my approval whilst flipping through the pages.

A bit of background on the book: It was published by the Harvard Business Press in August of 2006 as a study of several companies in order to distill the elements for a successful strategy. What is required to do this? Make tough decisions about which processes you must execute well, then implement the IT systems needed to digitize those processes.

First off, since Business Execution is right there in the subtitle, the book specifies what warning signs can be used to indicate that an organization might not have the best foundation for execution. The research done by the authors indicates that companies with a proper foundation for execution reported 17% greater strategic effectiveness, divided over operational efficiency (31%), customer intimacy (33%), product leadership (34%) and strategic agility (29%) on top of bottom-line impacts. These warning signs lead to topics that need to be addressed right of the bat of an EA initiative:

  • Different departments within the organization give different answers to customer questions
  • Adapted for a new regulation or reporting requirement is a major effort
  • Lack of agility, meaning every strategic initiative seems to need to start from scratch
  • IT is a consistent bottleneck
  • The same activity within the organization is addressed by different processes, even on different systems
  • Lack of sufficient information to make key product or customer decisions
  • Data replication and transformation takes up a large chunk of peoples’ workload
  • Senior management is adverse to discussing IT agenda items
  • The added value of IT components and/or teams is not or insufficiently known

Evidently, the book will praise Enterprise Architecture as a part of the solution of creating a solid foundation, identifying it as the organization logic for business processes and IT infrastructure, based on the organization’s Operating Model and its integration and standardization needs. The IT Engagement Model, a system of governance mechanisms, will ensure that objectives (both local and companywide) are achieved both IT and business projects.

The model above illustrates these three factors for a successful execution, and connecting back to a previous article where I discuss the synergy between the BPM and the EA discipline, the BPM discipline would be used to elaborate and execute the projects defined in the engagement model. This illustration used in the book was provided by the MIT Sloan Center for Information Systems Research.

There are four types of Operating Model, each with their own strengths and weakness, as well as implications on how to achieve them through an Enterprise Architecture, as they stipulate different requirements for standardization and diversification. These types are:

  • Diversification: Low standardization and low integration.
  • Coordination: Low standardization and high integration.
  • Replication: High standardization and low integration.
  • Unification: High standardization and high integration.

Dependent on the choice of operating model, this determines the type of growth for the organization. The following table on the left gives the characteristics of each of these models, as the table of the right elaborates on the growth types. Each of these tables is clickable for better resolution.


It should be clear that the choice of Operating Model guides development of business and IT capabilities, and as such plays an important role in determining which strategic opportunities the organization should and should not pursue. In effect, it becomes a de facto driver of business strategy.

Enterprise Architecture is a discipline often presented in principles, policies and technology choices. However, a single diagram (called the “core diagram”) goes a long way to starting the debate around EA among stakeholders on their road towards understanding what enterprise architecture their organization needs. A helicopter view of sorts, or an elevator pitch. This diagram should consist of the following components:

  1. Core Business Processes
  2. Shared Data Driving Core Processes
  3. Key Linking and Automation Technologies
  4. Key Customers

The stages any organization goes through to achieve a foundation for business execution are rather predictable, and are called the stages of architecture maturity. They are as follows:

  1. Business Silo Architecture: Maximizing individual business unit or functional needs
  2. Standardized Technology Architecture: Enhancing technology standardization and increased centralization of technology management in order to augment IT efficiency
  3. Optimized Core Architecture: Aligning organizationwide data and process standardization with the operating model of choice
  4. Business Modularity Architecture: Optimal reuse of loosely coupled IT-enabled business process components in order to create a marriage of global standards with local differences
  5. Dynamic Venturing Architecture: Extending the concepts of reusability to enable rapid reconfiguration of the organization’s portfolio of businesses

Successful organizational learning coupled to these stages comes with a different set of requirements. The table below gives an overview for each of the levels, as well as a level that is added to the list later in the book, namely the Dynamic Venturing Architecture.

The management practices for each of these maturity levels match the organization’s evolution through these stages of maturity closely. This ranges from the introduction of business cases and project methodology in business silos to using EA core diagrams, post-implementation assessments, technology research and adoption processes, as well as a full-time enterprise team. To me, this seems to be so evident and natural. For example introducing architects on project teams linked with the standardized technology architecture has been already standard practice in solution architecture and thus not an earth-shattering revelation, even so far back as 2006 when this book was published.

The book does give a nice overview of the different models for outsourcing, each with their proper advantages. Where Business Process Outsourcing (BPO) identifies Contractual Partners, Cooperative Partners and Partners in Success based on the level of integration with one’s partner, this book names levels based not only on key metrics, but also on client-vendor relationships and client expectations. Linking these models to the enterprise architecture maturity levels, the books also stipulates what can be outsourced, what the ideal relationship is (similar to the levels of BPO), and which objectives are achievable.

The book reiterates its structured approach and summarizes it in its final chapter, stating the six steps to rethink an organization’s foundation for execution:

  1. Analyze the AS-IS situation of your foundation for execution
  2. Define an operating model for your organization
  3. Design an Enterprise Architecture
  4. Establish priorities
  5. Design and implement an IT engagement model
  6. Exploit your foundation for growth

Review EA Comment