To err is human ...

Introduction

Software development is as much an art as it is science. The creative element introduces possibility of errors – gaps in architecture, in design, in requirements or in logic or introducing unexpected data at run time. A critical element of any enterprise application is its ability to identify and segregate problems (i.e. fault isolation - one problem should not bring down the full system) or recover from some of them (i.e. fault tolerance – retry mechanisms etc). Breaking down a monolithic application into a collection of service/micro-service helps in fault isolation at a technical level. Segregating applications by business domains and applying domain-driven architecture and domain driven design achieves the same at a business function level.

Problem Context

In a specific situation, we realized that the application in scope has three very clearly identifiable business functions – collection of data, processing of data and distribution of processed data. These functions were are tightly coupled in the application and any error/fault in the collection step would automatically mean the whole pipeline is contaminated. In such scenarios, when things do go wrong, the operations team (IT and business) had a lot of overhead in keeping up with the time critical activities as well as fixing the source of the problem and address the specific instance - the impacts are far reaching both at a technical level (to solve the root cause) and at business level (affects further in the chain of functions).

Solution Approach

We were lucky - due to several (other) reasons, the application was re-built from the ground-up. While designing, we choose to split the original application into separate sub-applications per business domain with control checks at interfaces. What this allowed subsequently was to build application function to detect faults and address at the interfaces. This had a two-fold advantage –

• The problems are now contained within one business/application domain and hence easier to isolate and address.
• The business processes can run uncontaminated in the subsequent steps as the errors could be easily trapped and addressed. This made it easier for business to recover and continue as usual.

Conclusion

The lesson is here is not how to have good architecture to make up for bad application development! But, things go wrong, eventually. The lesson is how to think through an application such that the software facilitates the business rather than being an anchor, how to recover gracefully from problems, how to live so that you can fight another day.

Business agility is not measured by how many scrum teams you have and which scrum ceremonies you observe. It is the ability of the business to react/respond to change in business context.

A deeper strategic advantage of segregating applications by business domain (i.e. building a set of business capabilities which combine to give the application features) is that it gives the opportunity for:

• Each business domain/capability to evolve separately without complicating rest of your landscape
• Each business capability can be combined in interesting ways as the market evolves, in ways which may not have been imagined when the original application was first designed. Think of it as API at business domain level!

Domain driven design is like API but at business domain level.

This is why business agility is not about how many scrum teams you have and which scrum ceremonies you observe. It is the same concepts but operating at a different level altogether. IT agility helps to gain business agility but it is not sufficient!

Is your business agile? In the next post I will explain how this approach helps business agility and why the environment is right to switch paradigms (if you have not already done it).