Cloud Computing

Definition

In business architecture terms, cloud computing is best understood not as a technology stack but as a delivery and consumption model that reshapes how capabilities get enabled. Rather than an organization building and running its own data centers, it rents computing power, storage, networking, and software from a provider (such as AWS, Microsoft Azure, or Google Cloud) and pays based on consumption. This shift moves IT spending from a capital expense to an operating expense and changes the questions architects must ask—not 'do we have enough servers?' but 'which capabilities need elastic scale, and which vendor relationship best supports our operating model?' Cloud computing is typically described through three service models—Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS)—and three deployment models—public, private, and hybrid cloud. Each combination carries different implications for capability ownership, data governance, and vendor dependency. A business architect's job is not to select the technology (that's the domain of the technical architect) but to determine which business capabilities are candidates for cloud enablement, what constraints apply (regulatory, latency, data residency), and how the operating model must adapt to a world where technology enablers are rented rather than owned. It's important to draw a boundary here: cloud computing is an enabling technology pattern, not a business capability itself. 'Cloud Migration' is a program; 'IT Infrastructure Provisioning' is a capability that cloud computing enables. Conflating the two is a common source of confusion in capability maps, where architects mistakenly model 'Cloud Computing' as a capability rather than recognizing it as one possible realization option for capabilities like Compute Management or Data Storage.

Origin & Context

The term traces its modern usage to the mid-2000s, popularized as vendors like Amazon (with Amazon Web Services, launched in 2006) began offering computing resources as a metered, on-demand utility. The concept itself draws on older ideas of utility computing and time-sharing from the 1960s. Within enterprise and business architecture practice, cloud computing became a formal consideration in frameworks like TOGAF's Technology Architecture domain and is treated in BIZBOK as a technology enabler that must be cross-mapped to capabilities rather than modeled as one.

Why It Matters

CIOs and CTOs care because cloud adoption directly affects capital allocation, vendor risk exposure, and the organization's ability to scale capabilities quickly during growth or contraction. Business architects care because cloud decisions ripple into the operating model—shared services, sourcing strategy, and capability ownership all shift when infrastructure becomes a rented service. Getting the capability-to-cloud mapping wrong leads to redundant cloud spend, shadow IT proliferation, and compliance exposure when data residency requirements aren't respected. Done well, cloud-enabled capability planning lets organizations reallocate technology investment toward differentiating capabilities instead of commodity infrastructure maintenance.

Common Misconceptions

Myth: Cloud computing is always cheaper than running your own data center.

Reality: Cloud economics depend heavily on workload patterns. Steady, predictable workloads often run more cheaply on owned infrastructure, while variable or bursty workloads benefit from cloud elasticity. Architects should model total cost of ownership against actual capability demand patterns rather than assuming cloud is a default cost-saver.

Myth: Cloud computing is a business capability that belongs on a capability map.

Reality: Cloud is a technology enablement pattern, not a capability. It should appear in cross-mappings—linking capabilities to the technologies that realize them—not as a node in the capability hierarchy itself. Treating it as a capability inflates the map with implementation detail and obscures what the business actually does.

Myth: Moving to the cloud automatically modernizes the business.

Reality: A 'lift and shift' migration moves existing applications onto cloud infrastructure without changing underlying processes or capability design. Real transformation requires re-architecting capabilities to exploit cloud-native patterns—otherwise the organization simply relocates its technical debt to a rented environment.

Practical Example

A regional insurer's business architecture team was asked to support a cloud migration business case. Rather than starting with infrastructure inventory, the lead business architect built a capability heat map showing which capabilities—Claims Intake, Policy Underwriting, Customer Self-Service—had the highest volatility in demand and the greatest need for rapid scaling during catastrophe events. Working with the enterprise architect, they cross-mapped these capabilities to candidate cloud service models, flagging Policy Underwriting as a poor early candidate due to regulatory data residency constraints, while prioritizing Customer Self-Service for SaaS enablement. This capability-led sequencing gave the CIO a defensible, business-outcome-driven migration roadmap instead of a generic 'move everything to the cloud' mandate, and it surfaced compliance risks before contracts were signed rather than after.

Industry Applications

Financial Services

Banks use hybrid cloud models to keep regulated core banking and payments capabilities on private infrastructure while moving customer engagement and analytics capabilities to public cloud for faster innovation cycles.

Healthcare

Providers map capabilities like Patient Records Management against data residency and HIPAA-related constraints before selecting cloud deployment models, often landing on private or hybrid cloud for sensitive clinical data.

Retail

Retailers lean on public cloud elasticity to support Demand Forecasting and E-Commerce Fulfillment capabilities during seasonal peaks, avoiding the cost of owning infrastructure sized for holiday traffic year-round.

Related Terms

• Business Capability: the unit of analysis that cloud computing enables but must never be confused with