In the first part of this series, I gave a quick introduction of the MDSD approach. Let's now enter in more details. I will explain here one of the main motivations of going for the model driven paradigm shift or: how a model driven approach can dramatically help make developing high quality software faster and easier.
Part 1: Toward generative programming? The case for Model Driven Software Development: A quick overview of the MDSD approach
Part 2: The case for Model Driven Software Development - Developing high quality, well designed software applications is hard and expensive – MDSD can help!
Developing high quality, well designed software applications is hard and expensive
The benefits of designing and implementing applications using a proper layered architecture approach, good separation of concerns, relevant design patterns to make the solution flexible, extensible and maintainable are not to be proven anymore and is a common understanding in the industry. However designing and implementing high quality software this way does take time and is expensive. And this will NOT help you deliver faster. YES you will produce better quality software but it will not necessarily make you more productive, at least not in the short term. It does not mean you should develop bad quality software and YES developing quality software with good design practices will in the medium/long term range be VERY profitable and even open windows for extra evolutions you did not even thought of up-front. But it can prove very difficult to sell quality practices for short projects where the extra cost and time involved for doing a state of the art design up-front will be overkill. And not only the design but also the implementation phase on a highly engineered application can cost you extra resources and time. If you indeed have a layered architecture, then implementing a new functionality will most probably involve writing code in all layers. And if you have designed your application using design patterns, then you will probably have to regularly create a set of new classes for any new feature in your application. A good example is the MVP pattern: for any new user interface you want to include, you have to create not one but at least three classes for that matter.
Maintaining a software application is expensive
Many studies state that the TCO (Total Cost of ownership) of a software application for a big part due to maintenance and evolution AFTER deployment to production! This means that what is expensive is not so much the development of an application but its exploitation and maintenance over time.
Implementing a well-designed, state-of-the-art application requires validation and any new development should go through a full validation process, may it be manual (peer reviews), automatic, or both. Don't do that and you can be sure that your quality will degrade rather quickly with time, and inconsistency and hacks will be introduced in your design. And the more engineered your software application is, the more difficult will it be to keep it this way and not introduce bad practices or hacks in the design, which could prove disastrous in the long term. Yes you can document your technical architecture and design principles but it means that it is again extra cost involved, thus increasing the TCO of your application. Moreover you need to find a way to keep the knowledge and know-how in the company and make sure that any person leaving the company does not do so before a proper knowledge transfer inside the company…
On the other hand, a poorly designed software application will most probably cost even more to maintain and evolve. And maintenance and evolution of such an application can to some extend become so difficult that no-one dares touching too much the code base, thus decreasing the ability for the application to evolve and decreasing the application users' satisfaction.
The case for the model driven approach: make quality easy and cost effective
YES it is very frustrating when a client tells you that he understands where you come from with your idea of writing state of the art, well engineered solutions, but that unfortunately for his project he just wants something delivered fast and at a reasonable price. And unfortunately this scenario is not uncommon. So what to do? Forget your dreams to create great designs and develop applications as they should be? Forget about the benefits of well designed quality software solutions for your clients with low budget or working with tough time constraints?
Well this is where proper tooling and especially the model driven approach can help in this direction. Because a properly targeted DSL and associated tools can eliminate the extra effort required to develop a highly engineered solution by automating the creation of all the classes, components and other artifacts required to full-fill the application design. Of course what requires (a lot of) time is the writing of the DSLs and associated tools that you need. However this work will then be reusable for all the features of the application, for the evolutions of the application and for future projects. This makes the initial investment very profitable, not only long-term on the initial project, but even short term for the actual project and for any new project starting. One way to overpass the extra cost involved in writing the DSLs and tools is to find on the market existing DSLs or at least existing tools that can help you quick-start the writing of your own DSLs. Finding already existing functional DSLs that suit your business is hard as any business has its own specificities and rules. However finding a technical DSL is easier as they are reusable horizontally across domains. And I will again give the example of a now very common and well known DSL: the ORM tools. But other more advanced tools exist to generate more than just the database access and persistence part of the application.
The case for the model driven approach: reduce the TCO by reducing maintenance costs
One more benefit of using a DSL approach is also the following: when you are using a DSL to model and generate parts or all of your application, then evolutions of the application will be implemented by changing the model and re-generating the application. Therefore you (almost) don't have the risk to degrade your design quality by not respecting the architectural rules. And you don't need the extra validation step to make sure the evolutions are implemented respectful of the original design principals of your architecture. This is because the design rules are enforced by the DSL itself and the code generation process! Therefore a successful model driven strategy will also result in reducing the total cost of ownership by dramatically reducing the cost of maintenance and evolutions and even further: enforce the software quality in the long term.
We therefore talked about what I consider being the main motivation for adopting the model driven software development approach: the MDSD approach enables the cost effective implementation of high quality, highly engineered software applications while dramatically reducing the maintenance and evolution costs and enforcing the application quality and stability in the long term.
I will keep writing more on the model driven approach, so stay in touch if you like the topic and enjoyed the reading!
Comments