Many proposals contain a page that says the solution is “aligned to TOGAF, the Cloud Adoption Framework and the Well-Architected Framework”. Sometimes it comes with a diagram of a framework cycle copied from somewhere. It rarely changes a single decision in the rest of the document.
Evaluators who know these frameworks see through that immediately. Evaluators who do not know them learn nothing from it. Either way, the page costs space and credibility.
Used properly, each framework answers a different question, and each can make a proposal genuinely stronger. This part explains what the three frameworks are in plain language, how to use them in a bid, and how to avoid framework theatre: naming a method to look mature without letting it change any work.
As in the rest of the series, we follow Ridgeline Digital’s bid for Rivermark Water’s customer self-service and case management platform. Both organisations are fictional, and all figures are illustrative.
Three frameworks, three different questions
A useful way to keep these frameworks straight is to remember that they work at different altitudes.
TOGAF is a standard for enterprise architecture published by The Open Group. Enterprise architecture is the discipline of describing how an organisation’s business, information, applications and technology fit together, and how to change them in a controlled way. TOGAF’s best-known part is the Architecture Development Method (ADM), a cycle that moves from an architecture vision, through business, data, application and technology architecture, to planning the migration and governing the implementation. Its main question is: how should architecture and change be developed and governed?
A Cloud Adoption Framework (CAF) is guidance from a cloud provider on how an organisation should adopt cloud well. Microsoft, AWS and Google each publish their own. The details differ, but all of them cover much more than moving servers: strategy, organisational readiness and skills, governance, security and ongoing operations. Its main question is: how should cloud strategy, readiness, governance, security and operations be organised?
A Well-Architected Framework (WAF) is guidance, again published by each major provider, for reviewing whether a single workload is built well. A workload is one system or service, such as Rivermark’s case management platform. The review looks at quality areas like reliability, security, cost, performance and operations, and asks where the design is making sensible trade-offs. Its main question is: does this workload make sound quality trade-offs?
An everyday comparison helps. If an organisation were building a new hospital wing, TOGAF would be the master plan for how the whole hospital changes over time. A cloud adoption framework would be the question of whether the hospital has the staff, procedures and management structure to run a modern wing. A well-architected review would be the inspection of the wing itself: fire exits, power backup, running costs.
How each one helps a proposal
| Framework | Main question | Good proposal use | Misuse |
|---|---|---|---|
| TOGAF and the ADM | How should enterprise architecture and transition be developed and governed? | Stakeholders, current and target states, gaps, roadmap and governance | Showing every phase to prove maturity |
| Cloud Adoption Framework | How should cloud strategy, readiness, governance, security and operations be organised? | Exposing organisational and platform adoption work | Treating adoption as infrastructure deployment |
| Well-Architected Framework | Does a workload make sound quality trade-offs? | Reviewing a target and creating a decision and risk backlog | Claiming WAF alignment proves compliance |
The pattern in the right-hand column is the same every time. Misuse means using the framework as a badge. Good use means letting it produce something the client can act on.
TOGAF at Rivermark: frame the change, not the whole enterprise
Rivermark is not asking for an enterprise architecture programme. It wants one bounded capability changed: how customers report faults, raise billing queries and get updates. So Ridgeline uses TOGAF-style thinking in a focused way:
- Current state (the “baseline”). Three channels handled by hand, an ageing ticketing tool, a field-job spreadsheet and a billing system with read-only views.
- Target state. One case record per request, self-service channels, an agent console and a clean connection to billing.
- Gaps. No write access to billing, no customer identity, no end-to-end complaints tracking, no cloud operations capability.
- Roadmap. Three safe stages rather than one leap, covered in detail in Part 9.
- Governance. Who approves each stage and what evidence allows the next one to start.
What Ridgeline does not do is walk the evaluator through every phase of the ADM with a heading for each. That would prove Ridgeline has read TOGAF. It would not help Rivermark decide anything.
A cloud adoption view at Rivermark: expose the work nobody priced
This is where a cloud adoption framework earns its place. During discovery Ridgeline learns that Rivermark’s IT team has never run a production workload in the cloud. The RFP describes the platform as though it is simply software to be installed.
A cloud adoption lens makes the hidden work visible. Before a single customer can report a fault online, someone has to set up governed cloud accounts, connect staff sign-in to the utility’s identity platform, define who can spend what, decide how security monitoring works, and give Rivermark’s own people enough skill to hold the managed service to account.
In the proposal, that becomes a “foundation” work package with a clear outcome and price, plus a skills-transfer plan. It also supports win theme 3 from Part 5: a service Rivermark can run. Treating cloud adoption as “deploy the platform” would have left that work out of the price and landed it on Rivermark after award.
A well-architected review at Rivermark: turn quality into decisions
The well-architected lens is applied to the proposed case management workload itself. Ridgeline’s architects walk through the quality areas and write down each significant trade-off as a decision or a risk.
One example shows how this works. The RFP requires hosting in South Africa. That rules out recovering the service in a region on another continent. So Ridgeline proposes running across two availability zones, which are separate data centres within one South African region, and states the recovery targets plainly: restore service within four hours after a major failure, and lose no more than 15 minutes of case updates. Those two targets have names that are worth knowing. The recovery time objective (RTO) is how long the service may be down. The recovery point objective (RPO) is how much recent data may be lost. Recovery copies stay inside South Africa too. That means less geographic separation than a second region abroad would give, and the review does not hide it: the reduced separation is written down as a trade-off that Rivermark accepts because of the hosting requirement.
The review also produces backlog items that would otherwise be discovered in production. If the billing views are unavailable, the portal shows the last known balance with the time it was read, and queues the customer’s query, rather than showing a wrong figure. If messaging costs spike during a storm week, an alert fires before the monthly bill does.
Crucially, the proposal does not claim that following a well-architected framework makes the service compliant with POPIA or anything else. A WAF review is a quality check on design decisions. Compliance is a separate question with its own evidence.
None of them replaces the real work
One point is worth stating in full: TOGAF can frame the change, CAF can organise the platform and operating capability, and WAF can test workload quality, but none of them replaces requirements engineering, detailed design, security assurance, delivery planning or client approval.
Frameworks give structure to thinking. They do not do the thinking. A proposal that names all three but has no traceability matrix, no estimate that matches the architecture and no named owner after launch has simply decorated its gaps.
Tailoring is competence
The right amount of framework depends on the size and risk of the change. Doing less on a small engagement is not a shortcut. It is judgement.
- A proof of concept may need only a context view, the experiment being run and a list of risks.
- Rivermark’s platform bid needs current and target states, gaps, a transition roadmap, a cloud readiness plan, a workload review and work packages tied to each stage.
- A regulated transformation at a bank may need formal baselines, target and transition states, governance, standards, work packages and recorded architecture decisions that a regulator could inspect.
An evaluator reading a proof-of-concept proposal stuffed with formal governance artefacts will worry about cost and speed. An evaluator reading a bank transformation proposal with nothing but a context view will worry about control. Matching the artefacts to the bid is itself evidence that the team knows what it is doing.
How to write about frameworks in the proposal
A few practical habits keep the frameworks honest:
- Name the output, not the framework. “A transition roadmap with three approval gates” is more useful than “TOGAF-aligned”.
- Show one consequence. For each framework mentioned, point to at least one decision, work package or risk it produced.
- Use the client’s language first. Rivermark’s evaluators talk about faults, queries and complaints, not ADM phases.
- Keep the method in the appendix. If the RFP asks about methodology, answer it there, briefly, and cross-reference the results in the main body.
References
Checked on 11 September 2026:
- TOGAF Standard, 10th Edition
- Microsoft Cloud Adoption Framework
- AWS Cloud Adoption Framework
- Google Cloud Adoption Framework
- AWS Well-Architected Framework
- Azure Well-Architected Framework
- Google Cloud Well-Architected Framework
What to take from this part
Each framework answers a different question. TOGAF frames the change, a cloud adoption framework exposes the organisational foundation, and a well-architected review tests one workload.
A framework only counts if it changes something. Point to the decision, work package or risk it produced.
WAF alignment is not compliance. It is a quality review of design trade-offs, nothing more.
Tailoring is a sign of competence. Match the artefacts to the size and risk of the bid.
Next in the series: One diagram cannot answer every question: architecture layers and views.
How CloudNala can help
We help bid and architecture teams decide which framework outputs a particular pursuit genuinely needs, and then produce them quickly: a focused current and target view, a cloud readiness assessment that surfaces unpriced foundation work, or a well-architected review that turns into a decision and risk backlog the proposal can reference.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a Bid Review or write to us at consult@cloudnala.co.za