Model the Business Flows → Derive the Spec → Validate → Build with Confidence → Release → Repeat
The Problem: The Hidden Cost That's Slowing You Down - The "Translation Tax"
Every time an idea is translated from a document to a ticket, and from a ticket to code, you lose business intent, time and money.
This is the hidden cost of building software that no one talks about.
1. The Business Idea
It begins with a core business goal and strategy, documented across several sources, e.g. documents, emails, slides, spreadsheets, and more.
2. The Design
Designers translate this strategy into mockups, interpreting the scattered business needs into a visual language.
3. The Backlog of Tickets
Product managers translate the designs into a backlog of tickets, losing crucial context and nuance with each new entry.
4. The Technical Implementation
Software Architects, Developers, DevOps and Security teams translate these tickets into a working software system, based off a fragmented and second-hand view of the original business goal.
5. The Quality Assurance (QA)
QA translates the tickets and the final feature implementation into quality assurance test plans, unaware of the loss of the original business intent and critical edge cases.
The Result: A Cycle of Waste
- Endless Alignment Meetings to bridge the gaps between teams.
- Outdated Documentation that no one trusts.
- Misaligned Features that are technically correct but miss the business mark.
- Costly Rework to fix misunderstandings after the fact.
What if your business plan, architecture, and test plan were all the same artifact?
The Solution: Business Modelling Spec Driven Development (BMSDD)
BMSDD prevents the "translation tax" by creating a single source of truth, the Business Model and the derived Spec.
BMSDD
Business Modelling · Spec · Driven Development
RULE 1
Model the Business Flows
Define what happens and how it happens
RULE 2
Derive Technical Specifications
Specs emerge directly from the business model
RULE 3
Automate Boilerplate
Auto-Generate repetition - don’t write it
RULE 4
Minimize Accidental Coupling & Complexity
DRA (Domain Resource Action) · Vertical Slices · Explicit & Decoupled structure
RULE 5
Implement Business Logic as per Business Model
Organise code into Functional Core (for pure functions) + Imperative Shell (for side effects)
Result → A simple working software system with no “lost in translation” errors
Understanding the Business Flow
From User Action to Business Value
1. Business Action (Intent or Request)
User clicks to submit an order and a "Place Order" action is sent to the system, with the relevant context.
e.g. CustomerID, CartID, ShippingAddressID, PaymentID, etc.
2. Business Rules Validation
System checks all Business Rules for the Business Action "Place Order".
e.g. "enough stock", "shipping address validity", "payment processed", etc.
3. Business Decision
A Business Decision is made for the "Place Order" Business Action, based on the result of the Business Rules checks.
e.g. ACCEPT , PENDING or REJECT.
4. Immutable Business Fact Recorded
The Unchangeable History and Source of Truth for every Business Decision made by the system.
e.g. The Business Decision for the "Place Order" Business Action would result in an "Order Accepted", "Order Pending", or "Order Rejected" Immutable Business Fact.
An Immutable Business Fact is of Guaranteed Business Value because it enables point-in-time travel to the past, which enables recovery, debugging, compliance, auditability, accountability, and more.
5. Business Behaviours, Outcomes and Value
Business Behaviours triggered, e.g. Send User Email, Notify Warehouse, etc.
Business Outcomes, e.g. increase in sales for the current month, quarter, year, etc.
Business Value, e.g. amount paid by the customer, being a returning customer, etc.
Business Flow Modelling
From Business Fact to Business Action (The Right Way)
1. Model Business Facts (what happened)
First, we find all the Business Facts for all Business Flows (The How). Facts are the ones of Business Interest, coming from a Business Decision that was made based on Business Rules. For example: "User Registered", "Order Placed", "Order Shipped", etc.
2. Model Business Decisions (why did it happen)
Now that we know the Business Facts, we can map them to their respective Business Decisions, e.g. "Order can be Placed?", "Order can be Shipped?", etc.
3. Model Business Rules (how did it happen)
Business Rules govern how Business Decisions are made, e.g "Payment confirmed", "Inventory allocated", etc.
4. Model Business Actions (what needs to happen)
Business Actions are Intents (or Requests) with instructions to trigger changes in the Business, e.g. "Register User", "Place Order", "Fulfil Order", etc.
Filtering Out the Noise: What Truly Matters
BMSDD forces a crucial distinction: not all system activity is of Business Interest. We only record as a Business Fact data changes that drive Business Behaviours, Outcomes and Value.
Business Fact: A customer's address is updated (Impacts shipping, billing, etc.).
Operational Detail: A user clicked a button 3 times (Just logging/telemetry, no change to the official story).
Guaranteed Auditability for Accountability and Compliance
Since Business Facts are immutable, they intrinsically guarantee they can be Audited for Accountability and Compliance.
Every Business Decision is recorded as an Immutable Business Fact that is linked to a time, an actor, a purpose, with all relevant context for it.
What does BMSDD bring to the table?
Business Modelling Spec Driven Development aligns strategy, product, and architecture around a single source of truth, the business model.
For Executives
Ensure software execution faithfully delivers business strategy, reduces risk, and protects long-term business value.
- • Prevents strategic misalignments before they become costly mistakes
- • Reduces risks in budget, delivery and compliance
- • Creates an auditable source of truth from Immutable Business Facts
For Product Leaders
Turns business intent into a clear and validated business model and specification, before development begins.
- • Faster discovery, validation and sign-off before development starts
- • Shared understanding across teams for fewer surprises in delivery
- • Prevents costly misunderstandings, rework, and misaligned features
For Architects & Engineers
Build systems from business models and specifications, not from business requirements docs that promote ambiguity and assumptions.
- • Specs derived from the Business Model for reduced ambiguity
- • Technology stack agnostic. Automated Specs, Docs and Boilerplate
- • Improves AI Code Assistants Efficiency
A Clear Path Forward for New and Existing Software Projects
Business Modelling isn't just to ensure new ideas start on the right foot. It's a powerful way to regain control of existing software systems to map all current and new Business flows, the Features.
For New Projects: Build it Right, Once.
De-risk your investment and accelerate development by achieving clarity before you build.
- Achieve stakeholder sign-off on a visual, easy-to-understand Business Model before coding begins.
- Eliminate ambiguity from day one, leading to more accurate estimates and faster delivery.
- Generate technical specifications directly from the model, ensuring development builds exactly what the business designed.
For Existing Projects: Tame the Complexity.
Regain control over legacy systems and de-risk new features with an accurate blueprint.
- Map out your existing processes into a clear Business Model to finally understand how your system *actually* works.
- Create a shared understanding that onboards new team members faster and aligns veterans.
- Confidently add features or refactor, knowing you have a trustworthy map that prevents unintended side effects.
BMSDD FRAMEWORK - Value Proposition
(Business Modelling Spec Driven Development)
Bridging the Gap Between Business & Developers
💼 For Business
- ✓
Quick Simulation & Early Validation
Validate the flow to sign-off before it's built to eliminate the "lost in translation" errors
- ✓
Agility & Speed & Time to Market
Accelerates delivery by enabling parallel workflows and automated prototyping
- ✓
Unchangeable Source of Truth
Decisions made based on Business Rules and recorded as Immutable Business Facts
- ✓
Unlimited Business Intelligence
Derive Business Insights from the Immutable Business Facts History
- ✓
Auditability & Compliance
Auditable and accountable records for all decisions, from Immutable Business Facts
- ✓
Cost Efficiency
Prevents expensive rework by fixing ambiguities during the modelling phase.
The Foundation
SOURCE OF TRUTH
Business Model
Technical Specifications
Immutable Business Facts
👨💻 For Developers
- ✓
Clarity from Day One
Clear specs from the business model mean no more guessing games.
- ✓
Automated Code Generation
Generate boilerplate code from the spec and focus on the core logic.
- ✓
Improved Maintainability
A clear, decoupled architecture makes the system easier to understand and modify.
- ✓
Enhanced AI Assistant Efficiency
Well-defined specs make it easier for AI assistants to understand the code and help you.
- ✓
Technology Agnostic
The business model is not tied to any specific technology stack.
- ✓
Reduced Rework
Get it right the first time with clear requirements from the start.
About the BMSDD Framework
Our Mission
Our mission is to fundamentally change the conversation between business and developers. We created the Business Modelling Spec Driven Development (BMSDD) framework to eliminate the costly "lost in translation" errors that plague software projects, ensuring that what gets built is exactly what the business expects and needs.
Our Philosophy
We believe that a business's core logic is its most valuable asset. By modelling business flows into immutable facts, deriving specifications from those models, and driving development from both, we enable the business and developers to create software systems that are not just robust, scalable, easy to maintain, and add features, but also auditable, accountable, and perfectly aligned with the business's strategic goals.