Sunday, January 27, 2013

How Model Driven Development improves business agility

An interesting observation I’ve been able to make while working with Business Process Management Suites and other Rapid Application Development tools is on how developing software with these tools helps improving business agility. Everyone working in software development knows there is a big fuzz about Agile and Scrum to bring agility to the software development process. My experience is that in many cases the software development really benefits from these Agile approaches. However I believe that by using state-of-the art Model Driven Development (MDD) tooling, we can take this Agility a big step further, to the business itself.

TRADITIONAL SOFTWARE DEVELOPMENT If you look at traditional software development, you’ll find several disciplines working together to create software. In the picture below you can see how information is handed over from one discipline into the other.


Interesting to note from the picture is that most disciplines only create “paper” files. It is only the implementation discipline that is able to create an executable program from these paper representations of the software. The distance between the developers in the implementation discipline and the business has caused many problems in the past. To overcome these problems several measures were taken. One stream tried to make the software development process more formal and “make sure” that information from one discipline translated correctly to the work of another (RUP). Other streams tried to have developers take roles from several disciplines and work “in close collaboration with business” (Agile). Both solutions have their benefits and challenges.

MODEL DRIVEN DEVELOPMENT Model Driven Development takes the best out of both approaches, it allows for each discipline to take control of its own executable models and it allows the development team to work in close collaboration with the business. Using Model Driven Development every discipline can create executable software for the aspects they are working on, see the picture below:



To give you an example: The business modeling discipline will create an executable business process model. Now you may ask yourself, “but what to execute when many requirements are not clear yet?” “What can business users expect from an empty process model?”. At the moment of eliciting and specifying the business process there are no forms, interfaces yet and there is no data available! Definitely, it is not a complete solution that the business modeling discipline creates. However the business modeler defines the process steps and defines what department or what specific role handle the steps. He specifies the service level agreement (SLA) for a certain step and where to escalate to if the SLA is not met, etcetera. Having the exact business process model in place will give other disciplines a clear picture on where their work will fit in. When other disciplines have added their models the solution starts to work. At the end of the project the business process created in an early phase will still stand!

IMPROVED BUSINESS AGILITY So how does this way of working and these tools improve your business’ agility to adapt to changes in the market or other changes in your environment? I’ll describe three ways in which MDD helps bringing agility: the ability to give feedback quickly on required changes, the ability to change one business rule without affecting other aspects of the software and the ability to have business users change business rules themselves.
QUICK FEEDBACK By being able to show the result of models in real software gives the business possibilities to feedback on all of models based on software and not on paper representations of the software. Most Model Driven Development tools have the ability to unit test models and show results while developing (Agile)

SEPARATION OF CONCERNS Secondly the different models themselves treat different aspects of the delivered software, yet fit together like pieces of a puzzle. The fact that separate models exist for each aspect means that these models can also be changed independently. Suppose a process step is worked out as a wizard that guides a user through a set of dialogs. Then the actual information gathered may change without a change of who is filling out the form. The same way the process step may be routed to a different department, without the need to change the actual dialogs. The better you are able separate concerns and keep from mixing them, the better your solution will be adaptable to new situations and the higher your business agility will become.
RULE DELEGATION Thirdly we could actually delegate models to business users. For instance a decision table readily available as a model in the development suite could be changed on the fly by a business user to update a calculation or a decision in the system.

I would like to hear your thoughts about how MDD tools could bring agility to your business. Feel free to contact me if you would like to know more...