Partner Program

Maximize market potential through a partner program offering LeanIX solutions tailored to your business model.

Learn more
EA Process

Enterprise Architecture Deliverables

Enterprise architecture deliverables are the tangible outputs and strategic outcomes an EA team produces to help the organization understand the current state, define the future state, guide change, and support decisions.

► Learn four steps that will generate ongoing business value, fast.

Download an EA road map
EN-LP-1P-road-map-to-successful-ea-780x555

Once an organization establishes an enterprise architecture practice, the next question is practical: what should the team actually deliver?

This page explains the main types of enterprise architecture deliverables, how they support different stakeholders, and how a new EA team can prioritize them.

 

What are enterprise architecture deliverables?

Enterprise architecture deliverables are the outputs an EA team creates and maintains to help the organization understand its current state, design its future state, govern change, and support decisions.

These outputs can include maps, inventories, standards, principles, assessments, roadmaps, and other materials used by business and IT stakeholders.

In practice, a deliverable is something the architecture team produces for the organization to use, such as an application inventory, a target architecture, a set of standards, or an impact analysis for a planned transformation.

EA Deliverables vs. artifacts vs. repository vs. documentation

These terms overlap, but they are not the same.

  • EA deliverables — the broader outputs the EA team is expected to produce, such as a roadmap, target architecture, standards model, or capability map

  • An EA repository is the managed place where architecture content is stored, connected, and maintained. In practice, many organizations manage that repository in an EA tool.

  • EA artifacts are the specific work products inside that environment, such as diagrams, matrices, catalogs, heatmaps, and assessment views.

  • EA documentation is the broader written record that explains standards, decisions, context, and architecture knowledge.

This distinction matters because many teams use these terms interchangeably, even though they describe different parts of the architecture practice.

Why this matters after establishing an EA process?

After an EA team is formed, stakeholders usually expect more than a charter or an operating model. They want to see what the function actually produces and how those outputs help the organization move forward.

Clear deliverables make enterprise architecture easier to understand, easier to govern, and easier to apply in real decisions.

Guide

An agile framework to implement TOGAF with LeanIX' enterprise architecture tool

A step-by-step illustration of how to follow TOGAF’s principles with a lean EA tool.

Get your free copy
An agile framework to implement TOGAF with LeanIX' enterprise architecture tool

Main types of EA deliverables

What an EA team delivers depends on the organization’s goals, maturity, and scope. Still, most teams are expected to produce a similar set of outputs over time.

These usually fall into four groups: current-state deliverables, future-state deliverables, governance deliverables, and analysis and planning deliverables.

Current-state deliverables

These outputs help the organization understand how the business and IT landscape looks today. They create the baseline for governance, planning, and change.

Common examples include:

  • IT landscape — a view of the main applications, technologies, and connections across the enterprise

  • Application inventory — a structured list of applications, often including ownership, lifecycle, business fit, technical fit, criticality, and vendor information

  • Business capability map — a view of what the business does and which capabilities matter most

  • Technology inventory — a record of platforms, components, vendors, or standards in use

  • Current-state architecture views — diagrams or models that explain how key parts of the organization work today

  • Lifecycle views — outputs that show which applications or technologies are active, planned, phased out, or obsolete

Without this baseline, it becomes much harder to assess duplication, risk, technical debt, or change impact.

Future-state deliverables

These outputs describe where the organization wants to go and what the target should look like. They help turn enterprise architecture into a forward-looking discipline, not only a documentation practice.

Common examples include:

  • Target architecture — a future-state view of business, application, data, or technology architecture

  • IT roadmaps — transition plans that show how the organization moves from the current state to the target state

  • Architecture principles — decision rules that shape future design choices

  • Standards and reference architectures — agreed patterns that guide solution and technology decisions

  • Transformation views — architecture outputs tied to major initiatives such as cloud migration, ERP change, or AI adoption

These help teams move from understanding the landscape to shaping it.

Governance deliverables

Enterprise architecture is also expected to support consistency and control. Governance deliverables help organizations make architecture decisions in a more structured way.

Common examples include:

  • Architecture standards — approved technology, integration, data, security, or design rules

  • Principles and policies — guardrails for architecture decisions

  • Decision records — documented architecture decisions and their rationale

  • Review materials — inputs used in architecture reviews or governance boards

  • Exception tracking — records of where the organization has approved deviations from standards

  • Repository guidance — rules for how architecture content should be maintained and governed over time

These outputs help make governance visible and repeatable instead of depending on informal decisions.

Analysis and planning deliverables

Enterprise architecture is also expected to help assess options, risks, costs, and dependencies.

Common examples include:

  • Impact analysis — a view of what may be affected by a planned change

  • Maturity assessments — an evaluation of architecture capabilities, practices, or domains

  • Heatmaps — visual views of risk, fit, criticality, cost, or complexity

  • TCO views — cost transparency outputs that show application or technology costs and help identify rationalization opportunities

  • TIME or disposition views — classification outputs that help teams decide whether an application should be tolerated, invested in, migrated, or eliminated

  • Technology risk assessments — analysis of lifecycle risk, vendor dependency, or obsolescence

  • AI readiness assessments — an evaluation of whether the organization, processes, data, and technology are ready for AI-related change

These outputs are especially useful when leaders need to compare priorities, sequence initiatives, or understand trade-offs across the landscape.

To keep them consistent over time, many organizations define the underlying object types and relationships through an enterprise architecture meta model.

Tangible deliverables vs. intangible outcomes

Enterprise architecture is expected to create both visible outputs and less visible organizational value.

Some deliverables are concrete and easy to point to. Others matter because they improve how the organization makes decisions, governs change, and works across business and IT.

Tangible deliverables

Tangible deliverables are the outputs people can review, maintain, and use directly in planning or governance. These are often the first things stakeholders expect from an EA team because they make the practice visible.

Common examples include an IT landscape, application inventory, business capability map, target architecture, IT roadmap, impact analysis, maturity assessment, architecture standards, technology lifecycle views, TCO views, and decision records.

These outputs help answer practical questions.

  • Which applications support a critical capability?

  • Which technologies are nearing end of life?

  • Which systems cost the most to maintain?

  • Which changes are already planned?

Tangible deliverables give teams a shared reference point for those discussions.

Intangible outcomes

Intangible outcomes are harder to point to, but they are just as important. They reflect the value EA creates through better structure, alignment, and decision support.

Common examples include:

  • a shared language across business and IT

  • clearer ownership and accountability

  • stronger enterprise architecture governance

  • better prioritization of change

  • more consistent use of architecture principles and technology standards

  • stronger alignment between business goals and technology planning

  • better visibility for enterprise architecture stakeholders

These outcomes usually appear when deliverables are used consistently over time. A roadmap, capability map, or repository may be the visible output, but the deeper value often shows up as better conversations, fewer disconnected decisions, and a clearer path through complex change.

Why do both matter?

A strong EA practice needs both. If the team only creates tangible outputs, architecture can become a documentation exercise. If it only promises strategic influence, stakeholders may struggle to see what the function actually produces.

The goal is to make the two work together. Tangible deliverables give structure to the practice. Intangible outcomes show whether those outputs are helping the organization make better decisions.

 

How do deliverables support enterprise architecture stakeholders?

All these deliverables only become useful when the right people can use them. Different stakeholder groups need different views of the landscape, different levels of detail, and different types of outputs.

1. Leadership and transformation stakeholders

Leaders usually need outputs that help them make directional decisions, prioritize change, and understand trade-offs across the enterprise.

This often includes a target architecture, IT roadmap, capability-based views, cost views, lifecycle views, and high-level impact analysis. These outputs help answer questions such as where to invest, what to modernize first, and which dependencies could slow down a transformation.

2. Business stakeholders

Business stakeholders need deliverables that connect technology to business goals, capabilities, products, and operating needs.

That is where outputs such as a business capability map, business architecture views, business objectives, and selected current-state or future-state views become useful. These deliverables help explain how technology supports the business, where gaps or duplication exist, and which changes matter most to business performance.

3. IT stakeholders

IT stakeholders usually need more operational and dependency-focused deliverables. These outputs help them understand what exists, how it connects, and what needs to change.

Common examples include an IT landscape, application inventory, technology standards, lifecycle views, EA artifacts, and more detailed impact analysis. For engineering, solution, and platform teams, the most useful deliverables often show dependencies between applications, interfaces, technologies, and ownership.

4. Governance, risk, and compliance stakeholders

Governance, risk, and compliance stakeholders need outputs that support control, consistency, and traceability.

This includes enterprise architecture governance materials, architecture principles, standards views, exception records, technology lifecycle views, obsolescence views, and risk-focused assessments. In organizations working on data, security, or AI-related change, these stakeholders may also need AI readiness views and architecture decision records that explain why a certain direction was chosen.

A strong EA practice does not create one generic output for everyone. It produces a connected set of deliverables and metrics that can be adapted for different enterprise architecture stakeholders while staying grounded in the same underlying repository and architecture structure.

 

How to prioritize deliverables in a new EA team?

A new EA team does not need to produce everything at once. The better approach is to start with the deliverables that answer the most urgent stakeholder questions and create a usable baseline for future work.

1. Start with stakeholder questions

The first step is to understand what different stakeholders need to know. Leaders may want to see where to invest, what to modernize, or which risks are growing. IT teams may need visibility into the application landscape, technology standards, or end-of-life dependencies. Governance teams may need clearer principles, exception tracking, or impact views.

A good starting set of questions is often:

    • Which applications do we have today?

    • Which business capabilities do they support?

    • Which technologies create the most risk or cost?

    • What major changes are already planned?

    • Which decisions need better architecture input?

The answers to those questions usually point to the first deliverables worth building.

2. Build a minimum useful set

Most new EA teams get more traction by creating a small set of connected deliverables than by trying to produce every possible output in the first phase.

A practical starting set often includes an application inventory, an IT landscape, a business capability map, a first target architecture for a priority area, and a simple IT roadmap. In some organizations, it also makes sense to add technology standards, a basic impact analysis, or lifecycle views if modernization risk is already high.

The goal is not completeness. The goal is to create a small number of outputs that people will actually use in planning, governance, and transformation work.

3. Expand based on maturity and business need

Once the first deliverables are being used, the EA team can expand based on real demand. That may include adding maturity assessment views, technology TCO analysis, Gartner TIME model classifications, AI readiness assessments, or stronger governance outputs such as decision records and exception tracking.

This is also the point where an enterprise architecture repository becomes more important, because the team needs a managed way to keep deliverables connected and current.

A simple rule works well for new teams: start with the deliverables that answer today’s questions, then expand only when new outputs support a real governance, planning, or transformation need.

As the practice grows, teams usually need a managed way to keep deliverables connected and current. That often means maintaining them in an enterprise architecture repository and structuring them consistently through an enterprise architecture meta model.

EN-LP-1P-road-map-to-successful-ea-780x555

Free Poster

6 Steps for Achieving Quick and Sustainable Value with EA.

Download
Free Poster

Enterprise Architecture Roadmap

Learn 6 steps of Enterprise Architecture that will generate ongoing business value, fast.

Get your free Copy
EN-LP-1P-road-map-to-successful-ea-780x555
check icon

Establish an enterprise architecture practice

check icon

Maintain an enterprise architecture practice

check icon

Generate ongoing business value of EA, fast

FAQs

Are enterprise architecture deliverables supposed to be documents?

Not always. Some deliverables are documents, diagrams, catalogs, or roadmaps. Others are working views, decision records, standards, assessment outputs, or repository-backed datasets. A useful rule is that a deliverable should help someone make, guide, or govern a decision, not just sit in a folder.
Usually fewer than people expect. A new EA team does not need a long list of outputs on day one. It needs a small set that answers urgent stakeholder questions and can be maintained over time.
Yes. Enterprise architecture usually works at a broader planning and governance level, while solution architecture goes deeper into the design of a specific change or solution. In practice, EA deliverables are more likely to include capability views, roadmaps, standards, portfolio analysis, and governance inputs, while solution architecture usually produces more detailed solution designs and implementation-facing documentation.
No. In most organizations, a useful deliverable beats a perfect one that arrives too late. Early versions are often enough to support discussion, expose gaps, and improve the next round of planning. The more important question is whether the output is clear, current enough, and trusted enough to support a decision.
Usually, it is better understood as the managed environment where deliverables, artifacts, and related architecture content are stored and maintained. Some explanations describe deliverables as outputs of architecture work, while the repository acts as the place where those outputs are cataloged, organized, and reused. In practice, teams often talk about the repository as part of the overall deliverable set because it supports the whole architecture function.
Because volume is not the same as usefulness. A team can produce many diagrams, matrices, or documents and still fail to support the decisions stakeholders care about. The most effective deliverables are tied to real questions such as where to invest, what to retire, what creates risk, or how to govern change. Outputs matter when they change understanding or decisions, not when they simply increase documentation.
Request a Demo

Gain Value out of Your EA Program Now!

Request Demo