AWS Cloud Adoption Framework: Business Perspective — Strategy, Portfolio, Innovation, Product, Partnership, Insights, and Data Monetization

In a nutshell

Imagine your company is about to add two floors to its building. Before anyone orders a single brick, someone has to answer the business questions: Why are we extending — more staff, or a new shopfront that earns rent? What rooms do we actually need, and in what order? Who signs the cheques, and how will we know, a year later, that the money was well spent? The AWS Cloud Adoption Framework (CAF) Business perspective is exactly that conversation, but for moving to the cloud. It is the part of a cloud programme that decides why you are investing, what outcomes justify the spend, and how you will prove it worked — before a single EC2 instance is launched.

The word “CAF” here means the Cloud Adoption Framework — AWS’s playbook for transforming an organisation, not a firewall or any product you deploy. CAF sorts all the abilities you need into six perspectives (Business, People, Governance, Platform, Security, Operations). This lesson is about the Business perspective: the one owned by the CEO, CFO, COO, CIO, and CTO, and the one that keeps every technical decision tied to a line the finance team recognises. Its job is to make sure you do not end up with a beautifully engineered platform that nobody asked for.

If the other perspectives answer how to build and run the cloud, the Business perspective answers why and what for. It is made of eight capabilities — strategy management, portfolio management, innovation management, product management, strategic partnership, data monetization, business insights, and data science — and getting them right is the difference between “we migrated to save money” (vague, unmeasurable) and “we exit two data centres by FY28 and launch a usage-billed data product to a new segment” (fundable, sequenced, provable).

Level: Beginner-friendly on-ramp → Advanced · Time: ~53 min read

Prerequisites. No AWS console skills are needed — this is strategy, not clicking. It helps to have skimmed the CAF overview lesson so the six perspectives are familiar, and to know roughly what a migration is (moving workloads from your own data centre to AWS). A rough grasp of TCO (total cost of ownership) and what a P&L is will make the money sections land faster, but both are explained here.

After this lesson you will be able to:

• Explain what the CAF Business perspective is, name its eight capabilities, and say who owns them.
• Place the Business perspective inside the full CAF map — six perspectives, four transformation domains, four phases — and describe how it links to People, Governance, Platform, Security, and Operations.
• Assign the 7 Rs to an application estate from discovery data instead of opinion.
• Build a simple cloud business case / TCO and read it with a CFO’s eyes, using the four value sources of the AWS Cloud Value Framework.
• Set a pilot’s graduation rule up front so experiments become products instead of “perpetual pilots.”
• Sequence a data monetization strategy internal-first, external-later, and know which governance guardrails gate the external step.

Where this fits

The AWS Cloud Adoption Framework organizes cloud transformation guidance into six perspectives — Business, People, Governance, Platform, Security, and Operations — each a collection of foundational capabilities owned by a recognizable set of stakeholders. The Business perspective is the one that answers why you are investing in the cloud and what business outcomes justify the spend; its common stakeholders are the CEO, CFO, COO, CIO, and CTO. It comprises eight capabilities, and this article goes deep on seven of them — strategy management, portfolio management, innovation management, product management, strategic partnership, business insights, and data monetization — leaving data science for the analytics-heavy follow-on. The Business perspective is what keeps the other five honest: the People perspective restructures the org to deliver the products Business prioritized, Platform and Operations build and run them, and Governance and Security keep them compliant — but if the Business perspective is weak, you ship a technically immaculate platform that nobody asked for and cannot trace to a P&L line.

The CAF map: perspectives, domains, and phases

Before diving into the eight capabilities, it helps to see the whole board. Beginners often meet the Business perspective as a floating list of buzzwords; it makes far more sense once you can point to where it sits in the framework. AWS CAF is built from three intersecting ideas — what you are transforming, the abilities that make transformation possible, and the journey you take to get there.

What you are transforming — the four transformation domains. AWS says cloud transformation touches four domains. This is the “surface area” of change:

The Business perspective is where you decide how far to push each domain. A pure lift-and-shift touches only Technology; a real transformation deliberately funds Process, Organization, and Product change too — and it is the Business perspective’s strategy and portfolio capabilities that make that call explicit rather than accidental.

The abilities that make it possible — foundational capabilities in six perspectives. AWS’s precise language: each transformation domain is enabled by a set of foundational capabilities. A capability is “an organizational ability to leverage processes to deploy resources to achieve a particular outcome.” There are 47 of these foundational capabilities in total, grouped into six perspectives. So “foundational capabilities” is not a fourth thing you learn separately — it is the umbrella term for all the CAF capabilities, including the eight in this lesson. The six perspectives split cleanly into two halves:

A common exam-style trap: people say “the four foundational perspectives.” There is no such split. There are four transformation domains and six perspectives of foundational capabilities — keep the four (domains) and the six (perspectives) in separate boxes and the framework stops being confusing.

The eight Business-perspective capabilities. This lesson goes deep on seven of them and hands data science to the analytics-heavy follow-on, but here is the full set so the count is honest:

The journey — four phases. CAF describes the transformation as an iterative journey through four phases. You do not do them once; you loop, especially per wave or per product:

Notice how Business shows up in every phase, not just at the start — a point beginners routinely miss. Envision and Align are almost entirely Business/People/Governance work; Launch and Scale are where Platform, Security, and Operations do the heavy lifting against the objectives the Business perspective set. That hand-off is the whole point: the Business perspective writes the contract, and the technical perspectives fulfil it. With that map in hand, the eight capabilities below stop being a list and become a sequence.

Strategy management

What it is. Strategy management is the capability of leveraging the cloud to accelerate your business outcomes — deciding how the cloud supports and shapes long-term business goals rather than treating it as an infrastructure swap. AWS frames it around four moves: support long-term goals, retire technical debt, explore new cloud-enabled value propositions and revenue models, and reach new customers or market segments. Critically, strategy is not a one-time document; you prioritize strategic objectives and evolve them as technology and your business environment change.

Why it matters. Strategy is the root from which the other seven capabilities inherit. Portfolio management prioritizes “in line with strategic intent” — if intent is undefined, prioritization degenerates into whoever shouts loudest. Innovation initiatives are selected “in line with strategic priorities.” Data monetization must be “aligned with your strategic intent.” A vague strategy (“move to the cloud to save money”) under-specifies every downstream decision; a sharp one (“exit two data centers by FY28 and launch a usage-billed data product to a new SMB segment”) tells you exactly how to sequence migration against innovation.

How to do it well. Separate the two engines of cloud value and fund them differently. Cost-out (technical-debt retirement, data-center exit, run-rate reduction) is measured on time-to-vacate and unit-cost reduction. Growth (new value propositions, new segments, new revenue models) is measured on time-to-market and adoption. Conflating them is the classic failure: gating a revenue product behind a two-year lift-and-shift starves it, while judging a migration on “AI features shipped” declares a success a failure. Write the strategy as testable objectives with target dates and owners, and revisit it on a cadence (quarterly is typical) as a living artifact.

Artifacts, decisions, and AWS tooling.

A common, useful starting point is a CAF Assessment workshop facilitated by AWS or an APN partner: it scores each capability’s current vs target maturity and produces an Action Plan that ties strategic objectives to specific capability uplift. The decision that comes out of strategy management is not a Terraform module — it is a funded, time-bound list of objectives every later capability can point to.

Portfolio management

What it is. Portfolio management prioritizes cloud products and initiatives in line with strategic intent, operational efficiency, and your capacity to deliver. It is where strategy becomes a sequenced, evidenced plan: which applications move when, which get modernized, which get retired, and which net-new initiatives get funded — all balanced against resource, financial, and schedule constraints.

Why it matters. This is the capability that operationalizes strategy and most directly drives time-to-value. Two ideas from AWS make it concrete. First, rationalize the existing estate with the 7 Rs — the seven common migration strategies — so every application has a disposition backed by data, not opinion. Second, balance the portfolio across short- and long-term outcomes and low-risk (proven) vs higher-risk (experimental) bets, spanning migration, modernization, and innovation, and weighing both financial (lower cost, higher revenue) and non-financial (customer/employee experience) benefits.

The 7 Rs. Every workload in the estate is assigned one disposition:

How to do it well. Build a data-driven business case before committing budget. AWS Migration Evaluator (formerly TSO Logic) analyzes on-premises utilization and projects a right-sized AWS cost and Quick Wins, while AWS Application Discovery Service and Migration Hub inventory servers and map dependencies so you assign Rs from evidence, not a spreadsheet guess. Resist front-loading only low-risk rehosts — a portfolio that is 100% lift-and-shift never realizes the modernization or innovation value the strategy promised. To compress time-to-value, AWS explicitly recommends increasing planning-cycle frequency or adopting continuous planning rather than an annual big-bang plan.

Artifacts, decisions, and AWS tooling.

The output is a wave plan: prioritized move groups, each with a disposition, a business case, and a target window — the contract between the Business perspective and the Platform/Operations teams who will execute it.

Innovation management

What it is. Innovation management is leveraging the cloud to develop new — and improve existing — processes, products, and experiences. Its premise is that the ability to provision and shut down resources instantly reduces time-to-value and the cost and risk of experimentation, so the rational response is to run more experiments cheaply, not to gate a few expensive ones.

Why it matters. Cloud agility is only realized if you have a mechanism to convert it into shipped change. Without an explicit innovation strategy, the elasticity advantage leaks away — teams still queue ideas behind annual planning and over-provision “just in case.” AWS prescribes a deliberate mix: incremental innovation that optimizes existing products, processes, and experiences, and disruptive innovation that enables new business models. You need both pipelines plus a way to choose between ideas and a way to scale the winners.

How to do it well. Stand up two mechanisms. (1) An idea funnel: solicit and select ideas in line with strategic priorities — many AWS customers adopt the Amazon Working Backwards method, starting each idea as a press release and FAQ (PR/FAQ) so the customer outcome is defined before a line of code. (2) An experiment-to-scale pipeline: an end-to-end process for taking a successful pilot to production. Make experiments genuinely cheap and disposable — separate sandbox accounts via AWS Control Tower Account Factory, hard budget caps via AWS Budgets, and tear-down automation so a failed experiment costs days and dollars, not quarters. Amazon’s own “two-pizza team” and bias-for-action mechanisms exist precisely to keep the cost of trying low.

Artifacts, decisions, and AWS tooling.

The decision that matters here is how a pilot graduates: define the metric, threshold, and owner that promote an experiment into a funded product before you run it — otherwise winners stall in “perpetual pilot.”

Product management

What it is. Product management is managing data- and cloud-enabled offerings that deliver repeatable value to internal and external customers as products through their lifecycles. The shift is organizational: from project teams that disband after a delivery to small, enduring, empowered, cross-functional teams that own a product end to end. AWS lists the moves explicitly — develop a balanced product portfolio aligned to strategy; stand up two-pizza-style teams that champion customer needs; identify product owners; understand customer journeys; define product roadmaps; manage end-to-end lifecycles and value streams; iterate fast on the cloud platform; and reduce inter-team dependencies via well-defined interfaces.

Why it matters. A migration that lands workloads but keeps a project-and-handoff operating model squanders cloud agility — every change still routes through a central queue. Product orientation is what makes “you build it, you run it” real and lets value-stream metrics (lead time, deployment frequency) actually improve. The emphasis on well-defined interfaces between products is not cosmetic: it is how you decouple teams so they ship independently, which on AWS maps cleanly to API contracts and account/VPC boundaries.

How to do it well. Treat internal platform capabilities as products too — a landing zone, a CI/CD paved road, or a data platform each has an owner, a roadmap, and consumers. Give each product team its own AWS account(s) so the blast radius and cost are naturally bounded, and expose capabilities through stable contracts: Amazon API Gateway for synchronous interfaces, Amazon EventBridge for event-driven integration, and AWS Service Catalog to publish self-service products other teams consume. Wire DORA-style metrics from the delivery toolchain (AWS CodePipeline/CodeBuild or third-party CI) so each product’s value stream is measured, not asserted.

Artifacts, decisions, and AWS tooling.

The key decision is the product boundary: drawing it around a customer-meaningful capability (and a value stream) rather than around an existing org chart is what makes the rest of the model work.

Strategic partnership

What it is. Strategic partnership is building or growing your business through a strategic partnership with your cloud provider. It applies when you sell cloud-hosted software, cloud-integrated products, or cloud-related professional/consulting/managed services — i.e., when AWS is not just your supplier but your route to market. The partnership lets you build cloud expertise, promote solutions to AWS customers, and drive successful customer engagements.

Why it matters. For an ISV or services firm, the economics of go-to-market shift materially once you engage the AWS Partner Network (APN): promotional credits and funding lower the cost of building and proving solutions, co-selling puts your offering in front of AWS’s field and customers, and AWS Marketplace becomes a transactable channel with private offers and consumption-based billing that can draw down a customer’s existing AWS commitment. Ignoring this capability means leaving demand-generation and funding on the table that competitors are using.

How to do it well. Treat the partnership as a journey with concrete milestones rather than a logo:

Artifacts, decisions, and AWS tooling. You produce an APN tier/competency plan (which competencies and specializations to pursue and by when), a co-sell motion registered through ACE (opportunity pipeline shared with AWS), a Marketplace listing (public and/or private offers with metering), and joint case studies that highlight specific business challenges solved. The decision is strategic: is AWS a supplier or a channel? If your revenue depends on AWS customers, the partnership is itself a product line that the Business perspective must resource, not an afterthought for the procurement team.

Business insights

What it is. Business insights is the capability to gain real-time insights and answer questions about your business. AWS positions near-real-time descriptive analytics as the part of your data monetization strategy that lets you track business performance, improve decision-making, and optimize operations — the “what is happening now / what just happened” layer beneath predictive data science.

Why it matters. Descriptive insight is where most measurable value is realized first and fastest, and it is the feedback loop for every other Business-perspective capability: it tells you whether a migration wave hit its cost target, whether an innovation pilot is being adopted, and whether a product’s KPIs are moving. AWS is explicit that success here is as much non-technical as technical — visualization and communication matter alongside statistics — and that analytics must be aligned to business goals and KPIs, not produced for its own sake.

How to do it well. Establish cross-functional analytics teams that genuinely understand the business context (not a walled-off BI silo). Use a Data Catalog to locate governed data products, then visualization to find trends and relationships — big picture first, drill down as needed. On AWS this is a recognizable stack: AWS Glue Data Catalog (with AWS Lake Formation governance) to discover and permission data products; Amazon Athena and Amazon Redshift (including Redshift Spectrum/Serverless) to query the lake and warehouse; Amazon QuickSight for dashboards and natural-language Q via QuickSight Q; and Amazon OpenSearch Service or Managed Service for Apache Flink / Amazon Data Firehose when “near real-time” means streaming. Tie each dashboard to a named KPI and an owner.

Artifacts, decisions, and AWS tooling.

The decision is which questions the business must answer in near-real-time — that scoping prevents a sprawling dashboard estate nobody reads and focuses the analytics team on KPIs that drive action.

Data monetization

What it is. Data monetization is leveraging data to obtain measurable business benefit. The cloud makes collecting, storing, and analyzing vast data economical; the capability is turning that into a comprehensive, long-term, strategy-aligned monetization plan. AWS frames the value you pursue in three forms — transactional (understand and complete business transactions), informational (describe past performance, infer conclusions), and analytical (automate activities, guide decisions, predict outcomes) — and gives a clear sequencing rule: monetize data internally first, then consider external monetization (for example, selling data via a marketplace).

Why it matters. Data monetization is the capability that most directly creates new revenue and efficiency, and it is the umbrella under which business insights (descriptive) and data science (predictive/prescriptive) deliver. The internal-before-external rule is a guardrail against the common mistake of building a data-products business before the organization can even act on its own data — and before governance, lineage, and consent are mature enough to externalize anything safely.

How to do it well. Start with internal use cases that compound: AWS cites customer-behavior insights driving hyper-personalization, localization, micro-segmentation, subscriber retention, and loyalty/rewards — measurable on retention, conversion, and operating cost. Treat data as a product with a lakehouse foundation: store in Amazon S3, catalog and govern with AWS Glue and Lake Formation (row/column/cell-level permissions and tag-based access), and query with Athena/Redshift. Adopt a data mesh so domains own and publish data products through governed interfaces, optionally using Amazon DataZone to publish, discover, and subscribe across domains with governance. Only when internal value, governance, and consent are proven do you externalize — packaging governed datasets as AWS Data Exchange products for sale through AWS Marketplace, or exposing them via APIs.

Artifacts, decisions, and AWS tooling.

A decision worth calling out: when you do externalize or share data with partners, AWS Clean Rooms lets you collaborate on combined datasets without either party copying or exposing the raw data — the difference between a compliant data-collaboration revenue stream and a privacy incident.

Building the business case: a worked TCO

Strategy and portfolio management both hinge on a business case, and beginners often think that means “cloud is cheaper, here’s a bill comparison.” It is bigger than that. AWS frames cloud value through the Cloud Value Framework, which has four sources of value — only the first is a pure cost line:

The trap is to build the case on cost savings alone and then be surprised when the CFO asks “is that all?” A mature case quantifies cost, estimates productivity and resilience, and narrates agility with leading indicators. But since the TCO line is the one everyone starts with, let’s work one all the way through.

Step 1 — establish the on-premises run-rate. Add up the fully loaded annual cost of running the estate today, not just the hardware sticker price. Discovery tools (AWS Migration Evaluator, Application Discovery Service) supply utilization data so this is evidence, not a guess. Representative figures for a ~640-instance estate:

Step 2 — project the AWS run-rate after right-sizing. The mistake here is to price like-for-like (“same 16 vCPUs on-prem → same on EC2”). Migration Evaluator’s whole point is that on-prem servers are chronically over-provisioned; you right-size to actual utilization, apply Savings Plans / Reserved Instances for steady workloads, use Graviton where the workload supports arm64, tier storage (S3 Intelligent-Tiering, gp3 over gp2), and fold self-managed software into managed services (so a SQL Server license line disappears into Amazon Aurora):

Step 3 — compute the annual saving. $11.0M − $5.7M = $4.3M/year, a ~39% run-rate reduction. That percentage — not the absolute — is the number to socialize, because it survives changes in scale.

Step 4 — subtract the cost of getting there. A business case that ignores migration cost is fiction. Add the one-time investment, and credit any AWS co-investment (e.g., Migration Acceleration Program funding/credits) and the value of retiring licenses early:

Step 5 — payback and a three-year view. Simple payback = net one-time cost ÷ annual saving = $3.1M ÷ $4.3M ≈ 0.72 years (~9 months) after steady state. A 3-year cash view (assuming a 12-month migration during which savings ramp from ~0 to full):

So the honest story is “we spend $1.3M net in year one and are $7.3M ahead over three years, before counting productivity, resilience, or the revenue from the new data product.” That framing — cost as the floor, the other three value sources as upside — is what turns a nervous CFO into a sponsor.

Step 6 — express it as unit cost. The most durable metric is not total spend but cost per unit of business — cost per order shipped, per active customer, per 1,000 API calls. Total cloud spend rising while unit cost falls is a success (you grew), yet a raw bill-watcher would raise an alarm. Teaching the CFO to read unit cost is one of the highest-leverage things the Business perspective does.

Cloud financial management and stakeholder alignment

Cloud financial management (CFM) is the discipline of managing, optimizing, and planning cloud cost as an ongoing practice — the thing that keeps the business case true after go-live. Strictly, CFM lives in the Governance perspective, but it is the Business perspective’s closest partner: strategy sets the run-rate target, and CFM is how you actually hit and hold it. The industry name for the culture around it is FinOps. It has four recurring motions:

The single highest-leverage move is a mandatory tagging standard enforced from day one (CostCenter, Product, Environment, Owner), because you cannot allocate — and therefore cannot create accountability for — untagged spend. A minimal, illustrative budget guardrail:

// Representative AWS Budgets definition (values are placeholders)
{
  "BudgetName": "supplier-insights-prod-monthly",
  "BudgetLimit": { "Amount": "18000", "Unit": "USD" },
  "TimeUnit": "MONTHLY",
  "BudgetType": "COST",
  "CostFilters": { "TagKeyValue": ["user:Product$SupplierInsights"] }
}

Stakeholder alignment is the other job that decides whether any of this survives contact with the org. The Business perspective’s stakeholders — CEO, CFO, COO, CIO, CTO — do not care about the same things, and a business case that speaks only to one of them stalls. Translate deliberately:

The mechanism AWS gives you to get these five people into one room and agree is the CAF Assessment workshop: it scores each capability’s current-vs-target maturity, surfaces the gaps, and produces a shared Action Plan — an alignment artifact as much as a planning one. This maps directly onto the Align phase from the CAF map above. Alignment is not a soft skill here; it is the deliverable that unblocks funding.

Real-world enterprise scenario

Helios Retail Group is a fictional mid-market omnichannel retailer: ~$2.1B revenue, 480 stores across India and Southeast Asia, an e-commerce site, two on-premises data centers (one lease expiring in 18 months), and roughly 640 application instances. The CIO sponsors a CAF Assessment; the CEO, CFO, COO, and CTO form the steering group. Here is how each Business-perspective capability plays out.

• Strategy management. The steering group writes four objectives: (1) exit the lease-expiring data center within 16 months; (2) cut run-rate 22% via right-sizing and retirement; (3) launch a usage-billed merchandising-insights product for Helios’s CPG suppliers (a new revenue model and segment); (4) lift e-commerce conversion 8% through personalization. Objectives 1–2 are cost-out; 3–4 are growth, funded separately. Artifact: a strategic objectives register with owners and FY targets, reviewed quarterly. AWS Cloud Economics validates the run-rate thesis.
• Portfolio management. Application Discovery Service + Migration Hub inventory the 640 instances; Migration Evaluator produces the business case. Dispositions: 96 Retire (zero-usage), 70 Retain (compliance/recent-spend holds), 300 Rehost to hit the data-center deadline, 90 Replatform (SQL Server → Amazon Aurora PostgreSQL, self-managed Kafka → Amazon MSK), 60 Repurchase (self-hosted HR/ITSM → SaaS), 24 Refactor (the merchandising platform that powers Objective 3). Five migration waves are scheduled. Artifact: a wave plan with 7 Rs and a business case showing a projected 24% run-rate reduction — beating the 22% target.
• Innovation management. A PR/FAQ funnel opens; the supplier-insights idea wins because it maps to Objective 3. Engineering spins up disposable accounts via Control Tower Account Factory with $5,000 AWS Budgets caps, and builds the pilot on Amazon Bedrock + Lambda + Step Functions in six weeks. Graduation rule, set up front: ≥3 paying supplier design partners ⇒ promote to funded product. Artifact: innovation strategy + a graduated pilot.
• Product management. Helios stands up three two-pizza teams: Storefront, Supplier Insights, and an internal Cloud Platform paved-road team. Each gets its own AWS accounts; teams integrate only through Amazon API Gateway and EventBridge contracts, and consume the platform via AWS Service Catalog. Artifact: a product portfolio, ownership model, and interface contracts, with DORA metrics wired from CodePipeline.
• Strategic partnership. Because Supplier Insights is sold to third parties, Helios joins the APN, pursues the Retail Competency and SaaS Factory track, registers the new product as a Marketplace private-offer listing for suppliers, and opens an ACE co-sell pipeline. Artifact: an APN competency plan + Marketplace listing.
• Business insights. A cross-functional analytics squad builds QuickSight dashboards over a Glue-catalogued, Lake Formation–governed lake, querying via Athena and Redshift Serverless. Each dashboard maps to a KPI (conversion, basket size, wave run-rate). Artifact: a KPI tree + governed dashboards, with QuickSight Q for ad-hoc questions.
• Data monetization. Internally first: Amazon Personalize drives storefront recommendations (toward the 8% conversion goal). Externally next: governed merchandising datasets are published as AWS Data Exchange products, and joint analyses with suppliers run in AWS Clean Rooms so raw customer data never leaves Helios. Artifact: a data monetization strategy with internal-then-external sequencing.

Measurable outcome (12 months in): data center exited two months early; run-rate down 24%; e-commerce conversion up 6.4% and climbing; Supplier Insights at 11 paying suppliers generating its first $1.4M ARR — a clean, traceable line from each Business-perspective capability to a number the CFO recognizes.

Deliverables & checklist

• CAF Assessment completed; current vs target maturity scored for each Business capability, with an Action Plan.
• Strategic objectives register — cost-out and growth objectives, owners, target dates, quarterly review cadence.
• Technical-debt inventory and the renewal/refresh costs being avoided.
• Application portfolio with a 7 Rs disposition per workload, backed by discovery data.
• Data-driven business case (Migration Evaluator) and a prioritized, balanced wave plan.
• Innovation strategy (incremental + disruptive) with an idea funnel and a documented pilot-to-production graduation rule.
• Product portfolio, team/ownership model, roadmaps, and inter-product interface contracts.
• APN partnership plan (competencies, ACE co-sell, Marketplace listing) — if you sell on or alongside AWS.
• KPI tree mapped to goals + governed, catalogued data products and self-service dashboards.
• Data monetization strategy with explicit internal-first, external-later sequencing and a governance backbone.

Common pitfalls

• Treating the Business perspective as paperwork. Teams skip it to “start migrating.” Without strategic objectives, the 7 Rs become guesses and the portfolio becomes 100% rehost. Avoid it by making the strategic objectives register a gate the wave plan must reference.
• Conflating cost-out with growth funding. Judging a revenue product on cost savings (or a migration on features) kills good initiatives. Avoid it by funding and measuring the two engines separately from the start.
• Lift-and-shift everything, modernize never. A pure-rehost portfolio realizes none of the agility value the strategy promised. Avoid it by reserving explicit Replatform/Refactor capacity in every wave and protecting an innovation track alongside migration.
• Perpetual pilots. Experiments are cheap to start but never graduate because no one set the threshold to promote them. Avoid it by defining the graduation metric, owner, and funding before the experiment runs.
• Externalizing data too early. Selling data products before internal use, governance, lineage, and consent are mature invites compliance incidents. Avoid it by enforcing AWS’s internal-first rule and using Lake Formation governance and AWS Clean Rooms before any external sharing.
• A BI silo disconnected from the business. Dashboards built without business context go unread and untrusted. Avoid it with cross-functional analytics teams and a strict rule that every dashboard maps to a named KPI and owner.

Going deeper

How a CAF Assessment actually scores. The workshop is not a vibe check. Each capability is rated on a maturity scale (typically five levels, from ad hoc to optimized) for current state and target state, and the gap is weighted by how much the strategy depends on that capability. A retailer chasing a data product will weight data monetization, business insights, and product management heavily; a bank exiting a data centre under a lease deadline weights portfolio management and cloud financial management. The output — the Action Plan — is a prioritized backlog of capability uplifts mapped to the four phases, with owners and dates. Treat the maturity scores as a baseline you re-measure: the point is the slope, not the snapshot.

Which framework, when — CAF vs Well-Architected vs MAP. This is where experienced folks still trip, partly because of a naming collision in this very course. Keep three things separate:

And a footnote that saves confusion: the aws-waf-* lessons in this course are the Well-Architected pillars; AWS WAF (the web application firewall) is a different, unrelated product; and CAF is neither. Three “W/CAF” things, three scopes.

MAP funding mechanics, without the hand-waving. MAP’s Assess phase typically includes a Migration Readiness Assessment (MRA) that scores readiness across the CAF perspectives — so MAP and CAF interlock rather than compete. Mobilize builds the landing zone and skills; Migrate & Modernize executes waves. The AWS investment is usually tied to migrated run-rate/ARR and is milestone-gated, which is exactly why the portfolio’s business case and wave plan have to be credible: the funding follows evidenced migration, not intentions. Beginners assume “AWS pays for migration”; the reality is co-investment proportional to committed, demonstrated movement.

Marketplace and co-sell economics (strategic partnership). When AWS is your channel, three levers change the maths. ACE (APN Customer Engagements) shares pipeline both ways, so AWS field teams can source and co-sell your deals. AWS Marketplace private offers are transacted through the buyer’s AWS account, which means the spend is billed on their existing AWS invoice and can count toward their committed-spend agreements (e.g., an Enterprise Discount Program commitment) — a powerful procurement shortcut that removes a new-vendor onboarding cycle. And SaaS metering lets you bill by consumption. The strategic decision the Business perspective must make explicitly: is AWS a supplier (a cost line) or a channel (a revenue line)? If revenue depends on AWS customers, the partnership is a product line to resource, not a procurement afterthought.

Data monetization’s governance edges. The internal-first rule is a risk control, not a maturity nicety. Externalizing data trips four wires beginners underestimate: lineage (can you prove where a field came from?), consent (did the customer agree to this use?), residency (may the data leave a jurisdiction?), and re-identification (can “anonymized” rows be joined back to a person?). Two AWS services exist precisely for the safe path: AWS Lake Formation for fine-grained (row/column/cell, tag-based) governed access, and AWS Clean Rooms, which lets you and a partner run analysis on the intersection of your datasets without either side copying or seeing the other’s raw rows. The difference between a compliant data-collaboration revenue stream and a privacy incident is often just “did we use Clean Rooms or did we email a CSV.”

Value realization is a multi-year job, not a slide. The Business perspective connects to Governance’s benefits management capability: you baseline projected value in the business case, then track realized value against it for years. The gap between the two — the value leak — usually comes from stalled modernization (100% rehost realizes cost but not agility), perpetual pilots, or untagged spend that no one can allocate. Institutionalize a quarterly value-realization review with the same objectives register you started with; without it, the elegant business case quietly becomes fiction 18 months in.

How Business hands off to the technical perspectives. The wave plan and product model are contracts the technical perspectives fulfil. Product boundaries map to AWS accounts (vended by Control Tower / Organizations) so blast radius and cost are naturally bounded; inter-product interfaces map to API Gateway (sync) and EventBridge (async); guardrails the Governance and Security perspectives set — Service Control Policies, Resource Control Policies, permission boundaries — enforce the very boundaries the product model draws on paper. When someone says “the Business perspective is just strategy documents,” this is the rebuttal: every business decision here has a concrete technical footprint downstream.

Practice challenges

Work these top-to-bottom; they escalate from “name the concept” to “design the strategy.” Try each before opening the solution.

1. (Beginner) Who owns this decision? Your CFO refuses to approve a migration until she sees a payback period and a predictable monthly spend. Which CAF perspective and capability is this request, and which other stakeholders belong in the room?

<details><summary>Solution</summary>

It is the Business perspective, primarily strategy management and portfolio management (the business case), leaning on cloud financial management (which formally lives in the Governance perspective). The room needs the CFO (owner of the money question), plus the CIO/CTO (who own delivery and can commit the run-rate target) and ideally the CEO if growth objectives are in scope. Why: cost questions are Business/Governance, not Platform — pricing an EC2 instance is easy; deciding whether the investment clears a hurdle rate is a business capability.

</details>

2. (Beginner → Intermediate) Assign the 7 Rs. Discovery returns these four apps. Give each one R and a one-line reason: (a) an internal wiki with 3 logins in 90 days; (b) a self-hosted CRM with a commodity SaaS equivalent; © a licensed SQL Server app you must move before the DC lease ends in 5 months; (d) the merchandising engine that powers a new revenue product in your strategy.

<details><summary>Solution</summary>

(a) Retire — near-zero usage; decommission. (b) Repurchase — drop and move to SaaS; a commodity capability is not worth self-hosting. © Rehost (lift-and-shift to EC2) or Replatform (SQL Server → Amazon RDS/Aurora if time allows) — the deadline favours rehost now, optimize later. (d) Refactor — strategic, revenue-bearing app where cloud-native agility/scale justify the cost. Why: each R is a fit-for-purpose disposition backed by evidence, not a ladder where “refactor” is the winner — the deadline and business value decide.

</details>

3. (Intermediate) Do the TCO arithmetic. On-prem run-rate is $8.0M/yr; projected AWS run-rate after right-sizing is $5.6M/yr; net one-time migration cost (after AWS MAP credits) is $1.8M. Compute the annual saving, the % run-rate reduction, and the simple payback period. Name one value source you have not captured.

<details><summary>Solution</summary>

Annual saving = $8.0M − $5.6M = $2.4M/yr. Reduction = 2.4 ÷ 8.0 = 30%. Simple payback = $1.8M ÷ $2.4M = 0.75 yr (~9 months). Uncaptured value: any of staff productivity, operational resilience, or business agility — the three non-cost sources of the Cloud Value Framework. Why: a case built on cost alone understates the real return and gets out-argued by anyone who remembers the other three value sources.

</details>

4. (Intermediate) Write a graduation rule. An innovation pilot (a supplier-insights product) is being built on Bedrock + Lambda in a sandbox account with a $5,000 budget cap. Write a one-sentence rule that promotes it from experiment to funded product, and say who owns the decision.

<details><summary>Solution</summary>

Example: “If ≥3 paying supplier design partners sign by end of the 8-week pilot and projected 12-month ARR ≥ $500K, the Supplier-Insights product owner promotes it to a funded product; otherwise we tear the sandbox down.” The rule names a metric, a threshold, a deadline, an owner, and a kill path. Why: pilots become “perpetual pilots” precisely because no one set the promote/kill threshold before starting — defining it up front is the whole discipline of innovation management.

</details>

5. (Advanced) Sequence a data-monetization strategy. You hold rich customer purchase data and suppliers want insights from it. Lay out the internal-then-external sequence and list the governance gates that must clear before any external step, plus the AWS service that lets you share with suppliers without exposing raw customer rows.

<details><summary>Solution</summary>

Internal first: use the data for personalization/segmentation (e.g., Amazon Personalize) to lift conversion — measurable, low-risk, builds the governed lakehouse (S3 + Glue Catalog + Lake Formation). External only after these gates clear: lineage (provenance of every field), consent (customers agreed to this use), residency (data may lawfully leave the jurisdiction), and re-identification risk assessed. Then share via AWS Clean Rooms, which runs joint analysis on the intersection without either party copying/seeing the other’s raw data; package licensed datasets as AWS Data Exchange products only when governance is proven. Why: AWS’s internal-first rule exists because selling data before governance/consent/lineage are mature is the fast path to a compliance incident.

</details>

6. (Advanced) Supplier or channel? Your firm has built SaaS that runs on AWS and you want AWS customers to buy it. Map your next moves onto the strategic-partnership journey and make the one strategic call this capability forces.

<details><summary>Solution</summary>

Journey moves: validate expertise (pursue a relevant AWS Competency + SaaS Factory track), designate skilled staff (certifications/specializations), co-sell by registering opportunities through ACE, fund build/proof via partner funding, and transact via an AWS Marketplace listing with private offers (billed through the buyer’s AWS account, and able to count toward their committed spend / EDP). The forced call: is AWS a supplier or a channel? Here it is a channel — revenue depends on AWS customers — so the partnership is a resourced product line, not a procurement task. Why: the economics of go-to-market (funding, co-sell pipeline, Marketplace as a transactable channel) only unlock once you treat AWS as a route to market, not just a hosting bill.

</details>

Common beginner mistakes

These are conceptual misunderstandings — distinct from the program-execution traps in Common pitfalls above. Each is a wrong mental model and the right one to replace it with.

• “CAF is a technical/architecture framework.” It is not. CAF is an organization-wide transformation-readiness framework (six perspectives, people and process included). The per-workload technical framework is Well-Architected; the web firewall product is AWS WAF. Three different things — do not blend them.
• “The Business perspective is just the CFO’s cost spreadsheet.” Cost is one of four value sources and one of eight capabilities. Growth, innovation, product, partnership, insights, and monetization are equally the Business perspective. A cost-only reading misses where most of the value (agility, new revenue) actually comes from.
• “There are four foundational perspectives.” No. There are four transformation domains (Technology, Process, Organization, Product) and six perspectives holding 47 foundational capabilities. Mixing up the four and the six is the single most common CAF error.
• “The 7 Rs are a maturity ladder — refactor is the goal.” Each R is a fit-for-purpose disposition. A rehost under a lease deadline, or a repurchase of a commodity app, can be exactly the right, most valuable answer. A portfolio that refactors everything is as wrong as one that rehosts everything.
• “TCO means comparing the AWS bill to my server prices.” Fully-loaded run-rate includes power, cooling, space, licenses, and infra labour — and you must right-size (on-prem is over-provisioned) and subtract one-time migration cost. Like-for-like sizing overstates AWS cost and sinks good cases.
• “You do the Business perspective once, at kick-off.” It recurs in every phase (Envision → Align → Launch → Scale) and every wave, and its value-realization tracking runs for years. Strategy is a living register reviewed on a cadence, not a document you file.
• “Data monetization means selling our data.” Monetize internally first (personalization, segmentation, efficiency); external selling comes later, only after governance, consent, and lineage are mature — and even then often via Clean Rooms rather than raw data transfer.

Glossary

• AWS CAF (Cloud Adoption Framework): AWS’s guidance for transforming an organization to use the cloud effectively — organized as perspectives, capabilities, transformation domains, and phases. Not a product you deploy.
• Perspective: One of the six groupings of CAF capabilities — Business, People, Governance (business-focused) and Platform, Security, Operations (technical-focused).
• Capability / foundational capability: An organizational ability to combine people, process, and technology to achieve an outcome. CAF defines 47 foundational capabilities across the six perspectives.
• Transformation domain: One of the four areas cloud transformation changes — Technology, Process, Organization, Product. Foundational capabilities enable these domains.
• CAF phases: The iterative journey — Envision → Align → Launch → Scale — repeated per program and per wave.
• CAF Assessment / Action Plan: A facilitated workshop scoring each capability’s current-vs-target maturity; its output is a prioritized, owned Action Plan tied to the phases.
• 7 Rs: The migration dispositions — Retire, Retain, Relocate, Rehost, Repurchase, Replatform, Refactor — assigned per workload from discovery evidence.
• TCO (total cost of ownership): The fully-loaded cost of running workloads — hardware, power, space, licenses, and labour — used to compare on-prem run-rate against a projected AWS run-rate.
• Run-rate: The ongoing annual cost of operating the estate (as opposed to one-time migration cost).
• Unit cost: Cost per unit of business (per order, per customer, per 1,000 calls) — the durable metric that can fall even as total spend rises.
• Cloud Value Framework: AWS’s four sources of cloud value — cost savings, staff productivity, operational resilience, business agility.
• Cost-out vs growth: The two engines of cloud value — cost-out (data-center exit, run-rate reduction) measured on time-to-vacate/unit cost; growth (new value, new segments) measured on time-to-market/adoption. Fund and measure them separately.
• Business case: The evidenced argument for the investment — TCO, payback, and the non-cost value sources.
• Migration Evaluator / Application Discovery Service / Migration Hub: AWS discovery tools that supply utilization and dependency data so the 7 Rs and the business case are evidence-based.
• MAP (Migration Acceleration Program): AWS’s funded migration methodology — Assess → Mobilize → Migrate & Modernize — with tooling and milestone-gated co-investment. The MRA (Migration Readiness Assessment) scores readiness in the Assess phase.
• CFM (cloud financial management) / FinOps: The ongoing practice of seeing, saving, planning, and running cloud cost with accountability. Formally a Governance capability; the Business perspective’s closest partner.
• Savings Plans / Reserved Instances: Commitment-based discounts for steady-state usage — a core “Save” lever in CFM.
• Showback / chargeback: Reporting (showback) or billing (chargeback) cloud cost to the team/product that incurred it — powered by cost allocation tags.
• Working Backwards / PR-FAQ: Amazon’s method of starting an idea as a press release + FAQ so the customer outcome is defined before any build — an idea-funnel mechanism for innovation management.
• Two-pizza team: A small, enduring, cross-functional team that owns a product end-to-end (“you build it, you run it”).
• DORA metrics: Delivery performance measures (lead time, deployment frequency, change-fail rate, MTTR) used to gauge a product’s value stream.
• APN / ACE / SaaS Factory: The AWS Partner Network; APN Customer Engagements (co-sell pipeline sharing); and the SaaS Factory program for building multi-tenant SaaS — the strategic-partnership toolkit.
• AWS Marketplace private offer: A negotiated listing transacted through the buyer’s AWS account; can count toward their committed spend (e.g., an EDP — Enterprise Discount Program — commitment).
• Data monetization value types: transactional (complete transactions), informational (describe/infer from past performance), analytical (automate, guide, predict).
• Lakehouse / data mesh: A governed store (e.g., S3 + Glue Data Catalog + Lake Formation) combining lake and warehouse; a data mesh has domains own and publish data products through governed interfaces (optionally via Amazon DataZone).
• AWS Clean Rooms: A service for joint analysis on combined datasets without either party copying or seeing the other’s raw data — the safe path for external data collaboration.
• AWS Data Exchange: A marketplace for publishing/licensing governed data products — the external monetization step, taken only after internal value and governance are proven.
• Benefits management: The Governance-perspective capability that tracks realized value against the business case’s projected value over time; closing the “value leak” is its job.
• RACI: Responsible / Accountable / Consulted / Informed — the alignment grid that assigns each decision an owner across stakeholders and perspectives.

What’s next

Part 3 of this series moves to the People perspective — culture, organization, leadership, and the workforce transformation that staffs and runs the products this phase prioritized.