Why Model-Driven is the solution to the evolution challenge

The only viable route to manage obsolescence

What is the evolution challenge?

Technology innovation is going fast, and this pace of change is accelerating as the world goes global and the competition gets fierce. A lot of announcements are made every day by technology providers and it does not look like this motion is going to slow down. The multi-layer style of software development has increased flexibility and capability, but has also strongly increased the complexity of software development. With the multiplication of platforms and devices, such as cloud platforms or new mobile devices, and the growing needs to connect to collaborative social networks, we can be sure that this complexity will keep increasing in the future.

At the same time, for several decades now, businesses have developed significant operational IT systems, going further and deeper in features supporting their business and vertical sector. This means the legacy is way more important than it was years ago, and it is most of the time increasing. A recent study by Gartner showed that what they call the “IT Debt” is growing at a worrying rate.

In all businesses, there is a high pressure to lower costs, while providing new services to remain competitive in a more complex environment, and at the same time bearing the increasing legacy burden mentioned above, with its set of obsolescence constraints. Some systems even run totally unsupported which might become a critical issue that will force a reengineering at some stage.

For enterprises which need to maintain and improve the systems supporting their businesses, this is a quite unsolvable challenge, at least by keeping the same approach that was used in the past.

What is our proposed solution?

In our view, it is not a solution to just apply past recipes of redeveloping the applications at each new technology wave. In fact, we do not see any client managing to do it and except for very few extra-rich exceptions, no enterprise can afford such a cost. And even if you were very rich, it would probably be a better option to spend your money on increasing your business.

At the same time, maintaining very old applications tends to be field reality, but one can legitimately wonder how long can this still be sustained without a major crisis. And such a “status quo” strategy, which is obviously less risky in the short term, is probably a sure path to death in the long term. Because once a competitor in the same vertical has been able to deal with it, it will be too late to start a reengineering which will take a long time to achieve. Competition will have killed you during this period.

This is why we think that there are 2 critical areas that any enterprise organization should be working on proactively:

A. Set measurable objectives on the reduction of maintenance for existing legacy systems,

B. Use the savings to implement new projects in a way as independent from technology as possible.

On point A, it is critical to precisely evaluate maintenance costs, in terms of hardware, software licenses and maintenance fees, and of course human expenses to run the system and correct bugs. For custom applications that are in maintenance mode, the cost is highly correlated to the number of lines of code and the quality of the application. Refactoring existing applications without any functional change can provide huge savings and is not a hard task, as long as we do not fall into the trap of changing features at the same time.

On point B, model-driven is exactly the promise of capitalizing our work at a higher abstraction level than code. We and our customers have been delivering projects that way for 6 years, and this evolution capability is obvious once you have done it.

We sum this up through our 4 tenets that come from our experience:

1. Business entities have longer lifecycles than technology and should be defined in formats that will survive technology shifts and allow supporting them without reengineering the application.

2. Business rules and process changes need to occur through short cycles that can fit into a lean continuous maintenance scheme.

3. Efficient coupling of data, model, and presentation layers including customized code parts must be guaranteed by design.

4. Coding patterns need to be standardized and their implementation automated to ensure maintenance can be performed by standardized skills.

If model-driven is the solution, why Microsoft does not seem to be interested?

Since Microsoft dropped the Oslo project, and smart and talented people like Don Box have moved to other jobs in the company, one can legitimately wonder what Microsoft plans about model-driven are. Visual Studio Magazine has even published an article somewhat positioning our CodeFluent Entities product as the future of Model-Driven on the Microsoft platform.

Why has Oslo failed? As former Microsoft employees, here are some of our views on the subject.

Microsoft is a platform company. Despite a huge product offering, most of the revenue still comes from the platform, and any initiative that structurally helps the customer in being able to move away from the platform is not very well received internally, which one can easily understand. It generates a lot of internal conflicts between product groups.

It is interesting to note that even in Entity Framework, which approaches the data tier modeling in different ways, the “Code First” approach is pushed quite strongly by Microsoft. We think coding before thinking is probably not the good approach, as the global view of your model and the real key design questions are lost, but it seems more important for Microsoft to ensure developers approach development in a platform-dependent format and directly inside the language, than take the risk to give them the opportunity to switch to another platform at a later stage.

In further posts, we will detail more about our metrics for software development performance gathered from our field experience, and the cost that we think consistent with the dimension of a project: counting tables, screens, rules, reports or entities, as well as lines of code.

In a few hours, we will celebrate our 100^th post on CodeFluent Entities blog, and give some insights on how we got there, starting from a very pragmatic field experience.