1
Raw Cloud Services
Provider capabilities are ingredients: useful machinery, but not yet a developer product.
ComputeNetworkStorageDatabaseKubernetesDNSMessagingIdentity
GOVERNED PRODUCT HIERARCHY · OPERATING MODEL
Productize the building blocks
before composing the outcome.
Infrastructure-as-a-Product does not jump from raw cloud APIs straight to a developer portal. Each cloud capability first becomes a governed service product with a stable contract, minimum security baseline, bounded configuration, entitlements, evidence and lifecycle. Composite products are then assembled from those governed building blocks.
THE MISSING MIDDLE LAYER
Raw service. Governed product. Composite outcome.
No raw cloud service should become a developer dependency until the platform has productized the service boundary around it.
↓
2
Governed Service Products
Each service receives a consumer contract and an approved operating envelope.
Network ProductObject Storage ProductDatabase ProductKubernetes ProductDNS ProductIdentity ProductLogging ProductMessaging Product
MINIMUM SECURITY BASELINEAPPROVED PATTERNSENTITLEMENTSEVIDENCELIFECYCLEEXCEPTION RULES
↓
3
Composite Infrastructure Products
End-to-end environments are composed from governed service products, not rebuilt directly from raw provider primitives.
Cloud Foundation EnvironmentApplication Platform EnvironmentData Platform EnvironmentManaged Interconnect
↓
4
Developer Outcomes
Application, data and platform teams receive ready-to-use governed outcomes rather than ingredients.
Secure by product definition.
Governed by contract. Validated by evidence.
Minimum security is not an optional checkbox. It is part of what the product is.
GOVERNANCE, RISK & SECURITY
Define what must remain true.
Governance and Security participate before a service enters the catalog. They own policy intent and minimum control requirements, not provider implementation code.
PRODUCT ENGINEERING
Turn requirements into a product contract.
Platform Engineering translates approved governance requirements into schemas, service-product contracts, compositions, deterministic rules and lifecycle behavior. Security says what must be true; the platform makes it true by construction.
Remove unsafe choices
Developers choose only within the approved envelope. Encryption, logging and mandatory controls are not optional consumer decisions.
Encode the baseline
Provider-specific resources and policy mechanisms implement the approved service-product profile behind the stable contract.
Prove it remains true
Guard checks architecture, policy, security, entitlement and evidence conditions before governed change proceeds.
Compose without weakening
Higher-order products inherit the constraints of their governed service products rather than silently dropping them.
HOW A TEAM USES THE PORTFOLIO
From bounded request to governed infrastructure outcome.
The products participate at different boundaries. Human authorization remains explicit rather than being hidden inside an application.
Storefront
The team browses approved products and supplies bounded intent instead of raw cloud configuration.
Entitlements & Guardrails
Allowed products, quotas, sizes, budget boundaries, security baselines and policy requirements constrain the request.
Guard
Deterministic architecture, security, policy and evidence rules verify the proposed change.
Console + Human
Verified evidence and exception context are presented to authorized reviewers where a decision is required.
Forge + Assurance
Governed products are composed while accepted evidence, authority, scope and safeguards remain bound to the action.
Crossplane
Only authorized product state reaches the control plane for continuous reconciliation through replaceable providers.
Entitlements prevent self-service from becoming runaway infrastructure.
Self-service stays bounded by product eligibility, approved sizes, quotas, spending limits, environment TTLs and accountable business ownership. Commercial entitlement permits use of the software; infrastructure entitlement constrains what a team is allowed to consume. Neither is production authorization.
TEAM RESPONSIBILITIES
A product operating model, not a portal project.
Own security intent
Define minimum baselines, prohibited states, conditional controls, evidence requirements and exception criteria. Security does not need to manually approve every compliant instance.
Encode and operate
Build the governed service products, compositions, provider mappings, reconciliation behavior and operational lifecycle.
Govern patterns
Define approved patterns, regulatory mappings, control inheritance and material-change boundaries.
Bound consumption
Define quotas, size classes, budget limits, consumption policies, ownership and cost evidence.
Own the customer outcome
Define supported outcomes, product options, lifecycle, adoption and the experience teams use to consume the platform.
Provide bounded intent
Choose approved products and supported options. They do not rebuild security, networking or provider topology for every application.
Define operability
Contribute observability, reliability, service limits, incident expectations and operational evidence to service-product definitions.
Decide exceptions
Human review focuses on deviations, material changes and exceptional risk rather than routinely reapproving already-governed products.
Governed Product Inheritance
A composite infrastructure product inherits the security, governance, evidence, entitlement and lifecycle constraints of the governed service products from which it is composed. Composition may add tighter controls; it must not silently weaken inherited ones.
OPERATING PRINCIPLE
Review the product once. Automate compliant consumption. Escalate exceptions.
This is what lets governance scale. Security and governance invest in defining and approving reusable service-product boundaries; ordinary consumption stays automated inside those boundaries, while exceptions and material changes return to authorized human review.