Business in the Driver's Seat
Application development with conventional methods is slow, expensive, and often unsuccessful. The industry still builds software with medieval methods. That is why the results of many software projects are unsatisfactory. It does not have to be this way!
The Business-Driven Application Development (BDAD) methodology was developed by Quatico and enables the business to steer application development with precision. Domain experts can express the requirements for the application in their own domain language, by example – without the lengthy detour through business analysts or requirements engineers.
What is Business-Driven Application Development?
With the «Business-Driven Application Development» methodology, or BDAD for short, the business can steer application development with precision. Domain experts can express the requirements for the application in their own domain language, by example. Without the lengthy detour through business analysts or requirements engineers.
What is the difference between BDAD and conventional development methodology?
In conventional development methodology, domain experts, product owners, business analysts, requirements engineers, software engineers, and testers are in constant exchange. Translation errors arise continuously along the way – like a game of telephone. The entire round trip from product owner to tester is slow, laborious, and is usually repeated several times.
Conventional:
Domain expert → Product Owner → Business Analyst → Requirements Engineer →
Software Engineer → Tester → (follow-up questions) → Repeat...
BDAD:
Domain expert (in domain language) → Executable specification → Automated tests →
Continuous Delivery → Value for customers
This conventional approach is too error-prone, too slow, and too expensive. BDAD eliminates translation errors through a shared language and automated execution.
What foundations is BDAD based on? What makes it so advanced?
Our methodology is based on a shared language, on quality gates, and on automation.
The Foundation: A Shared Language
Business and IT develop a shared domain understanding and a shared vocabulary, and they express domain workflows in natural language – so-called application scenarios. We formalize the important application scenarios so that a machine can execute them. Et voilà, this gives us automatically executable application scenarios. We call them «executable specifications».
The technically inclined may recognize the practice of «Behavior-Driven Development» (BDD). We use Gherkin to express application scenarios in a language understandable to both humans and machines:
Scenario: Customer orders a product
Given a customer with a valid account
And the product is available
When the customer orders the product
Then an order is created
And the inventory is updated
Quality Gates: Automated Tests
These automatically executable application scenarios are an important quality gate. Already during development, developers can tell whether the application still meets the domain requirements. With the help of additional automated quality gates, for example for design and security, we ensure the quality of releases and reduce manual testing effort to the necessary minimum.
Continuous Delivery: On-Demand Releases
With an automated continuous delivery pipeline, we can release on demand – several times a day if desired. This lets us meet customer needs precisely in short iterations. Only a few teams have developed this capability. For us, it is method.
Inspiration: DDD and BDD
Our methodology is inspired by Domain-Driven Design (DDD) and Behavior-Driven Development (BDD). But hardly anyone has the courage and the competence to put the methodology into practice. On top of open source technology, Quatico has built an opt-in framework in which every gear meshes precisely with the next. This is how we manage to deliver value from the very start of a project and keep our promise of going live with an MVP in 30 days.
What benefits does Business-Driven Application Development bring to customers?
Efficiency and Speed
By steering application development with precision, our teams are very efficient at fulfilling customer wishes. We produce comparatively little «waste». Automation enables us to take many small steps in a very short time. With each small step, we can learn and adjust the direction a little.
Digital Gold: Executable Specifications
Our automatically executable application scenarios are digital gold. In contrast to specifications in a Jira ticket, which feel like instant digital trash. We nurture and maintain the application scenarios that are executed with every iteration, and we know at all times whether the application still does what it should.
Concrete Benefits
In short: thanks to our approach, our customers reach the market quickly and are highly agile and cost-effective. Software developed by Quatico has a 90% lower total cost of ownership (TCO) than software developed with conventional methodology. That is why we are «revolutionarily affordable».
Summary of the benefits:
- Speed: MVP possible in 30 days
- Cost: 90% lower total cost of ownership (TCO)
- Quality: Automated tests ensure consistency
- Agility: Fast to market, highly agile
- Efficiency: Little «waste», precise fulfillment of customer wishes
Field Report: ewz Customer Portal
A concrete example of the successful application of BDAD is the customer portal for the electricity utility of the City of Zurich (ewz).
Project Context
The ewz customer portal is a complex system that maps various business processes and has to communicate with legacy systems such as SAP as well as external systems. The challenges were manifold: complex business processes, legacy systems, data exchange between different systems, and the need to be fast to market.
Methodology: Event Storming to Define the MVP
At the start of the project, we ran an Event Storming session to define the MVP. Together with the domain experts, we identified the most important domain events and developed a shared language. This shared language was used across the entire team – from the domain experts to the developers.
Success Factors
Trust was the basis for the successful collaboration. We earned our customers' trust, and they trust that we can quickly correct any errors when things get tricky.
Iterative development made it possible to learn quickly and adjust the direction. With each small step, we could gather feedback and adapt the application accordingly.
Automated tests ensured that the application does what it should at all times. The executable specifications were run with every iteration and served as an important quality gate.
Learnings
The project demonstrated the importance of trust, onboarding new team members, and agile flexibility. New team members could be onboarded quickly, because the shared language and the executable specifications made understanding easier.
What are the success factors for getting it right?
Consistency
Besides craftsmanship competence, it takes a good deal of persistence to put the methodology into practice. BDAD requires discipline and consistency in its application.
Courage
If you want to learn quickly in the market, it also takes courage to experiment with unfinished functionality. Not everyone feels comfortable with wind in their hair. But it is exactly this willingness to experiment and learn early that makes it possible to be fast to market.
Trust
Trust is the basis. We earned our customers' trust, and they trust that we can quickly correct any errors when things get tricky.
Isn't writing out concrete application scenarios exhausting and demanding for customers?
Yes and no. We do not just walk up to customers and say: «So, now give us your key success use cases and write out the automatically executable application scenarios.» We guide customers through workshops, do the grunt work ourselves at first, and slowly introduce customers to the practice.
With the first successes, interest and willingness grow to help shape the shared language and the application scenarios. Once our customers have experienced what kind of race car they are driving, they no longer want to leave the driver's seat at all.
Is your methodology suitable for every project?
In principle yes, but the methodology is especially worthwhile for projects with demanding domain requirements.
Which customers are we the right fit for?
- For customers who want to differentiate themselves: Customers who want to offer their own customers a modern digital service
- For customers who need to move fast in the market: Customers who have to move quickly in the market
- For customers who want to digitalize: Customers who want to digitalize their business model or individual services
- For partnership-based collaboration: Our customers want to be challenged and advised by us. In that sense, we fit customers who seek a partnership of equals
Is BDAD old wine in new bottles?
Honestly now, isn't this old wine in new bottles? DDD and BDD have been around for 20 years.
It is true that our methodology is inspired by Domain-Driven Design (DDD) and Behavior-Driven Development (BDD). But hardly anyone has the courage and the competence to put the methodology into practice. On top of open source technology, Quatico has built an opt-in framework in which every gear meshes precisely with the next.
This is how we manage to deliver value from the very start of a project and keep our promise of going live with an MVP in 30 days. BDAD is not a theoretical methodology, but a practically proven and successfully applied approach.
Best Practices for BDAD
1. Run an Event Storming
A workshop with all stakeholders: business experts, developers, product owners, designers. Together, identify and model the domain events.
2. Maintain a Shared Language
A living glossary: what do domain terms mean? What are concepts called in the code? Regular reviews and maintenance of the shared language.
3. Create Executable Specifications
Express important application scenarios in natural language and formalize them so they can be executed automatically. These specifications are digital gold and are run with every iteration.
4. Set Up Automated Quality Gates
Not just functional tests, but also quality gates for design, security, and performance. Reduces manual testing effort to the necessary minimum.
5. Proceed Iteratively
Not everything at once: start with an MVP, learn and adapt, expand step by step. With each small step, learn and adjust the direction.
6. Continuous Learning
BDAD is a journey: regular retrospectives, knowledge sharing, community exchange. The methodology keeps evolving.
Challenges
Legacy Systems
Existing systems such as SAP or other legacy systems must be integrated. Data exchange between different systems can be complex. Step-by-step refactoring and parallel operation are often necessary.
Changes in Team Structure
New team members have to be onboarded. The shared language and the executable specifications help, but it takes time and patience.
Agile Contract Models
Traditional contract models do not always fit agile development. Agile contract models based on trust and collaboration are necessary.
Mindset Shift
Moving from code-first to business-first thinking requires a cultural change. Not everyone feels comfortable with this approach right away. It takes time and patience to get the team used to this new way of working.
Conclusion
Business-Driven Application Development has changed our understanding of software development. BDAD is a unique methodology developed by Quatico that is based on DDD and BDD but, through a practically proven framework and consistent application, leads to concrete results:
- Better software: Because it does what the business needs
- Faster to market: MVP possible in 30 days
- Revolutionarily affordable: 90% lower total cost of ownership
- Happier teams: Because the work makes sense
- More satisfied customers: Because their language is spoken
Further Information
- Agile Breakfast Zürich: Business Driven Application Development - A Field Report - Talk from November 2, 2022 with Natascha Wloka (Product Owner ewz), Christian Kehl (Project Manager Quatico), and Jan Wloka (CTO Quatico)
Interested?
Would you like to learn more about BDAD or start a project with this methodology? Get in touch! We would be happy to show you how BDAD can work for your project too.
About the author
