Clarify a complex opportunity
Rapidly map context, risks, options and the next evidence required before major investment.
Solutioning method
Move from ambiguity to working evidence.
My method connects business context, technical reality, architecture decisions, implementation guidance and production proof in one repeatable operating discipline.
Six-stage discipline
How I spend my days solving systems problems.
Frame the real problem
Clarify the outcome, current pain, actors, decisions, rules, data, dependencies, risk and what success must look like. Separate the requested feature from the business result behind it.
Inspect reality
Read code, schemas, logs, support evidence, documents, interfaces and operational workflows before making architecture claims. Recover hidden business knowledge from the current system.
Shape the target
Define journeys, service boundaries, APIs, integration sequences, data ownership, identity, infrastructure and operating responsibilities. Make assumptions and trade-offs visible.
Test the design
Challenge options against security, POPIA, scalability, availability, performance, resilience, cost, migration and delivery risk. Explore failure before production does.
Guide implementation
Translate architecture into contracts, slices, acceptance criteria and practical direction for developers, analysts, testers, vendors and operators.
Close with evidence
Verify UAT, migration, recovery, observability, release controls and production behaviour—not only task completion or a successful demonstration.
Discovery inputs
What I need to understand before proposing a solution.
- The business outcome and why it matters now
- Who performs, approves, supports and depends on the process
- Current workflows, exceptions and manual workarounds
- Data sources, ownership, privacy and quality concerns
- Existing applications, integrations and infrastructure
- Security, compliance and audit requirements
- Operational pain, failure impact and support evidence
- Time, budget, capacity and delivery constraints
Discovery outputs
What becomes clearer.
- Agreed problem statement and success measures
- Current-state map and risk picture
- Target capabilities and system boundaries
- Recommended architecture and trade-offs
- Incremental roadmap and dependency sequence
- Acceptance, migration and release evidence
- Open decisions, assumptions and approval gates
- Ownership during build and after launch
Engagement shapesDiscovery sprint Architecture baseline Target design Modernisation assessment Delivery guidance Production readiness
The method adapts to the problem.
Recover current-state truth
Document systems, workflows, data, dependencies, risks and operational realities.
Shape a new platform or capability
Create the architecture, implementation direction, controls and delivery roadmap.
Choose a safe change path
Determine what to stabilise, refactor, encapsulate, replatform, extract or replace.
Keep implementation aligned
Support decisions, reviews, acceptance, risks and cross-team dependencies during delivery.
Prove the solution can operate
Review testing, migration, observability, security, rollback, support and release evidence.
The discipline
Four qualities the process protects.
Claritypeople understand the problem and decisions
Continuitychange protects critical operations
Controlrisk, access and approvals are explicit
Confidenceevidence supports release and support
Begin with discovery
The first useful deliverable is a better understanding of the problem.
From there, architecture, technology and delivery choices become easier to justify.