As an enterprise architect working with large, multi-national or multi-line of business organisations, ensuring that each application you create is part of the ecosystem, part of the whole, is essential.

Every vendor has best-in-breed industry cloud applications, whether it is SAP or Power Platform, and large organisations use one, several or all of these in various ways. Whilst you could create one large solution, based on one architecture, it doesn’t mean you should. Every organisation has a sweet spot for which ERP suite suits them and which CRM or IoT vendor’s solution fits their requirements, driven by cost, technology and users, in an order or ratio defined by each organisation.

When you have groups of organisations, whether that is in the same country with significantly different structures or drivers or multi-national businesses with slight variations due to tax, costs or other localised details, being flexible in your choices of point applications, with a basis of app integration is essential. This is where building a composable architecture as your core is essential.

An Overview

Wikipedia defines Composablity as

Composability is a system design principle that deals with the inter-relationships of components. A highly composable system provides components that can be selected and assembled in various combinations to satisfy specific user requirements. In information systems, the essential features that make a component composable are that it be:

• self-contained (modular): it can be deployed independently – note that it may cooperate with other components, but dependent components are replaceable

• stateless: it treats each request as an independent transaction, unrelated to any previous request. Stateless is just one technique; managed state and transactional systems can also be composable, but with greater difficulty.

It is widely believed that composable systems are more trustworthy than non-composable systems because it is easier to evaluate their individual parts.

To say it another way, I see it is similar to Lego, or any other building block toy you fancy. Like a honeycomb of interconnected solutions, it provides the opportunity to change one of the components with out impacting the whole.

Imagine a small organisation, with an ERP, CRM, PoS and office systems. Each one is tightly coupled with the other as the business starts out, each one is pretty customised from it’s initial intention.

It comes to an inflexion point when the Loyalty system becomes cost-prohibitive or functionality inadequate and needs to be upgraded or expanded to accomodate true CRM functionality, such as Omnichannel or Marketing. Transformation of this one core part of the organisation is now restricted as we also need to change 3 different integrations.

As that application suite further expands, more change is needed to add in a proper CRM, Consumer research products and the like.

In a composable architecture, each system has a common integration pattern, decoupled or divorced, from the main application. An integration layer, the purple in this diagram, adds the flexibility to integrate at will.

A platform provides the integration between each application with a common, Industry-led data model. Replacing the CRM system now entails replacing the one set of integrations with the common standard, rather than the 4 previously.

This platform is a solution in of itself, the glue linking each app, providing listeners and subscribers to data transaction, centred around your organisations view of data.

Further, in a multi-business or multi-national organisation, separate entities could make their own choices on the systems they want to deploy, choosing the best fit for their particular needs. Starting with a chocolate box of choice of systems from your parent organisation you can swap out and add to as your business needs shift, underpinned with a common data and integration strategy.

Expanding this analogy, if you want to introduce another actor in your ecosystem, implementing AI-led reporting, for example, you have a common starting point. Implement integrations between this norm rather than with all the other solutions. With the waves of technology coming faster and faster, the bedrock of a composable architecture is essential to ensure your business keeps up.

Why?

The why has already been stated, but to list them

• Flexibility – Quicker to swap in or add a new component to your company solution ecosystem without re-creating each integration.
• Freedom – Choose the best solution for your needs, don’t stick with one stack because you think you should, use best in breed for your price point.
• Stability – No dependency on one component

Most importantly, not everything will be suitable for your current technology stack. Don’t expect to re-invent the wheel each time in your low-code tool of choice, look at the market, what tools are your competitors using, what does Gartner say? Best in breed tools might not suit you right now, due to costs, talent, time etc, but be open to expanding your ecosystem if it makes technical sense, you have the skills required, matches your budget and will give you the ROI you need to improve your business.

Steps to Start

1. Define your data

In the Power Platform world, there is a Common Data Model borne from Microsoft’s and Adobe’s partnership on common data patterns in the past. If you are coming from this stack, or any other, it is a great place to start.

Salesforce and SAP have their own variations on these, so depending on your core platforms, take their version as your starting point.

What this gives you is a standard approach to most entities, such as account, contact or opportunity. Please, please please don’t create another case/incident/request/certificate entity, re-use and relabel the standard one.

These entities will have most of what your business needs – most organisations are not as unique as they think they are. Using this base, create a model that is specific to your business. Have a shared understanding of what Account Number is for your business and how to associate contacts with cases. You should be creating data schemas in a functional or business focussed way, spreadsheets with columns and tables is just fine. A Visio with a visualisation of your ERD is enough to drive discussion and understanding.

2. Define your integration layer

There are lots of ways to integrate systems, from Power Automate to Amazon Enterprise Service Bus or Boomi. Your integration layer choice will depend on your stack, like any business choice, but is crucial that it will meet your long term aims, as well as your first steps. Power Automate can act like a bus, when a change is triggered in the source, make a change in the subscriber, but doesn’t have the complexities required for larger scale deployments.

Azure Service Bus does pay as you go, Amazon has similar, which allows you to make those first movements. Using a bus will allow you to truly decouple your apps and the various subscribers that you will have. Most people will also start with a central data repository as their first step. A data lake to hold the primary data versions for those entities that are shared across your organisation. Whilst this is not necessary, it opens up lots of opportunity for AI, BI and other intelligent operations.

3. Create messages

With your established organisation data model, create a message protocol for each and samples to aid understanding. Currently, this would be in JSON. Make sure you steer away from any alignment to one supplier, as these should be independent of the stack like the other components. This will effectively be your start. Get ready for your first subscriber and publisher and test. Ensure you anticipate growth and capacity for your integration layer.

4. Enforce decoupling

If you don’t stop app devs directly integrating their SAP with the IoT solution they just purchased, Composability becomes as redundant as fax machines. Work with your technical leadership and product owners to drive understanding of the why and what of your architecture. Ensure you are augmenting your common data understanding with every new application, re-use what you have as much as possible and do any transformation specific to the new application rather than every integration you have already done.