Within the field of business IT problems it is hard to resit the temptation to use a tool that promise to solve all your complex IT problems.
Despite the progress and technology innovation in the last 25 years some IT related problems are still very hard to solve.
To name of few typical business IT problems:
- Too high development and operational cost.
- Inflexible IT solutions when business needs change.
- Vendor lock-ins.
- Security, privacy and safety risks.
- Availability issues.
- Disasters for business operations due to the fact that minimum quality standards are not met. E.g. quality aspects like data integrity, configuration management or restoring systems still cause real disasters for business continuity.
The track record for successful large IT projects is still very miserable, also in 2019. So every sensible company is still fearful for starting a new big IT project. Since no one is immune for marketing you should be suspicious solving your real complex problems using a new holy grail IT solution. Good marketing has an emphasis that there is something real new on the table. A current trend is using low-code or no-code solutions to solve all complex IT problems that will occur during and after large IT projects are finished. Since developing IT solutions involves high cost and takes often more time than estimate the new holy grail solutions claim to solve this productivity and cost problem. But this is not all: the new low-code solutions also claim to solve all typical IT life cycle management problems.
I love new solutions that solve real problems. New IT solutions can bring real advantages for business at large. But is the holy grail promised by the new low-code tools really true and proven?
The new holy grail solutions can be categorized as the new era of MDA solution tools.
Model driven architecture (MDA) is a software design approach for the development of software systems. Model driven architecture provides models written in well-defined design language. The models consist of multiple components including model, transformation and meta-models. Tools that use a MDA approach claim to generate working software out of a model. So no more coding, just model your problem. So the promise is not to create software manual anymore, but the solution will generate software based on the model directly. So bye bye high skilled traditional software engineers?
MDA is not new. From 1980 several names have been given to the MDA idea of generating software based on a model, e.g.:
- Low code tooling
- No code tooling
- Model Driven Engineering (MDE)
- Model Driven Design (MDD)
- 4GL tools
The promises made by MDA software solutions, no-code solutions or low-code software vendors are high. So you should be aware of key aspects when evaluating if a MDA software solution solves your problem.
Key factors to evaluate MDA like tools are:
- MDA is a concept with strong underlying believes of a problem situation it tries to solve. This means that every MDA solution tool is biased and does not work for ever problem situation. So always determine first your exact problem situation and the problems or complexity problems you want to solve before evaluating solutions. An software tool alone will never solve your organizational problems that make software development costly in your organization.
- The productivity gain promised by MDA tools is not always met. When trying to solve complex problems with a MDA tool-based approach, the productivity gain is at best doubtful. Most productivity problems are not related to the software design, delivery tools or process. The hard and complex problems that impact performance in large business IT projects are related with having no general agreement and perception of the goals, requirements and principles for the IT system that must be created to solve some fuzzy problem definition.
- MDA is has a strong focus on initial productivity gain. But a continuous fast changing business context with changing requirements requires an approach and toolset that is suited for giving long term productivity benefits.
- Personal that is able to analyse, model and create and update a model in the required model language for the chosen low-code tool is not widely available. Most business problems are not modelled and solved using the BPMN standard (Business Process Model and Notation). Software engineers are good at creating software and some are also great in developing software architectures. Creating BPM models or other type of models to address business problems are no core competence of software engineers. And remember: Adjusting parameters using check-boxes or drawing lines on a canvas to outline a process is just engineering. Most real business people will never use or have the time or knowledge for making changing within business administration interfaces. Configuration using no-code tools is most of the time still programming, but with painful limitations.
- MDA tools and products developed have difficulties to keep up with the continuously changing IT technology world. Browser technology and mobile technology are constantly changing. However this is not always an evolutionary path.
- General DSL’s (Domain Specific Language) used within MDA tools rarely bring the productivity gain. DSL’s like BPMN, UML, SYSML are known to be complex to model a problem fast and correct for software generation.
- Custom defined DSL’s used by several MDA tools are not open so you are locked in by the tool and the vendor.
- Full model testing, so business process testing using the generated software is often lacking. In order to prevent surprises automated correctness testing of the model is a severe challenge for MDA tools.
- Nonfunctional requirements like performance, security and stability are hard to incorporate within a model or generated code.
- Discipline in relation with your business culture is crucial for long term success with MDA tools. Simple changes on data or model parameters require the tool process to be followed exactly. Every step in the way the tool vendor has implemented it. So you need to follow the rules of the tools to implement changes correctly.
- MDA tools are not strong on versioning and dealing with multiple parallel development tracks and teams simultaneously. Most tools are in fact based on a big design upfront paradigm, like an overall data model. Versioning on models, meta data and data of all created and generated software assets is poorly supported, if supported at all. Common practices seen in mature agile software development tools using micro services paradigms and advanced distributed version control systems are often lacking in the new low-code MDA family of tools. In large companies it is not uncommon to encounter models with hundreds (or even thousands) of entities / classes. That kind of models not only doesn’t help with developing software faster and more cost-efficiently but even has an adverse effect.
Simple solutions for complex business IT problems rarely exist. Within 2019 creating complex software always means that minimum quality levels for e.g. security and privacy are mandatory. This is not simple at all. Creating a simple solution means you have to do a lot of difficult and inconvenient work. E.g. solid and proven business and IT architectures and designs are needed. For some problem areas you should create software to generate software to solve the problem needed. E.g. creating software to test a new part of an airplane control system.
There is definitely a category of business problems that is well suited for using new latest MDA category of no-code solutions. Innovation within the field of business IT and the way business IT software is created is always needed. The latest family of MDA no-code and low-code tools do trigger innovation processes. E.g. a new tool will force you to look at your problem context from a different perspective. But never fall in love with an IT solution if you do not fully understand the problem and the problem context you want to solve.
The productivity loss of solving business IT problems is seldom directly related to your current software engineering tools or process. Software is binary. Only a problem that is well stated and constant can be solved efficient using traditional software development tools. Else use or try new machine learning techniques. Business problems where organizational and human factors have large impact on the problem situation are by nature harder to solve. The new family of MDA tools will not change this.