Composable Architecture — DZone

Introduction

There has been a change in basic assumptions by which the software selections happen in an organization. Though principles, policies, and guidelines dictate the same, in most cases the following factors have a direct bearing in the selection of products, technologies, and development:

• Existing skills within an organization
• Availability of the chosen skill in the market
• Protection of existing investment in infrastructure, IP, human resources
• How the chosen product/technology deals with the existing IT landscape
• And of course, other tangible benefits such as TCO, ROI, time to market, etc.

Let us get into the brass tacks of composable architecture. Every architecture is made up of domains and capabilities mapped to the domains. Each capability can be fulfilled by one or more solution components and vice versa.

Composable architecture does not deviate from the above principles of domain decomposition; it only differs from the composition of the components to achieve the desired business domain functions.

The entire architecture revolves around the principle of variability. What it means is variability can occur in technical layers or functional capabilities.

Let us take for example the risk management framework as a domain. This domain deals with various elements of the customer such as the following:

• Know your customer
• Financial fitment analysis
• Fraud analysis
• Relationship analysis

Each of these analyses needs to be performed to qualify a customer for onboarding into a financial institution. The capabilities could vary based on the technical and functional components (Lego blocks) which are stacked against each domain as shown in the schematic below:

Let us take KYC as an example and get into the details. The below diagram has a KYC domain with four Lego blocks, however, it’s managing the same function “KYC” but from multiple dimensions and each has its own cost of implementation, cost of operation, pros, and cons. And each one would suit a different segment of customers. For example, the Gen-X and Gen-Y customers prefer Video KYC or a third party, whereas senior citizens would prefer the old-school way of manual analysis as their handwriting might not be fit enough for an OCR. This is the variability a composable architecture brings to the table.

As rightly indicated by Gartner:

By 2024, the design mantra for new SaaS and custom applications will be “composable API-first or API-only,” rendering traditional SaaS and custom applications as “legacy.”

Evolution of Architecture Styles

Architectural styles have come a long way, starting from monolith green screen applications to till date composable architecture. Each style comes with added advantages and complexity. Currently, the chosen style is microservices-based architecture which provides flexibility, agility, and faster time to market. However, the microservices architecture style lacks composability in terms of ad-hoc inclusion/exclusion of capabilities in each domain.

All these architecture styles do not provide a composable capability, however, providing flexibility in increasing order with microservices architecture provides maximum flexibility and agility.

The need for composable architecture is more business and market-driven rather than technology-driven. In the current scenario, disruptive innovations happen on a small scale as well as large. For example, an AI-based, ICR-based KYC is an innovation in the KYC space whereas something like metaverse is a large-scale disruptive innovation that might not be a candidate for composable architecture.

Key Principles in Composable Architecture

Composable architecture is a complete, ground-up new technical innovation, and it is an incremental innovation on top of the popular microservices architecture. As explained in the above section, composable architecture has the capability to add or exclude ad-hoc capabilities for a particular domain without impacting the modularity of the architecture or the services orchestration.

Two fundamental principles need to be followed:

• API first: API becomes the fundamental philosophy of providing as well as consuming the business functionality
• Just-in-time orchestration binding: The process of orchestration is discovered at runtime the way the services are discovered. The orchestrations need to be stored in a persistent or in-memory DB (graph DB is a good option as it can depict the sequence along with alternate paths).

Composable Services: Logical Solution View

Taking a couple of domain areas and capability areas described earlier as examples, a logical view (tech-stack agnostic) of the solution involving composable services is illustrated below:

A larger solution built using composable services comprises the following core framework capabilities:

Composability Core Framework Capabilities

Composable Decision Service

The underlying set of rules that determine and drive the functional capabilities that are applicable to a particular use case under a particular context.

Broad factors that drive this decision making include the following:

• Inter-dependencies between functional capabilities
• The sequence of functional capabilities
• Business attributes: KPIs, costs, risks
• Contextual aspects, including current and previous statuses of verifications/assessments, customer profiles and behavioral attributes, ecosystem parameters, alternate data, etc.

Dynamic Composability Points

These are essential points of application of the composable decision services, typically part of the service wiring/composability layer.

The level to which the wiring needs to be dynamic will depend on specific use cases, typically under the following types:

1. Dynamic wiring of services is based on a set of business attributes and rules within the same domain area — this would be similar to a decision tree, with varying degrees of complexity.
2. Advanced scenarios may leverage AI capabilities to drive composition (e.g. historical customer behavior data/alternate data could determine video-KYC is mandatory)
3. Cross-domain composability (either type-A or type-B, but covering functionality capabilities across different domain areas)

The above approach towards composability can be applied at the orchestration/choreography layer as well, apart from composability within single or multiple domain areas.

Composable Services: Solution Realization View

While there are multiple options for solution realization of composable services, the illustration below takes the example of leveraging graph databases to achieve the same.

Graph databases are extremely useful to model connections between different objects/entities. In this case, the objects/entities are the microservices themselves that are wired through different mechanisms (APIs, event-driven, other). This approach might be useful in cases where there are many services/APIs with complex inter-relations (with each relationship being driven by different attributes), that need to be wired together.

Alternate approaches could be to leverage a rule engine or AI-ML model to drive composability.

Composable Architecture Pattern

The following section explains a representational architectural pattern and how composable architecture could be realized. The following are the key components of the architecture patterns:

• Micro-app — Typical event generators in a digital scenario
• Event backbone — The event backbone handles the entire event detection, propagation, and processing
• Channel services — The BFF services that implement the channel-specific implementation
• SOR — System of records
• Event processing — Event processing engine where the technical events are converted to business events
• Event topics — Different topics which are propagated for different purposes
• Event store — Time series database to help implement transaction compensation
• Event action correlation — Name value store where the events are mapped to the actions to be performed, in the sense of whether a particular API needs to be invoked or a process orchestration to be initiated
• API gateway
• Domain services — All the domain services that wrap the business functions
• API registry — API discovery registry
• Composable fabric
• Orchestration registry — This registry helps to discover the process that needs to be triggered based on the business event which was provided by the “event action correlation” component.
• Orchestration binder — This component binds the API orchestration at runtime so that flexibility is provided for the orchestration. Any changes to orchestration against a process are mapped here so that the necessary composability can be achieved. This generates the BPMN-based execution scripts that get propagated to the orchestration execution engine.
• Orchestration execution — This component monitors the state of the orchestration execution and manages the state of the process. It’s a runtime component of the process like a process engine but lightweight and fit for purpose.
• Orchestration compensation — This is the framework required for orchestration roll-back in case of a process failure for several reasons.
• Notification — Notification component to pass the state of the orchestration to the event topic so that the subscribers can consume the same.

Conclusion

The intent of this article is to bring a perspective on composable architecture and break the myth behind the building blocks of the architecture. We have also highlighted an industry scenario and articulated how the same can be implemented using a graph DB.

In subsequent articles, we will deep dive into the implementation patterns for each of these components of the composable architecture

Originally published at https://dzone.com.