IT Scale and Perspectives

The core challenge in e-engineering architecture is dividing the problem space — identifying the natural boundaries within a complex system and creating a reference model flexible enough to support optimal partitioning across most business domains. This challenge has no single correct answer, because the right partition depends on what the architect needs to reason about at a given stage of the process.

Three approaches to problem space division have proven durable in practice. The first is modularity — breaking complex systems into smaller, independently manageable components, each with a clear purpose and well-defined interfaces to the components around it. The second is domain-driven design (DDD), which identifies core business domains and bounded contexts before any technical implementation begins. DDD aligns the software architecture with business objectives by starting with the business model rather than the technology stack. The third is microservices or service-oriented architecture, which allows each part of the business logic to be developed, deployed, and scaled independently — at the cost of increased complexity in managing service interactions and ensuring interoperability.

Creating a reference model that is flexible enough to serve multiple business domains requires five properties working together. It must abstract common patterns across domains, creating reusable components that can be adapted to different contexts. It must use layered architecture, where each layer — presentation, application, domain, data — can be modified independently without cascading changes through adjacent layers. It must adopt established architectural patterns — MVC for separation of concerns, CQRS for separating read and write operations, event sourcing for audit and temporal queries — that provide proven solutions to recurring design problems. It must be designed for scalability, supporting horizontal scaling, load balancing, and adaptation to new technologies as business strategy evolves. And it must support interoperability through APIs and standard protocols that are not tightly coupled to specific technology choices.

Flexibility introduces its own challenges. As a reference model becomes more general, it gains adaptability but loses prescriptive guidance — a model too abstract does not tell implementers what to actually build. As it becomes more specific, it gains clarity but loses applicability across domains. Additional abstraction layers and inter-service communication introduce performance overhead that must be accounted for in architectural planning. And adopting a reference model that requires teams to think architecturally — rather than just writing code — requires a cultural shift toward more collaborative and iterative ways of working. Strong governance and comprehensive documentation are the mechanisms that maintain the reference model's coherence as the system evolves and teams change.

The IT Architecture Scale is the reference model that reconciles these competing demands. It represents the natural partitions and perspectives of the architectural effort, organized along a single axis that moves from external, environmental concerns at the strategic level to internal, operational concerns at the implementation level.

The directional logic of the scale is fundamental to understanding it: the further left you are on the scale, the higher the level of abstraction and the broader the organizational perspective. The further right, the finer the level of detail and the narrower the implementation focus. Each level addresses a finer grain of architectural structure than the level above it — the zoom-in principle that governs how architectural work progresses from strategy to delivery.

The surrounding frames in the diagram encode two pieces of information about each level: the audience at the top of the frame — the stakeholders who consume the architectural artifacts produced at that level — and the generator or producer at the bottom — the role responsible for creating those artifacts. This dual labeling makes explicit what is often left implicit in architecture work: who the architecture is for, and who is accountable for producing it.

The IT Architecture Scale also reconciles the classic BIT architecture approach — as it evolved from the Zachman and James Martin frameworks introduced in Lesson 8 — with the concepts of perspectives and domains. Perspectives are segments on the scale axis that partition the scope of issues and concerns of the major stakeholders. The scale makes those perspectives explicit, assigns them to specific organizational roles, and connects each perspective to the value it contributes to the business.

1. Global & Partner Ecosystem Architecture (Chief Technology Officer's View)
   This level addresses the coordination and collaboration of business processes that cross enterprise boundaries — between the organization and its trading partners, suppliers, platform providers, and market ecosystems. The primary question at this level is: what drives external partners to participate, and what architectural decisions create or sustain that participation?
   The CTO's concerns at this level include improving connectivity, opening new channels in the marketplace, and ensuring that the organization's architectural choices do not create barriers to ecosystem participation. Modern examples include API gateway security policies that govern partner access, OAuth 2.0 and OIDC for federated identity across organizational boundaries, zero-trust network access (ZTNA) for inter-enterprise communication, and marketplace integration APIs (AWS Marketplace, Shopify Partner API) that define the terms of ecosystem participation.
   Key issue: the impact of business processes that cross enterprise boundaries on partner relationships, data sovereignty, and competitive positioning.
2. Enterprise & Data Mesh Architecture (Principal & Enterprise Architect's View)
   This level addresses intra-enterprise coordination — a single span of control for cross-departmental solutions that ensures consistency across the organization's internal operations. The primary question is: how does the organization improve collaboration and knowledge sharing across departments without creating centralized bottlenecks?
   Data mesh architecture — the distributed approach to data ownership and access that assigns domain teams responsibility for their own data products — is the defining architectural pattern at this level in 2026. ERP platform decisions (SAP S/4HANA, Oracle Fusion Cloud, Microsoft Dynamics 365) remain the anchor of enterprise-level architecture. API management platforms (Kong, Apigee) standardize the interfaces between enterprise systems. Common collaboration platforms (Slack, Microsoft Teams, Google Workspace) provide the shared communication layer that enables cross-departmental coordination without requiring every team to use the same tools.
   Key issue: coordination of system-level decisions to allow graceful transitions as business units evolve, merge, or change tools.
3. Domain & Solution Management Architecture
   This level manages integration complexity within the enterprise, focusing on adaptability and flexibility in the portfolio of applications, data systems, and infrastructure that serve specific business domains. Where the enterprise level defines the standards, the domain level applies them to specific problem spaces — a commerce domain, a logistics domain, a customer data domain — each with its own integration requirements and stakeholder concerns.
   Modern examples include API gateway management for domain-level service exposure, service mesh implementations (Istio, Envoy) for managing service-to-service communication within a domain, and cloud-native observability tooling (Datadog, New Relic) for network and application management.
   Key issue: managing the integration complexity of business processes, applications, data, and infrastructure across domain boundaries without creating tight coupling that prevents independent evolution.
4. Product & Service Application Framework Architecture
   This level addresses the functional suitability of specific applications — the degree to which point solutions meet the business requirements for performance, stability, and quality. The primary concern is mitigating performance overhead while ensuring that each application delivers the functionality stakeholders require.
   Modern examples include identity and access management platforms (Okta, Auth0) for user administration, observability dashboards (Grafana, Datadog) for logs and operational reporting, and application performance monitoring tools that measure whether the application is meeting its SLOs in production.
   Key issue: mitigating performance overhead while maintaining functional suitability — the architect must make explicit trade-offs between capability and cost at the application level.
5. Platform & Component Framework Architecture (Staff Engineer's & Tech Lead's View)
   This level defines the reconfiguration strategies and component frameworks that provide adaptability to the levels above it. Where the application level is concerned with what a system does, the framework level is concerned with how it is structured — the architectural patterns and platform standards that allow applications to be built, modified, and extended without rebuilding from scratch.
   Modern examples replace the legacy CORBA and EJB references entirely. For Java-based systems: Spring Boot, Quarkus, and Micronaut provide the application framework layer. For frontend systems: React, Vue, and Next.js define the component architecture. For infrastructure: Kubernetes operators and Helm charts define the framework for deploying and managing containerized workloads consistently across environments.
   Key issue: developing reconfiguration strategies that leverage component-level architecture to provide adaptability at the application and service levels without requiring full rebuilds.
6. Microservices & Service Level Architecture
   This level represents the individual contributor's view of component grouping — how discrete, independently deployable units of functionality are organized, isolated, and composed into larger systems. The primary concern is isolating lower-level components so that they can be modified and extended without cascading changes through the system.
   Modern examples replace the legacy class library and session bean references with current component patterns: npm packages and Maven artifacts for dependency management, Docker container images for portable deployment units, Kubernetes pods for runtime component isolation, and serverless functions (AWS Lambda, Azure Functions, Google Cloud Functions) for event-driven component execution.
   Key issue: isolation of lower-level solution components to handle future changes — the architect defines the boundaries that allow individual components to evolve without breaking the systems that depend on them.
7. Code & Infrastructure Build-Time Level (Individual Contributor's View)
   This level addresses the definition and management of the lowest-level solution components — the code, configuration, and infrastructure definitions that are the actual deliverables of the development process. The primary concern is delivery consistency — ensuring that what is built in development is what runs in production, every time.
   Modern examples extend beyond programming languages and compilers to the full build and delivery toolchain: Maven and Gradle for Java build management, GitHub Actions and GitLab CI for continuous integration pipelines, Dockerfile for container image definition, Terraform and Pulumi for infrastructure-as-code, and automated testing frameworks that validate each component before it is promoted through the delivery pipeline.
   Key issue: definition and management of lower-level solution components so that delivery is consistent, reproducible, and auditable across all environments.

The IT Architecture Scale succeeds where the BIT cube and layer cake struggled because it makes stakeholder perspective a first-class organizing principle rather than an afterthought. Each level of the scale is defined not just by its technical scope but by who needs to understand it and who is responsible for producing it. This makes the architecture communicable to a broad range of stakeholders — not just the IT department — which is the prerequisite for architecture to function as a coordination mechanism rather than a technical artifact that only specialists can read.

Architecture is now a major factor in the success or failure of an internet-based business venture. The IT Architecture Scale provides the framework for making architectural work visible, attributable, and legible across the full range of organizational roles — from the CTO setting ecosystem strategy to the individual contributor writing infrastructure-as-code. The building blocks of architecture module, which follows this one, introduces the specific approach prescribed by this course for applying the IT Architecture Scale to real e-business engagements.