3.3 Physical View

Minimum 4+1 Physical TOGAF Technology

Purpose

The Physical View describes all infrastructure that hosts and supports the solution — whether physical hardware, virtual machines, containers, serverless functions, or cloud-managed services. It addresses the concerns of infrastructure engineers, DevOps teams, platform engineers, and cloud architects.

Why 'Physical View'?

The name “Physical View” is retained for alignment with Kruchten’s 4+1 Architectural View Model, where it originally described the mapping of software to hardware. In modern practice, this view encompasses all deployment infrastructure regardless of abstraction level — from bare-metal servers to fully managed cloud services. It is equivalent to the Technology Architecture domain in TOGAF and the Deployment View in some other frameworks.

3.3.1 Deployment Architecture Diagram

Minimum

Provide a diagram showing the infrastructure that drives the solution.

[Insert deployment architecture diagram]

Guidance

Show: physical/virtual servers, containers, cloud services, storage, networks, firewalls, load balancers, Internet gateways, SaaS platforms, and any other infrastructure components. Include cloud regions, availability zones, and VPCs where applicable.

3.3.2 Hosting & Infrastructure

Minimum

Hosting Venues

Minimum

Attribute	Selection
Hosting Venue Type	Cloud / SaaS / On-Premises / Hybrid / Outsourced
Hosting Region(s)	[e.g., UK, EU, US, Asia, Other]
Service Model	IaaS / PaaS / SaaS / FaaS / Other
Cloud Provider	AWS / Azure / GCP / Other / N/A
Account / Subscription Type	[organisation-specific account type]

Compute

Recommended

Servers (Physical / Virtual)

Instance Name	Instance Type	vCPU	Memory (GB)	Storage	Quantity	OS
[name]	[type/size]	[n]	[n]	[n TB]	[n]	[OS version]

Containers

Attribute	Detail
Container Platform	EKS (AWS) / AKS (Azure) / GKE (GCP) / Docker / Kubernetes / Other
Base Image(s)	[e.g., Alpine, Node, NGINX]
Cluster Size	[number of nodes]

Serverless

Attribute	Detail
Serverless Services	[e.g., AWS Lambda, Azure Functions]
Function Details	[description of serverless components]

High Performance Computing

If the solution uses specialised compute:

Attribute	Detail
HPC Requirements	[e.g., GPU, FPGA, specialised compute]

Artificial Intelligence / Machine Learning

If the solution includes AI or machine learning components:

Attribute	Detail
AI/ML Components	[training and inference infrastructure]

Security Agents

Recommended

Document security software deployed on compute resources. This is captured in the Physical View because agents are infrastructure-level components, even though they serve a security function.

Document security agents deployed on compute resources:

• Anti-Malware
• Endpoint Detection and Response (EDR)
• Vulnerability Management
• Other: […]

3.3.3 Network Topology & Connectivity

Minimum

Connectivity Summary

Question	Response
Is this an Internet-facing application?	Yes / No - [details]
Outbound Internet connectivity required?	Yes / No - [details]
Cloud-to-on-premises connectivity required?	Yes / No - [details]
Wireless networking required?	Yes / No - [details]
Third-party / co-location connectivity required?	Yes / No - [details]
Cloud network peering required?	Yes / No - [details]

User & Administrator Access

Recommended

Document how users and administrators connect to the solution, including access methods, protocols, and network connectivity.

Attribute	Selection
User access method	Web (HTTPS) / VDI / RDP / Citrix / Mobile App / API / Other
User locations	[e.g., UK offices, Remote (VPN), Global, End-customers (Internet)]
Administrator access method	VDI / RDP / SSH / HTTPS / Bastion Host / Other
VPN required	Yes / No
Direct Connect / ExpressRoute	Yes / No

Transport Protocols

Recommended

Documenting transport protocols helps security and network teams verify that all communication paths use appropriate encryption and authentication.

Protocol	Used?	Purpose
HTTPS (TLS 1.2+)	Yes / No	[…]
SFTP	Yes / No	[…]
ODBC / JDBC	Yes / No	[…]
TCP (other)	Yes / No	[…]
gRPC	Yes / No	[…]
WebSocket	Yes / No	[…]
Other	Yes / No	[…]

Network Bandwidth

Recommended

Bandwidth requirements inform infrastructure sizing and cost estimation. Underestimating can cause performance issues; overestimating wastes budget.

Metric	Value
Peak egress bandwidth to Internet	[Mb/s]
Peak ingress bandwidth from Internet	[Mb/s]
Peak bandwidth between on-prem and cloud	[Mb/s]
Traffic characteristics	[constant / burst / periodic]
QoS requirements	[details]
Network performance expectations	[latency, jitter, etc.]

Internet Perimeter Protection

Recommended

Control	Implemented	Detail
DDoS Protection	Yes / No	[service used]
Rate Limiting	Yes / No	[details]
Source IP Restrictions	Yes / No	[IP allowlist, geo-blocking]
Web Application Firewall (WAF)	Yes / No	[product]
Client Verification Controls	Yes / No	[details]
File Upload Protection	Yes / No	[malware scanning approach]

3.3.4 Environments

Recommended

Environment	Description	Count & Venue	Compute Solution
Development	Software development only	[…]	[…]
Test / QA	Component and integration testing	[…]	[…]
Staging / Pre-Production	Production-like environment for validation	[…]	[…]
Production	Live service environment	[…]	[…]
DR	Disaster recovery environment	[…]	[…]

Connectivity Between Environments

Does the solution require connectivity between environment tiers (e.g., production to non-production)?

• Yes - [describe which components and data flows]
• No

3.3.5 End User Compute & IoT

Comprehensive

End User Compute

Document any end-user device requirements (VDI, BYOD, mobile, desktop software):

[…]

IoT Devices

Document any IoT devices (printers, scanners, cameras, sensors, etc.):

[…]

3.3.6 Sustainability Considerations

Recommended

The Physical View is where most carbon-impact decisions are made. Document the sustainability stance for the infrastructure choices above — full detail belongs in Section 4.5, but capture the headline decisions here.

Question	Response
Have hosting regions been chosen for low carbon intensity (e.g., regions with high renewable energy)?	Yes / No — [which regions and why]
Are non-production environments configured to auto-shutdown out of hours?	Yes / No — [schedule]
Has the compute family been chosen for performance-per-watt (e.g., ARM/Graviton, latest-generation)?	Yes / No — [details]
Is auto-scaling configured to release capacity when idle?	Yes / No — [trigger thresholds]
Is the DR strategy proportionate (cold standby vs warm vs hot) to the actual recovery objective?	[describe and rationale]

Why this matters

Always-on production at peak-sized infrastructure 24×7 is the most common sustainability anti-pattern. Three decisions in this view dominate carbon footprint: region selection (carbon intensity varies 5-10× across cloud regions), non-production auto-shutdown (typically 60-70% saving on dev/test compute), and right-sizing (over-provisioned VMs waste energy regardless of load).

Scoring Guidance

Score	What This Looks Like
1	Hosting venue identified but infrastructure not specified
3	Deployment diagram complete, compute sized, networking documented, environments listed
5	All of the above plus connectivity protocols specified, user/admin access methods documented, security agents listed, bandwidth and latency requirements quantified, sustainability decisions captured

Quality Attribute Cross-References:

• 4.2 Reliability - Infrastructure design directly determines availability and recovery capability
• 4.3 Performance - Compute sizing and network design affect performance
• 4.4 Cost - Infrastructure choices are the primary cost driver
• 4.5 Sustainability - Hosting venue and compute efficiency affect environmental impact