Enterprise architects are often challenged by the many enterprise architecture terms with conflicting interpretations. This dilemma calls for a glossary that provides concise, consistent definitions of relevant terms.
Here you'll find all the enterprise architecture terms that are used on a regular basis along with their definitions. If you want to go deeper into a particular concept, each entry includes a link to a lesson where you can learn more.
Agile: An iterative approach to planning and guiding project processes. Learn the difference between Agile, Kanban and Scrum here.
Application Architecture: A description of the structure and interaction of the applications as groups of capabilities that provide key business functions and manage the data assets.
Application Portfolio Management: The discipline applied to managing software assets to justify and measure the financial benefits of each application in comparison to the costs of the application's maintenance and operations. Learn more in our definitive guide to application portfolio management!
Application Rationalization: Application rationalization is the practice of strategically identifying business applications across an organization to determine which applications should be kept, replaced, retired or consolidated. The goal is to achieve improvements in business operations. Learn more with our 9 rules and guidelines for application rationalization.
Architectural Risk: Independently tracked risk or issue observable in the architecture. Typically captured by an Enterprise Architect. This entity may contain links to documentation of the risk, escalations, exceptions, status, events, and quantifiable measures. Learn more in our blog four steps to successful risk management.
Architecture: The structure of components, their inter-relationships, and the principles and guidelines governing their design and evolution over time.
Architecture Framework: A conceptual structure used to develop, implement, and sustain an architecture. View our lean framework for EA!
Architecture Principle: A qualitative statement of intent that should be met by the architecture. Has at least a supporting rationale and a measure of importance.
Assessment Metric: When a capability is defined in an organization, there are expectations of the level of performance or maturity required in order for the business to be successful in their mission. An assessment metric defines a way in which a set of capabilities will be measured. The measurement process must be consistent and, in the best case, should reference widely accepted business measurement practices. Learn here how to perform a technology risk assessment.
Business Architecture: A description of the structure and interaction between the business strategy, organization, functions, business processes, and information needs.
Business Architecture Framework: A conceptual view of how business blueprints, business scenarios, and business architecture knowledge base interrelate to provide a foundation for establishing the business architecture.
Business Capability: The expression or the articulation of the capacity, materials and expertise an organization needs in order to perform core functions. Learn more in our definitive guide to business capabilities!
Business Capability Modeling: A technique for the representation of an organization’s business anchor model, independent of the organization’s structure, processes, people or domains. Learn how to get started with business capability modeling in 4 steps!
Business Capability Roadmap: A capability roadmap is a plan describing a feasible series of carefully scoped initiatives along with the sequence and estimated timelines in which those initiatives should take place, in order to achieve a business objective. Usually delivered as a document or architectural model describing the business capabilities as they are, and the changes planned over the course of a future period of time. Read more in our whitepaper about business capabilities.
Business Capability Taxonomy: A business capability taxonomy is an ordered hierarchy of business capabilities, structured in a manner that makes sense to the stakeholders, and used to create associations between capabilities and business units.
Business Goal: A Goal is a statement about a state or condition of the enterprise to be brought about or sustained through appropriate Means. A Goal amplifies a Vision - that is, it indicates what must be satisfied on a continuing basis to effectively attain the Vision.
Business Information Model: A model illustrating the groupings and relationships between the data elements that make up business documents.
Business Model: A business model describes the rationale of how an organization creates, delivers, and captures value. Read a case study here.
Business Policy: Formally documented management expectations and intentions. Policies are used to direct decisions, and to ensure consistent and appropriate development and implementation of Processes, Standards, Roles, Activities, IT Infrastructure etc.
Business Process: An event-driven, end-to-end processing path that starts with a customer request and ends with a result for the customer. Business processes often cross departmental and even organizational boundaries.
Business Service: Supports business capabilities through an explicitly defined interface and is explicitly governed by an organization.
Capability: An ability that an organization, person, or system possesses. Capabilities are typically expressed in general and high-level terms and typically require a combination of organization, people, processes, and technology to achieve.
Capability Roadmap: See Business Capability Roadmap.
Case Study: A way of learning about a complex instance through extensive description and analysis. The case study articulates why the instance occurred as it did by exploring the factors contributing to its success or failure, and what one might consider in similar situations. Read one of our case studies "Better decision with metrics" here.
Change Management: The automated support for development, rollout and maintenance of system components (i.e., intelligent regeneration, package versioning, state control, library control, configuration management, turnover management and distributed impact sensitivity reporting).
Cloud Transformation: The process of moving data, applications or other business elements from an organization's onsite computers to the cloud, or moving them from one cloud environment to another. Read more in our white paper "How enterprise architecture paves the way into the cloud".
Compliance: The process of adhering to policies and decisions. Policies can be derived from internal directives, procedures and requirements, or from external laws, regulations, standards and agreements. Read more about how enterprise architecture can help with data compliance here.
Component: Technically, a dynamically bindable package of functionality that is managed as a unit and accessed through documented interfaces that can be discovered at runtime. Pragmatically, components tend to fall into two major groups: technical components, which perform a technology-specific task that is application-independent (e.g., a graphical user interface control), and business components, which encapsulate a piece of business functionality.
Data Object: Reflects information about important business items. This could be data of the kind of account, employee or organization. A Data Object Fact Sheet can be linked to Applications and Interfaces and stores additional information about data sensitivity. A good use of the Data Object is when you want to manage data sensitivity or manage consistency of business information.
Digital Transformation: The process of changing from analog to digital form, also known as digital enablement. Said another way, digitization takes an analog process and changes it to a digital form without any different-in-kind changes to the process itself. Read more in our white paper "Digital transformation: A case for lean enterprise architecture management".
Enterprise Architecture: A discipline for proactively and holistically leading enterprise responses to disruptive forces by identifying and analyzing the execution of change toward desired business vision and outcomes. EA delivers value by presenting business and IT leaders with signature-ready recommendations for adjusting policies and projects to achieve target business outcomes that capitalize on relevant business disruptions. Learn how to get started with EA with our Enterprise Architecture Success Kit.
Enterprise Asset Management: Asset register, work order management, inventory and procurement functions in an integrated business software package.
Enterprise Information Architecture: The part of the enterprise architecture process that describes — through a set of requirements, principles and models — the current state, future state and guidance necessary to flexibly share and exchange information assets to achieve effective enterprise change.
Enterprise principals: A basis for decision-making throughout an enterprise. Such principles are commonly found as a means of harmonizing decision making across an organization. In particular, they are a key element in a successful architecture governance strategy.
Factsheet: The central element in LeanIX. They are used to document and save information regarding architectural objects like e.g. Applications, Business Capabilities or IT-Components. With a Fact Sheet, you keep all relevant information on a "one-pager" and maintain the dependencies within your IT landscape. Learn more about fact sheets here.
Framework: Conventions, principles and practices for the description of architectures established within a specific domain of application and/or community of stakeholders. View our lean framework for EA!
GDPR: The General Data Protection Regulation is a regulation in EU law on data protection and privacy for all individuals within the European Union and the European Economic Area. Read more in our definitive guide to GDPR for EAs.
Governance Body: A group of individuals with the right to create and enforce business policies applicable across business processes.
Information Architecture: Set of rules that determine what, and how and where, information will be collected, stored, processed, transmitted, presented, and used. On the internet, information architecture means how a website's content is organized and presented to its users to facilitate navigation and search functions.
Integration: Detailed design and implementation services that link application functionality (custom software or package software) and/or data with each other or with the established or planned IT infrastructure. Specific activities might include project planning, project management, detailed design or implementation of application programming interfaces, web services, or middleware systems. Make sure to read our complete overview of enterprise integration patterns here.
Interface: A view or presentation of an object, service, or environment that a person (or group) interacts with, and the capabilities that provide for interaction across the interface.
Internet of Things (IoT): A system of interrelated computing devices, mechanical and digital machines, objects, animals or people that are provided with unique identifiers (UIDs) and the ability to transfer data over a network without requiring human-to-human or human-to-computer interaction. Learn how enterprise architecture enables IoT success here.
IT Architecture: Blueprints of the technologies, data structures, and applications that collectively comprise the information technology (IT) environment of an enterprise.
IT Component: A service, a software or hardware, anything you need to offer an Application. An IT Component has a lifecycle for risk and succession management, contains cost per Application for cost management and has a Provider. You should consider your internal services as an IT Component. With this approach, you can make the cost of your IT management effort visible.
IT Landscape: A set of hardware, software and facility elements, arranged in a specific configuration, which serves as a fabric to support the business operation of an enterprise. Get a complete overview of your IT Landscape with these out-of-the-box reports.
Kanban: Technique used in lean manufacturing (i.e., just-in-time) environments to reduce process cycle time by managing flow. Learn the difference between Agile, Kanban and Scrum here.
Key Performance Indicator: A high-level metric which reflects a process or characteristic that is typically measured on a business leader's scorecard.
Lean: A focused approach to the provision of effective solutions involving the consumption of a minimum of resources.
LeanIX: An agile IT and Enterprise Architecture solution for enterprises that need to manage a complex IT landscape. Get a demo now!
Lifecycle: The entire duration of something from the idea conception, through to the development, testing, deployment, support and ultimately retirement of it.
Loose Coupling: The relationship among element in a system in which events in various elements can occur independently. Learn more about loose coupling here.
Metapoint: Also known as viewpoint. A specification of the conventions for constructing and using a view. A metaview acts as a pattern or template of the view, from which to develop individual views. A metaview establishes the purposes and audience for a view, the ways in which the view is documented (e.g., for visual modeling), and the ways in which it is used (e.g., for analysis). Reshape your IT with 24 key EA metapoints here.
Microservices: A software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. Learn more in our white paper "Microservices - What an EA needs to know".
Model: A representation of a subject of interest. A model provides a smaller scale, simplified, and/or abstract representation of the subject matter. A model is constructed as a "means to an end". In the context of enterprise architecture, the subject matter is a whole or part of the enterprise and the end is the ability to construct "views" that address the concerns of particular stakeholders; i.e., their "viewpoints" in relation to the subject matter.
Operational Capability: The ability of a system to perform in the intended operational environment, particularly with respect to meeting the requirements of its stakeholders.
Operational Scenario: Description of an imagined sequence of events that includes the interaction of the product or service with its environment and users, as well as interaction among its product or service components.
Pattern: A technique for putting building blocks into context; for example, to describe a re-usable solution to a problem. Building blocks are what you use: patterns can tell you how you use them, when, why, and what trade-offs you have to make in doing so.
Performance Management: The combination of methodologies and metrics that enables users to define, monitor and optimize outcomes necessary to achieve organizational goals and objectives.
Portfolio Management: The selection, prioritization and control of an organization’s projects and programs in line with its strategic objectives and capacity to deliver. Learn all you need to know about portfolio management in our definitive guide.
Principle: A generalized type of business driver, a principle is any statement that is thought, by senior leadership, to be useful guidance for the organization to consider when making business decisions. A Principle is different from a directive in that a principle, by itself, has no teeth. In order for an executive to place "force of law" around a principle, there must be directives, rules, and (often) business processes that insure that a principle is normally followed.
Process Components: Define the business functional processes and delineate the relationship of the data element concepts to the processes. Information Architecture Process Components specifically identify the business domain and/or information subject area that relate to each business process and the information, business rules, and organizational roles/responsibilities that are part of the process
Product Cost Management: A technology that predicts and captures estimates of the costs of products, systems or solutions over their life cycles. Software functionality predicts costs and enables users to capture estimated costs and track actual costs versus predicted costs. It includes analytical tools to identify the major sources of costs and to leverage historical predicted/estimated costs and actual costs for comparison, with future predicted/estimated product, service and solution costs for profitable trade-offs. Learn more about cost management and EA here.
Product Lifecycle Management: A philosophy, process and discipline supported by software for managing products through the stages of their life cycles, from concept through retirement. As a discipline, it has grown from a mechanical design and engineering focus to being applied to many different vertical-industry product development challenges. Find our how to monitor product lifecycles and avoid risk here!
Quality Assurance: The maintenance of a desired level of quality in a service or product, especially by means of attention to every stage of the process of delivery or production. Learn more about our best practices to increase your data quality here.
Real-Time Analytics: The discipline that applies logic and mathematics to data to provide insights for making better decisions quickly. For some use cases, real time simply means the analytics is completed within a few seconds or minutes after the arrival of new data. On-demand real-time analytics waits for users or systems to request a query and then delivers the analytic results. Continuous real-time analytics is more proactive and alerts users or triggers responses as events happen. Read more about how to get started with real-time analytics and how to apply them to enterprise architecture.
Reference Architecture: A reference architecture is a document or set of documents to which a project manager or other interested party can refer for best practices. In information technology, a reference architecture can be used to select the best delivery method for particular technologies within an IT service catalog. Learn more about how to create a reference architecture here.
Repository: A system that manages all of the data of an enterprise, including data and process models and other enterprise information. Hence, the data in a repository is much more extensive than that in a Data Dictionary, which generally defines only the data making up a database.
Resource: An economic or productive factor required to accomplish an activity, or as means to undertake an enterprise and achieve desired outcome. Three most basic resources are land, labor, and capital; other resources include energy, entrepreneurship, information, expertise, management, and time.
Risk: One of the elements of a business model assessment, a risk is a type of potential impact to the organization that should be considered as part of a business judgment. The business model assessment is composed of one or more business judgments, and puts perspective around the model or models evaluated. Learn all you need to know about risk management in our definitive guide!
Robustness: The degree to which a system or component can function correctly in the presence of invalid inputs or stressful environmental conditions.
Scrum: A framework for project management that emphasizes teamwork, accountability and iterative progress toward a well-defined goal. Learn the difference between Agile, Kanban and Scrum here.
Service: A valuable action, deed, or effort performed to satisfy a need or to fulfill a demand.
Service Level Agreement (SLA): A service level agreement is a contract made between two business units, where one business unit provides a service to another. The contract describes specific measures by which the service provider's performance will be measured, as well as acceptable ranges of those measures that the consumer would find acceptable.
Service-Oriented Architecture (SOA): A design paradigm and discipline that helps IT to meet business demands. Some organizations realize significant benefits using SOA including faster time to market, lower costs, better application consistency and increased agility. SOA reduces redundancy and increases usability, maintainability and value. This produces interoperable, modular systems that are easier to use and maintain. SOA creates simpler and faster systems that increase agility and reduce total cost of ownership (TCO). Find out what the difference between microservices and SOA is in our blog.
Service-Level-Agreement (SLA): An agreement that sets the expectations between the service provider and the customer and describes the products or services to be delivered, the single point of contact for end-user problems and the metrics by which the effectiveness of the process is monitored and approved.
Shadow IT: IT devices, software and services outside the ownership or control of IT organizations.
Software-As-A-Solution (SaaS): Software that is owned, delivered and managed remotely by one or more providers. The provider delivers software based on one set of common code and data definitions that is consumed in a one-to-many model by all contracted customers at anytime on a pay-for-use basis or as a subscription based on use metrics.
Solution Architecture: An architectural description of a specific solution. Solution architectures combine guidance from different enterprise architecture viewpoints (business, information and technical), as well as from the enterprise solution architecture. Find out what the difference between enterprise architects and solution architects is here.
Stakeholder: Any person or representative of an organization who has a stake-a vested interest-in the outcome of a project or whose opinion must be accommodated. A stakeholder can be an end user, a purchaser, a contractor, a developer, or a project manager. Find out how to answer the top questions on your stakeholders with our free poster!
Standards: Specifications or styles that are widely accepted by users and adopted by several vendors. Standards are critical to the compatibility of hardware, software, and everything in between. Industry standards enable the essential elements of a computer and related infrastructure to work together. Standards provide specifications to hardware manufacturers and software developers that allow them to create products that will work together. Read more about how to govern standards with enterprise architecture.
Statement of Work (SOW): An objectives section allowing the customer to emphasize the desired end state or performance metric to be achieved. It also mandates the assessment of past performance, technical approach and cost for each task order. The customer determines the relative importance of each criterion.
Supply chain management (SCM): The processes of creating and fulfilling demands for goods and services. It encompasses a trading partner community engaged in the common goal of satisfying end customers.
Target: The desired future or "to be" state of the business environment, captured in a set of target business models. Find out how to create a target architecture here.
Technical Reference Model: A foundation to categorize the standards, specifications, and technologies to support the construction, delivery, and exchange of business and application components (Service Components) that may be used and leveraged in a Component-Based or Service-Oriented Architecture.
Technology Obsolescence: The time and state in which a piece of technology or product ceases to be useful, productive or compatible.
Technology Risk: Any potential for technology failures to disrupt your business such as information security incidents or service outages. Learn all you need to know about technology risk management in our definitive guide!
Total Cost Of Ownership (TCO): A comprehensive assessment of information technology (IT) or other costs across enterprise boundaries over time. For IT, TCO includes hardware and software acquisition, management and support, communications, end-user expenses and the opportunity cost of downtime, training and other productivity losses.
Usability: The degree to which something - software, hardware or anything else - is easy to use and a good fit for the people who use it.
Value Proposition: The central notion of a business model, the value proposition describes how the business, through its activities, adds value to the consumer or marketplace. The Value proposition binds together the notions of customer demands, required competencies, revenue models and business partnerships. It is a statement from the viewpoint of the target customers that informs everyone "why" the business' products and services are valuable.
Value Stream: A sequence of business processes the boundaries of which are typically defined by business transactions. They represent end-to-end sequences such as "order to cash" or "idea to available product".
Vendor Management: A discipline that enables organizations to control costs, drive service excellence and mitigate risks to gain increased value from their vendors throughout the deal life cycle.
Vendor Risk Management: The process of ensuring that the use of service providers and IT suppliers does not create an unacceptable potential for business disruption or a negative impact on business performance. VRM technology supports enterprises that must assess, monitor and manage their risk exposure from third-party suppliers (TPSs) that provide IT products and services, or that have access to enterprise information.
View: The representation of a related set of concerns. A view is what is seen from a viewpoint. An architecture view may be represented by a model to demonstrate to stakeholders their areas of interest in the architecture. A view does not have to be visual or graphical in nature. Reshape your IT with 24 key EA views here.
Web-oriented architecture (WOA): A substyle of service-oriented architecture (SOA) that leverages Web architecture. It emphasizes the generality of interfaces (user interfaces and APIs) via five fundamental generic interface constraints: resource identification (e.g., uniform resource identifier [URI]), manipulation of resources through representations (e.g., HTTP), self-descriptive messages (e.g., Multipurpose Internet Messaging Extensions [MIME] types), hypermedia as the engine of application state (e.g., links) and application neutrality.