I Configure Cloud. But I’m Called an Architect

My title says Architect. My work says something else.

I configure cloud services. I set up IAM, networking, scaling, environments.

This is critical work. But is this architecture?

Why Do I Believe I’m an Architect?

There are familiar reasons.

1. I’m certified by cloud vendors

AWS, Azure, GCP — I’ve cleared the exams.

What this actually means:

I understand cloud capabilities and configurations.This is P5 execution capability.

2. I design cloud landscapes

VPCs, subnets, security groups, load balancers.

What this actually means:

I’m defining infrastructure setup.Not system behavior.

3. I work with microservices and APIs

I deploy services, configure gateways, manage scaling.

What this actually means:

I’m enabling execution. Not defining interaction logic across the enterprise.

4. My role is titled “Cloud Architect”

The organization recognizes the responsibility.

What this actually means:

The title reflects scope of delivery. It does not confirm the presence of architecture.

What I Actually Do

Let’s be precise.

• I select cloud services

• I configure IAM and security

• I define environments

• I manage scaling and deployment

• I optimize performance

All of this is essential. But structurally:

This is implementation.

The Structural Distinction

Architecture = Definition + Visualization (P1–P4) Implementation = Execution (P5)

Architecture defines:

• P1 — Strategy: what outcomes the system must achieve

• P2 — Process: how activities are sequenced

• P3 — Systems / Logic: how rules, functions, UI, data, and timing interact

• P4 — Component Specifications: what parts exist

Cloud configuration enables it. It does not define it.

Case Study — Multi-Region Cloud Deployment

A platform is deployed across regions for scale and resilience. What exists:

• Multi-region cloud setup

• Load balancing and failover

• Auto-scaling infrastructure

• Observability and monitoring

From the outside, this is called architecture.

Then a change is introduced - Ensure consistent pricing, eligibility, and approval logic across all regions.

What is missing

• No unified P1 definition of pricing and eligibility strategy

• No consistent P2 sequence across regions

• No traceable P3 interaction between pricing, risk, and approval systems

• No defined P4 component structure

What happens

1. Each region behaves slightly differently

2. Pricing inconsistencies emerge

3. Approval flows diverge

4. Fixes are applied region by region

Measured impact

• Cross-region alignment → 2–3× slower

• Release delays → 20–30%

• Rework across regions → 25–40%

The infrastructure is correct. The system is not architected.

Stage 2–7 — What Actually Failed

Stage 2 — P1 not explicitly defined No clarity on unified business outcomes.

Stage 3 — P2 not modeled Sequences differ across regions.

Stage 4 — P3 not traceable System interactions are not visible end-to-end.

Stage 5 — P4 not defined Components are duplicated or fragmented.

Stage 6 — P5 dominates Cloud configuration becomes the primary activity.

Stage 7 — P6 operates on variation Operations adapt to inconsistency.

Then Where Is the Architect?

If I configure cloud and I’m called an architect…

Who is defining the system?

Because someone still has to define:

• Outcomes across the enterprise

• Sequences across functions

• System logic across interactions

• Structural components

If that role is not visible:

Architecture is not being done.

What Happens When the “Architect” Leaves

If architecture exists (P1–P4 defined),structure remains. If architecture is embedded in cloud configuration:

• Knowledge is tied to environments

• Decisions are tied to individuals

• Dependencies are not explicit

When the person leaves:

There is no architecture to inherit.

Observed impact

• Change analysis → 2–3× slower

• Cross-system change cost → 30–40% higher

• Release delays → 20–30%

• Dependency mapping → shifts from model → meetings

Financial Exposure

When cloud configuration is mistaken for architecture:

• Change cost ↑ 15–30% of IT budget

• Rework ↑ 25–40% of delivery effort

• Multi-region complexity multiplies cost

• Decision cycles extend from hours to weeks

The cost is not in the cloud. The cost is in the absence of structure (Architecture).

The Core Reality

Cloud is powerful. Configuration is essential. But neither replaces architecture.

Diagnostic Note

The problem is not that I configure cloud. The problem is that cloud configuration is being called architecture.

And the simplest test remains:

If your architecture leaves when your architect leaves, it was never architecture. It was memory.