Business Agility through Model Driven Development

Recently I was asked to give a talk in a TED like setup. This meant 18 minutes to tell my story. I couldn’t go into much detail, but the message had to be clear: a nice challenge! This post contains a short review of my talk along with the slides. Enjoy.

For a long time we know from Charles Darwin that it’s not the strongest who survive, nor the most intelligent, but the ones most adaptable to change. The same can be said for organizations. They need to be agile to survive todays dynamic business landscapes.

The problem is: people don’t like change. Meaning, changing organizations isn’t that easy. And to make things even more complicated: software doesn’t like change too.

A couple of months ago Tim Bray wrote a post titled "Doing it wrong". In short it stated: due to the excessive complexity of enterprise software, big projects fail. Again and again. This post triggered quite a discussion. The conclusion? Complexity slows change, and complexity just keeps growing. Cameron Purdy tells the story of E-bay: written by one guy in one day! Version 2 took him a couple of weeks, version 3 took many years, and version 4 will probably never come because the system is so complex that it literally cannot be replaced in total.

In this context, the big question is: how to align dynamic organizations and software?

I think three important things are needed:

  • Provide short feedback cycles. Automating business processes starts with process design. From the start you need iterations, a lot of them. They should be as short as possible to align the results of each step with its input. Include feedback from your functional requirements into your process design, include feedback from the realization phase into the functional requirements, model-deploy-test-model-deploy-etc. And finally learn from the production system by monitoring it and feeding that information back in your process design.
  • Involve domain experts in software development. The way to close the gap between business and IT is to involve the business in software development. Make sure domain experts are part of the software development team. No… domain experts won’t create all software on their own, but they should be part of the team and pair up with technical people.
  • Use a ubiquitous language. The gap between business and IT will not be closed by teaching domain experts to program. What we need is a language which can be used by both domain experts and programmers. A ubiquitous language, as Eric Evans calls it in Domain Driven Design.

To make this work in practice we need improvements along two dimensions: "Ease and speed of development" and "Flexibility and Interoperability":

The Mendix platform fulfills these wishes by providing a Model-Driven Development approach to software development. The Mendix platform makes it possible to model the business functionality of an application using high level models. To make sure this functionality can be used in your existing IT landscape we added a lot of integration options (e.g. webservices, Microsoft Office, SAP). In Mendix a model of an application is defined with multiple domain specific languages. Example DSLs are a business rules DSL and a mapping DSL (more examples). The Mendix platform is based on direct model execution to improve the ease and speed of development. We also provide Model-Execution-as-a-Service options to deliver cloud applications.

To conclude: the Mendix platform is designed to make software development easier, faster, and more flexible. Hence, the Mendix platform creates more business agility through model driven development.

It’s quite a short article, so I guess you have a lot of questions and remarks. Please shoot!
How do you think dynamic organizations and software can be aligned?

Be the first to comment!

Leave a Reply