Having worked with model-driven development for the last 20 years, I have been surprised many times by how much resistance we have met. It is not like other developers are indifferent or do not care. Many do care – but the reactions are surprisingly often skeptical and negative.

We have tried to take this as an indication that we are on to something relevant and beautiful. Big and disruptive shifts never come without agony and pain. The suggestion is that it is a defense mechanism that kicks in. People are afraid that model-driven development will change their current setup – and resistance to change is natural and triggers unconsciously. 

I do not believe in the anti-change theory. I think it is a simple case of not correctly separating the different issues at hand: modernity versus gist.

Modernity and Gist

Developers know that everything changes. Experienced developers have been left stranded with abandoned techniques and products throughout their careers. It is not a good feeling nor is it good for business or the credibility of the developers. No one likes to be forced into change by external influence, but a product that has lost new development and support must be replaced. This has led most developers to a minimalistic approach to using products. Minimalistic or gigantic – trust only the really big companies in software like Microsoft or Oracle – and things that are transparent like open source and simple tools.

The problem with traditional development that blends and mixes modernity with system gist is that change hits so hard. Everything must be rewritten once a technology change is required. If the gist changes a lot – rewrite. If modernity changes a lot – rewrite. If the fashion changes heavily – rewrite. There are more reasons to abandon made investments than what any investor dares to think about. All this is because of the mix-up of the three different areas.

If we separate the gist from modernity, we will find that most changes in technology leave the gist untouched. All different types of gist will be handled by many different approaches and technologies over their lifetime. For this, we can plan from the start.

Since few have had the opportunity to try this in real life, few know the benefits it brings.

Separating the gist from modernity protects that part of the system from the IT wind-of-change that is always blowing at hurricane strength. At the same time, free up the modernity area to change without having to change all the gist stuff at the same time. Both areas will win by keeping this separation.

As an information architect or developer of a domain work organization, the gist is the most interesting area. It is the theory and motive. This is also where the structural capital of the enterprise resides. Having this documented in a useful and actively maintained format is very attractive to any business.

For classic software architecture, Modernity is extremely important as it ties into the projected lifespan of the system, maintainability, how hard it is to build, usability concerns, security, efficiency, and overall investment sanity like “our maintenance burden must not be too disparate”. However, for a business wanting to build in-house systems to become more automated the modernity aspect is still important but they should put system gist in the front seat. It will be good for the whole business to structure their knowledge of whom they are and how they do things.

I agree that if you use no tools to manage your gist, it is easier to just mix gist and modernity and let it stew. Then sit back and wait for the inevitable rewrite need that forces you to do it all again. I propose that this is the wrong approach and an approach that is not very smart or efficient.

Looking back on many discussions over the years, I now believe that a lot of developers and software architects do not separate the system gist area from modernity with enough clarity. Many software developers also focus mainly on modernity issues – after all, as a professional developer, this is what you can reuse for different clients that all have different gist. I believe that this limits their ability to produce robust long-term systems. I suspect that this is part of the explanation for why software development has too low a success rate. It can also explain why legacy ERP systems that are so far from modernity that it hurts still have an appeal in the industry.

I believe we must be vigilant to correctly identify modernity and fashion arguments when solving system gist problems. If not, people will wrongfully let modernity or fashion arguments color their gist and by doing so, confuse both other developers and stakeholders.

This book is primarily on how to use MDriven to handle and manage gist and secondarily, how to use MDriven to help you manage modernity. I will show how the modernity issues are managed with standard techniques in Visual Studio with no limitations or assumptions – so that you are ready for all new modernity requirements that will be sailing up. Lastly, this book will cover how the gist and modernity offered by MDriven Framework are easily dressed up with the current fashion.

The MDriven Book - Next Chapter: What is next