5 things to consider before committing to composable architectures

Consideration

Composable Suite

1

With traditional MACH deployments, organizations will have to contract and procure with each platform. A baseline content-focused build could easily include content management, search, digital asset management and personalization features, requiring contracting and legal support with vendors proving each of these capabilities.

Composable suites typically bundle multiple features together, simplifying both the integration work and the contracting, legal and procurement activities into a single vendor.

2

Depending on how the composable solution is architected, business users may have to work in multiple tools to deliver a single user experience. That means they have to be trained and become proficient with different UIs from different vendors.

Composable suites can offer a common interface across multiple features, quickening the learning curve and reducing the number of UIs that have to be managed.

3

Selecting individual tools and platforms for each feature also requires that those tools be integrated together, which is typically the province of more mature IT teams and organizations. This also adds to overall cost and timelines of delivering these solutions.

Composable suites already integrate features together in a predictable, standards-compliant fashion, without giving up the ability to replace a given feature with a new tool if desired. In short, it’s the best of both worlds.

4

Most organizations aren’t able to fully commit to composable architectures because they also have to maintain what they’ve built in the past. Building a transition plan takes time, energy and effort.

Composable suites accelerate the ability to support hybrid architectures by streamlining costs and providing a natural path from traditional DXP platforms to modern, composable architecture.

5

An ages old debate exists about selecting the absolute best of breed versus best of need. To put it simply, oftentimes, the perfect is the enemy of the good. The value of composable architecture isn’t necessarily the absolute best of a given feature, but instead, the power, agility and speed improvements associated with a modern technology stack.

Composable suites work to deliver “good enough” features without sacrificing significant additional cost and effort trying to deliver perfection across all times and channels without fail. Composable suites are a vital method for helping organizations to navigate their way to fully composable architecture without giving up the native value of being able to buy the absolute nest, when they need it.

Consideration

Benefits

Drawbacks

Vendor management

Allows most flexibility in selecting vendors.

Must procure and manage vendor-specific relationships.

Business user interfaces

Each MACH tool has a unique interface; best of breed examples can integrate with other tools (ex: Ninetailed’s ability to embed in Contentstack’s UI).

Business users must learn multiple UIs and sometimes log into different platforms to access features and capabilities.

Tool integration

Each MACH component should be integrated with appropriate tools within the MACH ecosystem.

Core integration work is required at build time and must be maintained as component tools change over time.

Migration / adoption

MACH components can be architected and adopted on an as-needed basis, providing agility and flexibility in how to build MACH-driven platforms.

Each component of a MACH ecosystem must be reviewed to determine the most appropriate adoption model.

Best of breed

MACH components align fully with the idea of best of breed selections especially over time. MACH solutions provide the ability for organizations to change their architecture when a more powerful component becomes available over time.

Swapping components requires new integration points and potentially data / asset migration.

Consideration

Benefits

Drawbacks

Vendor management

Reduces the number of vendors to be managed and procured depending on specific mix of needed features and functionality.

Still have additional vendors to negotiate and manage.

Business user interfaces

Reduces number of UI to learn and manage.

Still may need to log in to additional interfaces, depending on specific makeup of composable ecosystem.

Tool integration

Reduced number of integration points. Simplified and expedited build times compared to native MACH.

Non-suite components must still be integrated separately.

Migration / adoption

Expedited build times. Reduced migration and adoption times compared to native MACH.

Non-suite components must still be migrated or adopted separately.

Best of breed

Best balance of best of breed versus best of need. Allows for flexibility in crafting unique composable ecosystems.

Assumes that all suite components meet expectations and needs for a given project. If not, no value is delivered in this approach.

Consideration

Benefits

Drawbacks

Vendor management

Consolidates all vendor management and procurement responsibilities to one single vendor.

Potential lock-in to a single vendor, often requiring a multi-year commitment, making it difficult to move quickly if a DXP isn’t viable.

Business user interfaces

Typically, a common UI is leveraged across all DXP modules and feature sets and requires a single login point for business users.

Not all DXPs feature unified UIs. Many that are the result of acquisitions and mergers suffer from origin UIs that complicate matters for business users.

Tool integration

Most core feature sets and capabilities come pre-integrated, saving development time. It also allows for easy sharing of analytics and insights across functionality (i.e. search activity automatically influences content recommendations), so the effect is magnified beyond simple integration alone to include data-sharing.

Requires alignment that the full feature set and capabilities of the platform are good enough for the desired outcome. Must validate the level of integration and data-sharing, as the depth of this integration varies by vendor.

Migration / adoption

Upon replatforming conclusion, provides a unified, consistent platform for operation and overall enhancement. Streamlined management and consistency of expectation.

Requires full commitment to migrating to a unified platform, even in phases or waves. Less helpful if migration is only focused on partial replatforming of a given digital ecosystem.

Best of breed

Much more focused on delivering a best-of-need model, as any given module can be outperformed by niche providers.

Still requires customization and integration work if niche providers are included. Some wasted energy and effort when replacing DXP functionality with niche provider work. Can also contribute to code bloat for unused features or capabilities.