How Itential Scaled Integration Production with Model Driven Development

Colin Sergi is a Georgia Institute of Technology Cooperative student that spent his first rotation with Itential immersed in the complex problems of network automation.  As a member of our applications team, Colin was primarily focused on improving the overall quality of our product.  We look forward to his return next spring!

Software Development, like every other industry, has it’s “hot new thing,” which can either change the course of the industry or simply fade out in the next 6 months or even 6 days. One of those “hot new things” is the low code environment (which is based on the academic concept of Model Driven Development). While most software products are focused on engaging non-software developers through low-code, Itential has experimented with creating components of our applications using this low-code approach. As such, I would like to share some insights from our initial foray into Model Driven Development through our work on our Adapter Builder, and how it could help you.

The Theory Behind Model Driven Development

Before we get started, I’ll provide a little bit of context of the theory behind the work we do. Model Driven Development is a development lifecycle in which the goal is to develop a precise model of the problem you’re trying to solve. Once that model is created, your model would be translated into an application through a tool (in practice, generally a third-party tool). One of our automation platform’s core elements is its low-code environment and as such, we understood the value of providing our customer delivery team with similar ease of use capabilities.

How We Leveraged Model Driven Deployment

We had a very promising use case for this. As an automation software company, our platform often has to integrate with various different systems for customers. Most of these new systems use what is known as a REST API. These integrations (known as adapters), originally were created through the following process:

1. You (the developer creating the adapter), had to read through the documentation of the API;
2. Figure out how to make a specific type of request to the network, and then;
3. Complete that request.

If you think through those steps, we are simply manually translating the model provided by documentation into working code. If we were applying the Model Driven Development methodology properly, the adapter would be completed once the actual model was finished (which, conveniently for us, is before we even get involved). We could just press a button (think Staples‘ Easy Button) and generate an adapter to work with the system we needed to connect to. All that would be needed is a tool that could actually generate that code from the model. So, we determined the most common ways REST APIs are modeled (that being through Swagger/OpenAPI docs, and Postman collections), and figured out how to translate that particular model of the API calls into actual working code. This tool was created to be the Adapter Builder and has already been very popular among our customers.

So, how does this example apply to a generic application? In our case, we had a process that required a lot of grunt work and no judgement calls. What we learned is that developing all of that code through grunt work is something that no one wants to do, and really shouldn’t have to do. This shortcut can potentially save you a lot of time and effort. Assuming that you never need to actually break the abstraction (which would be an incredibly difficult can of worms that I would never recommend).

As such, I hope this quick foray into Model Driven Deployment clearly explains how it can be potentially useful. At least for Itential, it seems that actually using this to develop a full application is highly impractical; but it can save you from the more boring parts of your job. For us, instead of making a developer spend anywhere from 3 hours to 3 days on building a custom adapter for a particular service, we can sometimes complete that work within minutes, freeing us to do other tasks.