Demo Block — Organizational Pain
Introduction
If shown after Enterprise pain:
We just saw how expert knowledge gets captured once and made available everywhere. Now let's go one step earlier — before any code gets written, requirements have to travel from business intent to something implementable. Let's see who's involved in that translation.
Context: Individual developers and teams now write better code faster — but that only helps if the work is set up correctly beforehand: clear boundaries, clear business intent, clear standards. A business analyst thinks in user stories, an architect thinks in components and boundaries. They usually don't share a system or even the same language. Business intent gets lost before it reaches the teams.
Demo persona: Architect.
Create a demo branch for ROBOFLOWAP (from main) and open it in the Workbench. Delete the Tech Debt and Risk elements from the Gift Card Service component diagram beforehand — they're placed
live during the demo. See Preparation and Clean-up.
Demo
Decomposing a business requirement happens across tools that usually don't connect. Architects, business analysts, and product owners don't share the same language, and each other's tools don't fit their own workflow. Workbench adapts to whoever is in the room: model elements that match the BA's vocabulary, the architect's notation, or whatever the organization needs.
-
Open ROBOFLOWAP in Workbench, on the demo branch. Go to Diagrams and select the C4 Level 2 Gift Card — B2B Webshop container diagram.
-
On the L2 diagram, click "+" and add a User Story element near where the Gift Card container will go:
- Title:
Buy with gift card - Summary:
As a customer, I want to purchase and redeem gift cards as part of checkout.
This is how the business side captures the requirement — in their own language, no architecture notation required.
- Title:
-
Now we need to break it down into containers, components, and whatever is needed to make it ready to implement.
-
Scroll right to the B2B Webshop system.
Following the business requirement, we first add another container — already prepared — for the Gift Card Service.
Click "+", search for "Gift card", and place the Gift Card container within the B2B Webshop system.
-
Gift cards need to be activated as part of checkout, so we first connect the Checkout Service with the Gift Card Service. Gift cards will also be used for payments.
Connect Checkout Service → Gift Card Service, label "activates"; connect Payment Service → Gift Card Service, label "redeems".
-
Now let's go one level deeper and refine the relationships to connect directly to the right components.
Right-click the Gift Card container, select Drill down, then the Gift Card component diagram.
We've already decomposed the Gift Card container into components. Let's refine the relationships to the containers we created before.
-
Click "+", search for "checkout", drag the Checkout Service container onto the diagram. Repeat for Payment Service. Right-click each and select Add available relationships.
These services already have relationships to the Gift Card Service — we created these before. But we need to refine them to connect to the concrete component.
-
Click each relationship and move it to point to the Gift Card API.
-
Click "+" and attach a Risk — "Missing or insufficient gift card validation" — to the Gift Card domain, and a Technical Debt — "No single source of truth for gift card payments" — to the API.
Governance elements can be attached directly to components and need to be resolved before implementation starts; otherwise these open topics would leave room for interpretation and the AI would just guess. Everything is versioned, traceable, and machine-readable. This design is available before anyone opens an IDE.
"This is the process that makes developers, teams, and enterprise work at scale. The architect, the BA, and the product owner work in the same place. What they decide together becomes the context that developers and AI work from."