Playbooks¶
Outcome-first recipes. Each one starts from a real situation an architect is already in — a deadline, a question from a boss, a migration on the calendar — and walks the shortest path to a finished deliverable you can hand to someone.
These differ from the feature guides: a guide explains an area of the app; a playbook stitches several areas together to produce one thing, tells you honestly where you'll have to do manual work, and ends with an artifact in your hands.
Read them in whatever order matches your pressure. If you don't know where to start, Get your sunset-risk list is the fastest path to a result a leadership team will care about.
| Playbook | The situation | You walk away with |
|---|---|---|
| Get your technology sunset-risk list | "What's about to go end-of-life, and what does it put at risk?" | A ranked EOL-exposure list + a shareable risk narrative |
| See your application portfolio | "What apps do we even have, and who owns them?" | One screen: every app, owner, what it supports, how risky |
| Find your redundant & unowned apps | "Where's the waste and the orphaned stuff?" | A worklist of duplicates and ownerless assets |
| Map your capability coverage gaps | "Which business capabilities are unsupported or at risk?" | A coverage map highlighting gaps and at-risk capabilities |
| What breaks if I retire this? | "We want to decommission X — what's the blast radius?" | A blast-radius report: affected apps, capability gaps, replacements |
How to use a playbook with someone who's struggling¶
Every playbook flags where people get stuck — almost always a step that needs real data wrangling or per-item enrichment. That stall point is the offer, not the obstacle. The highest-value way to onboard a new architect is to run the playbook with them on their data: you do the import and the fiddly enrichment, and hand back the finished deliverable. They get the result on day one without paying the setup tax — and they come back because the result is now part of how they report upward.