Current vs. Target State: Where Should Enterprise Architecture Start?

Practical guide to choosing the right entry point for enterprise architecture—without getting stuck in analysis paralysis

In enterprise architecture (EA), both current-state and target-state content are essential. But when launching or scaling your EA efforts, which one should come first?

It’s tempting to dive straight into visionary future-state planning. After all, it’s more exciting than mapping legacy applications. But in practice, the best starting point depends on your organization’s maturity, stakeholder readiness, and specific needs.

Here’s a look at the case for each approach—and how to find the right balance.

The Case for Starting with the Target State

Some consulting firms suggest leading with the target state, and there’s a good reason: future visions are more engaging. A compelling target state helps engage stakeholders, align teams, and communicate strategic direction.

However, creating a meaningful future-state architecture isn’t something you can do in a vacuum. It requires executive buy-in, a clear strategy, and an understanding of business needs and tech trends. Executives don’t attend EA workshops just for fun—they expect discussions to be tied to real priorities, like strategic planning, transformation programs, or major investments.

That’s why target-state modeling should be closely tied to processes like annual strategy cycles or portfolio reviews. Without this connection, it often results in abstract diagrams that look good in presentations but fail to influence real decisions. And if your EA practice is still in its early stages, securing the necessary input can be especially challenging.

Why the Current State Is Often the Smarter First Step

For most organizations—especially those establishing or rebooting EA—starting with the current state is more practical. It might feel less visionary, but it provides immediate value: clarifying the existing landscape, uncovering risks and inefficiencies, and supporting decision-making in areas like solution architecture, roadmap planning, and portfolio management.

Even better, much of the current-state data already exists—in process maps, IT inventories, and application documentation. You don’t need to start from scratch, but to gather, validate, complete, and structure that information into something usable.

At the beginning, it’s important to model the entire organization at a high level. This gives you a broad understanding of how everything fits together and provides a foundation for future planning. But don’t try to model everything in detail right away. Focus on what’s changing. Over-documentation is one of the quickest ways to lose momentum—and your audience.

Don’t Think Sequential—Think Iterative

Although the current state is usually the best entry point, the process shouldn’t be linear. You’ll get the most value by iterating between the current and target states.

Refining the current state often reveals opportunities and constraints that shape your future plans. At the same time, outlining your target state may expose gaps in your current understanding. Let these two perspectives evolve together.

What Should the Target State Include?

You don’t need a full-blown future-state architecture to get started. The most valuable target-state descriptions often begin small and grow as needed.

There are two main ways to model the target state:

• A high-level future vision for the entire organization: This doesn’t need to be detailed. Even a rough outline helps clarify direction and support strategy discussions. Focus on strategic goals, key capabilities, major business processes, shared data, and planned IT platforms and high-level services.

• More detailed target states for specific capabilities, domains or initiatives: Examples include an application landscape for a CRM implementation, a future capability map for HR, or a new integration model to support digital services. These are easier to produce and more immediately useful when tied to ongoing projects.

Both approaches are valuable. The broader model sets the context, while the narrower models support execution. Start where there’s demand, and let both evolve over time.

Be Clear About What You’re Showing

One common pitfall is mixing up current- and target-state models. This leads to confusion—especially when reused across presentations or shared repositories.

Be explicit: label your diagrams clearly (“Target State 2028”), use prefixes like (to-be), and consider visual cues like color coding. These practices make your models easier to understand and maintain.

Final Thoughts: Build Both—but Start Smart

If you’re just getting started, begin with a practical, high-level overview of the current state. It’s easier to create, faster to validate, immediately useful, and shows you can get things done.

From there, incrementally build out the target state where there’s stakeholder interest or real planning need. Iterate between both views to keep them aligned and relevant.

Remember: you’re not documenting for documentation’s sake. Every model should serve a purpose and have a user. If no one needs it, you probably don’t need to make it.

Keep things lightweight, focused, and aligned with real-world needs—and you’ll turn architecture into a tool for action, not overhead.

📚 Want more hands-on, no-nonsense insights like this? Subscribe to Enterprise Architecture Transformation to get regular posts on making EA practical, impactful, and sustainable.