Area of expertise
Cloud architecture
Cloud architecture does not deteriorate through debt alone. It becomes fragile when dependencies, exit costs, and ownership are no longer visible in decisions.
Operational definition
Cloud architecture arranges capabilities, flows, data, and ownership against explicit availability, security, cost, and reversibility constraints.
Problems actually encountered
-
01
Target defined by provider services rather than business constraints
-
02
Critical dependencies unknown before migration
-
03
Availability stated without failure-mode analysis
-
04
Operating and exit costs missing from trade-offs
Decisions involved
- Choose a topology and its responsibility boundaries
- Balance managed services, portability, and operating load
- Define acceptance and reversibility criteria
Common errors
- Copying a reference architecture without testing its assumptions
- Confusing high availability with disaster recovery
- Deferring identity, data, and cost governance until after migration
Signals that external expertise becomes useful
- A decision commits several years or teams
- Options are compared against different criteria
- An incident exposes a dependency owned by nobody
Omnivya method
-
1.
Frame the decision, constraints, and assumptions
-
2.
Map flows, dependencies, and ownership
-
3.
Test options against failure, cost, and change scenarios
-
4.
Document the trade-off and review conditions
Possible deliverables
- Architecture and dependency map
- Options matrix with weighted criteria
- Decision record and residual risks
Evidence of reasoning
- Decisions tied to verifiable constraints
- Explicit failure scenarios and acceptance criteria
- Residual risks separated from treated risks
Explicit limits
- No provider imposed without comparative analysis
- No availability promise the organisation cannot operate
- No long-term replacement of the architecture team
Related mission formats
- Architecture review
Have an architecture decision reviewed before it becomes irreversible.
- Trajectory framing
Write the possible trajectory after a diagnosis, without forcing delivery.
- Point support for a CTO decision
Short support for one precise CTO decision, with written assumptions and limits.
Frequently asked questions
- Do you work before or after cloud selection?
- Both. Before selection, we compare options. Afterwards, we check whether the target still matches actual constraints.
- Does a review require rearchitecture?
- No. It may confirm the target, call for a bounded correction, or recommend delaying an under-informed decision.
- Can you review an already documented architecture?
- Yes, provided we can access its assumptions, operating constraints, and accountable people.
Have an architecture decision reviewed
If this tension is yours, let’s frame the decision before widening the scope.