DEV Community: The Composable Connection

Composable vs Monolith

James Luterek — Tue, 18 Jul 2023 17:02:58 +0000

Introduction

In software development, developers traditionally had two options: build a new system from scratch or buy a monolithic software and hope it meets the requirements. A new paradigm labeled as composable, driven by APIs and the need for new UX touchpoints, has emerged to provide a new option.

Understanding the Terms

What is Composable Commerce?

Composable Commerce and Composable Architecture is creating a new solution by combining (or composing) multiple API-first software into a cohesive and powerful final experience. The final design involves multiple APIs covering the different business requirements, data orchestration, Backend-for-Frontend, and multiple frontends including a robust website. A good example is leveraging an authentication provider or email sending service instead of building one from scratch.

What is Headless Commerce?

Headless Commerce is similar in that you have an API layer and multiple frontends. The major difference is that in a headless solution all of the APIs may come from a single source. This brings it much closer to a monolithic software system where everything is built together, except instead of creating a theme which is rendered via the server, a SPA/PWA is deployed which calls the APIs. This provides more flexibility in theming and design, but lacks the same level of customization and selection you get with a composable system.

What is a Monolith or Monolith Commerce System?

Monolithic Commerce Systems provide a single software solution where everything is built together often in a single project and code base.

The spectrum of commerce systems ranges from a monolith - one massive piece of software, to composable - breaking the system up into more manageable, customizable chunks.

Major Differences

Customization

Composable solutions offer easier customization, allowing businesses to mix and match components and retain full control over the User Experience (UX). Monoliths, conversely, are difficult to customize. While composable solutions rely on multiple API-first software components, these components are small enough to be generic - there is no need to “reinvent the wheel.” Unique features, on the other hand, can still be built out with custom code.

Maintenance

If you build the composable system with SaaS APIs, such as Twilio for messaging or Amazon S3 for storage, maintenance costs are lower, and updates are easier. The underlying systems can be patched and improved without impacting the overall software. Monoliths, on the other hand, require everything to be patched, updated, and maintained together, which means higher maintenance costs. This also raises the risk of downtime.

Level of Effort

Composable Commerce systems requires a similar level of effort to deploy, regardless of business complexity. The bulk of the work is in setting up the initial design and infrastructure, but changes, improvements, or adding functionality over time are considerably easier. Monoliths start extremely easily, enabling a basic setup in a matter of hours or weeks. However, as business requirements increase in complexity, the level of effort rises exponentially.

This makes composable the obvious choice for complex, unique, or large software projects, but also for any projects that will grow over time.

Key Benefits and Drawbacks of Each

Monolith Commerce Systems

Monolith Commerce Systems present certain advantages such as out-of-the-box functionality. The decisions and architecture are predefined by the vendor, saving businesses the task of deciding on each aspect of the system. However, these benefits come with certain disadvantages. There's the risk of vendor lock-in, meaning that businesses are tied to their vendor's system and can't easily switch to another provider. This setup can also lead to slower adaptation to market changes. Businesses might find themselves struggling to update their commerce systems as quickly as they would like due to these constraints.

Composable Commerce

On the other hand, Composable Commerce brings flexibility, agility, and scalability to the table. Businesses can adapt more swiftly to market changes, enabling a faster time to market for their products or services. Additionally, they have the freedom to leverage any coding language or tools, as composable commerce systems make use of standard APIs. However, these benefits require careful management. Businesses might find themselves handling multiple vendor contracts, and it's essential to have a clear understanding of their requirements right from the beginning. These potential challenges need to be weighed against the benefits of a composable commerce system.

Potential Use Cases

Monolith Commerce Systems

Suitable for small businesses, website-centric businesses, industries with stable and standard requirements, and companies with basic processes and less competition.

Composable Commerce

Ideal for large businesses, businesses with unique requirements, companies that need a multi-touchpoint solution (website, mobile, etc.), companies aiming for modern technology, complex business models like B2B2C, and businesses that require a high level of differentiation through unique branding and experiences.

Blend

Composable is not all-or-nothing. You can borrow aspects of composable architecture into a larger monolithic system, start the process of going composable with headless solutions, or integrate composable services in your custom-built software.

Conclusion

Every software decision involves trade-offs - there is no one-size fits all answer. The choice between a monolith and composable commerce system depends on the business needs, scale, and the level of customization required. Composable Commerce offers significant advantages in terms of flexibility, customization, and scalability, but has a higher upfront level of effort.

Subscribe - https://www.youtube.com/JamesLuterek

Building Blocks of Composable Commerce

James Luterek — Tue, 18 Jul 2023 17:02:52 +0000

Composable Commerce breaks down into three main requirements, front-end, APIs, and integrations. The front-end will consist of any UI or customer touchpoint, the most common being a website, but could also include mobile applications, POS systems, AR/VR, and more.

The integrations help to combine the multiple APIs, but also to move data between them.

Finally, they APIs themselves. These are typically SaaS services and are typically what is meant when people talk about the building blocks of composable. These could include:

Product Information Management (PIM)

Products live at the center of digital commerce, without a product there is nothing to sell. A robust PIM is a foundational component and an excellent starting point. PIM enables businesses to store, manage, and maintain consistent product data. This includes attributes, descriptions, images, and technical specifications. By centralizing this core product information, a PIM helps ensure accuracy across touchpoints rather than duplicating data manually across multiple systems.

Traditional PIMs focus on the creation of products and may not be designed for serving that data to websites or mobile applications. In some projects it may be beneficial to keep the traditional PIM and add a digital PIM for enriching the data and propagating that data through scalable APIs.

It’s important for the PIM to be flexible, allowing for many prices, catalogs, languages, and variations. Limitations in the PIM will cascade down through the rest of the implementation.

Product Discovery / Search

Once the product data is defined, the next step is to enable customers to quickly find the products they need. This starts with a robust search engine which should go beyond a basic keyword search and include advanced filtering, personalized recommendations, boost/bury functionality, and configurable facets. Depending on the products, the search may also need to handle large catalogs with many variations.

The product search service also needs to be API-First and scalable, it will be responsible for powering product listing pages (PLP) and product search pages, which are both at the top of a traditional commerce funnel and get a significant amount of traffic.

Order Management System (OMS)

The OMS takes control after an order is placed. While the customer rarely interacts with the OMS, it is responsible for processing, tracking, and managing all the orders. The OMS can also participate in inventory management, payment processing, shipping, and returns. Having an extensible OMS is important to define all of the data that needs to be tracked as well as supporting custom life cycles or workflows. Having an OMS that can be properly integrated with APIs helps ensure an efficient and transparent fulfillment process, which creates higher customer satisfaction and lower support volumes.

Customer Relationship Management (CRM)

CRM tools create a unified view of each customer, storing interactions, preferences, purchase history, and enable more targeted marketing and personalized experiences. Many CRM tools also provide identity management allowing for streamlined authentication through social login. It is possible to split the customer profile and authentication into multiple services depending on the overall requirements. Since the CRM aggregates all of the customer data from other systems, choosing a solution with strong APIs is a must.

Content Management System (CMS)

It is possible to make a basic ecommerce system without a CMS, but the majority of companies have heavy content requirements and need to empower business users to make content changes. As a result almost all composable commerce implementations include a headless CMS. The CMS facilitates the creation, management, and publishing of digital content across all customer touchpoints. A major difference between traditional CMS solutions and headless CMS options is how they treat this data. The traditional system took a webpage view of content, often mixing content and markup, resulting in data that would need to be modified or adjusted when used in a mobile application or other channel. A headless CMS removes any artifacts related to the channel, so rather than creating a page with markup, a schema is defined to store the clean content which can then be formatted as necessary.

There can often be confusion between a headless CMS and a PIM. While it is possible to build a schema and represent products in a CMS, this brings issues and limitations to the project. It will also require rebuilding all business logic that the PIM provides. Instead, core product data should always be stored in the PIM. There are some circumstances where product content is split between a PIM and CMS, in these situations base product data lives in the PIM while extended details may be best suited for a more visual editor found in a CMS. It’s important to talk with an experienced architect to help decide where data should be allocated.

Payment and Fraud Detection

Payment gateways are a clear requirement for any digital commerce experience, not just composable solutions. By choosing composable API-first options for all components, more data can be leveraged when handling fraud detection. Especially data from the OMS and CRM to identify repeat offenders or unexpected behavior.

Summary

While this covers the core systems required in basically all composable commerce systems, the final solution is designed around a business’ specific needs and could include other specialized systems. These may include marketing automation, tax management, translation service, data warehouses, among others. These systems can be added or removed as requirements and objectives change. As a result, the need for extensive RFPs covering each possible requirement, current or future, is no longer necessary. Instead, the solution can evolve and grow over time, so functionality missed on initial launch can be quickly incorporated.

Subscribe - https://www.youtube.com/JamesLuterek

Principles of Composable Architecture

James Luterek — Tue, 18 Jul 2023 17:02:42 +0000

As a high-level definition we discuss composable in combining multiple building blocks, each solving for a business requirement. Digging deeper on the technical implementation, it’s clear that these building blocks must follow specific rules to ensure they can be leveraged and combined effectively. Combining many small monoliths would be a huge task, but services that apply these principles become easy to work with, extend, and merge making them fit the definition of composable.

API-First

API (Application Programming Interface) is a set of rules and access patterns that allow different software applications to communicate. While it is possible for API to be added to a monolithic system, taking an API-First approach prioritizes the design and flexibility of these APIs. An API-First design guarantees that all functionality is exposed via API and that the API contract is well thought-out rather than being a consequence of how the data is stored or the expected UI. An API-First service can be used to build any type of user experience, where APIs added later are highly influenced by the existing user interface and adds restraints to how it can be leveraged. Taking a flexible API-First approach is necessary for seamless integration between the many services leveraged in a composable architecture.

The term “Headless” is related to APIs. Headless defines a system where the frontend (client-side) and backend (server-side) systems are decoupled, allowing for independent development and deployment of each. This separation allows for a higher degree of UI customization than standard theming solutions.

Be careful when selecting services, while all API-First services can be considered headless, not all headless software is API-First. Some headless offerings were tacked on to existing monolithic applications and do not give the same level of freedom when accessing the API.

Modular Components and Services

This principle requires that all the building blocks are discrete, interchangeable modules, each responsible for a specific functionality. Each building block should be consumable individually without reliance or dependencies on other services. A lack of tight coupling ensures the service can be used where necessary and replaced if another service better fits the requirements.

This may sound very similar to microservices. Microservices are a cloud architecture design where an application is deployed as a collection of small, focused containers, often within a Kubernetes environment.

The major difference is that microservices can be loosely coupled and are typically deployed together in the same environment to minimize latency for intra-service communication. Composable services must be fully decoupled, are often provided by different vendors as a SaaS, and focus on a business need or requirement.
While microservices are not required to be a composable service, choosing solutions built on microservices guarantee a high level of modularity and typically have a greater ability to scale.

Cloud Native

While any application can be hosted in the cloud, cloud-native applications fully exploit the unique services cloud computing provides, both in how they are hosted and with configurable integrations connecting to those services.

While a traditional cloud-hosted monolith may require a virtual server for each instance, a cloud-native SaaS will leverage scalable containerization designed with auto-scaling to serve all users. This creates scalability and cost-efficiency. This is extremely important for composable commerce, as a virtual server has limits on scale, must be managed directly, and represents a point of failure for days of increased volume (e.g. Black Friday). This level of maintenance would be cost-prohibitive when combining many different solutions. Instead composable solutions must be resilient and reliable guaranteeing they will handle any traffic without manual configuration or maintenance.

Composable solutions also take an event-driven approach to data movement and allow end-users to subscribe to these events. These events could be exposed via webhooks, but the best providers can also tie directly into cloud services and publish the events to a queue. Having access to the events allows for real-time integrations and negates the need for scheduled jobs or large batch files.

Subscribe - https://www.youtube.com/JamesLuterek

Introduction to Composable Commerce

James Luterek — Tue, 18 Jul 2023 17:02:33 +0000

Defining Composable Commerce

Composable Commerce is a new approach to building out unique digital commerce experiences. Historically, businesses were forced into two distinct approaches: buying generic software that can be themed and lightly customized, or coding an entire solution from scratch. Composable Commerce provides a third approach. By breaking traditional software functionality into smaller pieces, each offered separately, they can then be used as building blocks to create custom software without extensive coding.

Benefits vs challenges of composable commerce

This approach allows every business the benefit of a custom solution, while matching the cost and effort associated with buying generic software. For businesses with unique requirements, who want to control the entire customer experience, or who hope to leverage cutting-edge techniques, composable commerce is an easier and cheaper solution than forcing these requirements into an existing software package. This enables businesses to quickly adapt to changing requirements, customer preferences, and marketing conditions, and to quickly take advantage of technological advancements.

Due to the architecture principles required to create these building blocks, the individual services benefit from better scalability, lower maintenance, and faster response times. Since each individual piece can be swapped out as requirements shift, there is no need for massive re-platforming projects, instead the system grows and evolves over time.

The major challenges of composable commerce are the initial investment in planning and designing the solution. When buying all-in-one software, the vendor defines what functionality will be delivered. With composable commerce more time is spent on defining the overall requirements to ensure the best pieces are identified and integrated. Additionally, with this being a new approach businesses and architects may face a steeper learning curve as they adapt. Thankfully, there are now experts with years of experience ready to assist in navigating the many possible components and services.

Composable commerce vs composable architecture

Composable commerce refers to the use and application of composable architecture for digital commerce solutions. Composable architecture is broader, defining the use of these concepts across any industry or project. Composable commerce is a subset of composable architecture, but highly focused on meeting the unique needs of selling online.

Subscribe - https://www.youtube.com/JamesLuterek