Glossary

Enterprise architecture glossary

Enterprise architecture has its own vocabulary, and the same words are not always used the same way. This glossary defines the core terms in plain, neutral language — from capability maps and application portfolio management to TOGAF, ArchiMate, governance and the EU regulations that shape architecture work. Where a term comes from a specific framework, we name its owner.

Fundamentals

Enterprise architecture (EA)

A discipline that describes how an organisation's business capabilities, processes, applications, data and technology fit together, and uses that view to guide change and align IT with strategy.

Business architecture

The part of enterprise architecture that models the business itself — its capabilities, value streams, organisation and information — independently of the applications and technology that support it.

Business capability

A stable description of what a business is able to do, independent of how it is done, by whom or with which tools. Capabilities provide a vocabulary that stays steady while processes and applications change.

Capability map

A structured, usually hierarchical view of an organisation's business capabilities. It is often used as a backbone to relate strategy, applications, data and investment to what the business actually does.

Value stream

An end-to-end sequence of activities that delivers value to a customer or stakeholder. In business architecture, value streams are often mapped against the capabilities that enable each stage.

Target architecture

The intended future state of the architecture that an organisation aims to reach. It is usually compared with the current state to identify gaps and plan a transition.

Architecture roadmap

A time-phased plan that sequences the changes needed to move from the current architecture to the target architecture, linking initiatives to capabilities, applications and dependencies.

Information system urbanisation

A mainly French-speaking approach to structuring the information system by analogy with city planning, organising it into coherent zones and blocks so it can evolve in a controlled way.

Solution architecture

The design of a specific solution to a defined problem, describing how applications, data, integrations and technology work together to meet a particular set of requirements. It sits between enterprise architecture and detailed system design.

Technical architecture

The domain of architecture that describes the technology foundation — infrastructure, platforms, networks, middleware and runtime environments — on which applications run. In TOGAF it corresponds to the technology architecture domain.

Security architecture

The discipline that structures security controls, principles and patterns across the architecture so that confidentiality, integrity and availability are addressed by design rather than added afterwards.

Operating model

A high-level description of how an organisation delivers value — how its processes, people, structure and technology are arranged to run the business day to day. It connects strategy to the way work is actually organised.

Baseline architecture

The description of the architecture as it exists today, used as the starting point against which a target architecture and the gaps between them are assessed. Also called the current or as-is architecture.

Transition architecture

An intermediate, deliverable state of the architecture between the baseline and the target. Transition architectures break a large change into manageable, value-bearing steps along the roadmap.

Gap analysis

The comparison of a baseline architecture with a target architecture to identify what is missing, redundant or to be changed. The resulting gaps drive the work packages and roadmap.

Frameworks & methods

TOGAF

An enterprise architecture framework published by The Open Group. It provides a method and a set of structures for developing and governing architecture across business, data, application and technology domains.

ADM (Architecture Development Method)

The iterative method at the core of TOGAF (The Open Group). It describes phases for moving from architecture vision through business, information-systems and technology architectures to implementation and governance.

Zachman Framework

An ontology for classifying architecture artefacts, attributed to John Zachman (Zachman International). It is a schema — a grid of perspectives and questions — rather than a method or process.

ArchiMate

A modeling language for enterprise architecture maintained by The Open Group. It offers a standard notation and layered structure (business, application, technology) for describing and relating architecture elements.

BIAN

A reference framework for banking architecture from BIAN e.V., describing the banking landscape as a set of standardised service domains to ease integration and shared understanding between banks and vendors.

FEAF

The Federal Enterprise Architecture Framework, originating from the United States federal government, which organises architecture through a set of reference models to support coordination across agencies.

Reference architecture

A reusable, vetted architecture template for a recurring problem or domain. It provides a common starting point and shared patterns so individual designs do not have to be created from scratch.

Capability-based planning

A planning approach that uses business capabilities as the unit of analysis, prioritising investment and change against the capabilities an organisation needs rather than against individual projects or technologies.

Total cost of ownership (TCO)

An estimate of the full cost of an application or system over its life, including acquisition, licensing, hosting, support, maintenance and eventual retirement — not just the initial purchase price. It informs portfolio and investment decisions.

Cloud migration

The process of moving applications, data and workloads from on-premises or legacy environments to cloud infrastructure or services. Common strategies range from lift-and-shift rehosting to re-platforming and full refactoring.

Legacy modernization

The work of updating, replacing or re-architecting older systems that have become costly, risky or hard to change, so they better fit current business needs and technology standards while limiting disruption.

Modeling & notation

Metamodel

The model that defines the types of elements and relationships an architecture repository can contain. It sets the rules and vocabulary that keep architecture data consistent and queryable.

Dependency

A relationship in which one element relies on another — for example an application depending on a database, a service or another application. Mapping dependencies is key to assessing impact and resilience.

Viewpoint

A specification of the conventions for constructing and interpreting a view, framing how a particular set of stakeholder concerns is addressed. The terms viewpoint and view are defined in the ISO/IEC/IEEE 42010 architecture-description standard.

View

A representation of an architecture from the perspective of a specific viewpoint, addressing one or more stakeholder concerns. In ISO/IEC/IEEE 42010, a view conforms to its governing viewpoint.

Concern

An interest of a stakeholder in the architecture — such as performance, cost, security or maintainability — that the architecture description should address. Concerns are a core notion in ISO/IEC/IEEE 42010.

Stakeholder

An individual, group or organisation with an interest in, or affected by, the architecture or the system it describes. Identifying stakeholders and their concerns is a starting point for choosing appropriate viewpoints and views.

Architecture decision record (ADR)

A short, dated document that captures a single architecture decision together with its context, the options considered and the consequences. ADRs build a lightweight, traceable history of why the architecture is the way it is.

Microservices

An architectural style in which an application is built as a set of small, independently deployable services, each owning a focused capability and communicating over well-defined interfaces, in contrast to a single monolithic application.

Event-driven architecture

An architectural style in which components communicate by producing and reacting to events rather than calling each other directly. It favours loose coupling and asynchronous processing, often using message brokers or event streams.

API and integration

An API (application programming interface) is a defined contract through which software components exchange data and services; integration is the broader practice of connecting applications so they work together. Both are central to how the application landscape is wired.

Application portfolio

Application portfolio

The full set of software applications an organisation uses, considered as a managed whole. Viewing applications as a portfolio supports decisions about cost, risk, overlap and investment.

APM (Application Portfolio Management)

The practice of inventorying, assessing and steering the application portfolio over time, weighing business value, cost, risk and technical fit to guide investment, modernisation and retirement decisions.

Application mapping

The activity of relating applications to the capabilities, processes, data and infrastructure they touch, producing a visual picture of how the application landscape supports the business.

Application rationalization

The process of reducing complexity and cost in the application portfolio by identifying redundant, low-value or high-risk applications and deciding which to keep, consolidate, replace or retire.

TIME model

A portfolio classification that sorts applications into Tolerate, Invest, Migrate or Eliminate, popularised by Gartner. It helps turn an assessment of business value and technical condition into clear action.

Technical debt

The accumulated cost of design or technology choices that made delivery faster in the short term but make future change harder, slower or riskier until they are addressed.

Decommissioning

The planned, controlled retirement of an application or system, including handling its data, interfaces and dependencies so that removing it does not disrupt the rest of the landscape.

Governance

Architecture governance

The set of roles, decisions, principles and controls that keep architecture work aligned with strategy and standards, defining who can decide and change what across the architecture.

ARB (Architecture Review Board)

A body that reviews and approves architecture decisions and exceptions against agreed principles and standards, providing a consistent point of control for significant changes.

Architecture principles

Durable, agreed statements that guide architecture decisions, expressing what the organisation values and constrains so that individual choices remain coherent over time.

Audit trail

A chronological record of changes and decisions that makes it possible to see who changed what, when and why. In architecture tooling it supports accountability and evidence for reviews.

Service catalog

A curated, published list of the IT or business services available to users, with details such as what each service does, who owns it and how it is requested. It gives a shared, demand-facing view of what the organisation offers.

Regulation & compliance

DORA

The Digital Operational Resilience Act, an EU regulation aimed at strengthening the operational resilience of the financial sector, including expectations around managing and documenting ICT risk and third-party dependencies. It is regulation, not architecture; a tool can help document and evidence, but does not by itself ensure compliance.

NIS2

An EU directive that broadens and strengthens cybersecurity requirements across essential and important entities in many sectors. Like DORA, it is a legal obligation; architecture tooling can support documentation and traceability but does not replace legal compliance.

Data & repository

Data architecture

The part of enterprise architecture that describes an organisation's data — its main entities, models, flows and ownership — and how data is structured, stored and shared to support the business.

Application register

A maintained inventory of the applications in use, with key attributes such as owner, purpose, criticality and dependencies. It is a foundation for portfolio management and for regulatory documentation.

Architecture repository

The single, structured store of an organisation's architecture content — capabilities, applications, data, dependencies and decisions — that keeps the information connected, current and shareable.

CMDB (Configuration Management Database)

A repository that records the IT assets and configuration items in an environment along with their attributes and relationships. Associated with IT service management practices such as ITIL, it supports impact analysis and change control.

Configuration item (CI)

Any component that needs to be managed in order to deliver a service — such as a server, application, network device or document. Configuration items and their relationships are typically tracked in a CMDB.

Business process

A structured set of activities that, together, produce a specific business outcome. Business processes describe how work flows across roles and systems and are often modelled to analyse, improve or automate them.

Data governance

The framework of roles, policies and processes that defines how data is owned, classified, secured and kept fit for use. It establishes accountability for data quality, definitions and access across the organisation.

Master data

The core, shared business entities used consistently across systems — such as customers, products, suppliers or accounts. Master data management aims to keep a single, trusted version of these entities to avoid conflicting records.

Interoperability

The ability of different systems or organisations to exchange information and use it meaningfully. It usually relies on shared standards, formats and semantics so that data keeps its meaning as it crosses boundaries.

Put the vocabulary to work

Capability maps, an application register, governance and a clear roadmap are not just definitions — they are what Archilu helps you build and keep current. See where you stand today, or book a working demo.

Definitions are provided for general understanding and are paraphrased in our own words. Framework names such as TOGAF and ArchiMate (The Open Group), the Zachman Framework (Zachman International) and BIAN (BIAN e.V.) are the trademarks or property of their respective owners. Archilu is an enterprise architecture tool, not legal or regulatory advice.