Skip to content
Software Architecture Guide

Technology Architecture

Explanation

Section titled “Explanation”

Technology architecture is the part of enterprise architecture that deals with infrastructure: the hardware, networks and platforms where software runs. The article Enterprise Architecture Layers explains how it sits beside the business, data and application layers.

Why software teams care. Infrastructure influences the system and some of its cross-cutting concepts (rules that apply across the whole system). Architects therefore need to know it. The arc42 deployment view records this infrastructure. From a software view, teams only need to capture the infrastructure elements that matter to them. If the system runs in several environments, document every relevant one.

Constraints. Technical constraints limit design freedom. A team must always deal with them, though some can be negotiated.

Standards and guidelines. Organizations agree on shared standards for technology. AWS guidance calls this platform architecture. It offers blueprints (ready-made patterns) and guardrails for security, networking and logging. Standards should adapt over time as goals and technology change. Standardizing patterns also improves governance and reduces administrative work as the organization grows. That is one way to cut redundancy and cost. Exceptions should be planned and governed.

Hosting choices. Some workloads stay on premises, meaning on hardware the organization runs itself. Reasons include latency, processing needs or data residency (rules about where data is kept). Hybrid architecture combines cloud services with datacenters, edge locations and other clouds. Hosting should follow workload requirements, not the current location of hardware.

Network design. A hybrid setup needs connectivity to the internet, between cloud environments, and between the on-premises network and the cloud.

Cost and lifecycle. Azure guidance advises comparing total cost of ownership for each hosting option. That includes hardware lifecycle, power, cooling, datacenter space and operations, set against cloud consumption costs. Hybrid operations must also account for local hardware lifecycle and update processes.

Regulation. Regulatory, privacy and sovereignty requirements must become concrete architectural requirements. Running a workload locally does not satisfy them by itself.

Ownership. Define who owns the hardware, platform, network and security.

Example

Section titled “Example”

A small company runs an order system. Its deployment view shows a test and a production environment, each with application servers, a database and a network link to a payment provider. The team lists only the elements that affect the software. A company standard says new services use an approved container platform with set logging and network rules. The team compares the cost of keeping its own servers against cloud hosting, including power, cooling and staff time. A legal requirement says customer data must stay in one country, so the team turns that into a concrete rule for where the database may run.

Trade-offs

Section titled “Trade-offs”

Standards lower administrative effort and cost, but they limit choice. Exceptions need a planned, governed process. Keeping workloads on premises can meet latency or residency needs, but it brings hardware lifecycle, update and skills duties for each location. Hybrid setups add network integration work. Cost comparisons must include the full cost of ownership, not only purchase price. Local hosting alone does not guarantee compliance.

Inputs to hosting decisions and where they lead

Diagram source 
flowchart TD
  S[Enterprise standards and guardrails] --> H[Hosting choice: on-premises, cloud, hybrid]
  R[Regulatory and sovereignty requirements] --> H
  C[Total cost of ownership] --> H
  H --> N[Network connectivity]
  H --> D[Deployment view in arc42]

Checks

Section titled “Checks”
  • The deployment view shows the infrastructure elements relevant to the software.
  • Every relevant environment is documented, not just production.
  • Technical constraints are listed, with a note on which may be negotiable.
  • Hosting choices cite workload requirements and compare total cost of ownership.
  • Regulatory and sovereignty requirements appear as concrete architectural requirements, and ownership of hardware, platform, network and security is defined.
Section titled “Related”

Sources

Section titled “Sources”