MDL Development Strategy
Development team at MDL have been working really hard to deliver the MVP, and the Architecture team has delivered UML diagrams that offers a number of benefits for our internal organization.
The Unified Modeling Language (UML) will help us to model MDL systems and help us to build software that is designed to be simple and easy to use.
At MDL, we are using UML diagrams because:
- Its a great way to illustrate information systems, no matter how simple or complex.
- Help us to better understand the general overview of the schematics of an application.
- To visually express any specific needs of a system and disseminate that information throughout the business.
- Create detailed specifications and highlight any specific functionality that need to be programmed / implemented to the described structure.
- Provide an implementation-independent description used in a system that are later passed between its components.
Well, this points are valid. But why do we need to document everything with UML ? The answer is simple, Cost saving.
MDL is saving on software maintenance costs
The cost of software maintenance is rising dramatically. In fact studies are reporting that nowadays software maintenance accounts for more than 90% of the total cost of software.
So bare with me here, because there are are several reasons for this.
Software systems become hard to maintain over time, while every day more and more software is being produced.
When the documentation is lacking or incomplete, information gets lost. It costs time and effort to recover that back. Furthermore, systems tend to become increasingly complex. This makes extending a system difficult and costly.
Rebuilding a system is also not an option, it will incur high costs, as the system that needs to be replaced can become very large, the test coverage unknown and the original and modified requirements are not well documented, nobody knows how its really supposed to work.
To perform proper maintenance on a existing software a number of different activities should be performed.
The key issue that needs to be dealt with is limited understanding. In other words, how quickly a software engineer can understand where to make a change or correction in software.
40-60% of the maintenance effort is devoted to this task, If the code is not documented and the architecture is defined. In practice, this means that 60% of the time a Developer will spend working is wasted on looking for the problem, rather then solving the problem.
Continuous integration and continuous deployment
At MDL, we have decided to take this seriously and start to save costs and improve quality. What we are building is a practical and integrated approach that is able to identify problems as early as possible, and allow us to produce the best possible software.
We have presented several ways to not only save software maintenance costs, but prevent delays and deliver the best product our customers well deserve. Our strategy is based on empirical studies. We have chosen a practical solution for establishing continuous incremental improvement and thus lowering software maintenance costs.
Furthermore, we described the unique state-of-the-art capabilities of our Architecture.
Finally, using an integrated approach, we presented the financial benefits for your business, which, as we have seen, can be substantial.
Call to action
After reading this post one thing should be clear. Saving on maintenance costs will never be achieved with one major action, this is a team effort and everyone is responsible.
Our integrated approach should institutionalized in the company’s own software maintenance area.
The practical information on software combined with the a great and supportive technology is the right approach that will allow us to reduce software maintenance costs and keep it low in a sustainable way, at the same time as we deliver a great product for our customers.
Keep an eye on the next posts, where we will explain how the MDL team will build this great architecture, together we are stronger.
- Thomas Modeneis - Chief Architect
- Ivens F. V. Signorini - Backend Developer