Service
Architecture Review Workshop
2 to 3 sessions. Make hard decisions with evidence.
You're facing a significant architecture decision. Multi-tenancy model. Migration strategy. Data boundaries. Security constraints. The team has opinions, but nobody's certain. The stakes are high and reversing course later will be expensive.
An Architecture Review Workshop brings structure to the chaos. We work through the options systematically, surface hidden assumptions, document trade-offs, and reach a decision you can defend. You leave with a clear path forward and the rationale to back it up.
Common use cases
- Multi-tenancy choices: Shared database? Schema-per-tenant? Separate deployments? Each has profound implications.
- Data boundaries and segregation: Where does customer data live? How is it isolated? What are the compliance implications?
- Migration strategy: Big bang or incremental? Strangler pattern? How do you get from here to there without breaking everything?
- Security and privacy constraints: How do access controls work? What's the audit trail? How do you prove compliance?
- Reliability and incident posture: What's your blast radius? How do you fail gracefully? What does recovery look like?
- Integration architecture: How do systems talk to each other? Where are the boundaries? What's the contract?
What you get
Decision Brief
Clear articulation of the decision to be made, the options available, and the trade-offs for each. This document captures what you're optimising for and what you're willing to sacrifice. Suitable for sharing with stakeholders who weren't in the room.
Recommended Option and Rationale
My recommendation with clear reasoning. Not "it depends" but a specific direction with the logic behind it. You may disagree, and that's fine. The value is in forcing clarity, not in blind compliance.
Immediate Next Steps
A 2-4 week action plan to start executing on the decision. Who does what, in what order, with what dependencies. Enough detail to start moving, not so much that it becomes shelf-ware.
Risks and Mitigations
What could go wrong with the recommended approach and how to reduce those risks. No decision is risk-free. The goal is eyes-open risk acceptance, not false confidence.
Architecture Decision Record (ADR)
Permanent documentation of what was decided, why, and what alternatives were rejected. Your future selves will thank you when someone asks "why did we build it this way?"
What's not included
- Implementation or hands-on development
- Detailed technical specifications or design documents
- Ongoing architecture governance
- Broad platform assessment (that's a Health Check)
If you need implementation support, we can discuss a Fractional CTO engagement or targeted follow-on work.
How it works
Preparation
You share context: the decision to be made, constraints, any prior thinking, and relevant documentation. I review async and come prepared with initial observations and questions.
Session 1: Problem Framing
Align on what we're actually deciding. Surface hidden assumptions and constraints. Clarify what success looks like and what trade-offs are acceptable. Often the most valuable session, because the problem is rarely what it first appears.
Session 2: Options and Trade-offs
Work through the viable options. For each: what does it enable, what does it prevent, what does it cost, what are the risks? By the end, we have a clear view of the decision landscape.
Session 3: Decision and Next Steps
Converge on a recommendation. Stress-test it. Define immediate next steps and who owns them. Sometimes this happens in session 2. Sometimes we need more exploration. We flex to the complexity.
Documentation
I deliver the decision brief, ADR, and next steps document within a week of the final session. You have permanent documentation of what was decided and why.
Common questions
How many sessions does it take?
Usually 2-3 sessions of 2-3 hours each, plus preparation and documentation time. Some decisions are simpler, others need more exploration. We scope it based on the complexity of your situation.
Who should attend?
Key technical decision-makers: senior engineers, architects, tech leads, and usually the CTO or VP Engineering. Sometimes product leadership if the decision has significant product implications. Keep it small enough for real discussion, typically 4-8 people.
What if we disagree with the recommendation?
The recommendation is informed advice, not a mandate. I present options with trade-offs and make a recommendation, but you know your context best. The value is in structured thinking and documented rationale, not in blindly following my opinion.
Can you help with implementation?
Yes, through a Fractional CTO engagement or targeted follow-on work. Many clients want ongoing support as they execute on the decision. We can discuss what that looks like.
How is this different from a Platform Health Check?
A Health Check assesses your current state broadly. An Architecture Review focuses deeply on a specific decision or problem. Health Checks diagnose; Architecture Reviews solve. Some clients do both: Health Check first to identify priorities, then Architecture Review to address the biggest one.
Related services
Facing an architecture decision?
Tell me what you're wrestling with. I'll let you know whether a structured review would help and what it might look like.
References available on request. I typically respond to emails within 2 business days.