Scope Definition

The conceptual scope of enterprise architecture is very broad. For this reason many EA practices start out with broad, open-ended scope.

This is fine while gathering initial support and finding out about the organization’s needs, but over time -- iteratively -- scope should be increasingly defined.

The more clearly the scope of an EA practice can be defined, the easier it is to make best use of the EA practice’s resources, demonstrate success, and advocate for further scope and resources.

How you use this guide will vary based on the level of scope definition you are moving your EA practice toward:

• Level 1 Initiating: Use this guide to get ideas about potential scope.
• Level 2 Formed: Use this guide to identify opportunities to demonstrate value and validate scope.
• Level 3 Defined: Use this guide to define scope, selecting from ideas for potential scope.
• Level 4 Managed: Use this guide to review dimensions of scope as you re-evaluate scope.
• Level 5 Improving: Use this guide to find ideas for potential additional scope.

Scope is Not Maturity

This is stated in the EAMM, but just as a reminder:

​

“In higher education, EA practices vary widely in the scope of their mission and the impact of their work. At the same time, industry definitions of enterprise architecture as a discipline and its goals continue to evolve. Therefore, the focus of this maturity model is not to prescribe what the scope of an EA practice should be. We believe it is for leadership in each institution to define why an EA practice is needed, set expectations for it, and create the conditions for its success.”

​

However, the ability to better define scope over time is an aspect of maturity (see Scope Definition in the EAMM).

Documenting Scope

When you are ready -- after some period of open-ended exploration and perhaps initial demonstration of value -- it is helpful to document the scope of the EA practice. This makes it possible to:

• Further clarify scope with stakeholders
• Widely communicate the mission of the EA practice
• Gain feedback and buy-in

​

A good way to record scope is in the form of a summary strategy for the EA practice. A simple one-pager helps your own team and others understand why the EA practice exists, what is driving its work, and the outcomes it is working toward.

There are many ways to capture strategy; here is a simple “strategy on a page” template:

Example: Strategy on a Page

The sample strategy on a page at right summarizes scope for an imaginary EA practice:

• Why: This practice is going to increase the effectiveness of the university’s IT spend (see blue highlights at right)
• What: This practice is focused on IT infrastructure and services (see green highlights at right)
• Where: This practice is going to deliver outcomes in central IT and with central administration (see orange highlights at right)
• How: This practice is going to do certain work such as systems analysis and business capability mapping (see purple highlights at right)

Having determined this scope, the EA practice can now review its ability to, for example, engage with stakeholders in the identified organizations, or create the stated deliverables.

Dimensions of Scope

As starting points for discussion, the following slides offer various perspectives on potential scope for an EA practice. Use these to generate ideas or review

Goals of the EA Practice

Capabilities of the EA Practice

• Who is the EA practice intended to provide value to?
• Where in the enterprise is EA intended to produce outcomes?
• What is the EA practice charged to accomplish? Why?

Perspectives on this area:

• Customers/Stakeholders
• Organizational Coverage
• IT Value Chain

• How will the EA practice deliver its outcomes?
• Doing what kinds of work?
• Delivering value through what means?
• Partnering with whom?

Perspectives on this area:

• Delivery Methods
• Management Areas/Activity Areas
• Architecture Domains
• Levels of Detail

Goals of the EA Practice >

Customers/Stakeholders

Like any service provider, the EA practice should be able to state the customers it seeks to serve and the value it seeks to offer them.

Examples of customers for an EA practice can include:

• Senior leaders who benefit from increased organizational capacity resulting from EA work
• Managers who benefit from information or methods provided by EA to improve decision-making
• IT service teams who benefit from standard reference architectures developed by EA
• Project teams who benefit from EA methods or work contributed by EA

There are many approaches to thinking about customers and business value; Strategyzer’s Value Proposition Canvas is one:

Goals of the EA Practice >

Organizational Coverage

Although EA conceptually is enterprise-wide in scope, in practice it is located in some organization within the enterprise. The EA practice should identify the organizations it seeks to achieve outcomes in, and its goals for growing that coverage.

Growing organizational coverage has various aspects including:

• Building relationships for effective collaboration in each organization
• Assessing what is most important to do and most feasible in each organization
• Finding sponsors to drive work and make decisions in each organization

If EA is located in IT, it is common to target outcomes in:

1. Central IT
2. Other IT service providers
3. Major enterprise-wide IT initiatives
4. Business owners of major applications managed by IT

Across the institution, EA may seek to target outcomes in different lines of business, such as:

• Teaching & learning (e.g., colleges, schools, departments)
• Research (e.g., research programs, research administration)
• Administration (e.g., finance, HR, IT, etc.)
• Patient care (if applicable)
• … etc. …

Goals of the EA Practice >

IT Value Chain

The EA practice is frequently located in IT or seeks to improve the performance of IT for the enterprise. To clarify the EA practice’s scope, consider which aspects of IT’s value chain you are seeking outcomes.

This is linked to other scope decisions, for example:

• Your drivers and outcomes may be more related to strategy or more based in projects or operations
• Your intended customers may be more focused on strategy, design, deployment, operations, etc.

There are many ways to describe the value chain for IT; a representative approach is the OpenGroup’s IT4IT model:

Capabilities of the EA Practice >

Delivery Methods

An EA practice has many potential ways to deliver on its desired outcomes. In maturing an EA practice, it is helpful to focus on selecting and getting good at selected methods.

Considerations in selecting methods to focus on include:

• From what will your intended customers most easily benefit?
• What will provide the broadest benefit for the least effort?
• What your team is most skilled in providing
• What fits the culture and management structure of your organization

Potential delivery methods for an EA practice are described in the EAMM in the Delivery attribute:

• Services: EA offers ongoing services such as consultation or design (perhaps as part of an IT service catalog)
• Engagements: EA creates project-like engagements with defined deliverables for stakeholders
• Staffing: EA team members staff initiatives to add architectural value
• Processes: EA has a role in specific processes, such as governance or design processes
• Reference architectures: EA leads creation of reference architectures and their application
• Methods: EA offers methods to improve information-gathering, analysis, and decision-making
• Frameworks: EA offers frameworks to provide shared concepts and approaches
• Outreach: EA conducts activities to raise awareness of EA resources and opportunities
• Training: EA trains people to understand and apply architectural principles and methods

Capabilities of the EA Practice >

Management/Activity Areas

An EA practice contributes to the existing management of an enterprise. To achieve its outcomes, an EA practice typically needs to support or enhance existing management (such as IT service or project management), or create new management processes (such as IT governance).

Extending EA to new areas of management has various aspects including:

• Building relationships with managers already working in the area
• Assessing existing management in the area
• Collaborating with sponsors and managers to agree on outcomes

Examples of management areas for possible EA work:

• Project management; project portfolio management
• Service management; service portfolio management
• Management of development teams (e.g., Agile management, release management, DevOps)
• Business relationship management
• Supplier relationship management
• Governance (especially IT governance)
• Strategy management
• Investment management
• Organizational change management
• Organizational development; workforce development

Capabilities of the EA Practice >

Architecture Domains

Several complementary architecture domains typically come into play in working on enterprise architecture. However, the EA practice may choose to deepen its expertise or grow its activity in particular architecture domains.

Reasons to do this can include:

• Need to focus limited EA team resources on a feasible range of expertise
• Need to respond to particular drivers and outcomes (for example, need to stand up data governance or develop a data strategy)
• Need to balance out lack of coverage in the organization (for example, an IT organization lacking business architecture resources)

​

​

There are many possible lists of architecture domains; the following from TOGAF are representative:

Capabilities of the EA Practice >

Levels of Detail

An EA practice can provide deliverables at various levels of detail depending on its desired outcomes. For example, it might contribute to a very high level strategy document or a very detailed requirements analysis.

While experienced architects are able to contribute at multiple levels, the EA practice may choose to focus on a few. Considerations include:

• Where the EA practice can be most effective in spending its time?
• What opportunities exist to hand off work to other teams for more detail?
• The skill sets available in the EA team

There are many ways to characterize levels of detail; the Zachman Framework is a representative example (left column):

​

Appendices

Appendix: Scope Definition

This appendix contains sample worksheets that can be used to open up discussion about different potential scopes for an EA practice.

1. Stakeholders and Outcomes: Who is a stakeholder in the EA practice, and why do they want it?
2. Coverage: What capabilities does the EA practice seek to enhance, where in the organization?
1. IT Organization Capabilities
2. Institution Capabilities
3. Practice Areas and Offerings: How does the EA practice seek to deliver outcomes?
• Architecture & Management Practice Areas
• EA Offerings

I. Stakeholders and Outcomes

Potential stakeholders include: your senior leadership or other sponsors; teams you serve; project stakeholders; roles you enable or support; etc.

Stakeholder:

What challenges do they face (relevant to EA)?

What outcomes do they seek from EA?

Definitions

For the column headings on the following worksheets:

​

For Part II: In order to build capabilities in the organization, the EA practice:

• Lead = Seeks to lead in this area
• Contribute = Seeks to contribute directly along with others
• Influence = Seeks to influence without direct responsibility
• Observe = Seeks to track this area without planned outcomes
• None = At this time, the EA practice doesn’t seek outcomes in this area

For Part III: To deliver outcomes, the EA practice:

• Lead = Seeks to lead this type of work in the organization
• Contribute = Seeks to contribute to this type of work along with others
• Enable = Seeks to enable others to do this type of work, for example through training
• Observe = Seeks to track work this area without committing to outcomes
• None = At this time, the EA practice isn’t involved in this type of work

Definitions

For Part II: As the organization develops capabilities in each area shown, the EA practice:

• Responsible = Directly working to build the capability (can involve others)
• Accountable = Ultimately answerable for the capability
• Consulted = Provides input to influence the capability
• Informed = Observing what is being done; may participate more later

For Part III.A: To deliver outcomes, the EA practice:

• Responsible = Actively doing this kind of work (can be alongside others)
• Accountable = Ultimately answerable for this type of work
• Consulted = Provides input to influence how this work is done
• Informed = Observing what is being done; may participate more later

On the following worksheets, apply the common RACI categories in the following way:

Also ask: In each case, if the EA practice is not Accountable, can you define who is?

II.A. IT Organization Capabilities

Lead

Contribute

Influence

None

If applicable, further define scope:

Capabilities:

II.B. Institution Capabilities

Lead

Contribute

Influence

None

If applicable, further define scope:

Capabilities:

III.A. Architecture & Management Practice Areas

Lead

Contribute

Enable

None

If applicable, further define scope:

Practice Areas:

III.B. EA Offerings

Potential offerings of an EA practice can include: services, products, training, facilitation, workshops, consultation, reference architectures, etc.

Offering:

Who is expected to utilize it? In what situations?

What’s out of scope? Where would you refer to?

Assessment Using the EAMM

As you apply the EAMM to your EA practice, refer back to these scoping worksheets to discuss:

• Scope Definition: How well defined is your scope? Do your stakeholders understand the scope you have identified for yourself?
• Discuss with regard to parts I, II, and III.
• Engagement: Who would you need to engage with to carry out the scope you have identified for yourself? How well engaged are they currently?
• In particular, discuss the Stakeholders you identified in Part I and the decision-makers for the areas you identified in Part II.
• Impact Assessment: In the areas of scope you have identified for yourself, how could you measure your impact? How well are you able to measure it now?
• In particular, discuss the capabilities you identified in Part II.
• Delivery: How well defined and easily repeatable is EA practice’s delivery of outcomes within the scope you have identified for yourself? How could you improve?
• In particular, discuss the practice areas and offerings you identified in part III.
• Management: How are you managing the EA practice to direct resources toward the areas of scope you have defined for yourself? How could you improve?
• Discuss with regard to parts I, II, and III.