A different way of thinking about software

Focus on the needs of the business, not the technology

Business driven development is a software development paradigm that focuses on the needs of the business over the tech. It is designed for enterprise software, which differs markedly from consumer-facing apps. BDD relies on modelling the needs of the business and uses these models to drive the design.

Background

Agile, XP, Scrum, Kanban, … Sometimes it seems like there are dozens of software development paradigms to choose from. But the truth is, most of these are optimized for developing small-scale consumer-facing applications. Here, it makes sense to be “agile” so you can respond quickly to a fickle market with short attention spans. But if you are developing a large piece of enterprise software you need a different approach. Typically, enterprise software is expected to last for years, and it has to be “bullet-proof”, as mistakes cost serious revenue. And this is where Business Driven Development comes into its own.

In this blog, I describe Business Driven Development in more detail.  You will see how enterprise software differs from typical app development. I will also clarify the difference between this and Behavior Driven Development (two terms that are often confused).

Business-driven development

Putting the business needs first

Companies often suffer because of a mismatch in expectations between the core business and their tech teams. Business Driven Development aims to overcome that.

Enterprise software development follows two patterns. The business asks the tech team “please solve this problem for us”, or the tech team creates a cool new idea and tries hard to get buy-in from the business. In both cases, you will see suboptimal outcomes. So, either the definition and scope of the problem statement were too vague, or the new solution doesn’t map to the actual needs of the business. As a result, you are left trying to fit a square-shaped solution into a round-shaped problem – it will fit, but there are lots of gaps around the edges!

In Business Driven Development, the business and tech teams work closely to define, specify, code and deliver software that exactly meets the needs of the business. Therefore, the upshot of applying BDD successfully is a business where the software is a key enabler, driving opportunities, improving efficiency and reducing costs. Clearly, all these are things any business would love, so how can you actually implement BDD?

The BDD cycle

BDD involves a cycle of activities designed to help you deliver consistently high-quality software. The cycle consists of four steps: Modelling, Building, Deploying and Managing. Let’s look at these in more detail.

Modelling

The first stage of the BDD cycle is to model the problem space and design your solution. This phase should involve senior figures in the business alongside business analysts and technical advisors who can provide feedback on what is and isn’t feasible. The first thing is to understand what the software should do and to come up with a precise set of requirements. Next, you can create a model of your existing business and run simulations to check your model is accurate. Then you should design the functionality of your software based on the requirements and models. One approach to this is to use a model-driven architecture (originally created by the Object Management Group in 2001).

Building

Once you have modeled and designed your new software you need to start the process of building (or assembling). Traditionally, this has been where the most effort and resource has been focussed. But with modern tools and a robust modelling phase, you should be able to make this phase far more efficient. The key things here are:

Discovery: Don’t try to reinvent the wheel. BDD encourages code reuse and the use of libraries. So, you should start by trying to find existing solutions that may help solve the problem. 

Construct: Now you can write the actual software. BDD isn’t too prescriptive here. But the aim is to write software that meets the requirements and is well documented and easy to maintain.  

Testing: It is critical to do good testing for enterprise-grade software. I will explain how Functionize can help you with this later.

Deploying

A key aspect of any successful enterprise software is deployment. At the scale of multinational enterprises, deployment planning and management are as challenging as building the software. Deployment consists of understanding and integrating the following:

People: Who will be using the software? Will they need any training? How will you manage user rollout?  

Processes: How will you manage the upgrade or rollout across the business? What are your contingency plans? How will you measure how successful this is? 

Information: How do you connect to your existing data? How do you protect your data? How do you ensure against corruption when you metaphorically throw the switch on the new software? 

Planning your deployment properly will be the difference a successful rollout and a complete failure. One way to do this effectively is Canary Testing. This is where the rollout is done to just a few users at a time and you compare their experience with existing users. Functionize can help you with automated Canary Testing, read about it here.

Managing

Enterprise software often has a life measured in years (or decades!) and so it requires careful management. This is one area where it differs dramatically from consumer applications. Key aspects you need to consider here are:

Application and Service Management: This covers day-to-day management of the software, fixing any bugs, dealing with any outages, etc. This is likely to involve DevOps and the product team. 

User & identity Management: This is related to things like security, data privacy, compliance, etc. Does your system hold personal data? If so you may well need to comply with GDPR. As a business, you need to proactively delete old user accounts, lest a disgruntled former employee decides to commit mayhem. 

Monitoring: One of the critical things is to perform ongoing monitoring of the service. This isn’t simply about backend performance metrics. You should also be talking to users and getting feedback on any pain-points, etc.

Rinse and Repeat

One of the important things that makes BDD closer to Agile than the traditional waterfall model is the idea that this process shouldn’t be static. As soon as the new software is released you should go back to the modelling stage. So, test your original assumptions, check that the software is behaving as expected, revisit the key business metrics. Often, new software will have a profound business impact. This may open up new ideas that need to be explored in future versions.

The Difference between Business and Behavior Driven Development

Try Googling the term “Business Driven Development” and you might be rather confused when you see the results. About half the results will be pages talking about “Behavior Driven Development”. Some of the other results will mix up the two terms. The problem is, they both have very similar names, both have identical abbreviations and both are to do with developing applications for business. So, what is the difference? 

Well, Business Driven Development is somewhat of a philosophy. By contrast, Behavior Driven Development is a narrowly defined software development methodology. In Behavior Driven Development you follow a rigorous process to take you from feature definition to finished code. It relies on domain-specific languages such as Gherkin and requires the use of tools to convert features into tests. Our recent blog talks more about Behavior Driven Development. 

If you look at their origins you can also see why the two paradigms differ. Business Driven Development came out of work done by IBM and the Object Management Group round the turn of the Millennium. Back then IBM was focussed on delivering enterprise scale software for some of the biggest multinationals globally. Therefore, Business Driven Development was optimized for this. By contrast, Behavior Driven Development is a refinement of Test Driven Development. So, it is a way of formalizing TDD to make it more focussed on delivering enterprise software.

How Functionize Can Help You

Increasingly, even complex enterprise software is being accessed via web or mobile frontends. And here at Functionize , we specialize in autonomous testing of such systems. Our NLP Engine lets you write tests in plain English. So, this means you can define the tests during the design phase. We make visual verification of test outcomes easy, with before, during and after screenshots for every step.

Our ML Engine uses machine learning and other AI techniques to ensure that tests are self-healing. Minor changes to the UI or layout won’t break your tests. For more complex failures our Root Cause Analysis can track down the actual trigger for the failure. You can then repair the test with One-Click Updates. For systems that don’t have a web or mobile UI we offer Autonomous Template Recognition. We even make it easy to do performance and load testing on your system.

Functionize streamlines your testing, freeing up time and resources to concentrate on the other critical steps in the development process. Why not speak to us and give it a try?