Cloud Adoption Strategy Template (Microsoft CAF, AWS CAF)
Motivations and outcomes, readiness, operating model, landing zone approach, 7 Rs portfolio, governance, skills, FinOps, roadmap, CAF mappings
Cara menggunakan: Use it when an organisation plans or resets its move to public cloud and needs one decision document for executives and platform teams. Fill the motivations and measurable outcomes with the sponsor first, then the readiness assessment. The main pitfall is promising cost savings with no baseline, owner or date.
Pratinjau
Cloud Adoption Strategy: [Organisation or programme name]
Strategy and plan for adopting public cloud across an organisation: motivations and business outcomes, current state and readiness, the cloud operating model, the landing zone and platform approach, the workload portfolio and its migration and modernisation dispositions (the 7 Rs), governance, security and compliance, skills and organisation, the financial model and FinOps, the roadmap and the risks. Mapping tables link each section to the Microsoft Cloud Adoption Framework for Azure (seven phases: Strategy, Plan, Ready, Adopt, Govern, Secure, Manage, as published in August 2026), the AWS Cloud Adoption Framework (six perspectives, whitepaper of 22 November 2021) and the Google Cloud Adoption Framework (four themes and three maturity phases). Provider-neutral. Replace every
[bracketed]value and every row marked Example.
Document control
| Field | Value |
|---|---|
| Document ID | [CAS-001] |
| Programme | [Cloud adoption programme name] |
| Version | [0.1] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@cloud-programme-lead] |
| Executive sponsor | [@cio-or-cto] |
| Approvers/reviewers | [@cfo-delegate], [@ciso], [@enterprise-architect], [@head-of-operations] |
| Target provider(s) | [Primary provider], [Secondary provider, if any] |
| Estate in scope | [Business units, data centres, number of applications] |
| Planning horizon | [YYYY-MM-DD to YYYY-MM-DD] |
| Classification | [Internal / Confidential] |
| Last updated | YYYY-MM-DD |
| Next review | YYYY-MM-DD |
Approvals
| Role | Name | Decision | Date |
|---|---|---|---|
| Executive sponsor | [@name] | [Approve / Approve with conditions / Reject] | YYYY-MM-DD |
| Finance | [@name] | [Decision] | YYYY-MM-DD |
| Security and risk | [@name] | [Decision] | YYYY-MM-DD |
| Enterprise architecture | [@name] | [Decision] | YYYY-MM-DD |
| Operations | [@name] | [Decision] | YYYY-MM-DD |
Revision history
| Version | Date | Author | Change summary |
|---|---|---|---|
| 0.1 | YYYY-MM-DD | [@name] | First draft for sponsor review |
| 0.2 | YYYY-MM-DD | [@name] | Example: Readiness assessment results and portfolio dispositions added |
| 1.0 | YYYY-MM-DD | [@name] | Example: Approved by the steering committee; funding for year 1 released |
Contents
- Motivations and business outcomes
- Current state and readiness
- Cloud operating model
- Landing zone and platform approach
- Workload portfolio and dispositions
- Governance
- Security and compliance
- Skills and organisation
- Financial model and FinOps
- Roadmap
- Risks and assumptions
- Decisions and traceability
- Framework mappings
- Glossary and references
1. Motivations and business outcomes
1.1 Motivations
State the triggers and motivations that make cloud adoption a priority now. Separate critical business events, which carry a date, from longer-term innovation goals, which carry a value. Rank them, because they drive the sequencing in section 10.
| ID | Motivation | Type | Trigger date | Sponsor |
|---|---|---|---|---|
| MOT-001 (Example) | Exit the leased data centre when the contract ends | Critical business event | YYYY-MM-DD | @cfo |
| MOT-002 (Example) | Shorten time to launch new digital products | Innovation | n/a | @chief-digital-officer |
| MOT-003 (Example) | Meet recovery objectives for tier 1 services | Risk reduction | YYYY-MM-DD | @cro |
| [MOT-NNN] | [Motivation] | [Type] | [Date] | [@owner] |
1.2 Business outcomes and measures
Express each outcome as a measurable change against a baseline. Each outcome needs an owner outside IT where possible, a baseline measured before migration starts and a target date.
| ID | Outcome | Measure | Baseline | Target | Date | Owner |
|---|---|---|---|---|---|---|
| OUT-001 (Example) | Lower infrastructure run cost | Annual infrastructure cost per active customer | [Value] | [Value] | YYYY-MM-DD | @cfo |
| OUT-002 (Example) | Faster delivery | Lead time from commit to production for tier 2 apps | [14 days] | [1 day] | YYYY-MM-DD | @head-of-engineering |
| OUT-003 (Example) | Resilience | Share of tier 1 services with a tested RTO of 1 hour or less | [20 %] | [100 %] | YYYY-MM-DD | @head-of-operations |
| [OUT-NNN] | [Outcome] | [Measure] | [Baseline] | [Target] | YYYY-MM-DD | [@owner] |
1.3 Strategic principles
Write five to eight principles that settle recurring debates before they start. Each one should rule something out.
- Example: Managed services before self-managed software, unless an exception is approved by the architecture board.
- Example: One primary provider; a second provider only for a named regulatory or commercial reason.
- Example: Every workload enters cloud through the landing zone; no accounts, subscriptions or projects outside it.
- Example: Migrate first and modernise after, except where section 5 records a reason to refactor during the move.
- [Principle]
2. Current state and readiness
2.1 Estate summary
| Item | Value | Source |
|---|---|---|
| Data centres and hosting contracts | Example: 2 sites; site A lease ends YYYY-MM-DD | Facilities contracts |
| Applications in scope | Example: 310 applications, 74 business critical | Validated portfolio, section 5 |
| Servers and storage | Example: 2,100 virtual machines, 180 physical hosts, 1.4 PB | Discovery tool export YYYY-MM-DD |
| Existing cloud use | Example: 46 unmanaged accounts and subscriptions, 9 SaaS platforms | Billing records |
| Licences with mobility constraints | [Database, operating system and middleware licences] | Licence register |
| Network connectivity | [Current WAN, internet breakout, existing cloud links] | Network team |
2.2 Readiness assessment
Rate readiness on evidence. Use the same five areas as the operating model so that each gap maps to a workstream.
| Area | Current state | Rating (1 to 5) | Gap | Action ID |
|---|---|---|---|---|
| Business and strategy (Example) | Outcomes agreed for 2 of 5 business units | 2 | No shared business case | ACT-001 |
| People and skills (Example) | 6 certified engineers, no platform team | 2 | Platform engineering capacity | ACT-004 |
| Governance and finance (Example) | No cloud policy, costs not allocated | 1 | Policies, tagging, showback | ACT-006 |
| Platform and operations (Example) | Manual provisioning, on-premises monitoring only | 2 | Landing zone, observability | ACT-002 |
| Security (Example) | Strong identity provider, no cloud security baseline | 3 | Guardrails, logging | ACT-003 |
| [Area] | [State] | [1 to 5] | [Gap] | [ACT-NNN] |
Rating scale: 1 no capability, 2 ad hoc, 3 defined, 4 managed and measured, 5 optimised. Record the date and the people who rated each area, and repeat the assessment at every major roadmap milestone.
2.3 Readiness actions
| ID | Action | Closes gap in | Owner | Due |
|---|---|---|---|---|
| ACT-001 (Example) | Agree outcomes and a shared business case with every business unit in scope | Business and strategy | @cloud-programme-lead | YYYY-MM-DD |
| ACT-002 (Example) | Build the landing zone and central observability | Platform and operations | @platform-lead | YYYY-MM-DD |
| ACT-003 (Example) | Define the cloud security baseline, guardrails and central logging | Security | @security-architect | YYYY-MM-DD |
| ACT-004 (Example) | Form the platform team and start the learning plan in section 8.2 | People and skills | @head-of-engineering | YYYY-MM-DD |
| ACT-005 (Example) | Review licence mobility for databases and middleware (RSK-004) | Platform and operations | @procurement | YYYY-MM-DD |
| ACT-006 (Example) | Publish cloud policies, the tagging standard and monthly showback | Governance and finance | @finops-lead | YYYY-MM-DD |
| [ACT-NNN] | [Action] | [Area] | [@owner] | YYYY-MM-DD |
3. Cloud operating model
3.1 Operating model choice
Choose the model that matches the organisation's appetite for central control versus team autonomy, and say why the alternatives were rejected.
| Model | Description | Chosen | Reason |
|---|---|---|---|
| Centralised operations | A central team builds and runs all cloud resources | [Yes / No] | [Reason] |
| Enterprise platform with workload autonomy | A platform team provides the landing zone and paved roads; workload teams build and run their own services inside guardrails | [Yes / No] | Example: Matches product team structure; keeps policy central |
| Decentralised | Each business unit runs its own cloud estate | [Yes / No] | [Reason] |
| [Hybrid variant] | [Description] | [Yes / No] | [Reason] |
3.2 Responsibilities
| Capability | Cloud centre of excellence | Platform team | Workload team | Security | Finance |
|---|---|---|---|---|---|
| Cloud policy and standards | A | C | I | R | C |
| Landing zone build and run | C | A/R | I | C | I |
| Account, subscription or project vending | I | A/R | R (request) | C | I |
| Workload architecture and operation | C | C | A/R | C | I |
| Security monitoring and response | I | C | R | A | I |
| Budgets, showback and optimisation | C | R | R | I | A |
R responsible, A accountable, C consulted, I informed.
3.3 Interaction model
The diagram shows how policy, guardrails and money flow to the platform team, and how vended environments and feedback flow between the platform and workload teams.
4. Landing zone and platform approach
The landing zone is the governed foundation into which every workload is
deployed: resource hierarchy, identity, network, security baseline,
logging, policy as code and the vending process. Record the strategic
choices here; the full design belongs in the Landing zone design
(architecture/landing-zone-design).
| Decision | Choice | Rationale | Decision ID |
|---|---|---|---|
| Implementation approach (Example) | Provider reference implementation, customised through IaC | Faster start; known upgrade path | DEC-002 |
| Hierarchy pattern (Example) | Separate platform and workload branches, environments split at account, subscription or project level | Clear policy inheritance | DEC-003 |
| Network topology (Example) | Hub and spoke with central egress inspection | Matches inspection requirements | DEC-004 |
| Identity (Example) | Federation from the existing identity provider, no local cloud users | Single joiner, mover and leaver process | DEC-005 |
| Environment vending (Example) | Self-service request through the service portal, automated provisioning in under one day | Supports workload autonomy | DEC-006 |
| [Decision] | [Choice] | [Rationale] | [DEC-NNN] |
List the paved-road platform services the platform team will offer, with the date each becomes available, because the migration waves in section 10 depend on them.
| Service | Description | Available from | Owner |
|---|---|---|---|
| Container platform (Example) | Managed Kubernetes with standard ingress and observability | YYYY-MM-DD | @platform-lead |
| Managed relational database (Example) | Standard configurations with backup and encryption defaults | YYYY-MM-DD | @platform-lead |
| CI/CD templates (Example) | Pipeline templates with policy checks and artefact signing | YYYY-MM-DD | @devex-lead |
| [Service] | [Description] | YYYY-MM-DD | [@owner] |
5. Workload portfolio and dispositions
5.1 Disposition vocabulary (7 Rs)
Use the seven migration strategies described in AWS Prescriptive Guidance. They are provider-neutral in practice; the other frameworks use similar categories under different names.
| Strategy | Meaning in this programme | Typical use |
|---|---|---|
| Retire | Decommission or archive; no cloud target | Low value, duplicate or unused applications |
| Retain | Keep in the source environment for now; revisit at a set date | Regulatory, hardware or dependency constraints |
| Rehost | Move to cloud virtual machines without changing the application | Time-boxed exits, large volumes |
| Relocate | Move at hypervisor or platform level to a cloud version of the same platform | Large virtualised estates with a compatible cloud service |
| Repurchase | Replace with a different product, usually SaaS | Commodity capabilities such as HR or ticketing |
| Replatform | Move with targeted optimisation, such as a managed database | Reduce operational effort without redesign |
| Refactor or re-architect | Redesign to use cloud-native capabilities | Strong business case for agility or scale |
5.2 Portfolio summary
| Disposition | Applications | Share | Notes |
|---|---|---|---|
| Retire (Example) | 42 | 14 % | Confirmed with business owners |
| Retain (Example) | 18 | 6 % | Mainframe and plant systems; review YYYY-MM-DD |
| Rehost (Example) | 121 | 39 % | Mostly in waves 2 to 6 |
| Relocate (Example) | 35 | 11 % | Virtualised cluster in site A |
| Repurchase (Example) | 22 | 7 % | SaaS replacements |
| Replatform (Example) | 52 | 17 % | Database moves to managed services |
| Refactor (Example) | 20 | 6 % | Customer-facing products only |
| Total (Example) | 310 | 100 % |
Record per-application dispositions, scoring and target states in the
Modernization assessment (architecture/modernization-assessment) and
the sequencing in the Migration wave plan (project/migration-wave-plan).
5.3 Cloud-native and new workloads
New products should start in cloud on the paved road. State which patterns are preferred for new builds (for example serverless functions, containers or managed data services), which require an architecture review, and how teams request an exception.
6. Governance
6.1 Governance bodies
| Body | Purpose | Members | Cadence |
|---|---|---|---|
| Steering committee (Example) | Funding, priorities, roadmap changes | Sponsor, finance, business unit heads | Monthly |
| Architecture board (Example) | Standards, exceptions, platform roadmap | Enterprise and platform architects, security | Fortnightly |
| Cloud centre of excellence (Example) | Policy drafting, enablement, metrics | Cross-functional core team | Weekly |
| [Body] | [Purpose] | [Members] | [Cadence] |
6.2 Cloud policies
| ID | Policy statement | Enforcement | Owner |
|---|---|---|---|
| POL-001 (Example) | Resources are deployed only in approved regions | Preventive guardrail at hierarchy root | @security-architect |
| POL-002 (Example) | Every resource carries the mandatory cost tags | Deny on create, weekly compliance report | @finops-lead |
| POL-003 (Example) | Data classified confidential is encrypted with customer-managed keys | Detective control, remediation within 30 days | @ciso |
| [POL-NNN] | [Statement] | [Preventive / Detective / Manual review] | [@owner] |
6.3 Exception process
Describe how a team requests a policy exception, who decides, how long an exception lasts and where it is recorded. Every exception carries an expiry date and a named risk owner.
7. Security and compliance
7.1 Security strategy
Summarise the security approach in a few statements: identity as the
primary control plane, least privilege, encryption by default, central
logging, continuous posture management and incident response that covers
cloud control-plane events. Link to the Security architecture
(security/security-architecture) for the detailed design.
7.2 Shared responsibility
| Layer | Provider responsibility | Our responsibility | Notes |
|---|---|---|---|
| Physical facilities and hardware | Full | None | Provider attestations reviewed annually |
| Virtualisation and managed service runtime | Full for managed services | Configuration | Varies by service model |
| Operating systems on virtual machines | None | Full | Patch baseline applies |
| Identity, access and data | None | Full | Always ours |
| [Layer] | [Provider] | [Ours] | [Notes] |
7.3 Compliance obligations
| ID | Obligation | Source | Impact on design | Owner |
|---|---|---|---|---|
| CMP-001 (Example) | Personal data of EU residents stays in approved regions | Data protection law and contracts | Region policy POL-001 | @dpo |
| CMP-002 (Example) | Payment card data isolated from other workloads | Card industry standard | Dedicated hierarchy branch | @ciso |
| [CMP-NNN] | [Obligation] | [Law, standard or contract] | [Design impact] | [@owner] |
8. Skills and organisation
8.1 Role changes
| Current role | Future role | People affected | Change approach |
|---|---|---|---|
| Server administrator (Example) | Platform engineer or site reliability engineer | 14 | Training path, pairing in waves 1 to 3 |
| Network engineer (Example) | Cloud network engineer | 6 | Certification, landing zone build |
| Database administrator (Example) | Data platform engineer | 5 | Managed database operations training |
| [Role] | [Future role] | [Number] | [Approach] |
8.2 Learning plan
| Audience | Learning objective | Format | Target date | Measure |
|---|---|---|---|---|
| All engineers (Example) | Cloud fundamentals and landing zone usage | Online course and internal workshop | YYYY-MM-DD | 90 % completion |
| Platform team (Example) | Advanced networking, IaC and policy as code | Instructor-led and hands-on labs | YYYY-MM-DD | Professional certification |
| Leaders and finance (Example) | Cloud economics and FinOps | Briefing series | YYYY-MM-DD | Attendance, showback in use |
| [Audience] | [Objective] | [Format] | YYYY-MM-DD | [Measure] |
8.3 Change management
Describe how the programme communicates with staff, how concerns are raised and answered, and how early successes are recognised. Name the change lead and the channels used.
9. Financial model and FinOps
9.1 Business case summary
Summarise the multi-year cost comparison and link to the full TCO
analysis (architecture/tco-analysis). Include dual-running costs
during migration, exit costs and the cost of training and partners.
| Cost element | Year 1 | Year 2 | Year 3 | Notes |
|---|---|---|---|---|
| Cloud consumption (Example) | [Value] | [Value] | [Value] | Grows with waves |
| Dual running on premises (Example) | [Value] | [Value] | [Value] | Falls after site exit |
| Migration services and tools (Example) | [Value] | [Value] | [Value] | Partner and discovery tooling |
| Training and change (Example) | [Value] | [Value] | [Value] | Section 8 |
| Avoided cost (Example) | [Value] | [Value] | [Value] | Hardware refresh and lease |
9.2 Funding and allocation
| Item | Approach |
|---|---|
| Platform costs | Example: Funded centrally for two years, then allocated by consumption share |
| Workload costs | Example: Shown back to business units monthly, charged back from year 2 |
| Commitments and discounts | Example: Bought centrally after three months of stable usage, reviewed quarterly |
| Budget alerts | Example: Alert at 80 % and 100 % of monthly budget per environment |
9.3 FinOps practice
Adopt the FinOps Framework phases (Inform, Optimize, Operate) from the
FinOps Foundation. Name the FinOps lead, the review cadence and the
reports each audience receives. Run recurring reviews with the FinOps
cost review template (ops/finops-cost-review).
10. Roadmap
| Phase | Scope | Exit criteria | Target date |
|---|---|---|---|
| PH-1 Foundation (Example) | Strategy approved, landing zone live, first platform services | Security baseline verified, vending in production | YYYY-MM-DD |
| PH-2 Pilot (Example) | Three low-risk applications | Runbooks proven, rollback tested | YYYY-MM-DD |
| PH-3 Scale migration (Example) | Waves 1 to 6 | Site A empty, contracts closed | YYYY-MM-DD |
| PH-4 Optimise (Example) | Rightsizing, commitments, modernisation | Outcome targets OUT-001 to OUT-003 met | YYYY-MM-DD |
| [PH-N] | [Scope] | [Criteria] | YYYY-MM-DD |
11. Risks and assumptions
| ID | Risk | Likelihood | Impact | Response | Owner |
|---|---|---|---|---|---|
| RSK-001 (Example) | Data centre exit date slips because discovery is incomplete | Medium | High | Funded discovery sprint, weekly dependency review | @migration-lead |
| RSK-002 (Example) | Skills gap slows landing zone delivery | High | Medium | Partner pairing with knowledge transfer milestones | @platform-lead |
| RSK-003 (Example) | Cloud costs exceed forecast during dual running | Medium | High | Budgets, alerts, monthly FinOps review | @finops-lead |
| RSK-004 (Example) | Licence terms prevent moving key databases | Medium | High | Licence review before wave planning | @procurement |
| [RSK-NNN] | [Risk] | [L / M / H] | [L / M / H] | [Response] | [@owner] |
| ID | Assumption | Validated by | Date |
|---|---|---|---|
| ASM-001 (Example) | Network bandwidth to cloud is sufficient for replication of 40 TB per week | Network test | YYYY-MM-DD |
| [ASM-NNN] | [Assumption] | [Method] | YYYY-MM-DD |
Track project-level risks, issues and dependencies in the RAID log
(project/raid-log).
12. Decisions and traceability
| Outcome | Motivation | Decisions | Actions | Roadmap phase | Measure reported in |
|---|---|---|---|---|---|
| OUT-001 (Example) | MOT-001 | DEC-002, DEC-006 | ACT-002, ACT-006 | PH-3, PH-4 | Monthly FinOps report |
| OUT-002 (Example) | MOT-002 | DEC-006 | ACT-004 | PH-2, PH-4 | Engineering metrics dashboard |
| OUT-003 (Example) | MOT-003 | DEC-004 | ACT-003 | PH-3 | DR test reports |
| [OUT-NNN] | [MOT-NNN] | [DEC-NNN] | [ACT-NNN] | [PH-N] | [Report] |
Record significant decisions as architecture decision records using the
ADR template (architecture/adr-full).
13. Framework mappings
13.1 Microsoft Cloud Adoption Framework for Azure
As published on Microsoft Learn (overview updated August 2026), Azure adoption is organised in seven phases. Migrating, modernising and building cloud-native workloads are all covered under Adopt; older material may still show them as separate methodologies. Microsoft also publishes scenarios that build on this foundation, such as AI adoption, AI agents, data platform and sovereignty.
| CAF phase | Key question in CAF | Sections of this document |
|---|---|---|
| Strategy | What should adoption look like? | 1, 9.1 |
| Plan | How will we prepare for adoption? | 2, 5, 8, 10 |
| Ready | How will we build the landing zone? | 4 |
| Adopt | How will we migrate, modernise and build workloads? | 5, 10 |
| Govern | How will we control the environment? | 6, 9.2 |
| Secure | How will we protect the environment? | 7 |
| Manage | How will we operate and optimise over time? | 3, 9.3 |
13.2 AWS Cloud Adoption Framework
The AWS CAF groups foundational capabilities into six perspectives.
| AWS CAF perspective | Focus | Sections of this document |
|---|---|---|
| Business | Cloud investment linked to business outcomes | 1, 9.1 |
| People | Culture, organisation structure, leadership and workforce | 3, 8 |
| Governance | Orchestrating initiatives, maximising benefit, limiting risk | 6, 9.2, 11 |
| Platform | Scalable hybrid platform, modernising workloads, cloud-native builds | 4, 5 |
| Security | Confidentiality, integrity and availability of data and workloads | 7 |
| Operations | Delivering cloud services at the level the business needs | 3, 9.3 |
13.3 Google Cloud Adoption Framework
The Google Cloud Adoption Framework whitepaper assesses maturity across four themes (Learn, Lead, Scale, Secure) and three phases (Tactical, Strategic, Transformational), which together form its Cloud Maturity Scale; workstreams are called epics.
| Theme | Focus | Sections of this document |
|---|---|---|
| Learn | Upskilling staff and using external expertise | 8 |
| Lead | Executive mandate and cross-functional teams | 1, 3, 6 |
| Scale | Managed services and automation that cut manual effort | 4, 5, 9.3 |
| Secure | Protection through identity-centric, layered security | 7 |
Use the three phases as the rating scale in section 2.2 if the organisation prefers the Google maturity language: Tactical (ratings 1 and 2), Strategic (rating 3), Transformational (ratings 4 and 5).
14. Glossary and references
14.1 Glossary
| Term | Meaning |
|---|---|
| Landing zone | Governed, pre-configured cloud foundation into which workloads are deployed |
| Cloud centre of excellence | Cross-functional team that sets cloud standards and enables adoption |
| Paved road | Supported, pre-approved way of building and running a common type of workload |
| Vending | Automated provisioning of a governed account, subscription or project on request |
| Showback / chargeback | Reporting costs to consumers / billing them to consumers |
| 7 Rs | Seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform, refactor |
| Dual running | Period when both source and cloud environments are paid for |
14.2 References
| Reference | Version or date | Use |
|---|---|---|
| Microsoft Cloud Adoption Framework for Azure, learn.microsoft.com/azure/cloud-adoption-framework | Overview updated August 2026 | Phase mapping, section 13.1 |
| An Overview of the AWS Cloud Adoption Framework, AWS whitepaper | 22 November 2021 | Perspective mapping, section 13.2 |
| The Google Cloud Adoption Framework, Google Cloud whitepaper | As published by Google Cloud | Theme mapping, section 13.3 |
| AWS Prescriptive Guidance, Guide for AWS large migrations: About the migration strategies | Current web edition | 7 Rs vocabulary, section 5.1 |
| FinOps Framework, FinOps Foundation | Current web edition | Phases, section 9.3 |
| [Internal policy or standard] | [Version] | [Use] |
Standard and licence note
Structure aligned with the publicly documented phases of the Microsoft Cloud Adoption Framework for Azure, the six perspectives of the AWS Cloud Adoption Framework, the themes and maturity phases of the Google Cloud Adoption Framework, the seven migration strategies described in AWS Prescriptive Guidance and the phases of the FinOps Framework. The framework, phase, perspective and theme names belong to their publishers and are used for mapping only. This template is original text written for this collection and reproduces no text from these sources. Check the current official version of each framework before use; the provider pages are updated frequently. Template licence: MIT.
Templat terkait
Cloud Architecture Review Template (Six Pillars)
Well-architected style review across six pillars: questions, current state, high/medium/none risk, improvement plan, sign-off
ArsitekturArchitecture Decision Record Template (Tyree-Akerman, Y-Statement)
Detailed ADR – Tyree & Akerman fields (assumptions, constraints, positions, argument, implications, related items) plus Y-statement
ArsitekturAPI Versioning and Deprecation Policy Template
API lifecycle policy: versioning scheme, compatibility promises, breaking changes, timelines, Deprecation and Sunset headers