What do Business Process Design and Software Design have in common?


One of the generally accepted strategies in producing high quality software is the adoption of SOLID principles in code production. 

The goals of adopting the SOLID programming principle is to produce high quality small-grained components which you can be easily re-arranged to meet new business requirements. 

This allows software teams to deliver faster and enables business to achieve faster time-to-market.

The “S” in SOLID refers to the Single Responsibility Principle. This principle states the following:

"The single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility”

If we substitute the highlighted word class above with  business process components  sub-process" or "department" "role"  you discover similarity in goals.

However, the application of the single responsibility principle in both business and software has some challenges.

In the software world, as Mark Seemann points out, the application of the Single Responsibility Principle (SRP) leads to many small classes.  On large projects, some developers new to the SOLID concepts feel overwhelmed by the amount of navigation that is need to find out what a high level component does and also about the shear number of ways in which the software components can be combined or composed to create a solution.

In the business process world, as my colleague and founder at ChangeDriver,  Erik Arnbak points out In today’s fast-paced and highly competitive marketplace, it is crucial for enterprises to be capable of change, in order to remain profitable and up-to-speed. However, change management has always been an issue as enterprise has difficulty identifying the right things to change”. The solution - a live business process directory.

My experience from both the business process and software design areas, is that the benefits of having many reusable components or sub-processes out weigh the disadvantage of needing a “component directory” to help discover or navigate large designs. A typical example is trying to find out which component/department is responsible for a given action in a large design. 

I have found that I can use a business process tools like ChangeDriver to model and provide a directory for software I have built using the SOLID principles. 

In ChangeDriver I use the classic swim-lane diagram to achieve this. 


In the diagram above, which is produced using ChangeDriver and is the blue print of real life software components running in production, the swim-lanes represent the software components. The green boxes are responsibilities assigned to the given software component. The yellow boxes are the input required for a software component it to perform its responsibility. The yellow boxes may also represent the output or side-effects of the software component.

From the diagram its easy to get an overview of how many responsibilities a component is allocated. This is just the same way in which constructor over-injection helps detect the violation of the Single Responsibility Principle.

My ultimate goal is to use SOLID, ChangeDriver, Domain Specific Languages and Code Generation Tools  to produce software robots.