For prose document writers and nothing but code cowboys, there is a missing link – a way to describe system gist separated from the flavor of the year implementation method in a format that is not as flimsy and open to interpretation as prose documents.
What I propose here – and what many have proposed before me – is that we can document with models. The models are more descriptive than prose text, leaving less room for alternate interpretations. At the same time, models are less complex and easier to read than code written in the flavor and style of the year.
The model is then home to the system gist. Here it can be understood, discussed, criticized, and evolved long before it has taken the expensive form of implementation code.
What is somewhat new in what I say is that models can be compiled and executed just like code. We can then focus on using the current modern technique to execute the model. This way, the modeled solution can have a much longer lifespan than the user interface or delivery method heavily subjected to modernity and fashion.
Models can cover the uniqueness and true solution of your software.
A model executor brings your model to life in a specific environment. When one model executer goes out of style and something new is requested by the market, we do not rewrite the system gist. We create a new model executer and feed it the same model.
MDriven is the latest model executer we have created – but we have been involved in making many. A model that was executed with Delphi 1999 (BoldSoft) can be executed with c# MVC5 or with WPF (CapableObjects) today. It was executed with Windows Forms in 2003 (Borland, Embarcadero), with Silverlight in 2007, and with ASP.NET in 2005. No doubt, there will be new model executors when modernity so requires – and sure enough, MDriven Turnkey that brings any system gist to AngularJS is currently available.
One key to a good investment in software is to avoid entangling things that change for different reasons and with different intervals and speeds. Your system gist changes and evolves along with the business it supports. The modernity of the solution changes by market forces no one can control, but everyone must adapt to it.
I propose we keep these two areas apart so that they do not get confused as being the same problem.
I define Model-driven development as developing a system gist in its own machine-readable format. Build a software machine that turns the system gist into a complete software system and fulfills the required modernity aspects. Giving such a machine a descriptive name: ModernGistExecuter – we at MDriven call our implementation MDriven Framework.
The MDriven Book - Next Chapter: What is not to like