Visually Model Business Flows → Derive Technical 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 Flows Modelling Spec Driven Development (BFMSDD)
BFMSDD prevents the "translation tax" by creating a single source of truth, the visual Business Flows Model and the derived Technical Specification.
BFMSDD
Business Flows Modelling · Spec · Driven Development
RULE 1
Visually Model the Business Flows
Define what happens and how it happens
RULE 2
Derive Technical Specifications
The technical specs will emerge directly from the visual Business Flows Model: OpenAPI, AsyncAPI, GraphQL, gRPC, JSON Schemas and others.
→RULE 3
Automate Boilerplate
Auto-Generate repetition from the Business Flows Model - don’t write it. Focus instead on the core business logic to refine, enhance and augment it.
RULE 4
Minimize Accidental Coupling & Complexity
DRA (Domain Resource Action) · Vertical Slices · Explicit & Decoupled structure
RULE 5
Implement Business Logic as per Business Flows 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
BFMSDD - It's a framework for a software methodology, a tool or both?
BFMSDD It's primarily a way of working that can be adopted today using physical whiteboards (with sticky notes) or your favorite online diagramming tools (Miro, Mural, etc.), with a dedicated collaborative Online Canvas and AI-powered tooling coming soon.
Understanding the Business Flow
From User Action to Business Value
1. Business Action (Intent or Request)
User clicks to submit an order and the Business Action "Place Order" is sent to the software system, with the relevant context.
e.g. CustomerID, CartID, ShippingAddressID, PaymentID, etc.
2. Business Rules Validation
The Software 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 Business Action "Place Order", 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, representing the State Change of the business at that specific point in time.
The Business Decision for the Business Action "Place Order" could result in an Immutable Business Fact, e.g. "Order Accepted", "Order Pending", or "Order Rejected" .
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). These facts represent the system's State Changes over time. 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.
5. Model Device Screen (where it happens)
Device Screens are the specific interfaces where Business Actions are triggered by human actors, e.g. "Login Screen", "Checkout Screen", "Admin Dashboard", etc.
6. Model Actor (who made it happen)
Actors are the users or system automations performing the Business Action, e.g. "Guest", "Registered User", "Admin", "System Cron", etc.
Filtering Out the Noise
BFMSDD 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.
The difference:
Business Fact: Delivery address updated (Impacts shipping).
Business Fact: Track GPS coordinates to notify user when delivery driver is five minutes away.
Operational Detail: Track GPS coordinates every second for real-time tracking in a map.
The Full User Journey
The Business Flows Model makes the User Journey explicit by modelling not only how data flows from Actor Intent to Business Fact, but also how the software system responds and reacts to these business outcomes such as success, pending and failure.
Responses are modelled as a new flow for each View responsible for updating the Actor with the result on its Device Screen.
Reactions are side effects triggered by automations, which themselves are modelled as new Business Flows that create additional Business Facts and may trigger further system responses and reactions.
Auditability, 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. They are an unchangeable history of things that affected the software system State over time.
This intrinsically enables guaranteed:
- Auditability
- Compliance
- Accountability
- Point-in-Time Recovery & Debugging
The Perfect AI Booster for LLMs Efficiency
Stop fiddling with AI text prompts. Start giving LLMs an AI Boost, the Business Flows Model to generate a production-ready software system.
The Structured Blueprint Boost Your AI Coding Agent is Missing
Visual Context
The Business Flows Model reveals exactly what needs to be built and how via visual user flows, their connections, relationships and groups.
This leaves no room for ambiguity, assumptions and guessing games for the AI coding agent and its LLM model.
Embedded Metadata
The Business Flows Model image embeds the full structural hierarchy for: Domain → Bounded Context → Feature → Flow → Vertical Slice.
For each Vertical Slice it embeds the exact data shape for every element in the flow: Actor → Screen → Action → Rules → Decision → Fact.
AI Accelerator
AI LLMs excel at using a Business Flows Model to generate the Technical Specifications (OpenAPI, AsyncAPI, GraphQL, etc.), Interactive Prototypes, and Production-Ready Code for Event Sourcing, Event Driven or even CRUD software architectures. You choose the architecture, your AI coding agent will code it for you.
Developer Focus
Software Developers mostly focus on fine-tuning, enhancing and augmenting the core business logic, which an AI LLM wrote based on visually defined flows and embedded data for the: Business Actions, Business Rules, Business Decisions and Business Facts.
The boilerplate, wiring, and tests were also done by the AI coding assistant, but usually don't require too much attention and focus from the Software Engineers.
Model More. Code Less. Ship Faster.
With the Business Flows Model, AI builds it right the first time, less rework required.
Load and analyze the Business Flows Model to understand the user journey and use its metadata to know the business rules that govern the execution of each action for a flow.
How Do I Get Started?
You don't need to wait for our dedicated collaborative online canvas or our dedicate tools. Start applying the BFMSDD framework methodology today with your team.
Gather Your Team
Bring together in a physical or virtual room:
- → Business Experts (the "Why")
- → Product Owners (the "What")
- → Domain Experts (the "How it works")
- → Business Users (the "How its used")
- → Engineers (the "How it will be implemented")
Pick Your Tool
Use a whiteboard, sticky notes, or online canvas and diagram tools.
You don't need special software to start modelling the Business Flows to create a single source of truth and shared language that everyone understands and can work from.
Prefer an online tool that let you export an image with embed metadata to enable using it as an executable blueprint in tools and AI.
Follow the BFMSDD Loop
Start by using the BFMSDD Rules to map a Business Flow, the first step of the BFMSDD loop:
Model the Business Flows → Derive the Spec → Validate → Build with Confidence → Release → Repeat
For every New Feature, Improvement, Refactor or Bug Fix you MUST go back to the start of the BFMSDD Loop, otherwise the Business Flows Model will no longer be the executable blueprint from a single Source of Truth.
Dedicated Tools Coming Soon
We are building a specialized BFMSDD Online Canvas and MCP Server to automate the spec generation and AI coding assistance. Stay tuned!
What does BFMSDD bring to the table?
Business Flows Modelling Spec Driven Development aligns strategy, product, and architecture around a single source of truth, the visual Business Flows 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 Flows 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 the software system from a single Source of Truth, the Business Flows Model, not from business requirements, tickets and other docs that promote ambiguity and assumptions.
- • Derive the Spec, OpenAPI, AsyncAPI, GraphQL or other from the Business Flows 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 Flows 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 Business Flows for existing features and future ones.
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 Flows Model before coding begins.
- Eliminate ambiguity from day one, leading to more accurate estimates and faster delivery.
- Generate technical specifications directly from the Business Flows Model, ensuring software engineers, with or without AI assistance, build exactly what the business needs and expects.
For Existing Projects: Tame the Complexity.
Regain control over legacy software systems and de-risk new features with an accurate blueprint.
- Map out your existing processes into a clear Business Flows Model to finally understand how your system *actually* works.
- Creates a shared understanding that onboards new team members faster and aligns seniors through the visual Business Flows Model.
- Confidently add features or refactor, knowing you have a trustworthy map that prevents unintended side effects, the Business Flows Model.
BFMSDD FRAMEWORK - Value Proposition
(Business Flows Modelling Spec Driven Development)
Bridging the Gap Between Business, Product & Developer Teams
💼 For Business & Product Teams
- ✓
Quick Simulation & Early Validation
Validate the Business Flows to sign-off before software development starts to eliminate the "lost in translation" errors.
- ✓
Agility & Speed & Time to Market
Accelerates software delivery by enabling parallel development 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 the Immutable Business Facts history.
- ✓
Cost Efficiency
Prevents expensive rework by fixing ambiguities during the Business Flows Modelling phase.
The Foundation
SOURCE OF TRUTH
Business Flows Model
Technical Specifications
Immutable Business Facts
👨💻 For Developer Teams
- ✓
Clarity, Alignment and Shared Understanding from Day One
The Business Flows Model means Business, Product and Engineering teams are aligned and on the same page.
- ✓
Automated Code Generation
Generate boilerplate code from the Business Flows Model and its derived technical spec (OpenAPI, AsyncAPI, GraphQL, etc.) and focus on the core logic.
- ✓
Improved Maintainability
A clear, decoupled architecture makes the software system easier to understand, modify, maintain and scale.
- ✓
Enhanced AI Coding Assistants Efficiency
The Business Flows Model and derived technical specs make it easier for AI coding agents to reason and help.
- ✓
Technology Agnostic
The Business Flows Model is not tied to any specific technology stack or technical specification.
- ✓
Reduced Rework
Get it right the first time with a clear understanding of what the business needs and expects from the Business Flows Model.
Frequently Asked Questions
Common questions about the BFMSDD Framework.
Regardless of the question, it’s important to understand that BFMSDD is split into BFM (Business Flows Modelling) and SDD (Technical Specification-Driven Development). In this approach, technical specifications such as OpenAPI, AsyncAPI, and others are derived directly from a single Source of Truth: the Business Flows Model, a structured, executable blueprint that captures business intent, state changes and system behaviour in a unified way and orderered timeline.
It is primarily a framework methodology and a way of working.
While we are building dedicated AI-powered tools (like the Online Canvas and MCP Server), you can start using the methodology today with any whiteboard, physical canvas, or online canvas/diagramming tool.
No. The Business Flows Model brings immense value by itself through clarity and alignment. You can manually derive the technical specifications and code.
The AI Booster simply accelerates this process by automating the translation from the Business Flows Model to Code.
BFM shares the same approach in the initial discovery phase as Event Storming, where we start by finding the business facts, their bounded contexts, and business domains.
We then differ by explicitely modelling the Business Flows, with data shapes for input/output, business rules and business decisions.
This approach adds a structured, spec-driven layer on top of the discovery phase, the executable blueprint (the Business Flows Model), which becomes the single Source of Truth from which we can derive technical specifications and code, bridging the gap between sticky notes and production systems that Event Storming leaves open.
While BFM may share some similarities with Event Modeling (EM), the approaches differ in important ways.
BFMSDD is not locked into Event Sourcing and adopts a more business-centric language and set of concepts.
In each vertical slice, Business Rules and the Business Decision are explicitly modelled, and their result is captured as a Business Fact that clearly represents the decision result (e.g. "Order Accepted", "Order Pending", "Order Rejected).
This approach intentionally avoids mixing Business Decisions results with business reactions and side-effects. Business Facts that represent reactions to a decision (e.g. "Shipment Scheduled") or side effects triggered by it (e.g. "Order Email Sent") are always modelled as separate Business Flows. In EM, these same facts (events in their terminology) are "often" represented within the same vertical slice, where the business decision itself remains implicit and must be inferred from resulting reactions.
In BFM, business success and business failure paths are modelled within the same vertical slice, making the business flow explicit, readable, and easy to follow for all (business, product, engineering, etc.). In contrast, EM typically treats sucess and failure paths as implicit results of decisions, reactions, or side effects, with failure paths modelled in separate slices, when not omitted/forgotten, making the overall user flow and story more difficult to read, follow and reason about.
In the technical implementation, Business Facts immutability is guaranteed by enforcing append-only persistence and write-once semantics at the storage and application layers.
This is typically achieved by persisting Business Facts in append-only data stores (e.g. event logs, immutable tables, or ledger-style storage).
Optionally, to guarantee the Business Fact is the Single Source of Truth in the software system, we strongly recommend using an Event Sourcing architecture, which by design is immutable due to its exclusive append-only storage approach to tracking state changes, the Business Facts in our case, while still supporting CRUD-based read views to keep query-ready state for each specific use case.
By making immutability a technical constraint, not just a modelling convention, Business Facts remain a reliable, auditable, trustworthy and Single Source of Truth in production software systems.
Always do:
- Assign each Business Fact a unique identifier, hash, timestamp, and version, ensuring it can only be created once.
- Represent any correction or change as a new Business Fact, linked to the previous one if needed, rather than modifying existing data.
Alternatives to guarantee immutability, without append-only storage:
- Disallowing UPDATE and DELETE operations on Business Facts at the application and database levels.
- Enforcing immutability through database constraints, permissions, and APIs that only expose CREATE and READ operations.
About the BFMSDD Framework
Our Mission
Our mission is to fundamentally change the conversation between business and developers. We created the Business Flows Modelling Spec Driven Development (BFMSDD) 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 Business Facts, deriving a technical specification from the Business Flows Model, and driving development from both, we enable Business, Product and Engineering teams to build software systems that are not just robust, scalable, easy to maintain, and to add features, but also auditable, accountable, and perfectly aligned with the business's strategic goals.