How to further mitigate Technical Debts in Low Code Development
The magic is not in discovering the obvious but in taking it and scaling it.
How do you make AI work on top of IOT? And how do you address numerous obstacles preventing companies to share their data — for the sake of coming to an acceptable AI solution? These were some of the questions that come natural if your role is the one of a trend scout or innovation manager.
So, I decided it’s time for some acceleration concepts, a framework for “shared data pools”, helping everyone to come to an effective AI collaboration faster. I suggest partnering environments in the MindSphere World e.V., an association (which spans several countries now) that connects IIOT enthusiasts, MindSphere partners and users.
A work group called “Shared Data Pools” was quickly established as the community could see the benefits of progressing in this subject.
The outcome: important contractual preconditions (a role concept for related projects) and the idea for a platform, which does both: Connecting parties for shared data pool projects, contract configuration and generation to speed up the process of project setups and safeguard the data supply chain.
Following the Mendix motto “Thinkers to Makers“ I decided to give it a try and implement the platform concepts by myself — a learning curve that included both the Academy and some support by members of the Mendix partner community (Thank you, mansystems!).
Now, imagine a B2B (Business 2 Business) environment. There is a project related frame contract, as well as a non-disclosure agreement and there are several service agreements for data pipeline building, hosting and predictive model development.
These are the most interesting questions about liabilities and intellectual property distribution. Shared data pools can be either one-time, filled on a continuous base or anything in between. The data pools can be accessible for the public, for project members or just for the model developer.
In my first platform iterations, business logic and document generation were mishandled. I separated the business logic aspect of contract modules clearly from the bloody details of text components, on/off flags and other aspects of contract generation (Thanks, Martijn Raats!)
But it was clear that even the question of which party has to sign which contract module was resulting in heavy microflows. Some might suggest simplification by moving stuff into the domain model, but it was already overloaded in my case. And none of that allows adjustments during runtime of course.
It’s time for some serious business rule engine support!
After some iterations, I found Bizzomate’s offering of an external, web based decision rule engine (Avola). A decision tree can be comfortably setup, a mapping in Mendix helps mapping Mendix object attributes as an input for each decision or service request. The executed decision tree returns not just a top-level conclusion but the result set of sub-decisions in that tree. That helps to address more complex scenarios and if it’s determining what contract modules and templates to use or who needs to sign — the use of a proper decision rule engine helps to optimise microflows and make business logic much more maintainable! Glad I found this golden nugget in our ecosystem!
