MDD for Application Development

We have by now a solid 50 plus years of collective experience in the development of commercial-purpose software. Though the field has yet to reach the maturity of traditional engineering disciplines, a few things have become very clear in this relatively short time.

First of all, software development is inherently time-consuming and error prone. If nothing else, the amount of time invested in automated and manual testing infrastructures, methodologies and feedback-cycles should make this
obvious.

Secondly, large code-bases require experts to both maintain and expand them. Investment in a code-base therefore requires a long-term commitment from the company developing and supporting it. (Primarily in the form of acquiring and retaining in-house expertise).

Thirdly, any code-base that goes unmaintained for a long time will become unmanageable. The degree to which this happens depends on many factors, but include obsolescence of the technology used to build it, lack of experts that
still understand the technology and the loss of domain knowledge required to make competent decisions regarding the code-base.

These are general observations, but I have yet to encounter anyone who will disagree with them.

With these observations in mind, making sound decisions about the selection of technologies for development is hard.

Luckily we already have the means to start tackling these problems. They are standards and protocols. (A protocol is a standard, but is usually used to refer to a standard that defines dynamic or interactive behavior). In addition, the use of standards automatically enforces another aspect, namely abstraction.

Abstraction is crucial to the development of any system (software-based or otherwise). It allows us to build on work already done and provides us with a means of enforcing structured communications between discrete components of a
system. On the networking side we have the TCP/IP suite of protocols that power the Internet. On the more general software development side we use this generic functionality to provide e-mail, web traffic, instant-messaging, Voice over IP and many more applications without regard to the underlying network implementations. The functionality is simply there.

Let me repeat that for a moment. The functionality is simply there. We have managed to unify global communications across programming languages, hardware architectures and network varieties. Proprietary protocols notwithstanding, we have a global infrastructure that services billions of people every day.

This is a fairly impressive achievement. So why do the majority of large-scale commercial development efforts fail?

In my opinion a factor that contributes to this mess is the confusion of software development with application development.

Software decisions are hard-coded and static, but application decisions have to be flexible and dynamic. The two are not compatible.

Application development, on the other hand, is behavioral. Both can be boiled down to decision trees, but their nature is completely different.

The solution to this problem is to dis-entangle the two and view software as a construct that will accept formally defined behavior (in the form of configuration or DSLs) on the one hand and on the other provide an environment
for non-programmers to model the desired behavior of a system.

This is, in essence, what Model Driven Development (MDD) is about. Separating business logic from code-base logic. That code-base logic can go down many levels is a given, but business logic is multi-layered too and this presents a
different set of problems.

Any technology stack that facilitates this separation should, however, allow for custom transformation of the behavior at a high level and at the same time allow for extensibility at a low level.

High-level transformations are primarily important for integration with external systems (e.g. XML mappings), while low-level extensions (which require actual programming) should focus on logic that is not captured directly by the modeling environment.

These considerations aside, MDD provides a new level of abstraction whereby applications can be created and changed in near real-time by analysts that understand business requirements, but have no background in software
development.

To make this work, analysts have to be presented with a modeling environment in which they can directly dictate this logic, instead of going through intermediary parties. And this environment has to couple modeling with execution so decisions can be evaluated in real-time.

MDD tooling provides us with the structure to think about processes and business continuity instead of software instructions. This is a radical change from the traditional approach because it views business architectures from the top down.

From a business development perspective, MDD tooling and architecture allows one to stop thinking about software development risks and instead focus on application development. This area is still time-consuming, but low on risk. The high resource consumption is now focused on elements that are within an analyst’s control… rather than the vagaries of some software development team.

Mostly, MDD gives us a new way of thinking about existing problems. We have accumulated a vast knowledge base of how not to do things and MDD presents us with a new pattern for mapping old structures.