Composability: Low-code versus model-driven

Hi, I’m Sandy Kemsley of column2.com. I’m here today for the Trisotech blog with a few more thoughts on composable applications. In my previous two videos, I talked about the general definition of composability, and why you need to consider a best-of-breed approach to components. Today I’m going to look at how model-driven fits into the landscape.

Now, although it’s not strictly necessary, most platforms that fall into the composable category are also low-code, meaning that you don’t write a lot of technical code in a language like java, but you graphically assemble applications using building blocks in a way that’s more easily understood by less technical citizen-developers and business analysts. Some low-code environments use predefined application templates that are customized by modifying parameters, so they’re even easier to use. Others allow the developer to create some simple models like a linear workflow and the data structure of the parameters, but that’s not necessarily fully model-driven.

Now, let’s look at these three concepts together and see how they fit. They are somewhat independent but there’s overlaps.

• Composability is about how easy it is to include external components into an application.
• Low-code is about reducing the time and effort to create applications.
• Model-driven is about using a standard model format, usually what are called domain models or conceptual models to graphically create the application.

As I discussed in a previous video, application development environments can be composable without being either low-code or model-driven. The concept of composability is almost as old as programming itself and it includes things like calling external libraries from traditional coding languages.

Now, low-code on the other hand, does not imply that the environment is either composable or model-driven it could be a walled garden for creating applications based on modifying parameters of predefined templates, and did not even allow any external components to be added.

And model-driven doesn’t necessarily enforce composability since it could just be for modeling and executing applications that don’t even call external services. Now, however model-driven is usually considered to be, if not low-code, at least not full-on technical coding. Although it’s usually quite a bit more technical than most low-code.

Confused yet?

Let’s go back to the definition of model-driven engineering. It’s about creating these conceptual domain models of everything related to your business: process, decisions, data, and much more. And then, instead of having to write code that explicitly defines these entities, applications are created based on these abstract representations by putting together these models. Now, business process management systems or BPMS, are a great example of model-driven application development. Since they allow you to create a graphical process model using a standardized notation and then that model actually executes, it is your running application.

You need a bit more than just the process model for an entire application, of course, but a lot of the business logic can be represented in a process model using BPMN, which is the modeling standard. It’s the same with case management and decision management. We have these three related standards: BPMN, CMMN for case management, and DMN for decision management. And these provide graphical representations for modeling, as well as the underlying execution semantics that allow these models to be directly executable. So, they’re not just pretty pictures that represent what you want your application to do, they are actually part of the application.

Now, one argument against the wider use of these modeling standards — the BPMN, CMMN and DMN — is that they’re just a bit too technical for the audience that’s targeted by low-code systems. In other words, they are low-code-ish. Definitely less code than a traditional coding language, but more of a visual coding language than most low-code environments. And in fact, you can call these executable models as components from a traditional coding language. So, even though the models might be created graphically and were done model-driven in a relatively low-code environment, then used as components in a composable environment, the whole end-to-end application development would not be considered low-code because it would be coming from a more traditional coding language like java.

So, let’s sum it up then.

• Most modern composable environments are low-code, but they may not be model-driven.
• Any low-code system, that’s really useful, allows for composability of external components, but it doesn’t have to be model-driven
• Graphical model-driven systems are considered low-code, but might still require quite a bit of technical skill, so they might not be suitable for less technical citizen developers that are targeted by some of the low-code systems on the market. Any useful model-driven environment is also composable, so we won’t even go there.

So, that means instead of the overlapping Venn diagram that I showed you earlier, which is technically correct, the way that these systems are practically created and used today would fall into more like these patterns:

• So, at the center you have model-driven development. It’s included as part of low-code because all model-driven is low-code, although it may not be suitable for really non-technical developers. And it also allows for composition of external components. So, it is included within being composable. Again, as I said not every model-driven has to be composable, but any of the useful ones are.
• So, let’s look at the next ring out: low-code. So, it includes model-driven, since we’re classifying model-driven as low-code, but there are a lot of low-code environments that are not model-driven so you have a big category of low-code that’s not model-driven.
• Now, looking at composability, any sort of useful low-code system is also going to allow for composition of external components, so really they’re all composable for any sort of practical purposes.

So, that puts model-driven as a subset of low-code, and low-code as a subset of composable. So, you need to look at your developer audience to know which of these things are going to be important to you.

Are you looking at just a composable environment?

Always, you definitely want to have a composable environment because there’s too many third-party services and components out there that you might need to put together — and see the previous video that I did on best of breed to kind of understand more about that.

Do you need to have low-code?

Yeah, if you have less technical developers, or even your technical developers can use it either for prototyping or for applications that don’t need the type of optimization or hardening that would usually be done with more complex written code.

What about model-driven?

I would say, if you’re going low-code, go model-driven. Go with something that allows you to create models, such as data models and flow models, even if they’re fairly simple models, rather than using this limited just configurable template sort of paradigm. Technical complexity can obviously vary a lot with model-driven, from these very simple kinds of models to full BPMN and DMN, but you’ll find something in there that meets all application developer needs across whatever the spectrum might be.

That’s it for today you can find more of my writing and videos on the Trisotech blog or on my own blog at column2.com. See you next time.