Enterprise Architecture Planning for Agile Delivery

Enterprise architecture planning connects business goals to decisions about your processes and systems. An architecture roadmap sets out the order of changes.

Agile teams often depend on the same systems as they work through short delivery cycles. A change to one service can affect work outside the team building it.

Your plan should show which decisions involve the wider business and which belong with the delivery team. The steps below explain how to connect those decisions to a roadmap and update it as teams learn.

What is enterprise architecture planning?

Enterprise architecture planning sets out how a business and its technology should change to meet a goal. It also establishes how to move from the current state to the target architecture: the intended future arrangement of processes and systems.

A business capability is something the organization needs to do, such as manage orders. Map that capability to its systems to identify where a change reaches beyond one team. The plan then addresses those effects alongside each team’s work.

The term also refers to the Enterprise Architecture Planning methodology associated with Steven Spewak. Spewak was an enterprise architecture practitioner and coauthor of the book Enterprise Architecture Planning.

His method starts with business information needs before defining applications and technology. Broader uses of the term cover planning approaches beyond Spewak’s formal method.

An enterprise architecture roadmap shows the sequence of changes toward the target state. The supporting plan explains what each change depends on. Delivery leads use that information to decide when their teams can start work.

This matters when several teams depend on the same system. An enterprise resource planning (ERP) system supports core work through ERP modules, the components for functions such as finance and purchasing. Replacing it requires decisions about the connected systems as well as the ERP itself. The plan should explain how data will move and how the business will keep running during the change.

Key enterprise architecture planning deliverables

A practical set of enterprise architecture planning deliverables includes capability and current-state views, a target-state view, a gap and dependency register, architecture decision records, and a roadmap with a delivery plan.

Here’s what each deliverable helps you decide and who keeps it up to date.

The capability and current-state view links business capabilities to the systems that support them. Include facts that affect the decision, such as who owns an application or when its support ends. The initial view should focus on the work at hand so discovery does not become an attempt to map everything at once.

The target-state view shows the changes to systems and the links between them. It sets the direction while leaving teams room to develop designs that do not affect requirements for other teams.

The gap and dependency register records the work between those states. A dependency is work or information that another task relies on before it can proceed. Recording who provides it helps a delivery lead resolve delays before they spread.

An architecture decision record (ADR) explains a major choice and why the team made it. Include the options set aside and the assumptions behind the choice. Future teams can use that context to assess whether the original reasoning still holds.

The roadmap puts changes in order, while the delivery plan adds resources and commitments. If a design assumption changes, explain its effects to the people scheduling dependent work to help them adjust their plans.

Enterprise Architecture Frameworks for Agile Planning

Enterprise architecture frameworks help teams organize business and system information to support planning decisions. Each approach serves a different purpose:

• The Open Group Architecture Framework (TOGAF) includes an Architecture Development Method (ADM) for developing and managing architecture. Adapt the level of detail to the decision at hand.
• The Zachman Framework organizes enterprise descriptions by perspective and question, helping teams identify information gaps. It does not prescribe an implementation sequence.
• The Federal Enterprise Architecture Framework (FEAF) guides architecture work in the US federal government. Assess its fit with your organization’s requirements before adopting it.
• ArchiMate is a modeling language for showing enterprise components and their relationships. It complements a planning method by making those relationships easier to understand.

For agile delivery, connect each framework output or model to a specific decision, then use that decision to guide the roadmap and delivery work.

How to build an enterprise architecture plan in 7 steps

These seven steps will help you turn business goals into an enterprise architecture plan your teams can put into practice and update as they learn.

Step 1: Set business goals and planning boundaries

The business goal determines which architecture questions to address. Start with the problem you are trying to solve, then identify the systems and operations involved.

Your plan should explain how the business will measure progress and who owns that measure. State what the initiative includes and what remains outside it. Replacing an application is a different commitment from redesigning the business process it supports.

The sponsor should have authority to resolve competing priorities as the work changes. Establish how teams will raise disagreements they cannot settle themselves.

Step 2: Map current systems and dependencies

The current-state view should reflect how systems work today. Trace the business activity through its supporting systems and the data they exchange. An interface is the connection through which systems interact. Compare its documented behavior with what teams find in practice.

Early investigation should focus on dependencies that could change the design or delivery order. A service used by several teams deserves attention if another team controls its release schedule. A system close to the end of support creates a different timing constraint.

Keep uncertain information visible. When an old document is the only evidence that a connection works, assign someone to test it before another team commits to using it.

Step 3: Design the target architecture

The target architecture explains how the business will work after the change. Describe the capabilities that support the business goal, then identify which systems will provide them.

Requirements for service availability or access to sensitive data affect which designs are viable. Set those requirements with the people responsible for business operations and risk.

Business ownership should stay clear when several applications hold copies of a record. Identify who maintains that record and resolves conflicts between the copies.

Local designs should stay open to testing when they do not affect requirements beyond the team or material risks. Delivery teams can explore those choices as they build, without seeking enterprise approval for each one.

Step 4: Identify architecture gaps and record decisions

Each architecture gap should lead to work someone can take on. A comparison of the current and target states shows what must change to move between them.

Record the options for a major choice and the conditions that favor each one. If the preferred design depends on an untested assumption, explain what evidence would support or overturn it. The team then knows what to investigate before committing further effort.

A work package groups the resulting tasks around a clear outcome. A broad instruction to improve integration leaves too much unresolved. Specify the interface to change and the behavior the receiving system requires.

Step 5: Prioritize work and build the architecture roadmap

Business value sets priorities, but dependencies affect when work can start. A high-value change still has to wait when it relies on work that another team has not completed.

Weigh a change’s expected business impact against the effort to deliver it. The risk of disrupting essential operations also affects that choice. Explain the assumptions behind each estimate so an early guess does not look as firm as work the team has already assessed.

The delivery sequence should fit those dependencies and the teams’ capacity. Keep later commitments less detailed while major questions remain open. For upgrades to information technology (IT) systems, an IT modernization roadmap should show which team provides each dependency and when dependent teams will use it.

Step 6: Assign delivery responsibilities and release criteria

Identify who can accept the change’s effects on the business. A delivery role does not automatically grant authority to accept extra operating costs or disruption to another department.

The deployment strategies you choose set out how a software change will be introduced. Release criteria specify the evidence teams must provide before moving users or workloads to the new system.

Data migration moves records from one system to another. Reconciliation compares the source and destination records to find missing data or mismatches. The business owner needs to understand those results before authorizing the move.

The transition plan should also cover work left on the old system. Remaining workloads or contract terms affect when you can retire it. If that extends hosting costs, connect the cost estimate to the person who can authorize the extra spending.

Step 7: Update the plan with delivery feedback

Revise the plan when new evidence changes a decision. A test that rules out a technical option should change the affected work packages before teams continue on the old assumption.

Delivery teams should report which assumption a finding changes and identify the work that depends on it. When that evidence leads to a new decision, update the roadmap so affected teams can adjust their plans.

Enterprise architecture governance for agile teams

Enterprise architecture governance sets out who decides and when changes go through wider review. Clear responsibilities let teams handle routine design work while system owners address decisions that affect several teams.

In SAP LeanIX’s EA Insights 2025 survey of its international customer base, 51% of the 269 respondents to the decision-time question said an architecture decision took a month or longer.

For agile teams, a decision that takes a month can affect several delivery cycles. If teams start work that depends on that decision, they risk having to redo it once the outcome is clear. Raise these decisions before teams commit to the work they affect.

Decisions that affect several teams or are hard to undo deserve more review time. Schedule those reviews before related work starts. Routine design choices can stay with delivery teams when they meet the requirements of the wider business.

Here’s how to clarify who decides what and handle architecture questions before they hold up delivery.

Set enterprise and team decision responsibilities

A change’s effects determine who takes part in the decision. An internal code choice stays local when it preserves the behavior other teams rely on. Changing how products identify the same customer calls for input from the people who own and use those records.

Use a table to show who decides what in your agile development process.

Business input establishes who maintains records used by several teams and settles conflicts between copies. Architecture work connects that responsibility to the systems using the information.

Changes to an interface involve both the team providing it and the teams using it. Before changing it, establish whether systems using that interface will still work, including those that will not update at the same time.

Internal implementation includes choices such as how a team organizes code within its service. Keep those choices with the team while they meet requirements that apply across teams. A change to those requirements, or a risk beyond the team’s authority, calls for wider review.

An architecture exception records permission to depart from a requirement. The person who owns that requirement does not always have authority to accept every related risk. Record who authorized the exception and when to revisit the decision.

Use architecture spikes to test technical options

An architecture spike is a short investigation of a technical question before a team commits to a design. Set the question and decide what evidence will guide the next action.

An interface test should establish whether the connection meets the receiving team’s needs. A successful connection alone does not show that the system handles failures or the required workload.

An architecture owner helps the team use that evidence in its design decisions. It is a responsibility that an existing team member can hold. The role connects the team’s work to wider requirements while allowing the design to evolve.

Keep architecture records current and escalate exceptions

Architecture records should stay linked to the work that changes them. If new evidence changes a recorded decision, create a new ADR and mark the earlier one as superseded. The original reasoning should remain available so future teams can trace the change.

Changes that affect interfaces used by other teams or access to sensitive data call for escalation. Review decisions that are hard to reverse before the team commits. The authority required depends on the effects on the business and its obligations.

An escalation request should identify the affected requirement and explain the consequence of departing from it.

The review forum should match the authority the decision requires. An existing planning discussion works when it includes the responsible people before dependent work starts. If that group lacks authority for a decision, arrange a separate review.

If your plan calls for new software, our custom software development service covers design, build, and testing. We record design choices and build in small steps, so your team can test the work as it takes shape.

Put your enterprise architecture plan into practice

Enterprise architecture planning helps your teams coordinate changes to systems. The roadmap should connect business priorities to delivery work and reflect what teams learn from testing their designs.

Start with the decision holding up a system change that affects several teams. Its owners should have the evidence to resolve it before dependent work begins. Once they decide, update the roadmap.