Alan integrations bring down complexity

Integrations are hard, anyone who has ever done any serious integration projects will tell you that.

Why? Every new system gives us a new dimension of complexity. Certain logic can be in one system or another. It could even be both and work together in some unknown, intricate way. Add a few extra systems and you have a very hard puzzle to untangle when you want to fix or change something. At the heart of that problem is a dependency explosion that takes place

Figure 1: the dependency explosion that takes place when adding multiple integrations in traditional software platforms (either code, low code or no code)

The picture above gives an idea of the complexity explosion that takes place when you add new models (externals systems in this case) to the mix that have inter-dependencies with all other models. Actually, it paints a rather rosy picture, as the current default is not that there will be one external system that is added, but multiple, rather separate web services calls or even multiple different connection, through the database or for instance file based. And, not to forget, with dependencies on the other side to a data model, gui and logic in that other system. See how the complexity explodes?

So one problem is all of these different, interconnected models and it does not matter if they are text based or edited in a graphical modeler like in no-code platforms. The other problem is hidden dependencies. Hidden dependencies between systems can hide in a lot of places: the same data being communicated, mixed with changes in the instance data of a receiving system can produce different results than in other cases. Triggers can go off and produce a feedback loop. Specific characters or sentences can even trigger that. All in all resulting in behavior that is hard to predict and even hard to analyze afterwards. And if your systems are not bug-free by design, each one of these different, hard to reproduce cases may trigger an until then hidden bug. Good luck with that.

Alan

In Alan, you have one application model per application and very strict, single file, business readable interfaces that connect seamlessly to these application models. That rather changes the picture: each connection to a new system just adds one extra dependency of that interface to the application model.

 Figure 2: using Alan, the complexity just goes up linearly with the amount of integrations.

And because in Alan, you are not able to perform operations that might break, it is able to guarantee that systems will behave properly at a technical level. So you might create a wrong design but you will not able to create a system that crashes, corrupts data because of bugs or loops indefinitely. This does away with all of the ‘hidden dependencies’ in between systems that are hard to track and analyze afterwards.

Alan is able to give these guarantees because it forces you to either already have these guarantees or get them from another source, like user input or an external interface. And in the Alan system on the other side of the interface, the same applies: if an open order needs a reference to an active article, you cannot connect that interface to your application model if is not able to guarantee that. It prevents run-time errors from happening, by validating design-time that all needed guarantees can be given - no testing required.

 Finally, there is one characteristic of Alan that is very useful for creating functionally correct interfaces: the complete separation between design and implementation, so between business function and technology. All other connection techniques mix these two. And as interfaces are mostly considered 'technology', they are left to developers to design and create.

But interfaces should be designed separately on both levels: what business data should go over the connection & how do we make connections and send data. Design questions of the first kind are: which products and orders should we synchronize, when do we consider an order as started and when as finished? Design questions of the second level are: do we send the information push or pull based, over a web service, files, database, etc and can the connection be intermittent, so should messages be buffered?

Alan makes designing interfaces like that not only possible, but even necessary: you will not be able to mix them. That also makes sure that interfaces can stay the same at the business level, even if you switch from web services to file sharing or to database connections. So switching to new integration technologies will not impact the interface on a functional level.