The need to deliver better customer experiences and business agility have led to the concept of the composable enterprise. For example, in this article, Gartner lays out a compelling argument for organizations to follow the four principles of modularity, autonomy, orchestration, and discovery. At its core this means a decoupled, more agile organization so that business processes can pivot quickly, and technology applications can be composable. 

In this post, we’ll explore how to make that vision of the composable enterprise a practical reality. We’ll create a technology architecture that can strongly support this vision of a composable enterprise. We will also anticipate and address the two primary challenges for realizing this vision—unifying business processes and avoiding data reconciliations across the applications.

To create the examples illustrating the composable enterprise, we’ll use concepts from the Daml smart contract language. We’ll also use the features of the Canton interoperability protocol to integrate the business logic of various applications regardless of their technology stack.

Our example business process

As an example of composable business architecture, let’s consider a practical use case that many of us are familiar with—a telecom company that provides your broadband internet as well as your cellular service. Like any organization in any industry, multiple business units generally have evolved over time and often have different regulatory requirements. So it is typical to have diverse technology infrastructures and business processes that need to be integrated together to provide a unified front to the customers. 

In our telecom example, customers get a bundled discount depending on different parameters of their cellular and broadband subscription packages. For example, if they have a platinum broadband package, then they receive discounts on each cellular line. Likewise if they have multiple cellular lines, then they receive an extra service on the broadband plan. The combinations are endless.

The challenge that we will be addressing today is of creating composability so that the business processes are unified and that changes in one unit (e.g., a new cellular connection) do not need data transfers or reconciliations between multiple applications. In other words, a golden source of data across the enterprise is created. These two capabilities will allow the enterprise to pivot quickly as business needs change—or in other words, lead to a composable enterprise.  

First, let’s assume that a customer relationship and the customer’s updates is represented using traditional architecture as follows:

Each business division has its own database infrastructure, and then the updates are synced via different mechanisms. Regardless of how the updates are synced, you’ll note that transfer of data and reconciliation will always be needed to keep the records in sync. The need to keep all this running, while still maintaining data integrity, masking, and compliance, causes tremendous complexity in the enterprise technology landscape. 

This traditional approach of integration and syncing multiple databases leads to challenges as soon as a “customer” view is required. See this article by Gartner on 12 data and analytics trends for 2022 that brings out the need for a common data fabric to enable AI and analytics. In fact, the availability of clean data is also a must to build a composable enterprise business.

To simplify this, we’ll create the overall customer relationship using Daml smart contracts. The conceptual diagram becomes something like the below:

As you can see, the problem of golden source maintenance has been removed. The smart contracts layer maintains the golden source of data automatically based on unified business processes that span both business units. Moreover, within the golden source, we can now achieve full privacy and data segregation between the business divisions, and also more granularly. That’s because a smart contract language like Daml maintains privacy at the “Party” level. A “Party” to whom the data is visible is an entity that takes an action or is a stakeholder to a transaction. Because a business process in Daml is defined in this way, users would only be able to see transactions on the ledger to which they are a party. It follows that based on the need-to-know privacy requirements required by an enterprise, specific smart contracts would be created with different users as stakeholders. For example, while an overall customer relationship contract may be made available to customer services representatives from both enterprises, the smart contracts that contain the details of each relationship may only be available to specific users from within that business unit. For more details, refer to this explanation of how this enhanced privacy protection works.

How would we collaborate in a composable enterprise?

The collaboration between multiple business units and applications of a composable enterprise can be achieved through smart contracts that encode the rights and obligations of the parties. As mentioned before, one of the initial contracts to be created would be a “customer relationship” contract. This will be created by the business entity that onboards the customer first. Then, subsequent business entities would refer to this contract and add their relationships to it. The customer and both business units are signatories on the contract, which means that changes to this contract can be done only after every party has provided its consent. This capability is called a multi-signatory pattern. Both business1 and business2 have access to this overall contract without necessarily having the permission to read the actual, more detailed customer entitlements from the other business unit. That provides for strong privacy and compliance. We can of course model this any other way as well, to suit the business needs.

Now, based on this relationship, a customer representative (or even a chatbot) can avoid swivel chair operations and effectively service the customer.

We achieve this by adding a right to this smart contract. In Daml, every action that can be performed is a right that is afforded to the party in question. In our hypothetical organization, we have modeled a chinese wall between the broadband and cellular organizations, but naturally, we now want to give business1 (say, the broadband division) the right to update the broadband package that the customer is subscribed to. 

After adding the “right” for each business division, the conceptual model looks like this: 

Each business unit has the right to update their own part of the customer relationship. This makes sense because Business2 should not be able to alter the package that is owned by business 1. Thus, through the system of controllers and signatories, Daml provides regulatory and compliance guarantees built right into the business process model.

In our example, when the broadband division exercises this “right” and updates the broadband package, contrary to what happens in legacy technology architectures, we now avoid the usual data transfers and reconciliations. Instead, all parties will access a common, golden source of information, which in turn makes available only the information that a business unit needs.

So, in our simplistic use case, an update to the broadband package above will now automatically trigger a contract on the cellular side of the business. That way they can adjust the customer bundles as needed. In most cases, these subsequent actions will be automated.

Thus, there is no need to transfer or send data or messages back and forth between applications. Everything becomes a part of the golden source, fully private to the party that requires access to it.

In the updated golden source of this customer relationship, the cellular division (business2) can now update the pricing of the cellular subscription. Doing so also notifies the customer to accept new terms. This final loop is closed by sending a contract with the pricing change proposal to the customer. As you can see below, the customer has been given a right on that contract to accept the proposal. And as they do so, the original golden source of the customer relationship is also automatically updated.

This smart contract model above mirrors the business process closely (the one we decided to model), and accomplishes some remarkable things technologically:

1. No data reconciliation across the enterprise is needed. Contrast that with multiple databases that are often scattered across numerous applications, often being updated through middlewares and APIs. In the composable enterprise model we demonstrated using Daml, these databases can still exist, but will be synced tightly with the golden source of information created by the Daml smart contracts layer.
2. Unifying the business process: Enterprise and business architects finally get to have a single version of the business process to refer to—that represented by Daml above. There are no other documents or technical models to refer to. And, if the business process changes, so does this Daml model. This makes it very efficient to examine any change impacts and increase the speed of any pivots that are required. 

What about physical infrastructure decoupling in a composable enterprise using Daml?

Decoupling of the various business units is inherently supported by the composable enterprise business model above. The business logic of the organizational units can be hosted on a variety of different infrastructures and technology stacks. The Daml smart contracts layer outlined above can be distributed and synchronized across organizational units by the Canton distributed ledger layer. This way, there is full flexibility to choose the tech stack and deployment architecture for each business unit. 

The technology choices of the different business divisions will be respected by using a composable business architecture using Daml and Canton. For example, business1 could be using MS Azure, while business2 may be on Amazon AWS. The smart contract model ensures composability, making this completely transparent to the application developers on either side. All that they are exposed to are smart contract APIs from Daml.

As is evident, the deployment topology is flexible enough to support various kinds of architectures and requirements. 

What’s next in the journey towards a composable enterprise?

The model of a composable enterprise demonstrated above is simplistic, but we hope it shows how the vision for a composable enterprise is very much within reach when we use the right technologies. In this example, we modeled two business divisions being able to collaborate in real time without having to send and reconcile data back and forth. Similar use cases are in every industry. For example, Tracy Moors outlines legacy modernization in capital markets.

In addition, such an architecture provides businesses the capability to pivot quickly. Workflows can be quickly extended, and it mitigates the complex technology change management that is needed to support the vision of building a composable enterprise. Read more about the vision of the Global Economic Network that composable enterprises will plug into. Learn more about Daml here.