Effective enterprise architecture relies on a standardized vocabulary to describe the vast ecosystem of systems, data, and services that make up an organization. One of the most critical concepts in this framework is the Building Block. But how do you distinguish a reusable architectural component from a standard document or a specific project deliverable? This tutorial explores the logic of architectural categorization, focusing on the “Is It a Building Block?” decision model.
The Core Definition: What is a Building Block?
In the context of enterprise architecture, a building block is not merely a physical object. It is defined by its utility and reusability. The fundamental question to ask when evaluating a system component is:
Is it reusable as a capability or implementation component?
If the answer is YES, the item is almost certainly a Building Block. These are the foundational bricks of the enterprise—standardized solutions designed to be reused across multiple projects rather than built from scratch for a single initiative.
Key Characteristics
- Reusability: It can be utilized by various applications or business units.
- Standardization: It adheres to established standards (e.g., an API Gateway).
- Implementation Focus: It often represents a concrete technical capability rather than just a concept.
The Decision Logic: A Step-by-Step Analysis
Architecture modeling often requires a decision tree to classify work products. The primary bifurcation point in this model is the “Build vs. Buy” or “Standard vs. Ad-hoc” assessment.
Step 1: The Reusability Test
Begin by analyzing the item in question. Is it a generic capability that solves a common problem? If you identify a component that serves as a general implementation, such as an Identity Management Service, you have identified a building block.
However, if the item is unique to a specific project and cannot be easily extracted for reuse, the answer to the reusability test is NO. In this scenario, you must assess its purpose further to determine if it is a deliverable or an artifact.
Step 2: Categorizing Non-Building Blocks
When an item is not a building block, the model directs you to assess its role in the project lifecycle:
- Deliverables: Formal outputs of a project phase (e.g., an Architecture Work Package).
- Artifacts: Supporting documents, diagrams, or data structures (e.g., an Application Catalog).
Real-World Examples of Building Blocks
To make this concept concrete, let us examine four specific examples of items that qualify as Building Blocks because they are reusable capabilities:
- Identity Management Service: A centralized system for authentication and authorization. Instead of building login logic for every new app, the enterprise builds this block once and reuses it everywhere.
- Customer Data Capability: A standardized view or service for accessing customer information. This ensures data consistency across the organization.
- API Gateway: A management layer for traffic control, security, and monitoring of APIs. It is a universal infrastructure component.
- Cloud Landing Zone: A pre-configured environment for cloud resources. It is a reusable implementation pattern for cloud adoption.
Nuance: The Fluidity of Categories
It is important to understand that these categories describe different dimensions of the work product rather than rigid document types. A single item can belong to multiple categories depending on how it is used.
Consider an Application Catalog:
- As an Artifact: It is a document or data store listing applications.
- As a Building Block: If the catalog itself is treated as a formal tool used by developers to find and consume applications, it becomes a reusable implementation component.
Conclusion: Reuse, Standardize, Assemble
The goal of identifying building blocks is to move away from “reinventing the wheel” for every project. By adhering to the logic that Reusable Capability = Building Block, architects can create a robust library of standards. This allows teams to Reuse existing assets, Standardize the architecture, and Assemble solutions faster and more reliably.
Remember: This decision point helps identify a likely building block, but it does not define the other categories (like artifacts). Always consider the context of how the item is being utilized.
