5 Business Objectives for the EA Capability
In many regards, the two most important activities in establishing a successful EA Capability are understanding the enterprise context and the objective of the EA Capability. Too often, conversations about EA implicitly assume an enterprise context and a set of objectives. Participants in the conversation use the same words, with no common meaning, or shared expectations. Implicit assumptions invariably lead to failures. EA should endeavor to explicitly extract the enterprise context and set of objectives from the sponsor of the EA Capability, like the CEO or the CIO. Implicit deductions, though possible from certain documents, invariably misdirects the effort. Successful evolution of an EA Capability happens only when explicit alignment is continuously established and validated.
The purpose and objectives of the EA Capability will directly shape the EA organization model, the governance framework, the architecture contents, and the process model. Further, they will define whether the EA Capability is successful, or will follow the recurrent path of try, fail, and re-boot.
To have common understanding of the objectives and expectations, the following questions need to be answered:
- What is the EA Capability expected to achieve and why?
- What is the usage and application of the EA produced? For example, EA to support strategy, program, segment, capability, project, or third party.
- How is success going to be measured?
- Is the EA Capability doing the right thing for the enterprise context?
- What is the depth and breadth of the EA?
- What is the organization model of the EA Capability?
By approaching and answering questions, the purpose of the EA Capability and what it needs to be successful are framed. The Leader is in a position to separate wheat from chaff and focus on what is expected and what will be successful. Challenges regarding process integration and governance can be addressed. Challenges regarding organization model and existing resources are placed in stark relief.
Most sponsors for an EA Capability speak regarding financial goals or broad objectives (decrease cost of doing business, improve speed-to-market). Suyog Mahendra Shah[15] identifies that stakeholders may have different motivations and perspectives. The unaddressed gap between sponsors’ objectives and stakeholder perspective results in failure. The thought process of stakeholders will have to be shifted from task-based or project-based to thinking regarding systems and enterprise level.
A key first step for the EA Capability Leader is to play back the executive talk in explicit capabilities, go-to market approaches, or operational requirements. It is important to be specific to get alignment with the enterprise’s values, goals, and strategies to have a common understanding of the objectives and expectations of the EA Capability.
5.1 What is Expected?
Where will the EA Capability team be engaged? How to validate that the EA Capability is doing the right thing?
A quick perusal of the literature on the role of an Enterprise Architect or EA Capability will leave no understanding of the role. At the extremes, the role is classified as an enabler of enterprise transformation or responsible for the selection of technical IT standards. This wide variance is responsible for most failures of an EA Capability. A mixed bag of expectations will result in improper scoping for work products and planning the evolution and development of the EA Capability.
In its simplest terms, EA is used to describe the future state of an enterprise to guide the change to reach the future state. The description of the future state enables key people to understand what must be in their enterprise to meet the enterprise’s goals, objective, mission, and vision in the context within which the enterprise operates.
The gap between the enterprise’s current state and future state highlights what must change within the enterprise. This gap is a function of the enterprise context and the scope of changes the enterprise sees.
5.2 What is the Depth and Breadth of EA?
Typically, there are four broad purposes[16] of an EA Capability:
- EA to support Strategy: deliver EA to provide a target architecture, and develop roadmaps of change over a three to ten-year period
An architecture for this purpose will typically span many change programs or portfolios. In this context, architecture is used to identify change initiatives and supporting portfolio and programs. Set terms of reference, identify synergies, and govern execution of strategy via portfolio and programs.
- EA to support Portfolio: deliver EA to support cross-functional, multi-phase, and multi-project change initiatives
An architecture for this purpose will typically span a single portfolio. In this context, architecture is used to identify projects, and set their terms of reference, align their approaches, identify synergies, and govern their execution of projects.
- EA to support Project: deliver EA to support the enterprise’s project delivery method
An architecture for this purpose will typically span a single project. In this context, the architecture is used to clarify the purpose and value of the project, identify requirements to address synergy and future dependency, assure compliance with architectural governance, and support integration and alignment between projects.
- EA to support Solution Delivery: deliver EA that is used to support the solution deployment
An architecture for this purpose will typically be a single project or a significant part of it. In this context the architecture is used to define how the change will be designed and delivered, identify constraints, controls, and architecture requirements to the design, and finally act as a governance framework for change.
These four purposes frame the depth and breadth of an EA Capability’s operations and need to sustain an EA repository. Within the scope of the purpose, the Leader must understand what is expected from an EA Capability. Questions to ask include:
- Where in this hierarchy is the EA Capability expected to support decision-making?
- Where in this hierarchy is the EA Capability expected to support governing change activity?
- Is there a priority of focus; for example, solution deployment over strategy?
- Is there a concern that current change initiatives are failing to deliver expected value?
Consider that one EA Capability may support a strategist or functional Leader defining where the enterprise is going. Another EA Capability may take the strategist’s output and support governance activity to realize the changes specified by the strategist. Questions such as the above list help clarify the nuances of the purposes mentioned above. Given that different architecture projects may address different levels of detail, the way the EA Landscape is filled will vary. If plotted on a three-dimensional graph, at any given point of time, work being executed will look like a scatter diagram.
5.3 What is the Organization Model for EA Capability?
Most enterprises have some functioning EA Capability. The EA Capability is either being purposefully evolved or re-booted. In either case, the existing EA Capability needs to be assessed against expected purpose and objectives.
Questions to ask include:
- Does the existing EA Capability deliver recommendations before the required type of decision (budget, charter/business case)?
- Does the existing EA Capability provide support for governing follow-on activity against the decision?
- Does the existing EA Capability support all the desired decisions and governance support?
When an EA Capability has previously been IT-centric, it is common to have its support for decision and governance constrained to the IT domain and its involvement in decision-making artificially elevated.
- The outputs of these questions will directly impact the process alignment, governance framework, and architecture contents – the gap between the existing EA Capability and the desired EA Capability will directly feed the roadmap to evolve the EA Capability into what the enterprise desires
The following tables, derived from the World-Class Enterprise Architecture White Paper, provide an indication of the engagement of different stakeholders with support for decision-making and governance.
Table 1 and Table 2 should be used diagnostically in conjunction with Section 10.1 (What are the Touch-Points with Existing Enterprise Processes?). The Leader will need to ensure that the EA Capability is properly aligned. The essential questions are:
- Does the EA Capability support the decision-making needs of key stakeholders?
- Does the EA Capability support the governance needs of key stakeholders?
- Does the EA Capability engage with the correct enterprise decision-maker and execution processes?
Table 1: EA Capability to Stakeholder Decision-Making Needs
|
Stakeholder Group |
Relevance of EA Capability to the Stakeholder Group decision-making for the … |
|||
|
Strategy |
Portfolio |
Project |
Solution Delivery |
|
|
CEO |
High |
Low |
Low |
Low |
|
Heads of Change |
High |
Medium |
Low |
Medium |
|
Operational Executives |
High |
High |
Low |
Medium |
|
CIO |
High |
High |
Medium |
High |
|
Project Governance Bodies |
Low |
Medium |
High |
High |
|
Program & Project Management |
Low |
Medium |
High |
High |
|
Commercial & Financial Executives |
Low |
Medium |
Low |
High |
|
Subject Matter Experts & Project Teams |
Low |
Low |
Medium |
Low |
|
Chief Risk Officer |
High |
Medium |
Medium |
Low |
|
Chief Compliance Officer |
High |
Medium |
Medium |
Low |
Table 2: EA Capability to Stakeholder Governance Needs
|
Stakeholder Group |
Relevance of EA Capability to the Governance activity for the … |
|||
|
Strategy |
Portfolio |
Project |
Solution Delivery |
|
|
CEO |
High |
Medium |
Low |
Medium |
|
Heads of Change |
High |
Medium |
Medium |
Medium |
|
Operational Executives |
High |
High |
Medium |
Medium |
|
CIO |
High |
High |
High |
High |
|
Project Governance Bodies |
Low |
Low |
High |
High |
|
Program & Project Management |
Low |
High |
High |
High |
|
Commercial & Financial Executives |
Low |
Low |
High |
High |
|
Subject Matter Experts & Project Teams |
Low |
Low |
Medium |
Low |
|
Chief Risk Officer |
High |
Medium |
Medium |
Medium |
|
Chief Compliance Officer |
High |
Medium |
Medium |
Medium |
As a rule, stakeholders will require different support for decision-making than for governance activity. An EA Capability that is not engaged in architecture to support strategy decision-making, but is engaged at the portfolio level, may provide support for governance activity against the strategy level. This Guide turns to the importance of alignment of the EA Capability team, given the expectations of outcomes at strategy, portfolio, project, or third-party engagement levels.
5.3.1 Alignment of EA Capability Team in the Organization Model
Most teams delivering an EA Capability today fall under one of the three variants – function-centric,[17] strategy-centric, or IT-centric, as shown in Figure 7. As with all conceptual models, there will be variations or hybrids specific to an enterprise. For example, participants in the team may be aligned to one team, and the contributing members may be aligned with line of business (function-centric) teams.
The initial scope and impact of the EA Capability varies based on the model that is being followed in the enterprise. This alignment will impact the constitution of the architecture review board, governance model, and time to realize value.
Function-Centric EA
IT-Centric EA
Strategy-Centric EA
Figure 7: EA Team Common Organizational Placements
Each model supports a different set of objectives, empowerment, and constraints for the EA Capability team, as they are reflections of the outcome expectations from the EA. Having such a model does not preclude the charter for a team providing the EA Capability from addressing other aspects. When the expectation is such, there exists a possibility for alignment hierarchy for the EA Capability team to shift from one model to another as objectives and strategies change. The Leader must be cognizant of a coherent or mixed bag of expectations and charter to define appropriate execution methods.
A high-functioning EA Capability requires cross-discipline function behavior and engagement in other processes of the enterprise. These processes include corporate governance, fiscal control, customer and stakeholder engagement, and project management. Further, Martin van den Berg and Marlies van Steenbergen (2006)[18] highlight the need to cover individualistic architect functions like consulting, mentoring, commitment, motivation, and persistence. The EA Capability team must have sufficient capacity and diversity of domain knowledge, soft skills, and context to be successful.
5.4 How is Success Going to be Measured?
The enterprise’s objectives directly translate into metrics for the EA Capability and are directly derived from the purpose of the EA Capability. Some metrics will be operational health while others will be derived from the enterprise’s scorecard or strategy.
Recognize that not all EA Capability objectives are tangible and readily measurable. Consider an insurance company that says: “we need an architecture to make all of our customers be our promoters”. This statement applies to the entire enterprise. Though it appears measurable, dimensions like type of customer (enterprise versus single human), neutrality, or cultural differences should be accounted for to arrive at specific measures. Likewise, it is possible that folks in the team providing the EA Capability, including the Leader, have some ideas that could appear relevant, immediately actionable, and to be common sense. Including such ideas in the list of objectives without validation is one of several death traps for EA Capability. Be prepared to embrace such objectives and classify them accordingly, before converting them into measures.
Some of the objectives may have to be met by other functions in the enterprise. Given the objectives and purpose, care must be taken to align processes, the organizational model, and governance. One of the many death traps for an EA Capability is confusing “supporting decision-making” with “decision-making”. Consider an EA Capability that supports strategy: a team member lobbying to defund an effort considered risky has confused sound advice with ownership of the decision. This conflict is most common in IT-centric EA Capability and plays out in efforts to achieve elevated decision-making power without commensurate outcome responsibility. Confusing supporting a decision with empowerment and governance is simply wishful thinking.
Define success measures that reflect the level of empowerment, quality of outcome delivered, and impact expectations of the sponsor. For example, Gartner signals that EA Capability should present leadership with signature-ready recommendations. What kind of measure should a Leader attach to such an execution model?
Some questions that yield a wealth of insights to define the measures are:
- What would the enterprise do if the EA Capability did not exist?
- How will the enterprise track benefits realized at different levels of decision-making?
- Executive management is a directive function, and EA Capability is an advisory function. How do we measure the value of good advice?
- What would happen when EA Capabilities have a limited ability to deliver?
In general, increased risk and lower levels of value created. Measures may be instability within the business, lower profits, poor investment success track record.
- How will benefits from mature EA Capabilities be realized at different levels of decision-making?
How many recommendations have been accepted by decision authorities? What is the track record of risk identification and mitigation? Has the level of governance been commensurate with the business benefits to be realized?
Further, is the EA Capability being set up in response to a problem? The success measures will vary with the nature of the problem being solved. Common examples of problems to be solved include:
- Struggling expansion via Mergers and Acquisitions (M&A) and divestitures
- Stalled strategic growth in a specific market segment
- Impact of disruption
- Restructuring or retooling the enterprise
- Investor confidence problems from operational cost or unrealized R&D spend
- Inability to decide through information, communication, and technology complexity
- Inability to decide the balance of future gains against compromising business-as-usual
- Fear of recurrence of recent upheavals in supply chain, security, or IT project
- Perceived disruptive changes in operational practice (automation, cloud, outsourcing)
5.4.1 Revivalist and Bottom-Up EA Capability
It is easy to get caught in recurrent cycles of trial and error which ultimately repeat themselves when attempting to re-boot an EA Capability. In a re-boot or bottom-up scenario for EA Capability, it may often seem that the Leader is given the luxury to obtain answers to the questions the sponsors are identifying, albeit without budgetary support. Sometimes a change Leader gives the explicit sponsorship to make the enterprise a better place.
With bottom-up approaches, the challenge is to identify and deliver value to key decision-makers who have a passion to change the organization. If this is not accomplished from the outset, it is better to wait for decision-maker interest to align in the future. Attempting to deliver value before buy-in, in a bottom-up or self-initiation, though prevalent models, has wrought many challenges, as the Leader must act upon interpretation and assumption. When what is delivered is not valued by the potential sponsor, not only has the EA Capability team failed again, the team has wasted valuable resource. At a minimum, it is strongly recommended to understand the enterprise context and develop a value proposition to those in the enterprise who will sponsor a reviving EA Capability. It is strongly recommended to get proper buy-in, including financial allocation and resource commitments, before attempting to pursue a bottom-up approach to establish the EA practice. The Leader has to dig deeper for the reasons that prompted a need to re-initiate the effort. Consider the questions and answers about enterprise needs very carefully. Most of all, assume that the goal is to make the enterprise a better place.
The following are themes that can be used to deliver value and make the charter clear:
- Theme of “foundations for future scale”: creating an implementable effort – like integrating disparate systems or enabling flexibility to update systems and applications independent of each other with a well-defined investment and timeline
- Theme of “function clarity”: EA is about enablement and realization of alignment of business and technology functions; EA is not about monopolizing any one function – it is about collaborative success
Create a charter and communicate terms of collaboration and collective success.
- Theme of “risk reduction”: the very act of involvement in an economic activity is risky
The probability of occurrence and impact is what constitutes outcome. Building a story from a recent “incident” that could have been avoided with the EA Capability, articulating a pattern providing cost avoidance, and minimizing impact on future occurrence.
It is imperative that the Leader validates the enterprise context and objectives of the EA Capability periodically. Every enterprise exists in a dynamic environment. It is important to check the purpose for each planning cycle that the EA Capability team supports. It is essential that the Leader checks the objectives and context once in the planning cycle and again in the middle of the cycle. Best practice EA is a continuous, adaptive, incremental, and iterative process.
Carve out an EA Capability that can succeed and thrive in the enterprise. Use the knowledge from understanding the context for the enterprise. If failure happens in the first attempt to make the business case, consider rebuilding the case after reading through Section 11.2 (Linking the EA Value Map to the Enterprise Value Map) and Chapter 12 (Establishing and Evolving the EA Capability).
return to top of pageTOGAF® is a registered trademark of The Open Group