7.2 Technology Standards, the Standards Library, Platform Services, and Infrastructure Modeling
Key Takeaways
The TOGAF 10 Standards Library holds the standards new architectures must comply with; TOGAF 9 material calls a similar store the Standards Information Base.
TOGAF classes standards as Legal and Regulatory Obligations, Industry Standards, and Organizational Standards, and also categorizes them by architecture domain.
The TOGAF standards lifecycle is Proposed, Provisional (Trial), Standard (Active), Phasing-Out (Deprecated), and Retired (Obsolete).
New instances of a Phasing-Out standard are generally discouraged, and a Retired standard should be removed, with change accepted only as part of a decommissioning plan.
Infrastructure models separate logical technology components from physical ones, and Infrastructure as Code helps keep deployments consistent with approved standards.
7.2 Technology Standards, Platform Services, and Infrastructure Modeling
In large organizations, unmanaged technology diversity is a primary driver of runaway IT costs, security vulnerabilities, and operational fragility. When individual engineering teams are permitted to select arbitrary programming runtimes, database engines, operating systems, and infrastructure tools without centralized architectural guidance, the enterprise quickly finds itself supporting dozens of conflicting technologies. Phase D Technology Architecture establishes the governance mechanisms and modeling conventions required to tame this complexity: Technology Standards Management, the Standards Library, Platform Services Taxonomies, and Infrastructure Modeling.
The Standards Library in the TOGAF 10 Architecture Repository
In the TOGAF Standard, 10th Edition, technology standards are held in the Standards Library of the Architecture Repository. (TOGAF 9 called a similar store the Standards Information Base, a name still common in older material.) The Standards Library holds the specifications to which architectures must conform. TOGAF explains that it gives an unambiguous basis for governance: projects can see their obligations, and standards stated clearly can be assessed objectively.
Three Classes of Standard
- Legal and Regulatory Obligations: mandated by law, so the enterprise must comply or face serious consequences.
- Industry Standards: set by industry bodies (such as The Open Group) and selected by the enterprise. They support interoperation but sit outside the enterprise's control, so they must be monitored.
- Organizational Standards: set within the organization, for example a standard application chosen for portfolio consolidation. These need processes for exemptions and for evolving the standards.
Standards are categorized against the building blocks of the TOGAF Enterprise Metamodel and, at the top level, by architecture domain: business, data, applications, and technology standards. Technology standards include standard hardware products, standard software products, and standards for software development.
The TOGAF Standards Lifecycle
Standards are managed through a lifecycle and periodically reviewed:
[ Proposed ] --> [ Provisional (Trial) ] --> [ Standard (Active) ] --> [ Phasing-Out (Deprecated) ] --> [ Retired (Obsolete) ]
| Stage | TOGAF meaning | Practical use |
|---|---|---|
| Proposed Standard | Identified as a potential standard but not yet evaluated for adoption | Candidate for evaluation |
| Provisional Standard (Trial Standard) | Not yet tried and tested enough for its value to be fully understood | Projects may adopt it only under specific pilot conditions |
| Standard (Active Standard) | The mainstream solution that should generally be used as the approach of choice | Default for new work |
| Phasing-Out Standard (Deprecated Standard) | Approaching the end of its useful lifecycle | Projects reusing existing components can generally continue to use it; deploying new instances is generally discouraged |
| Retired Standard (Obsolete Standard) | No longer accepted as valid within the landscape | Remedial action should normally remove it; change activity is accepted only as part of a decommissioning plan |
When a standard changes status, TOGAF asks architects to assess the landscape impact and plan action, for example migration work packages for systems still on a phasing-out standard.
Standards Compliance and the Dispensation Process
The Standards Library is a governance instrument, not just a catalog. Designs are assessed against it in architecture development and in Phase G compliance reviews. If a project has a compelling reason to deviate, for example a specialized graph database for fraud analytics where the standard is relational, it cannot simply proceed. It requests a dispensation from the Architecture Board, which TOGAF describes as granted for a given time period with identified service and operational criteria that must be enforced while it lasts. Repeated dispensations for the same deviation are a signal to review the standard itself.
Platform Services Taxonomy
Platform services constitute the standardized software infrastructure layer that shields application developers from underlying hardware and cloud provider mechanics. By providing consistent, reusable platform building blocks, enterprise architects enable application engineering teams to focus on delivering business logic rather than rebuilding foundational infrastructure utilities.
A practical platform services taxonomy (an illustration rather than a TOGAF-defined list) groups services into five domains:
1. Compute Services
Provides runtime execution environments for application code.
- Building Blocks: Bare-metal servers, hypervisor virtual machines (VMware ESXi, KVM), container orchestration platforms (Kubernetes / Red Hat OpenShift), and serverless execution environments (AWS Lambda, Azure Functions).
- Architectural Concerns: CPU/memory overcommit ratios, autoscaling velocity, container isolation boundaries, and cold-start latency.
2. Persistence & Storage Services
Governs structured and unstructured enterprise data storage.
- Building Blocks: Block storage (SAN/NVMe over Fabrics), Network-Attached File Storage (NFS/SMB), distributed Object Storage (S3-compatible), Relational Database Management Systems (PostgreSQL, Oracle), distributed NoSQL document stores (MongoDB, Couchbase), and in-memory key-value caches (Redis, Memcached).
- Architectural Concerns: IOPS throughput, write endurance, synchronous vs. asynchronous data replication, and encryption at rest.
3. Messaging & Integration Services
Enables decoupled, asynchronous communication across distributed application services.
- Building Blocks: Enterprise message brokers (RabbitMQ, Apache ActiveMQ), distributed commit log event streaming engines (Apache Kafka, AWS Kinesis), API Gateways, and Service Meshes (Istio, Linkerd).
- Architectural Concerns: Message delivery guarantees (at-least-once, exactly-once), partitioned ordering, event schema evolution, and mutual TLS service mesh authentication.
4. Identity & Access Services
Enforces authentication, authorization, and cryptographic integrity across human users and machine workloads.
- Building Blocks: Enterprise directory services (Active Directory, LDAP), OpenID Connect / OAuth2 identity providers, Privileged Access Management (PAM), Public Key Infrastructure (PKI), and Hardware Security Modules (HSMs).
- Architectural Concerns: Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), token lifecycle management, and secrets rotation.
5. Observability & Operations Services
Provides end-to-end visibility into platform health, performance anomalies, and security events.
- Building Blocks: Centralized log aggregation (Elasticsearch, OpenSearch), time-series metrics collection (Prometheus, Datadog), distributed tracing (OpenTelemetry, Jaeger), and synthetic transaction monitors.
- Architectural Concerns: Telemetry ingestion volume, log retention compliance, alert noise reduction, and automated incident remediation.
Platform Services Architecture Matrix
| Platform Service Domain | Core Architectural Responsibility | Representative Enterprise Standard (Standards Library) | Obsolescence & Technical Debt Risk |
|---|---|---|---|
| Compute Execution | Provision and manage scalable runtime execution environments | Kubernetes (OCI-compliant container images) | Legacy proprietary Unix OS (AIX, Solaris) facing hardware vendor EOL |
| Data Persistence | Ensure durable, ACID-compliant or polyglot data storage | Managed PostgreSQL 16+; S3-compatible Object Storage | Legacy proprietary database engines with restrictive core-based licensing |
| Messaging & Events | Decouple system interactions and provide event streaming | Apache Kafka / Cloud-native managed event buses | Unmonitored point-to-point cron scripts and legacy MSMQ queues |
| Identity & Security | Centralize authentication and machine-to-machine trust | OpenID Connect / OAuth2 via corporate IdP | Hard-coded database passwords in configuration text files |
| Observability | Capture distributed telemetry, traces, and metrics | OpenTelemetry standard collectors and agents | Fragmented, server-local log files on unmonitored disk drives |
Infrastructure Modeling: From Logical ABBs to Physical SBBs
Enterprise architects use infrastructure models to communicate system topologies to infrastructure engineers, network teams, and security auditors. The TOGAF Enterprise Metamodel distinguishes logical from physical technology components; practical infrastructure models add nodes and networks:
- Logical Technology Components (ABBs): Abstract platform capabilities independent of vendor products (e.g., 'Load Balancer ABB', 'Relational Database Cluster ABB', 'Container Ingress Controller ABB').
- Physical Technology Components (SBBs): Specific commercial hardware appliances, cloud services, or software packages deployed in production (e.g., 'F5 BIG-IP iSeries 5800 Appliance', 'AWS Application Load Balancer', 'HAProxy v2.8 Enterprise').
- Technology Nodes & Execution Environments: The physical or virtual computing environments where software runs (e.g., 'DMZ Ingress Cluster Node', 'Core Processing Node', 'Branch Edge Gateway Node').
- Distribution Networks & Paths: The physical transmission links, virtual networks, VPN tunnels, and firewalls connecting technology nodes.
Modernizing Legacy Infrastructure & Infrastructure as Code (IaC)
A central responsibility in Phase D is transitioning an organization away from fragile, manually configured infrastructure toward declarative, programmable platforms.
Manual infrastructure management results in configuration drift—the silent, untracked divergence between different server environments (development, staging, production)—which accounts for a vast percentage of catastrophic production deployment failures.
Enterprise architects mandate modern infrastructure delivery patterns:
- Infrastructure as Code (IaC): Infrastructure topology is defined entirely in declarative, machine-readable configuration files (e.g., Terraform, OpenTofu, AWS CloudFormation) maintained in version-controlled repositories (Git). Changes must pass automated linting, security scans, and peer reviews before being deployed via CI/CD pipelines.
- Immutable Infrastructure: Rather than modifying running servers in place (applying manual patches or configuration tweaks), new virtual machine images or container images are compiled from scratch and deployed to replace existing instances. If an issue occurs, the environment rolls back instantly to the prior immutable image.
- GitOps & Continuous Reconciliation: Operational agents running inside the infrastructure (such as ArgoCD in Kubernetes) continuously compare the live runtime state against the desired state stored in the Git repository, automatically remediating configuration drift.
Real-World Case Example: Financial Services Platform Modernization and Standards Enforcement
Equinox Wealth Management, a global investment advisory managing $140 billion in assets, struggled with severe operational outages and regulatory audit failures. An internal architecture audit revealed that across twenty product teams:
- Eight different database engines were deployed, including two unpatched MySQL 5.5 databases supporting core portfolio valuations.
- Server instances were configured manually by individual systems administrators, resulting in severe configuration drift where staging environments did not reflect production security patches.
- Four project teams had deployed unvetted, open-source caching libraries that contained critical vulnerabilities (CVEs), exposing client financial statements.
During Phase D, the enterprise architecture team:
- Re-established the Standards Library, designating containerized PostgreSQL 16 on managed Kubernetes as the active relational Standard and classifying MySQL 5.5 as a Retired (Obsolete) standard to be removed through a decommissioning plan.
- Established an Architecture Dispensation Process, granting a time-limited 90-day dispensation to the portfolio valuation team to migrate to PostgreSQL while implementing compensating network isolation controls.
- Implemented a Standardized Platform Services Fabric, deploying a shared enterprise Kubernetes cluster pre-integrated with OpenTelemetry, HashiCorp Vault for secrets management, and OpenID Connect identity federation.
- Mandated Declarative Infrastructure as Code (IaC) across all projects, blocking any manual changes to production environments.
Within twelve months, Equinox eliminated all obsolete database engines, reduced production configuration defects by 88%, and saved $6.4 million in third-party database support fees.
Common Exam Traps & Practitioner Pitfalls
- Adopting Phasing-Out Standards for New Work: A scenario may describe a team that wants to build a new application on a technology classed as Phasing-Out (Deprecated) because developers know it. TOGAF says deploying new instances of a Phasing-Out standard is generally discouraged. The better answer steers the team to the active Standard and treats any justified exception as a time-bound dispensation decided by the Architecture Board.
- Conflating the Standards Library with the Architecture Landscape: The Architecture Landscape holds architectural views of the enterprise at particular points in time (baseline, transition, and target). The Standards Library holds the standards that architectures must conform to.
- Treating Infrastructure as Code (IaC) Merely as a DevOps Scripting Tool: IaC is an enterprise architectural governance mechanism. It ensures that Technology Architecture Building Blocks are instantiated deterministically, auditable via version control, and compliant with architectural policies before deployment.
- Modeling Physical Hardware Without Logical Abstraction: Capturing only physical server serial numbers and rack units in Phase D without defining logical technology nodes and platform services results in fragile models that become obsolete the moment virtual machines migrate or cloud instances scale.
A team designing a new claims system wants to use a database product that the Standards Library classes as a Phasing-Out (Deprecated) standard, because its developers already know it. Following TOGAF's standards lifecycle, how should the architect respond?
Approve it, because developer familiarity reduces delivery risk, and lifecycle status only matters once a standard has been Retired
Reclassify the product as an active Standard for the whole enterprise, since a new project using it shows the standard is still needed
Steer the team to the active Standard, since new use of a Phasing-Out standard is discouraged, and route any justified exception to the Architecture Board
Cancel the project for proposing a non-standard product, because any use of a Phasing-Out standard is an automatic compliance failure
In the TOGAF Standard, 10th Edition, what is the role of the Standards Library within the Architecture Repository?
It holds the standards architectures must conform to: legal and regulatory obligations, industry standards, and organizational standards
It stores the operational server logs, capacity telemetry, and service-level reports that production teams generate after deployment
It records Architecture Board decisions, compliance assessments, standards deviations, and the calendar of projects under review
It holds reusable reference architectures, reference models, templates, and patterns that speed up the creation of new architectures
An enterprise architecture team is designing the Target Technology Architecture for an omnichannel digital banking platform. They specify a 'Distributed Message Broker ABB' that provides publish-subscribe topic semantics, at-least-once delivery guarantees, and horizontal partition scaling, without selecting whether to deploy Apache Kafka, AWS Kinesis, or Azure Event Hubs. What architectural practice does this represent?
An architectural failure, because architects must specify the exact commercial product versions during Phase D for procurement to proceed
A breach of the TOGAF metamodel, which does not permit asynchronous messaging services in financial services technology architectures
Defining a logical Technology Architecture Building Block to set functional and quality requirements before choosing a Solution Building Block
Creating an Architecture Dispensation that lets the team bypass enterprise procurement governance until a vendor product is finally selected in Phase E
Sections you finish are checked off in the contents.