Composability: Leveraging best of breed

Hi, I’m Sandy Kemsley of column2.com. I’m here for the Trisotech blog with a few more thoughts on composable applications.

In my last video, I went through the basics of composability, and some of the benefits of composing applications by assembling components or services. Having the ability to reuse components in multiple applications is definitely one of the big benefits. As well as being able to stand on the shoulders of other developers, by calling their components from your application rather than developing everything yourself. I also spoke briefly about interoperability, which means that any service or component written by anyone, using any programming language, can be used by anyone else, creating a new application using potentially some other programming language, as long as they both use standard interfaces for interoperability.

Now, we’ve been through a few generations of these interfaces. Some of you must remember Corba and Soap, and the current gold standard is REST. As long as the component has a RESTful API and the application knows how to make a REST call, then they can work together. Now, all of this interoperability is important, because it allows organizations to take a best-of-breed approach to composing applications.

Why would you use the substandard functions that your monolithic application development environment provides when you could directly add in a better component from a best-of-breed vendor? Now, we see this a lot in the business process management world, with this push towards IBPMS (all in one app dev environments that have process engines and decision engines and user interface and everything bundled in there). Now, there are a lot of vendors that have really great process engines, and then they’ve bundled in some not-so-great versions of other capabilities, just so that they can tick all of the IBPMS boxes. Now, you can still use best-of-breed external components in your applications, but many organizations won’t because they’re already paying for the monolithic vendors’ walled garden. Plus the vendors would have you believe that things just won’t work quite as well if you don’t use their components. Now, can you really trust a vendor that wants to sell you an environment for creating composable applications, but doesn’t want you to use anyone else’s components?

The whole idea of composability, is independent building blocks after all. So you can plug and play any type of functionality into your application. If a third-party component won’t work as well, according to the vendor, you should be asking them: why not? Are they doing something non-standard behind the scenes, that would become obvious if you use someone else’s components? Are they denying external access to some shared infrastructure like an analytics data store? Or are all of their components actually one big inseparable monolithic engine under the covers?

Now, you’re going to need some capabilities as well, that just aren’t offered by your platform vendor, and this is really where best of breed becomes important. And these are usually things that are specific to your industry. So let’s say you found a great AI-driven chatbot for insurance claims, that you want to integrate into your claims application. Or a SCADA component that integrates with industry processes and physical machinery for running your manufacturing plant. You want to be able to locate any of these components in service directories and marketplaces, then plug them right into your applications. Now, I really believe that creating enterprise-strength applications that are still lightweight and agile relies on avoiding monolithic environments. Select the best low code environment for your application builders, select the best analytics platform, the best process automation, the best decisioning, the best artificial intelligence and machine learning, any other components for your particular needs. Then use that low code environment to compose them into applications. As you build those applications, figure out what other capabilities that you need, and add those. If a component no longer serves your needs, then replace it with a more appropriate one, possibly from a competitor and with cloud-based environments. You don’t even need to worry about where the component exists. Only that it performs when you call it, using that standard REST interface.

I’m going to continue on the composability topic for at least one more video. In the next video I’ll talk about the difference between low code and model driven for composability, because there’s a difference and there’s a lot of confusion over that. 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