Cloud Service

Definition

In business architecture, a cloud service is treated as a technology enabler — a specific delivery mechanism through which a business capability is realized, rather than the capability itself. When architects map capabilities to the applications and technology that support them, cloud services (typically categorized as Infrastructure-as-a-Service, Platform-as-a-Service, or Software-as-a-Service) sit in the technology and application architecture layers, providing the 'how it's delivered' behind the business's 'what it does.' A single business capability, such as Customer Onboarding, may be realized through several cloud services working together — a SaaS CRM, a PaaS-hosted workflow engine, and IaaS-based data storage. The defining characteristics of a true cloud service, drawn from widely accepted cloud computing standards, are on-demand self-service, broad network access, resource pooling, rapid elasticity, and measured (pay-for-use) consumption. This distinguishes a cloud service from a merely internet-accessible or hosted application that lacks elasticity or self-service provisioning. For business architects, the important boundary is this: a cloud service is not a capability, a process, or a value stream — it is a sourcing and delivery choice that must be evaluated against the capabilities it supports, the risk it introduces, and the redundancy it may create across the enterprise's technology portfolio.

Origin & Context

The term originates from cloud computing practice and was formalized by the U.S. National Institute of Standards and Technology (NIST SP 800-145), which defined cloud computing's essential characteristics and the IaaS/PaaS/SaaS service models still used industry-wide today. Enterprise and business architecture frameworks such as TOGAF later absorbed this vocabulary into the technology architecture domain, treating cloud services as a sourcing and deployment pattern that architects must reconcile against capability, application, and data architecture.

Why It Matters

CIOs and enterprise architects care about cloud services because sourcing decisions — build in-house, buy a license, or subscribe to a cloud service — directly affect cost structure, shifting spend from capital expenditure to operating expenditure and changing how technology investment is governed. Business architects care because without disciplined capability-to-cloud-service mapping, organizations accumulate redundant subscriptions that quietly inflate technology spend and fragment data. Regulatory and risk leaders care because cloud services introduce data residency, vendor concentration, and third-party risk considerations that must be assessed capability-by-capability, not application-by-application.

Common Misconceptions

Myth: A cloud service and a business capability are essentially the same thing.

Reality: A capability describes a stable business ability — what the organization does — independent of how it is delivered. A cloud service is one possible technology realization of that capability. Conflating the two causes architects to redesign the capability model every time a vendor or platform changes, when only the enabling technology has actually shifted.

Myth: Any application accessed over the internet qualifies as a cloud service.

Reality: A genuine cloud service exhibits specific characteristics — on-demand self-service, elastic scaling, resource pooling, and measured consumption. A legacy application simply hosted remotely and accessed via a browser, without elasticity or self-service provisioning, does not meet this bar and should not be treated as equivalent in risk or cost modeling.

Myth: Adopting cloud services automatically simplifies enterprise architecture.

Reality: Without rigorous capability-to-service mapping, cloud adoption often increases complexity: business units independently subscribe to overlapping SaaS tools, creating redundant capability support, inconsistent data, and expanded vendor risk — a pattern commonly called cloud sprawl.

Practical Example

During a capability rationalization exercise following an acquisition, a business architect at a mid-size insurer mapped both companies' cloud services against a shared capability map. The exercise revealed that Claims Processing was supported by two separate SaaS platforms — one from each legacy organization — alongside a third cloud service used only by a regional office. The architect presented the overlap to the technology steering committee alongside a heat map showing capability criticality and redundancy risk. Leadership used this to decide which cloud service would become the standard going forward, retire the others, and renegotiate vendor contracts. The exercise also surfaced a data residency conflict between two cloud providers that risk and compliance had not previously flagged, prompting an earlier and better-informed review than would have occurred through IT asset tracking alone.

Industry Applications

Financial Services

Mapping cloud services to regulated capabilities (e.g., KYC, transaction monitoring) to assess data residency and third-party risk exposure before vendor approval.

Healthcare

Evaluating SaaS clinical and administrative platforms against capability maps to ensure PHI handling requirements are met and to avoid duplicate patient-data systems across facilities.

Retail

Rationalizing e-commerce and inventory cloud services across brands or regions to eliminate redundant subscriptions and unify the customer data capability.

Related Terms

• Business Capability: the business ability a cloud service technically enables