Data is the key to No-Code programming

Data is the key to No-Code programming. When people solve complex IT problems without programming skills, they need to have a handle on the data.

With the slogan “It’s the economy, stupid!”, coined by campaign strategist James Carville, Bill Clinton won the 1992 U.S. presidential election. Placed on a sign in the Little Rock headquarters, staffers had this message constantly in front of them and could align and measure against it all the many, small decisions necessary to win the election.

“It’s the data, stupid!” is the guiding principle for the titan project. Above all else, it’s the data we need to get a handle on to create a coherent platform for iterative systems integration.

The world is changing

In the course of digitalization, the system landscape in companies is changing. Specialized software tools, machines, and systems used to be networked together to exchange planning and design data or statistical data, for example. This minor networking has the advantage that dependencies are not a problem when one tool is replaced by another or a software update is needed.

Today, the degree of networking of systems in companies and beyond company boundaries is increasing exponentially. Dependencies are no longer readily apparent at a glance. Such a complex system can no longer be simply replaced. The knowledge that has gone into automating processes would be lost.

A modern integration platform like titan must therefore be able to make complexity manageable while avoiding fixed dependencies on specialized tools. Open interfaces, easy adaptability, and loose coupling are just as important as a comprehensible presentation of data.

The single source of truth

There are several ways to describe data in a system. This involves both the documentation, which must be easy to understand and up-to-date and the technical evaluation and application of the data description.

Data schema and automated generation of documentation exist for various technical aspects. Interfaces for microservices are described with RAML or Swagger, for XML there is XML Schema and DTD, for databases SQL, and so on.

However, since the titan platform aims to be independent of specific technologies, this was not an option. We needed a technology-independent description of the data that is easy to understand and yet detailed enough so that technical aspects such as data models can be derived automatically. Interfaces and data models in databases should be defined using the same terms. The description of the data serves both humans as documentation and the system as a single source of truth. In our opinion, this is the only way to maintain the system over a long period without building up technical debt with each change.

The downward spiral

Technical debt is easily created when systems become more complex and no longer easy to keep track of. Changes are introduced without considering existing dependencies and conventions. If technical debt is not recognized and regularly addressed, eventually there will be more and more frequent disruptions and even system failure.

Networked systems, however, must both adapt regularly and grow. Only in this way can new requirements and challenges be met. In the future, the ever more comprehensive networking of IT systems will mean that management decisions will require more and more frequent changes in IT systems.

Divide et impera

The principle of divide and rule is also applied to the method of breaking down a large, overpowering, and difficult-to-control problem into many small and manageable ones.

Fig.1: Flow with Bricks and Ports

In the titan platform, based on this, processes are represented as a flowchart using flows. Flows are both the technical implementation of a process and its documentation. They serve to convey knowledge about the context so that people without an IT background can constructively collaborate on aspects of the system that affect them. Flows, in turn, consist of Bricks that are connected. A Brick solves a relatively small sub-aspect that a programmer can focus on during design. The sub-aspect should be small enough to be easily communicated and verified.

Data, Data, Data

Fig.2: Schema and transformations

Data packets are exchanged between bricks. These flow packets also represent a sub-aspect of the system. They flow through the system and leave their traces by controlling actions such as sending emails or turning on an alarm signal. Of course, they are also used to build or modify permanent data sets.

For the description of the data, we’ve developed a schema language for the titan platform, which can be optimized and adapted especially for this purpose. It serves as documentation of the data as well as a technical implementation.

Fig.2 shows how modules help to structure data and how technical aspects are derived.

titan platform takes care of the details

As humans, we are not well equipped to keep track of all the details of a complex system. Today, we use information technology and software for this purpose.

Schemas are used so that the titan platform can provide optimal support in taking care of the details of a change. For example, when bricks are connected, the system automatically checks whether the output data of one is compatible with the input data of the other. The user is informed if there are conflicts.

Bricks are used in different contexts in different flows. By describing the data, the titan platform can inform the user before a productive deployment if changes would cause problems.

Simulation and testing

Of course, changes in the system need to be tested. Testing integrated systems is challenging because data is system-specific. Creating and maintaining test data is costly. The schema helps to generate test data automatically and to test new flows.

Reusable data

Like bricks, data is represented in partial aspects. It is relatively easy to define an address.

address = [
    street = string,
    postal code = number,
    city = string
] : doc "Global definition of an address;

Like the address, partial aspects of the data can be easily described and reused in the system. The definition of a person with an address could look like this:

person = [
    fisrt name = string,
    last name = string,
    age = number,
    address = anschrift
] : doc "person with address";

If I want to describe a company contact that contains a list of people and the company’s address, I again combine the appropriate sub-items:

company = [
    company name = string,
    company address = anschrift,
    contact person = person*
] : doc "Company with address and contact persons";

The * afterperson indicates that this is a list.

Each aspect described is not a big challenge in itself. The advantage of reusability allows changes to propagate through all sub-aspects. The titan platform takes care of the details and indicates when potential problems occur. Necessary changes are made without fear of problems in operation. The system remains up to date.

The source of truth for all

For documentation, a user can use thedockeyword to add additional information. If the schema is changed, the online documentation is automatically updated.

The schema can be converted into different technical sub-aspects. In the titan platform, for example, a binary compact representation is generated so that schemas can be compared with each other or with data in real-time (Fig.2). In the future, other formats such as SQL data models, XML Schema, JSON Schema, and others will be generated.

The figure shows how global data types are used in sub-aspects of the data. From this complete data model, sub-aspects are converted into other representations for different purposes.

This creates an independent description that serves as a reference and single source of truth for both the people involved and the titan platform.

More info on titan coming soon. Follow us on Twitter @InDevOps_Titan

Here you can find the project ujoschema-py