From Context to Vision: Defining What Enterprise Architecture Should Achieve

Practical guide to setting the direction for your enterprise architecture function

Sep 22, 2025

In an earlier article, I wrote about how deep enterprise architects should go—and it sparked a lot of discussion.

One of the best points raised was this: the real answer depends on the objectives set for enterprise architecture (EA) in your organization.

And that’s exactly right. But defining those objectives is not as simple as it sounds. EA can easily drift into doing “a bit of everything,” but never making a real impact.

To avoid that, you need a clear purpose, set in the right order: first the organizational context, then goals and expectations, then the vision and development path.

In this article, I’ll walk through how to do just that.

1. Start with the Organizational Context

Everything begins with understanding where the organization and the EA function stand today:

Strategic and operational challenges: What pressures or changes is the organization facing—digital transformation, regulatory compliance, cost reduction?
Leadership priorities: What has management already emphasized? Has EA been given any explicit goals or is it still undefined?
EA maturity: Assess the current state of the EA function. Are there named architects? Deliverables being used? How well is EA integrated into governance? A simple maturity assessment can provide a clear baseline.

This step provides the grounding. Without it, any vision or target risks being disconnected from reality.

2. Identify Use Contexts and Clarify Goals

Once you understand the organizational context, the next step is to define where EA content and support will actually be applied—and what outcomes are expected. These two go hand in hand: use contexts point to goals, and goals help sharpen the value of those contexts.

Typical use contexts include:

Strategic planning
New development initiatives
IT portfolio and lifecycle management
Risk and compliance management

Equally important is defining what’s not in scope—for example, in some organizations EA is limited to IT only. Clear boundaries keep the focus sharp.

Start where there’s demand. If leaders are struggling with portfolio decisions, begin there. If new initiatives feel chaotic, focus on supporting them. Meeting an existing need is the fastest way to build credibility for EA.

Common EA goals include:

Better alignment between strategy and execution
More fact-based and visual decision-making
Reduced IT costs and complexity
Fewer fragmented or redundant initiatives

If expectations are vague or even unrealistic, that’s fine—document them anyway. Having a starting point makes it easier to refine over time. And if possible, link goals to indicators: fewer duplicate systems, faster project startups, better use of EA descriptions, or simply the number of initiatives actively supported by EA.

3. Craft the Vision

With the context, use cases, and goals clear, it’s time to look ahead and describe the future state of EA in your organization. A strong vision answers not only what EA will be, but also why it matters and who it serves.

Questions to guide the vision:

What should the EA function look like in 3–5 years?
Who will use EA and in what situations?
What value will it bring to leaders, delivery teams, and operations?
How will EA be perceived: a bureaucratic overhead or a trusted partner in change?

The vision should be inspiring yet concrete: show how EA supports large organizational goals (like transformation or efficiency), and describe how it will be embedded in daily practices (e.g., initiatives starting with EA input, portfolio decisions guided with EA insights).

4. Define Development Goals

Finally, translate the broader goals into concrete near-term development steps (1–2 years) for the EA function itself. These are not organization-wide outcomes, but the deliverables, capabilities and structures the EA function needs in order to contribute effectively.

Typical examples include:

Establish EA roles and clarify responsibilities
Set up a recurring EA working group
Deliver a baseline capability model and application map
Integrate EA checkpoints into project initiation and portfolio planning
Acquire and roll out an EA tool fit for purpose

Short timelines keep goals realistic and measurable. Longer-term aspirations (like becoming a strategic advisor or influencing culture) belong in the vision; the development plan is about building the foundations that make that vision possible.

Final Thoughts

Defining EA objectives is not about filling out a template—it’s about building a roadmap in the right order, where every step builds on the previous one:

Context and current state
Use contexts, goals and benefits
Vision
Development goals

The sequence matters. Jumping straight to vision without understanding context risks creating something disconnected from reality. Setting development goals before clarifying use contexts often leads to investing effort in areas no one values.

When you follow this flow, EA has a real chance of becoming credible and purposeful. It also becomes easier for leadership to understand what EA is for, and for architects themselves to prioritize limited time and resources.

Done this way, EA turns from “architecture for architecture’s sake” into a management tool that helps the organization steer change with clarity and confidence.