In Enterprise Architecture, complex systems are not built from scratch in one monolithic step. Instead, they are assembled from standardized, reusable components known as Building Blocks. Think of them as the architectural “Lego bricks” of an organization: each block provides a specific piece of functionality, and when combined according to a clear design, they form a complete, interoperable enterprise system.
This guide provides a complete, self-contained overview of building blocks, their types, how they evolve during architecture development, and how they are applied in real-world scenarios.
A Building Block is a package of functionality defined to meet specific business needs across an organization. It is not just a piece of software; it represents a clearly defined capability that can be combined with other blocks to deliver complete architectures and solutions.
Every building block has published interfaces, which are the standardized ways other systems or users interact with it. Because interfaces are public and stable, different blocks can interoperate seamlessly, even if they are built by different teams or vendors.
An enterprise architecture is essentially a composition of:
A set of building blocks depicted in an architectural model.
A specification of how those blocks are connected to meet overall system requirements.
When designing with building blocks, three guiding principles apply:
Relevance: Only include blocks that implement services the enterprise actually requires.
Flexibility: A single block may implement one, several, or only part of a required service.
Standards Compliance: All building blocks should conform to organizational or industry standards.
Not every component qualifies as a well-designed building block. To be effective in enterprise architecture, a building block should possess the following characteristics:
Considers Implementation & Usage: Designed with real-world deployment in mind, and evolves to leverage new technologies and standards.
Modular & Composable: Can be assembled from smaller blocks or act as a subassembly within larger blocks.
Reusable & Replaceable: Designed to be deployed across multiple projects without rewriting, and easily swapped out if a better option emerges.
Loosely Coupled Specification: The what (specification) is kept separate from the how (implementation). This allows the same functionality to be realized in multiple ways without breaking the architecture.
Well-Specified with Stable Interfaces: Clear, documented boundaries and interaction points that do not change frequently.
Building blocks operate at different levels of abstraction. The TOGAF framework distinguishes between two primary types:
Focus: What needs to be done.
Nature: Abstract, functional, and requirement-driven. They represent architecture documentation, models, and high-level capabilities.
When Defined: Primarily during Phases A, B, C, and D of the architecture development cycle.
Minimum Specification Includes:
Fundamental functionality and attributes (semantics, security, manageability)
Supplied interfaces
Interoperability and relationships to other blocks
Dependent blocks with required functionality
Mapping to business/organizational entities and policies
Role: Capture business, data, application, and technology requirements. They guide and shape the selection of concrete products.
Focus: How it will be implemented.
Nature: Concrete, implementation-specific, and product/vendor-aware. They represent real software, hardware, or custom developments.
When Defined: First appear in Phase E, where product-specific options are evaluated to fill architectural gaps.
Minimum Specification Includes:
Specific functionality and attributes
Implemented interfaces
Required SBBs and their interface names
Mapping to IT topology and operational policies
Shared attributes (security, scalability, performance, configurability)
Design drivers, constraints, and relationships back to ABBs
Role: Define the actual products and components that will deliver the functionality.
| Aspect | Architecture Building Block (ABB) | Solution Building Block (SBB) |
|---|---|---|
| Question Answered | What capability is required? | Which product/component delivers it? |
| Abstraction Level | High/Logical | Low/Physical |
| Vendor Awareness | Vendor-neutral | Product/Vendor-specific |
| Primary Phase | A, B, C, D | E onwards |
| Output | Requirements & Functional Models | Procurement, Development, Deployment |
The Architecture Development Method (ADM) is an iterative process where building blocks mature from abstract concepts to deployed solutions:
Phase A (Architecture Vision): Building blocks start as high-level, abstract entities. They outline the core capabilities needed to achieve the vision.
Phases B, C, D (Business, Data, Application, Technology): Blocks are refined within their respective domains. Functional definitions are expanded, interfaces are clarified, and relationships between blocks are mapped.
Phase E (Opportunities & Solutions): Gaps between baseline and target states are analyzed. Here, ABBs are matched with concrete SBBs (commercial products, cloud services, or custom code) to implement the required functionality.
Implementation & Deployment: SBBs are procured or developed, integrated via their published interfaces, and deployed according to architecture governance.
Throughout this evolution, maintaining published and reasonably stable interfaces is critical. It ensures that as blocks are replaced or upgraded, the broader architecture remains intact.
A pattern is an idea that has proven useful in one practical context and is likely to be useful in others. While building blocks are what you use, patterns tell you how, when, and why to use them.
Provide context for assembling building blocks.
Describe reusable solutions to recurring architectural problems.
Highlight trade-offs (e.g., performance vs. security, cost vs. flexibility).
Guide architects toward proven combinations of ABBs and SBBs that have succeeded in the past.
Patterns essentially serve as reference blueprints. Instead of reinventing the wheel for every project, architects can apply established patterns to accelerate design, reduce risk, and ensure consistency across the enterprise.
ABB: Customer Data Management Service
Functionality: Store, retrieve, update, and secure customer records.
Interfaces: RESTful API for CRUD operations, OAuth 2.0 for authentication.
Rules: Must comply with data privacy regulations, support multi-tenant access.
SBB: Salesforce CRM OR Custom .NET Web App + SQL Server Database
Implementation: Real software purchased or built that fulfills the ABB’s specification.
Mapping: The CRM’s API matches the ABB’s interface requirements; configuration aligns with privacy rules.
ABB: Identity & Access Management (IAM)
Functionality: Centralized login, multi-factor authentication, role-based access control, session management.
Interfaces: SAML/OIDC endpoints, LDAP directory sync.
SBB: Microsoft Entra ID (Azure AD) or Okta Identity Cloud
Implementation: Cloud-hosted SaaS products deployed to handle authentication across all enterprise applications.
ABB: Secure Payment Gateway
Functionality: Authorize, capture, and settle financial transactions; tokenize sensitive card data; generate audit logs.
Interfaces: PCI-DSS compliant API, webhook for transaction status.
SBB: Stripe API Integration or In-house Payment Module using AWS Payment Cryptography
Implementation: The chosen third-party service or internal development that realizes the payment ABB.
Building blocks are the foundational, reusable components of enterprise architecture.
A well-designed block has stable interfaces, is loosely coupled to implementation, and is both reusable and replaceable.
ABBs define what is needed (abstract, requirement-driven). SBBs define how it’s built (concrete, product-driven).
Building blocks evolve from abstract concepts in early ADM phases to specific implementations in later phases.
Architecture patterns provide proven blueprints for combining blocks, highlighting trade-offs and accelerating design.
Successful architectures only include necessary blocks, ensure standards compliance, and leverage published interfaces for seamless interoperability.
By mastering building blocks, architects can design flexible, cost-effective, and future-proof enterprise systems that align directly with business objectives while minimizing technical debt and vendor lock-in.
