Composability: Old Wine in New Bottles?

hi I’m Sandy Kemsley of column2.com. I’m here for the Trisotech blog with some thoughts on composable applications.

Composability, in its most general form, is the ability to assemble components into a variety of different configurations. Think of Lego, where each building block is a component, that can be assembled into an unlimited number of larger structures, from rocket ships to castles. Now, composability in software development is the ability to create applications by piecing together software components. Not really that different from the Lego example. Now, funnily enough, it’s being promoted as a “hot new capability”, and I even saw an otherwise quite reputable source describe composability as a unique characteristic of cloud computing. It is, however, neither new nor unique to cloud computing, although there are some modern twists on it, that I’ll go into in a little bit more detail.

Now, for you old-timers in software development, the idea of reusable components dates back to the 1940’s when subroutines were first described. A subroutine is a reusable self-contained set of functionality that can be called from other applications. Which is pretty much the same high-level definition as a function, a service, or even a microservice. Yes, there are technological distinctions between all of these, but they all exist for the same purpose: being able to quickly assemble capabilities into applications, without having to write all that code yourself every time, and then being able to rearrange the capabilities, just by rearranging the order in which the services are called. In short, composability makes it faster to create applications and then to change them, while allowing you to include functionality that you didn’t have time to create yourself or maybe you didn’t have the skills to create yourself. So speed, reuse, flexibility, and enhanced functionality are the things that we get out of composability.

Components, that your organization creates internally, could share engines and data stores. So, for example: services that access processes in a business process management system, likely share the same underlying BPM engine, and probably even the process state data services that access your legacy systems are sharing the same legacy data store in the back end, which makes them inherently stateful as well. This is really the modern version of our old subroutines, where we were developing reusable ways to work with our own methods and systems.

Because many of the services that you may want to include in your application, don’t exist within your organization. And you’re going to be calling external services when you’re composing applications. External services are more likely to be completely self-contained and stateless: they’ll have their own engines, they’ll have their own data stores, and all of that is going to be invisible to you as the calling party. You see the service interface, but you don’t need to know how they perform the operations as long as they do the right activity for you.

Things do start to get more interesting in composability with cloud architectures.

Now, again for the old-timers, think of these more like those third-party software libraries, that you used to include in your projects to perform specific functions that you didn’t want to develop yourself, or maybe had functionality based on someone else’s intellectual property built into them. A key enabler of today’s composability is the interoperability provided by these standardized calling interfaces. And that’s where cloud architectures have had a big influence.

So these days, we’re all using REST and similar API formats to add in new components to our applications regardless of where they are whether these are internal or external services. The components could be running on the same server as a calling application, or they could be in a different container within the same organization, or they could be on the other side of the world and managed by a different company. And it doesn’t matter. We’ll use the same interface to compose them into our applications regardless.

These standards also allow for language interoperability

So that a component created in Java, or Cobalt for that matter, could be called from a low code composition platform, or it could be called from a Javascript web app and neither side, either the calling side or the service side, has to know anything about each other’s technologies. We have that interoperable layer in between. And that’s definitely an improvement over the old days, where my Fortran programs could only call Fortran subroutines.

I have more to say on composability, particularly on best of breed component approaches, and the difference between low code and model driven. Check out my next video next month to hear more about this.

Follow Sandy on her personal blog Column 2.