DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Please enter at least three characters to search
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

The software you build is only as secure as the code that powers it. Learn how malicious code creeps into your software supply chain.

Apache Cassandra combines the benefits of major NoSQL databases to support data management needs not covered by traditional RDBMS vendors.

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

Modernize your data layer. Learn how to design cloud-native database architectures to meet the evolving demands of AI and GenAI workloads.

Related

  • Spotify Backstage: A Unifying Force for Developer Experience
  • Oracle Maximum Security Architecture
  • Which Tool Is Better for Code Completion — Azure Data Studio or dbForge SQL Complete?
  • Architecture and Code Design, Pt. 2: Polyglot Persistence Insights To Use Today and in the Upcoming Years

Trending

  • Building Resilient Networks: Limiting the Risk and Scope of Cyber Attacks
  • Mastering Advanced Traffic Management in Multi-Cloud Kubernetes: Scaling With Multiple Istio Ingress Gateways
  • Assessing Bias in AI Chatbot Responses
  • Customer 360: Fraud Detection in Fintech With PySpark and ML
  1. DZone
  2. Data Engineering
  3. Databases
  4. Composable Architecture

Composable Architecture

This article discusses the concept of composable application architecture and the architectural pattern. It also includes a real-world industry example.

By 
Periasamy Irisappan user avatar
Periasamy Irisappan
·
Krishnaraj Sivaramakrishnan user avatar
Krishnaraj Sivaramakrishnan
·
Updated May. 13, 22 · Tutorial
Likes (19)
Comment
Save
Tweet
Share
19.7K Views

Join the DZone community and get the full member experience.

Join For Free

"Composable architecture: not exactly Legos..."

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.

Domains and capabilities breakdown

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:

Block stacks: KYC, financial fitment analysis, fraud analysis, and relationship analysis

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.

breakdown of block stacks: domain is the base and capabilities are stacked on top

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.”

Source: Gartner

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.

 Monolith > 2-tier > 3-tier > API enabled > Microservices architecture


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:

Composable Decision Service diagram

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.

solution realization view/graph database

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.

Composable Architecture Pattern diagram


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

Architecture Database

Opinions expressed by DZone contributors are their own.

Related

  • Spotify Backstage: A Unifying Force for Developer Experience
  • Oracle Maximum Security Architecture
  • Which Tool Is Better for Code Completion — Azure Data Studio or dbForge SQL Complete?
  • Architecture and Code Design, Pt. 2: Polyglot Persistence Insights To Use Today and in the Upcoming Years

Partner Resources

×

Comments
Oops! Something Went Wrong

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • support@dzone.com

Let's be friends:

Likes
There are no likes...yet! 👀
Be the first to like this post!
It looks like you're not logged in.
Sign in to see who liked this post!