Enterprise Architect’s Handbook: A Blueprint to Design and Outperform Enterprise-level IT Strategy (English Edition)

By Dr. Vishwakarma J S

These days, more than ever, enterprise architects are the driving forces behind digital transformation initiatives and the vital link between IT and business. This book enables the readers to become self-sufficient Enterprise Architects by enabling them to understand the business strategy and design the technology landscape, encompassing systems, data, applications, platforms, and enterprise tools, following that strategy.

To comprehend the technology landscape, topics such as Stakeholder Matrix, HeatMaps, Value Stream Mapping, ERDs, Infrastructure, and Network diagrams are discussed in depth in this book. The book also covers numerous approaches for measuring the effectiveness of architecture implementation, including Balanced ScoreCards, OKRs, and Value Drivers – Design Thinking. This book instructs readers on how to create data pillars for complex, interconnected corporate systems. The book teaches you how to implement various architectures, including service-oriented architecture. It describes and illustrates popular tools used by Architectural teams and professionals.

The primary objective of this book is to match business requirements with the technical infrastructure that supports the service delivery team, business development team, and IT Integration team. This book ensures that the technologies chosen and how they are applied, satisfy the business goals of organizations and their customers.

• Language: English
• Publisher: BPB Online LLP
• Release date: Sep 20, 2022
• ISBN: 9789355511638

Book preview

CHAPTER 1

Understanding Your Organization’s Current Landscape – Complexities and Priorities

Introduction

The objective of this chapter is to develop/capture the As Is architecture and capability for an enterprise, or for a specific key initiative, to define and capture the relevant building blocks from information, application and technology domains taking into consideration the stakeholders concerns and requirements, and in alignment with the Enterprise Architecture (EA) principles. As Is Architecture development is needed in most cases to understand what capabilities exist today. It guides an enterprise to see what would need to be improved to meet the desired capability, in alignment of the enterprises’ goals and business objectives. In many cases, the enterprise might decide to move directly to the target architecture. Some scenarios for the same would be as follows:

It is a new business capability such as cloud enablement or analytics, and may not exist currently within the enterprise; hence, the target architecture in this case is the obvious choice, as you will be developing it from ground up and would be a greenfield (new) implementation.

There might be a new technology initiative, pushed as part of innovation, that does not exist today within the enterprise; in such cases as well, target architecture is the logical step. It might need to integrate with the As Is systems of records or differentiations. However, it is a to be state in all cases.

Structure

In this chapter, we will cover the following topics:

Architecture vision

Strategic imperatives of business

Assess global policy impacts

SOAP (Strategy on a Page)

Case study (organization redesign)

Objectives

In this chapter, you will gain an understanding of how to capture and translate the strategy, objectives, and goals of an organization and align them to the architecture vision needed. You will understand how to determine what the organization’s top priorities are with respect to organization’s vision and translate vision to key constituents of objective, goals, and its metrics. The sample use case of organization redesign allows you to apply architecture paradigm to shape the same.

Enterprise vision leading to architecture vision

Architecture vision phase will enable the enterprise to develop creative, practical, and implementable high-level enterprise architecture that reflects enterprise business strategies, responds to identified issues and challenges, and defines the boundaries of the solution to build consensus among all stakeholders before delving into the detailed enterprise architecture models. The architecture vision phase establishes the need for a formal understanding between the business, IT and enterprise EA office to reflect what is expected of the architecture engagement and what artefacts and products would be developed as part of the architecture deliverables and artifacts. As part of the vision, the enterprise EA office would also be able to ascertain the need for architectural domains and their high-level architectural engagement throughout the cycle or phases as applicable. Figure 1.1 illustrates how to map the architecture refresh or new, with high-level suggestions on the key phases:

Figure 1.1: Typical Enterprise Operating and Architecture Refresh Process

Strategic imperatives

The goal of defining strategic imperatives is to identify where to play and how to win. Defining strategic imperatives is a critical component of architecture refresh or new process, as it outlines the set of principles that should guide the refresh and the high-level case for change. The process can take place at the enterprise or the Line of Business (LOB) level, depending on the scope of enterprise’ architecture refresh needs.

Output

There is no standard set of strategic imperatives for an organization – each organization’s imperatives are different and will depend on the unique set of internal and external circumstances facing the firm. Any evaluation of strategic imperatives must generate two key deliverables: a summary of internal/external opportunities and challenges and a broad set of strategic objectives for the firm:

Summary of internal/external challenges and opportunities: At the onset of an enterprise architecture refresh, the project team should summarize the most important internal and external factors influencing the positioning of the business and the key factors motivating architecture redesign. This summary should take into account not only the business’s evolution since the last refresh but also any changes in the political, legal, and regulatory environment that have impacted the industry more broadly. Figure 1.2 shows a sample assessment of the business context underlying the most recent architecture redesign efforts:

Figure 1.2:Sample View of factors and forces to consider

The preceding graphic illustrates that a combination of internal and external factors, including a slow economic recovery, intensifying product and price competition, and an increasing need to leverage scale and capitalize on global opportunities makes it important for an enterprise to revitalize the current operating model and build a foundation to realize strategic imperatives.

Identify strategic imperatives for architecture redesign: Once the business context has been identified, the next step is to formulate a set of strategic imperatives outlining the path forward for the organization. Imperatives should aim to identify not only how the organization will measure success along key strategic dimensions but also highlight the areas of opportunity deemed to be the most important to the future growth of the company. While imperatives should and do vary significantly from one refresh to another, key imperatives typically (but not always) fall into the general buckets of developing products (for example, how should we refocus our product portfolio to orient toward higher growth?), understanding customers (for example, how do we improve customer acquisition and retention?), enhancing distribution (for example, what channels represent the highest growth opportunities?), increasing efficiency (for example, improving operational excellence and leveraging scale), and pursuing growth opportunities, both organically and through mergers and acquisitions. Figure 1.3 shows an illustrative set of strategic imperatives that were borne out of executive group sessions and strategy team sessions preceding the most recent architecture refresh.

Figure 1.3:Sample Strategic Imperatives for the Enterprise

Process for achieving output

A few specific inputs can help define the current business context and determine the strategic imperatives that should inform architecture redesign:

First, working sessions among the project team and senior strategy team leadership can help to develop an initial set of business issues to consider and a set of strategic imperatives that underpin the case for architecture change.

Interviews with the LOBs and senior members can also provide helpful background context and clarify key challenges and opportunities. Table 1.1 provides a sample of high-level interview questions and discussion points relevant to defining strategic imperatives.

Table 1.1: Sample questions to understand the need for architecture change

Assess top global policy impacts

Effective corporate policies translate the strategic imperatives into a concrete set of design principles and decision rules that will govern the way the architecture and operating model is structured. This section outlines the high-level approach to identify the most important cross-matrix decision areas for the business.

Output

For any architecture refresh, decision area analysis must generate an understanding of the policies and decision areas of the most importance to the firm. In general, top global decision areas can be defined as those that:

Protect an enterprise from risk

Enable prioritization across the portfolio and execution of cross-enterprise initiatives

Drive top line and margin growth

Develop external view of what is needed for success

Require cross-matrix input and deep functional area expertise

Figure 1.4 shows illustrative output identifying some of the most important decision areas identified by the blueprint team as part of the assumption of current effort:

Figure 1.4: Blueprint Identifying priorities – Sample

Process for generating output

A few specific inputs can help prioritize top global decision areas and determine what policies should be overhauled as part of the broader operating model redesign. These are as follows:

Working sessions among the project team and key functional leaders can help determine the key decision areas by functional area that require greater clarity.

Interviews with functional areas leaders across the enterprise are also valuable for vetting major policy challenges and opportunities. Table 1.2 provides a sample of high-level interview questions and discussion points relevant to identifying top decision areas.

Table 1.2: Questions to get you a good start around policy needs

Strategy On a Page (SOAP)

IT strategy is often vague, confusing, and difficult to put across business stakeholders. As a result, IT business partners and IT executive team members fail to fully understand the strategy or cascade it to execution teams. This Strategy on a Page communicates in a single page the key IT initiative, core themes, people and technology focused needs and a current to target state view. It’s a very simple and concise view to use for communication across various stakeholders. Figure 1.5 is a simple interpretation of the SOAP example:

¹Figure 1.5: CEB’s Sample for SOAP (Strategy on a Page View)

Using the SOAP template from CEB

This section would cover the key inputs and outputs you would need to follow to create a SOAP:

Statement of IT strategy: This section should be used to discuss, agree, and capture a clear and simple statement of what we want to achieve in line to what has been set by corporate strategy and how IT will enable it.

State of IT as is year: This is where the IT stakeholders should capture 5-7 metrics of the current state of IT in the enterprise.

Top five to seven IT initiatives: This is the section where IT stakeholders must define and capture some of the key initiatives that are underway and that will help them achieve the target metrics set 3–5-year roadmap.

Top 5 – 7 assumptions: It is critical for stakeholders to capture the key assumptions that help ascertain what these initiatives are expected to be laid upon.

State of IT target year (3-5 year): This is the section where IT stakeholders need to capture some of the key metrics to achieve in the next 3-5 years.

Define and capture current capabilities

This section discusses the process for defining the role of the enterprise and outlining key components of the future state enterprise model. The section is divided into two clear approaches:

Optimal integration model: It describes the process for determining the role of the IT strategy division and the optimal integration model for the firm

Key components of service delivery model: It highlights the methodology for determining how capabilities should be delivered (for example, global vs. local, SS vs. COE, tiered vs. standard) (use case that we will run while trying to relate the study to practical implications of how to assemble it all for a successful architecture refresh or new one from strategic point of view.

Optimal integration model

The goal of integration model assessment is to determine the role that the strategy team should play within the enterprise. This is a critical component of the redesign process, as it determines the underlying structure of the operating model and the consequent range of scale and scope benefits achievable by the organization.

Output

For any architecture refresh, a well-executed assessment of enterprise integration must generate an understanding of the two key variables:

Level of integration: The selection of an appropriate integration model is critical to support overall refresh efforts, as it answers the critical question: what kind of company should we be? The output from this step should ideally include the following:

A selection of one of the three common types of operating models (fully integrated, distributed, and selectively integrated)

A high-level outline of the roles the strategy team and the LOBs in policy and strategy development and risk management

A sample of the result from this exercise, generated by the blueprint team as part of the current architecture refresh, is presented in the following two figures:

Figure 1.6: Integration Continuum sample

In Figure 1.7, we can see how we can connect the dots of strategy to enablers:

Figure 1.7: Flow of strategy and enabler value of IT

Roles of corporate and the businesses: Based on the integration model selected, there are clear implications for the roles of the businesses and corporate in operating the company. As such, a detailed list of the roles and responsibilities that each should play under the new model is essential. Where possible, this list should identify, among other things, who is responsible for setting overall enterprise and business-level strategy, who has accountability for the P&L, who will be responsible for talent management, and who will be responsible for originating and maintaining corporate policies and capabilities critical to the ongoing operations of the company. While this is a subjective process, analytical rigor is extremely valuable in helping delineate accountabilities as closely as possible. Figure 1.8 provides a sample output from this exercise, as completed by the executive groups in a typical consensus:

Figure 1.8:Sample output of the strategy information flow

What if we wanted to change the enterprise model to Shared Services (SS) and Centre of Excellence (CoE) – Use Case

Process for achieving output

Determining the appropriate integration model for the enterprise is a challenging process that can involve several rounds of iteration between multiple stakeholders. There are three common models to consider.

Fully integrated

Description: In this model, the corporate center sets enterprise strategy and policy, and acts as general manager with tight control of business operations.

Selection criteria: This is typically utilized in companies with a single core business (or a couple of highly related businesses). This degree of control/centralization allows the company to take advantage of scale and scope benefits without limiting the responsiveness of the business to the needs of different regions, customers, or product groups.

Examples: Southwest Airlines

Selectively integrated

Description: In the selectively integrated model, the corporate center sets enterprise-wide strategy and policy, and the businesses develop and execute business-specific strategies. The corporate center will also provide certain services where scale/scope advantages are realized beyond what can be in the businesses alone.

Selection criteria: A selectively integrated model is deployed when certain outcomes of both centralization (for example, scale, quality, risk management, efficiency) and de-centralization (for example, local market knowledge, product customization) are attractive. In this situation, a company should aim to balance shared and centralized capabilities with business-level autonomy to maximize the benefits of both centralization and de-centralization as much as possible.

Examples: Microsoft, Unilever

Distributed

Description: In a distributed model, the corporate center plays more of a shareholder role where it is responsible for market entry/exit decisions, structuring investments, and appointing key talent to run the business.

Selection criteria: The distributed model is more common in multi-core businesses where scale benefits are outweighed by the individual needs to business units and their need to remain responsible to different customers, regions and/or product groups.

Examples: Berkshire Hathaway; Private Equity firms

The illustration in Figure 1.9 is a good example of how it can be looked at:

Figure 1.9: Sample Enterprise Operating Model Change that impacts the Architecture

Constructs of a service delivery model

To capture benefits and manage challenges, the project team will also need to build a more deliberate service delivery model (informed by external best practices) that will provide the company with a common approach to capability management across the organization.

Output and process for achieving output

In order to outline the future state service delivery model, the project team must answer three key questions:

What types of services should be delivered globally?

How should they be delivered?

What types of service levels will be provided?

The process for answering these questions is described in further detail in the following sections. Determining which services are deployed globally today and focus which corporate services should be global in scope in the future.

Global: Global services are delivered consistently enterprise-wide. Global services do not necessitate the pooling of all resources in one location. Although the service must be provided consistently throughout the enterprise, the personnel providing the service can be in several locations throughout the world. Global services must nonetheless be run centrally and consistently, and in the end, report to one central head. Typically, corporate services will be designated global where:

Providing greater autonomy could impact the risk profile of the organization

Consolidating activities could provide significant benefits of scale

Consolidating activities provides value from greater consistency and/or higher quality

Benefits brought by delivering standard services across the enterprise outweigh those that come with customization of specific LOB requirements

Figure 1.10 gives you a glimpse of the driving pillars for a typical service that we intend to deploy globally:

Figure 1.10: Key considerations for Service Delivery Model

How are these services delivered today? How should these services be delivered in the future?

Typically, corporate services are delivered via shared services or centers of expertise, with policy residing in the corporate center:

Corporate Center (policy setting area): The corporate center sets enterprise-wide policy and strategy to guide decision-making. This policy and strategy setting is owned by senior executives, typically functional heads, and their direct reports.

Shared services: Shared services are created to build scale and reduce costs through operating efficiency. The use of shared services enables greater standardization of processes and technology, thereby reducing complexity. In addition, shared services improve the effectiveness of the service by increasing the organization’s experience delivering the given service. The primary goal of a shared service is to deliver acceptable levels of quality at the lowest possible costs. Typically, the activities performed by shared services are transactional or execution-focused, do not require high-cost labor, and can often be performed in lower cost locations. An effective shared service adheres to the cost and quality levels established in service-level agreements with LOBs and other internal customers. Creating shared services also enables a company to move to an outsourced model in the future should that be deemed advantageous. After an enterprise is familiar with consolidated service functions and relationships based on service-level agreements, moving to an outsourced model is easier.

Centers of Expertise: Centers of Expertise (CoE) create a central repository of valuable knowledge, skills, and expertise. CoEs help optimize the deployment of scarce resources across the enterprise. Consolidating scarce expertise allows for increased collaboration, as CoE members leverage one another’s knowledge in solving complex problems. The primary goal of centers of expertise is to provide high-quality services at acceptable levels of cost. A CoE adds value to the enterprise by acting as an expert advisor or by performing complex work. Furthermore, CoEs are valuable in establishing best practices to be used across the enterprise and creating new insights that can drive competitive advantage (for example, customer segmentation). A successful CoE delivers expertise and/or advice to a LOB/function within a required timeframe. Figure 1.11 summarizes the criteria for performing a top-down categorization of capabilities as SS or CoE as well as sample output from top-down classification analysis performed as part of the current architecture refresh.

Figure 1.11: Simple Classification Table

In terms of the complexities of a SS vs CoE, if we had to create a sample view or map each function, it would look very similar to Figure 1.12:

Figure 1.12: SS vs CoE mapping of process landscape

Architecture vision for the business capability improvement project, initiative, or the case at hand would be imperative to the use case at hand of looking at an organization redesign from typical services to a SS and CoE. It would help the architect to identify stakeholders, engage with them at the right level, be able to capture the requirements for architectural deliverables, provide update to the business impact analysis, and detail out any constraints and perceived or actual risks for the target state of the capability in proposal.

Key items that follow similar transformation needs are what is included in and should be kept out of the purview of the scope of architecture cycle. Architecture vision document that sets out the desired outcome of the architecture engagement, and this helps in the EA Office to conduct or check the feasibility of the critical areas that the architecture would affect.

At this step, the level of EA Office engagement can also be established; for example, whether needed only for governance or for validation of a new business case or as case may be.

It is a good practice to maintain the logs and details of:

What is going to change and what will be reused from architectural repositories

Need for EA representation during different phases of the program/project

Clear understanding of the architecture domains being covered

Understanding of the timeline of involvement from the EA

Conclusion

What we covered in this chapter will enable you to answer the what questions around business strategy capture, understand the key constraints an architect needs to be mindful of and definitely what they can do around those constraints would be covered at length in the following chapters.

In the next chapter, we will tag along the use case of organization redesign with the example of shared services and CoE and see how to capture the expected outcomes and themes that we, as architects, can then use to shape it all up for the right plan and definition for implementation.

Points to remember

No architecture is complete without the right understanding, acceptance and clear documentation of the enterprise’s strategy and implementation plan.

Architecture is an enabler to achieve these corporate strategies.

It’s important to ask questions and document the answers with clear responses and emphasize on keywords that matter.

Visual diagrams can be a great way to share an idea and brainstorm on the challenges you see.

_____________________________

¹ The Corporate Executive Board Company – SOAP template

CHAPTER 2

Strategic Direction, Value Drivers, and Expected Business Outcomes

Introduction

In the previous chapter, we read about a typical enterprise strategy driving the need for and impacting the enterprise operating model, initiating the discussions for architecture refresh and its implicit need to make it happen. This typically is the WHY of the entire journey.

We will build on the use case and continue the journey of architecting your enterprise from ground up. In this chapter, the emphasis would be on WHAT is needed to make the new enterprise work like a giant wheel.

Structure

In this chapter, we will cover the following topics:

Capturing objectives, goals and assigning metrics to them

Use cases of internal audit, customer sales and service

Templates that you can leverage

Objectives

In this section of the book, we will address the very first step on how you can capture the strategic drivers that an enterprise sets. We will run it with an example of two known departments of any mid or large size enterprise, namely, internal audits and customers sales and service group. This