TIBCO CTO: Beyond APIs, IT stack composability is the sum of many parts

Levels of composability

Petracek reminds us that composability manifests itself at various levels:

• Composable infrastructure & networking.
• Composable analytics and business processes.
• Composable application design, development and testing.
• Composable application usage, at the user level.

In practical real world use case terms, we can even talk about composability paving the way to decentralised finance (DeFi) and blockchain.

The concept itself is not new, as composable design approaches have been discussed and utilised for a number of years. So what does the TIBCO technical chief think it really means to be composable?

“Formal definitions exist, but I like to think of composability as the ability to dynamically assemble reusable ‘building blocks’ into new capabilities to support user requirements and business needs. This may involve provisioning various cloud infrastructure services such as storage and compute, combining APIs into a new service to perform a certain function, building data pipelines from logic operators to provide an analytical workload, joining process fragments for a new business process, and more,” said Petracek.

These blocks as they are described here may of course be swapped out or reworked independently; they can also evolve as business needs require.

Beyond APIs, the sum of many parts

This is why Petracek is firm in his opinion that composability doesn’t just mean APIs and the option to form synaptic connections between operating systems, applications and services (what APIs do, obviously), despite the fact that APIs are indeed important.

“It is not just about APIs, although that is one enabler of successful composability.  This statement is also true with microservices, DevOps, cloud, micro frontends, RPA, analytics operators, containers, or any number of other technologies. Each of these items by itself does not complete the vision of a composable enterprise. Rather, it is the combination of these technologies, along with proper design practices, organisation structure, and culture that makes composability possible,” said Petracek.

Given the shape of the TIBCO corporate playbook and central technology proposition, we would expect the company to be talking about the importance of data integration.

TIBCO CTO Nelson Petracek: Composability is not enough – it must be combined with an element of discoverability & observability.

In this context, the company insists that composability needs to be a common thread and binding fabric that runs across the entire software stack. It needs to be based not just on static interfaces or contracts, but also on context, time, defined goals and constraints. 

“From an application standpoint, it can be powered in many forms, from static or design-time definitions, to assembly via declarative approaches, rules, or even AI/ML and belief-desire-intent software models. It must encompass not only business logic, but also infrastructure, storage, networking, execution environments, data the end user experience, and security. It must also be dynamic, as fixed or point-to-point ‘building block’ links are not sufficiently dynamic or agile to meet the demands of today’s evolving landscape,” said Petracek.  

Composability needs (meta) discoverability

But delivering ‘building blocks’ for composability is not enough – the approach must be combined with an element of discoverability, or the ability to quickly and easily discover the components available for composition. 

If we were printing the tech show T-shirt to convey this (above) truism, it would read: 

Composability + discoverability = ability vs. composability – discoverability = fragility.

Thinking about how to achieve discoverability, TIBCO’s Petracek is adamant on the absolutely critical need for metadata to defines the available elements, their function, inclusion in other areas, security boundaries, limitations, associated quality and numerous other attributes. 

“It is also helpful to think of this metadata as a graph, instead of name-value pairs or rows in a database. Composability is based on relationships and treating these relationships as queryable, first class citizens, is key to understanding how the various layers of the software stack are related and utilised,” he said.

Build up and (carefully) tear down

As a final thought (and this is perhaps a comment that really reflects the work carried out with TIBCO’s working customer base), Petracek wants us to remember that composability needs to be thought of as not just a way to build something up, but also as a way to facilitate tearing things down. 

“Composability should not be used to build a monolith, or the benefits of such an approach will not be achieved. Be patient, as the magic does not come immediately,” he concluded.

The internal mechanics of any truly composable software stack are no point-and-click or drag-and-drop affair, regardless of how many pre-architected shortcuts, templates and (software development) accelerators we associate it with. Composability needs discoverability, manageability and observability, otherwise we don’t know what to compose with or what we have composed. Finally, then, composability is not just APIs, it is the sum of all working parts… and these should be built with an eye on deconstruction as much as construction. 

If we have learned anything, perhaps it is the need to use composability and a way to build up, build down, build out and build around… that could be a software application development tune worth orchestrating.