Enterprise Architecture as Strategy, Jeanne W. Ross, et al.

The authors ask would you like your business to have:

• higher profitability
• faster time to market
• more value from your IT investments
• twenty-five percent lower IT costs
• better access to shared customer data
• lower risk of mission critical systems failure
• eighty percent higher senior management satisfaction with technology

No doubt the answer to all of these is yes. But whether this book is relevant to a particular company lies in the answers to the following questions:

• one customer question elicits different answers
• new regulations require major effort
• business agility is difficult and growth initiative aren’t profitable
• IT is consistently a bottleneck
• different business processes and systems complete the same activity
• information necessary for making decisions is not available
• employees move data from one system to another
• senior management dreads discussing IT agenda items
• management does know whether it gets good value from IT

In this book the authors refer to Enterprise Architecture as a model describing the key elements – process and data – of a business. They differential EA as described in the book from the IT EA comprised of four tiers (business process, application, data and technical architectures). Some might call the author’s architecture a Business Architecture.

The argument the book puts forward is that there are a set of core business processes and data that a business needs to get right. They are foundational in the sense that other business activity will build from them. The authors make an analogy with basic human functions like breathing, blood circulation – all brainstem functions. They are key activities but we don’t have to think about them, leaving us time to consider higher level activities. The authors argue that if foundational processes and data are not established (and thus built upon) they will be rebuilt for every project; they will never be optimized; they will always consume management cycles.

The authors state that each company has varying degrees of standardization of business processes and integration of data. This combination they call the operating model. Through their research, the authors have characterized four different Operating Models: Diversification, Unification, Co-ordination, and Replication.

Diversification refers to an operating model with low standardization and integration. A Unification model is where there is high standardization and integration. Co-ordination refers to high integration but low standardization. Replication refers to low integration but high standardization.

It should be noted that the authors use relative terms low and high to describe the levels of standardization and integration so even in a Diversification model, technology standards may be developed and deployed such as common products, computing centres, call centres, branches.

While the authors present four simple types of operating models, real-world practice is likely a little more complex. Different operating models could be at play at different layers of the organization. For example, while the enterprise as a whole could share certain data and process (e.g., related to employees and financial information) individual business units could be quite centralized within themselves.

The key outcome of identifying the operating model is the establishment of a core set of operating principles that can be governed against and applied consistently across projects. Determmining one’s operating model, or where one would like to be is a hard task and must be done at a senior executive level.

The EA diagram reflects the specific processes and data shared. Typically the elements highlighted in the diagram include process, data, customers, channels.

The observed benefits of having an Enterprise Architecture include:

• reduced IT costs
• increased responsivness
• improved risk management
• increased management satisfaction (with IT)
• enhanced strategic business outcomes

Ultimately, the objective is to deploy the foundation (of process and data). The authors cite specific steps and activities towards that goal. Broadly, the first steps are to identify the operating model, then the corresponding processes and data as appropriate followed by documenting the EA Diagram. The authors recommend against a big-bang approach favouring an incremental approach: building the foundation one project at a time. This they argue distributes the cost and risk; gradually increases the robustness of the foundation; proves out the Enterprise Architecture (and implicitly allows time to refine).

However taking an incremental approach requires good management. To that end, the authors define an Engagement Model with three main ingredients:

• Company-wide IT governance
• Formalized project management
• linking mechanisms

The relationship between these three ingredients is summarized in the following quote:

“without effective IT Governance, there is no clarity about who makes what decision and how those people are held accountable. Without good project management, projects risk cost and schedule overruns and failure to meet objectives. Without effective linking mechanisms, there are no regular opportunities to have discussions and make decisions about a project’s ability to leverage the foundation and contributes to the foundation’s evolution. “

For organizations executing the deployment stages the authors explore three different outsourcing models (partnering, co-sourcing and transaction) and recommend which model is appropriate given an organization’s architectural maturity. The key message here is that while one outsourcing model may be appropriate when an agreement is signed, it may need to be revisited as the organization matures.

Finally the authors explore how to achieve profitable growth in each of the four operating models. As before, real case studies are provided to support the thesis.

Building upon a foundation is not a new idea and while many of the practices cited by the authors will be familiar, the book provides a useful description of a complete approach allowing one to link together the pieces and identify gaps. It shows the relationship among business strategy, architecture, development process, project management, outsourcing and governance. As well relevant best practices and results others have achieved are provided offering potential benchmarks.

By focusing at the business level, rather than the technical level the book provides a context for many of the technical strategies we consider, such as Web Services and Services Oriented Architectures, and properly positions them as solutions not objectives.