AWS Cloud Adoption Framework

The AWS Cloud Adoption Framework (CAF) is AWS’s published guidance for planning a cloud transformation: a whitepaper that names the capabilities an organisation needs, groups them by the people responsible for them, and sequences the work. It is a planning aid, not a methodology to be followed literally, and its value is mostly in giving the business, technology and security stakeholders a shared vocabulary for the gaps between them.

The four transformation phases

CAF describes the journey as four iterative and incremental phases.

1. Envision — identify and prioritise transformation opportunities against strategic business objectives, and tie each one to a named senior stakeholder and a measurable business outcome.
2. Align — find the capability gaps across the six perspectives below, surface the cross-organisational dependencies, and bring the stakeholder concerns into the open before they become blockers.
3. Launch — deliver pilots in production. Pilots should be consequential enough that their outcome influences direction, and the learning from them should change the approach before anything is scaled.
4. Scale — expand the successful pilots to full scale and make sure the business benefits that justified the investment are actually realised and sustained.

The order matters less than the iteration. Foundational capabilities do not all have to be in place at once; they are built up as the transformation progresses.

The six perspectives

Each perspective groups the capabilities owned by a particular set of stakeholders. The gap analysis in the Align phase runs across all six.

Business — making the case for cloud investment, aligning cloud outcomes with business goals, and establishing how benefit will be measured once the work is underway.

People — the perspective that decides most migrations. Roles change, career paths and incentives have to change with them, and training has to be planned as work rather than assumed. An organisation that gets the technology right and this wrong stalls after the pilot.

Governance — portfolio and programme management, the project management office’s place in a cloud delivery model, and revising KPIs that were written for on-premises capabilities.

Platform — the technical standards: architecture patterns, the service choices an organisation commits to, and the engineering capability to build and run them.

Security — identity and access management, logging and audit, applying the shared responsibility model in practice, defining who owns which security control, and compliance management.

Operations — monitoring, performance measurement, service level management, business continuity and the disaster recovery approach, adapted to cloud rather than inherited from the data centre.

CAF is not an enterprise architecture framework

CAF is frequently confused with TOGAF, The Open Group Architecture Framework, which is a different thing with a different scope. TOGAF is a general enterprise architecture framework — vendor-neutral, in development since the mid-1990s, and built around the Architecture Development Method, a cycle of phases from architecture vision through to change management. It describes how to run an architecture practice for an entire enterprise; CAF describes how to plan and sequence a move to one cloud provider.

Both are frameworks in the ordinary sense: they provide structure, expect to be adapted to the organisation using them, and fail in the same way when they are not — as a bureaucratic layer that produces documents rather than decisions. Adopting either says nothing about whether an organisation has a working architecture practice.