Glossary of Terms and Phrases - Solutions Architecture Best Practices and Framework

Glossary of Terms and Phrases

(Chapter 2 of Solutions Architecture Best Practices and Framework)

Authored and Published By: The International Foundation for Information Technology (IF4IT), LLC

Term	Abbreviation	Definition
Anti-Pattern	—	A common but counterproductive approach to a problem — tempting because it appears to save time or effort, but reliably producing a worse outcome than the corresponding Best Practice. Paired explicitly with relevant Best Practices throughout this document to make what to avoid as concrete as what to do.
Application Architect	—	A type of Technical/Technology Architect who specializes in a specific application or set of applications — the same specialization pattern as a Technology Architect who specializes in a technology such as storage solutions. Not a subtype of Solutions Architecture.
Architecture Decision Record	ADR	A record of a specific architecture decision and who made it. The Solutions Architecture Reference Book’s own decision record extends beyond Architecture Decision Records to include approvals for decisions affecting pre-existing constructs not owned by the Solutions Architect.
Architecture Flywheel Effect	—	The continuous, self-reinforcing cycle in which each Solutions Architecture engagement both draws upon and contributes to the EA Platform. Each engagement accelerates and de-risks its own work by leveraging what the EA Platform already provides (Current State lookup, Future State deconfliction/reuse), while further vetting, feeding, and improving that same EA Platform for engagements still to come. The more it is used, the more valuable it becomes.
Architecture Repository	Architecture Repo	The consistent, centralized component of the EA Platform used to categorize, organize, store, and share all documented EA knowledge — including completed and in-progress SARBs — as distinct from the Enterprise Model, which holds structured data and information sourced and derived from inventories. Two parallel EA Platform storage constructs: the Enterprise Model for structured and semi-structured data and information, the Architecture Repository for raw and loosely structured documents.
Architecture Review Board	ARB	A cross-organizational governance body that reviews and approves significant architecture decisions. Already defined in the published Application Portfolio Management (APM) Best Practices Glossary and referenced here rather than redefined; cited in this document as an example Service within the EA Platform.
Architecture Value Ladder	—	A four-level maturity model for any architecture function — Review, Advise, Embed, Own — from the Enterprise Architecture Value Model, in which value becomes visible only once a function moves from advisory work to accountable ownership. Solutions Architecture is naturally positioned at Level 3, “Embed.”
Business Architecture	—	One of the specialized architecture practices Solutions Architecture draws on. Its scope includes Capabilities, Processes, Procedures, Roles & Responsibilities, Stakeholders, Facilities & Real Estate, and People/Human.
Course-correction	—	When detailed realization planning in SAF Phase 5 reveals that the chosen Solutions Option is no longer viable on the terms the Customer actually decided on in Phase 4 — cost, risk, or feasibility having changed materially — that is a course-correction, not a normal planning refinement. It belongs back with the Customer, not resolved unilaterally within Phase 5.
Customer, the	—	The term used consistently throughout this document for the problem owner(s) of a Solutions Architecture engagement — internal (the Business or IT itself) or external (a separate enterprise being served as a professional service). See “Who Solutions Architecture Serves: Internal and External Customers” for the distinction.
Data & Information Architecture	—	One of the specialized architecture practices Solutions Architecture draws on, focused on data and information concepts, including Integrations.
EA Platform	—	The broad set of things needed to (1) perform the Enterprise Architecture function, and (2) meet the needs of its stakeholders — the Business and IT (e.g., Engineering, Software Development, Testers, other Architects), and every architecture sub-practice (Business Architecture, Data & Information Architecture, Security Architecture, Technical/Technology Architecture, Solutions Architecture, among others — representative, not exhaustive). These things include, but are not limited to: technologies, Products and Services, inventories, data, information, artifacts, and Architecture Decision Records (ADRs); the Enterprise Model; standards, policies, procedures, frameworks, and best practices; documents, diagrams, roadmaps, and other models; and relevant Capabilities, Processes, and Procedures. Services, as one type of thing, include governance bodies such as the Technology Review Board (TRB) and Architecture Review Board (ARB), and services to create, maintain, and govern appropriate inventories. The Enterprise Model is one component of the EA Platform, not synonymous with it.
Enterprise Model	EM	The structured and semi-structured data and information component of the EA Platform, sourced and derived from governed inventories. Distinct from the Architecture Repository, which holds documents rather than data. Some organizations refer to the Enterprise Model as the “EA Model.”
Horizontal Solution	—	An existing Enterprise Architecture Value Model term for a technology platform, service, capability, or system that multiple portfolios consume. Narrower than, and not synonymous with, a Solution Set.
Lead Solutions Architect	—	The role required whenever a Solutions Architecture engagement is staffed with more than one Solutions Architect — accountable for the SARB’s overall coherence and serving as the Customer’s single point of accountability on the team. Does not change who owns the final decision in Phase 4; that remains the Customer’s, Lead or otherwise.
Local Domain Expert	—	A specialist within a single specialized architecture practice or SA Dimension, capable of resolving problems that stay within their own domain without cross-dimensional integration.
Non-Functional Requirements	NFRs	The requirements that describe how well a solution must do what it does — performance, scalability, availability, reliability, maintainability, usability, interoperability, and recoverability — as distinct from functional requirements, which describe what the solution must do. Established alongside functional requirements in SAF Phase 1 and evaluated the same way in Phase 3’s fit assessment.
Problem-Domain KPIs and Metrics	—	The specific KPIs, metrics, and measures relevant to the problem being solved — not process metrics about how the engagement itself was run. Identified and vetted with the Customer in SAF Phase 1, so that how a chosen Solutions Option is projected to move them can be assessed in Phase 3 and presented in Phase 4.
Program Lead	—	The role that coordinates alignment and sequencing across a Program’s constituent engagements, mirroring the Lead Solutions Architect role but operating across engagements rather than within one. Never substitutes for any single engagement’s own Lead Solutions Architect or its Customer’s decision authority.
Risk	—	One of the SA Dimensions: what could go wrong with a Solutions Option — technical, delivery, or organizational — first identified during Vision Development in SAF Phase 1, refined into a Risk Register, and assessed for every Solutions Option under consideration in Phase 3, not only the one ultimately recommended.
Security Architecture	—	One of the specialized architecture practices Solutions Architecture draws on, focused on security concepts, including Identity & Access Management.
Solutioning	—	The verb form of practicing Solutions Architecture: the act of determining a Solution Set for a specific problem.
Solutions Architecture	SA	(1) Noun form, a.k.a. “Solution Set”: a comprehensive and well-documented answer to a problem — the combined set of things (data & information, tools & technologies, processes & procedures, roles & responsibilities, security, answers to Non-Functional Requirements (NFRs), etc.) and the relationships between them, deliberately chosen and arranged to solve a given problem or set of problems. May be referred to informally in body text as “the Solution.” (2) Practice form: the repeatable and specific type of professional architecture practice that makes coming to such answers — and documenting them — consistent. The managed discipline of determining, vetting, presenting, deciding on, and realizing Solutions Architectures for specific problems, federated to and feeding EA/the EA Platform.
Solutions Architecture Dimensions	SA Dimensions	Illustrative, not exhaustive, categories a comprehensive Solution Set may need to address — Business (including Facilities & Real Estate and People/Human), Technology, Data & Information, and Security, among others not yet identified.
Solutions Architecture Framework	SAF	The repeatable, five-phase methodology this document standardizes for practicing Solutions Architecture: Vision Development and Understanding, Current State Collection and Analysis, Future State Solutions Options Determination and Vetting, Solutions Presentation and Decisioning, and Solutions Realization Planning.
Solutions Architecture Reference Book	SARB	The governed, per-engagement knowledge artifact that serves as the collection of all other related governed artifacts produced across a Solutions Architecture engagement. At a minimum, it holds: the problem statement (vision, mission, goals & desired outcomes); the current state representation; assessments and analyses; the options considered; and — critically — all decisions made throughout the engagement, and by whom. This decision record goes beyond Architecture Decision Records (ADRs) alone: it also captures decisions affecting pre-existing constructs (e.g., existing applications, data & information) not owned by the Solutions Architect, which must instead be vetted with and approved by the stakeholders who own them. This is what makes the SARB a governance artifact, not just a knowledge repository — it establishes accountability for who decided, and who approved, what. Done well, it is one of the more comprehensive documentation sets delivered by any area of IT. The SARB is not one document among several candidate artifact types — it is the governed container that holds all other related governed artifacts for the engagement.
Technical/Technology Architecture	—	One of the specialized architecture practices Solutions Architecture draws on, focused on technical/technology concepts. Application Architect is a type of Technical/Technology Architect.
Technology Review Board	TRB	A cross-organizational governance body that reviews and approves significant technology decisions, similar in function to an Architecture Review Board. Already defined in the published Application Portfolio Management (APM) Best Practices Glossary and referenced here rather than redefined; cited in this document as an example Service within the EA Platform.
Transition Plan	—	A required component of every Future State Solutions Option, developed in SAF Phase 3, capturing an initial roadmap, required costs, required skills acquisition, and what changes in moving from Current State to that specific option. Accurate enough at that stage to give the Customer real directionality for choosing among options, without needing to be fully detailed until SAF Phase 5, if that phase is performed. Choosing a Solutions Option in SAF Phase 4 carries its Transition Plan forward as the foundation for Phase 5.

How to cite this page

When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.

Example (informal web citation):

The International Foundation for Information Technology (IF4IT), LLC. Glossary of Terms and Phrases | Solutions Architecture Best Practices and Framework. https://if4it.org/best-practices/solutions-architecture/glossary-of-terms-and-phrases/ (accessed 2026-10-26).

See About Us for content governance and site-wide citation guidance.

Legal Disclaimers