Tips for Designing Effective Composable Solution Architectures

Introduction

The networked software industry is pivoting towards solutions composed from multiple systems that each provide individual Packaged Business Capabilities (PBCs). This article discusses numerous architectural decisions and challenges that organizations implementing composable solutions may face.

This blog post is part of a series about challenges that organizations face when implementing composable solutions. For more context on these topics, please read the introductory post before proceeding with this one.

Architecture: Vendor Lock-In

Composable architecture loosens the coupling between vendor products and customer solutions. Looser coupling has numerous technical advantages including a reduction in vendor lock-in, which is a hard dependency on a vendor that is difficult to eliminate from the solution. While there are several architectural approaches to loosen coupling in composable solutions, service-oriented architecture cannot eliminate coupling between components completely. It is impossible to implement a solution without using vendor APIs and Software Development Kits (SDKs), both of which result in vendor lock-in: replacing a vendor in a composable solution requires significant refactoring of the code.

One technique to achieve looser coupling is to eliminate calls to concrete, vendor-proprietary and platform-specific Application Programming Interfaces (APIs) in favor of service-oriented APIs used in composable solutions. Unfortunately, service APIs, webhooks, and the JSON formats that they use to exchange data are just as vendor-proprietary as concrete APIs. Digital Experience Composition and Orchestration solutions abstract vendor APIs, but just shifts the coupling from one set of vendors to a single vendor.

Architectural approaches such as service brokerage, aggregation of data into search indexes, and employing enterprise message buses can address this concern to some extent, but not completely, and with even greater complexity. Unfortunately, these techniques increase can increase costs and potential failure points, reduce performance, slow development, and can impede troubleshooting, all of which work against other objectives of composable solutions.

When implementing composable solutions, employ architectural solutions with the intention of reducing vendor lock-in to a level that is appropriate for the constraints of the project.

Architecture: Lack of Standards

Many of the challenges listed in this document result directly from a lack of standards in the digital experience management industry. Each vendor defines its own service APIs and data formats, which are major factors in vendor lock-in. Any customer code that uses a specific APIs and data formats is relatively tightly coupled to that vendor’s solution, where coupling is an architectural aspect to avoid in composable systems. The result is that replacing any component requires significant refactoring of the solution.

Organizations should favor composable vendors that implement emerging standards.

Architecture: Best Practices

It will take time for composable software vendors, systems integrators, advertising agencies, and customers to define and document best practices for implementing composable solutions, including techniques to minimize vendor lock-in. Until then, to develop the best possible solutions for the long term, customers that cannot hire experienced architects or must depend on third parties with the required knowledge.

For example, composable architecture depends on employing service-oriented products. This implies that custom solutions built using these products should employ microservice architectures, but this is not actually the case. Best practice may not be to use microservice architecture to implement custom applications, exposing every possible function as a separately scalable service, customer solutions can expose services at a lower level of granularity that meets their requirements for integration rather than conforming to an excessive architectural goal.

Organizations should employ or contract experienced solution architects to ensure that they follow current and emerging best practices for composable implementations.

Architecture: Release Management

Whether implemented by developers, business users, or directly by tools, every solution depends on code. While it may be possible to use CMS publishing processes to deploy specific types of data changes, something must be responsible for promoting code from pre-production to production environments. For experience management initiatives, deployment typically involves a Continuous Integration/Continuous Delivery (CI/CD) toolchain, with appropriate quality assurance steps along the way.

Beyond simply acquiring CI/CD tooling, organizations need to invest in automating releases, potentially using tools that include capabilities to perform this function on their behalf.

Architecture: Publishing Workflow

Though this challenge is not specific to composable solutions, implementing publishing workflow, especially around internationalization, can be challenging. If the workflow is too simple, it may not provide the required checkpoints and orchestration capabilities. If the workflow is too complex, users will find ways around it or be frustrated with the solution.

Set expectations of publishing workflow appropriately from the outset of the project. Implement a process that meets the most common use cases, but realize that manual effort may be more efficient than attempting to automate every possible permutation and exception to the standard publishing sequence.

Architecture: Technology Selection

Before implementing composable digital experience management solutions, organizations face many decisions including:

• Composable product selection (CMS, search, and so forth)
• Front-end design frameworks (React.js or equivalent)
• Back-end development frameworks (Node.js or equivalent)
• Back-end service hosting infrastructure
• DevOps tooling
• Content delivery hosting infrastructure

Conceptually, each component of a composable software stack is a black box, meaning that organizations should not require knowledge of its internal technologies and instead focus on its service interfaces. In reality, a mismatch between technologies used by the client and those used by vendors can create challenges in support processes, where each team is familiar with a different language. When a customer requires code support, it can be advantageous for both to use the same programming languages, libraries, and architectural paradigms.

Headless CMS typically encourage organizations to use JavaScript for both front-end and back-end coding. Many information technology departments may have experience with and preferences for enterprise technologies such as Java and .NET. Switching from preferred technologies to those commonly used in composable solutions can present productivity declines until teams expand to include the relevant skillsets or existing developers make their way through the requisite learning curves. Organizations can continue to use their preferred technologies to implement other components of the solution but may find themselves to those technologies preferred by their vendors over time.

An organization’s technology selection and experience can be especially important to customizing user interfaces. For example, when adding features such as custom field types to a headless CMS, the user interface is likely to be more consistent if the customer uses the same front-end programming framework used by the CMS vendor. The CMS is the product most likely to influence development technologies selected by its customers.

Where possible, organizations should align their technology selections with those used by their vendors.

Architecture: Complexity

Integrating components of composable solutions, such as content management, commerce, and multivariate testing, can be more complex than using monolithic platform solutions to achieve the same functionality. Digital Experience Composition (DXC) vendors have emerged to address this issue to some extent, but these tightly couple the customer’s solution to the DXC rather than the systems that it abstracts.

With more elements in a composable solution, complexity and the number of integration points increases, as does the number of potential failure points. Organizations should maintain clear documentation and diagrams describing the architecture of their implementation.

Architecture: Legacy Integrations

Many organizations have legacy systems that are not service-oriented but must be incorporated into composable solutions, resulting the additional complexity of hybrid architectures. For example, an organization may have an Enterprise Resource Planning (ERP) system that does not implement composable architecture.

Customers truly dedicated to implementing composable must implement service-oriented artifices to abstract such systems.