How we think
We don't start with technology.
We don't begin with “What technology should we use?” We begin with “What problem are we actually trying to solve?” Then we work through the questions below, in roughly this order.
- What do we know?
- What are we assuming?
- What don't we know?
- What is the business value?
- What constraints exist?
- What options are available?
- What does each option cost?
- What are the trade-offs?
- How reversible is the decision?
- What architecture best fits the problem?
- Why are we making this decision?
Methodology
The Desha Value-First Method™
Seven stages. The order matters: architecture comes fifth, after we know what the problem is, which beliefs are load-bearing, and what solving it is worth.
Stage 01 of 07
Understand
Before any option is on the table, we build a picture of what exists and what is being attempted.
- Business objective
- Product
- Users
- Current process
- Current architecture
- Technology
- Data
- Integrations
- People
- Constraints
- Previous attempts
Stage 03
The Desha Evidence Ladder
Most bad technology decisions are not made on bad information. They are made on assumptions that were quietly promoted to facts. The ladder keeps each statement where it belongs until the evidence moves it.
Separate what we know from what we believe.
- Example
- “Customers will accept a 24-hour turnaround if the result is more accurate.”
- The test we apply
- Who believes this, and what would it cost us if it were wrong?
Try it · challenge an assumption
“Customers will accept a 24-hour turnaround if the result is more accurate.”
What's the evidence?
The statement doesn't change. Where it sits on the ladder does, and so does how much weight it can bear.
Traceability
The Desha Decision Chain
Every important technology decision should be traceable back to a problem, evidence and a reason.
Stage 04 · Quantify
Economics sit next to the engineering.
A build estimate on its own is a partial answer. Every option is costed across four horizons, and every figure carries its basis and its confidence.
Build Cost
Cost to create.
People, tooling, licences and the opportunity cost of the team while it is building.
Run Cost
Cost to operate.
Cloud, inference, support, on-call, monitoring. The bill that arrives every month.
Change Cost
Cost to evolve.
How expensive is the next feature, the next integration, the next regulatory change?
Exit Cost
Cost to replace or leave.
Data export, contract terms, retraining, migration. The cost you only discover when you want out.
What we evaluate
- Expected value
- Revenue opportunity
- Cost reduction
- Productivity
- Risk reduction
- Customer impact
- Expected ROI
- Investment ceiling
- Operating cost
- Payback
- Time to value
The rule
Do not fabricate ROI. If the information is unavailable, label it an assumption or an unknown.
Every estimate in a Desha Decision Pack carries a basis and a confidence level. “Unknown” is a legitimate value. A false number is not.
Decision dimension
Complexity Must Earn Its Place.
Every architectural element carries a permanent operating cost that is cognitive, financial and organisational. Before it goes on the diagram, it has to be justified by a real requirement.
Try it · what goes on the diagram?
Operating cost, cognitive load and failure modes rise with every element, earned or not.
Select once to add without a requirement; again to attach one; again to remove.
Complexity should be justified by a real requirement. Do not use complexity to make an architecture look sophisticated.
Decision dimension
How Hard Is It To Change Our Mind?
Some decisions are a door that swings both ways. Others are a door that locks behind you. Both are fine, as long as you know which one you're walking through.
What it means for the decision
Worth a deliberate decision and a written reason.
What we evaluate for significant decisions
- Cost of reversal
- What would it cost, in money and people, to undo this?
- Time to reversal
- Weeks, quarters or years?
- Migration difficulty
- Is there a path out, or a rewrite?
- Vendor dependency
- How much of the system only works with this supplier?
- Data portability
- Can we take our data, and its meaning, with us?
- Contractual constraints
- Minimum terms, notice periods, exclusivity.
- Operational dependency
- What runs on this that we'd have to keep running through a change?
We do not collapse this into a score unless the underlying information supports one. A single number hides exactly the detail that matters.
Stage 05 · Architect
Architecture is the answer to a question, not the question.
The architecture stage happens fifth, on purpose. By then we know the problem, the evidence, the value and the constraints, so the design has something to be right about.
HLD
The shape of the system on one page.
Application
Services, boundaries, ownership.
Data
Stores, flows, lineage, residency.
AI
Models, retrieval, evaluation, fallback.
Integration
What talks to what, and how it fails.
APIs
Contracts, versioning, consumers.
Cloud
Runtime, regions, managed vs self-run.
Security
Threats, controls, secrets.
Identity
Who is who, and what can they do.
Non-functional requirements
NFRs are first-class requirements.
- Scalability
- Performance
- Availability
- Resilience
- Observability
- Disaster recovery
- Compliance
- Maintainability
- Operational complexity
- Vendor dependency
Each carries a target where one can be stated, such as a latency, an availability figure or a recovery objective, and each target links back to the evidence that justifies it.
Stage 07 · Decide
Decision Traceability
For every major architectural decision we capture the same eight things. Six months later, anyone should be able to read why.
Eighteen months later the question is never “what did we choose?” It is “why?”, and whether the reason still holds. A trace answers both without finding the person who made it.
Consulting output
Desha Decision Pack
A tangible output of deeper consulting engagements: one document that carries the problem, the evidence, the economics, the architecture and the reason, so the decision survives the meeting it was made in.
The full pack is an output of deeper advisory work where it is appropriate. The free 30-minute session will not produce one, though it will usually produce the first three sections.
Decision Gate
Every pack ends with one of three outcomes. It is a decision aid for you. It is not a verdict, and it is not a sales mechanism.
There appears to be sufficient evidence and value to investigate or proceed further.
Important assumptions, questions or prerequisites need to be resolved.
Based on the information available, there is not currently sufficient justification to proceed.
[Executive problem statement]
Prepared for [client] · [date]
- Executive Problem Statement
- Business Objective
- Current State
- Evidence
- Assumptions
- Constraints
- Expected Value
- Investment
- Operating Cost
- Architecture Options
- HLD
- NFRs
- Build vs Buy
- Trade-Off Matrix
- Complexity Assessment
- Reversibility Assessment
- Risks
- Decision Trace
- 5 Why Analysis
- Decision Gate
- Next Steps
Rationale: [Two load-bearing assumptions remain unverified; the investment ceiling is unknown.]
Prerequisites: [Measure current volume · confirm data-residency requirement · agree ceiling.]
Free · 30 minutes · one real problem
Bring a problem. Leave with clarity.
Thirty minutes, one real problem, structured thinking. If there's no value, there's no engagement.