In an earlier post, I identified ISO20022 as a model-driven success story. Here, I give some other examples of model-driven from e-Government and telecommunications. They are not all at the same level of maturity, but the reason why a model-driven approach makes sense is the same.
May 8th, 2012
Modelling is a standard approach to solving complex engineering problems. When it’s not possible to figure out all the complexities of a problem as you build, you model first.
There is a fantastic legacy of magnificent cathedrals from the Middle Ages in Europe. They are the ones that remain, but it seems there were plenty that collapsed. There was a lot of trial and error, and some of it ended in error. We still build magnificent buildings, but the results are more reliable. What’s changed? Probably lots of things, but any seriously involved architectural work now involves an amount of architectural drawings, designs and models.
This is not unlike the world of very large software systems. The software industry is still in its infancy. Very many large projects fail or run very seriously over time and budget. Software developers are very proud when their software goes live – because so much of it never does. More often than not it gets shelved (collapses), not because the software doesn’t work, but because it is solving the wrong problem.
Why are Models Important?
We need them to help us to design and document software systems. Models help us to understand the problem we are trying to solve and to design the system that solves the problem.
In the world of software, modelling also has another truly significant benefit. If you model well, it is possible to autogenerate significant aspects of the software system itself. This is called model driven engineering, and when done well, can lead to dramatic savings in cost and time, as well as much improved quality. What is the reason for these gains? It’s to do with Chinese whispers. When lots of people draw rough sketches, send emails, put together spreadsheets, talk for a few minutes on the phone and leave everything a little bit loose, there is scope for a lot of misunderstanding. If you model well, and generate from the model, there is no possibility for miscommunication.
There are plenty of mature tools available now for modelling software systems: some suitable for the expert software developer, some suitable for systems engineers and analysts, but all with plenty of useful capabilities to help teams build more robust software systems. Given time, and the adoption of good modelling practices and tools, teams will get better at building the right software.