Build a scalable tech stack with a composable strategy

If you walk into a Western kitchen, you’ll find drawers overflowing with gadgets: garlic presses, avocado slicers, egg separators, knives for every task. What you’ll find in a Chinese kitchen is a wok and a cleaver. That’s it.

The Chinese kitchen produces more variety, cooks faster, and adapts on the fly. Meanwhile, in the Western kitchen, you have 47 specialty gadgets to clean, store, maintain, and replace.

Your GTM stack is the Western kitchen.

The GTM tech stack is at a crossroads 

Three forces are converging to shake up how we build our stacks:

1. Stack complexity - The average enterprise now juggles over 90 technologies in its GTM stack, resulting in high levels of fragility, cost, and support requirements.
2. Budget cuts  - Tech budgets have been cut over the last 2-3 years and will stay tight due to unfavorable macroeconomic trends.
3. AI - AI is introducing new capabilities across all segments, and many companies have a mandate to leverage it to cut costs further.

Some teams are responding by buying more specialized AI tools; that is, more gadgets for the drawer. Others are taking the wok-and-cleaver approach: composable architecture built on versatile infrastructure platforms managed by skilled operators. 

In a composable architecture, you buy infrastructure technologies and build your own business solutions on top of them. Teams are using this approach to build solutions such as CDPs, ABM platforms and attribution, and increasingly for marketing automation, AI agents and buying groups (ABM 2.0).

A number of Openprise customers have replaced or are replacing their Eloqua and Marketo this way, and these projects are coming up more frequently. Here is a presentation from Open/MOps-Apalooza ‘23 where Conrad Millen from Rippling described how they replaced Marketo with a composable solution: https://www.openprisetech.com/resources/videos/open23/highly-mechanized-prospecting/

I’m seeing more teams make this shift to composable architecture. I will walk through the three main reasons why they make this strategic choice, then outline what infrastructure you need to build a composable architecture.

#1: Reduce stack complexity

Today’s GTM stack is overly complex, fragile, and expensive, due to over a decade of abundant budgets, technology innovations, shiny-toy syndrome, and high job mobility in the Ops and leadership teams. A composable architecture is the only solution to drastically reducing the complexity of your tech stack while not giving up any GTM capabilities.

Reduce point-to-point integrations and data silos

When you add a new application to your tech stack, you’re adding three or more moving parts because each new application also adds another data silo and one or more point-to-point integrations. A centralized integration architecture can reduce the number of integrations, but the only way to eliminate data silos would involve not adding the application in the first place.

In a composable architecture, a solution uses the data from the systems of records directly. Additional data specific to the solution is stored in a centralized data store, avoiding additional data silos. Since the solution is built on the common infrastructure, no additional point-to-point integration would be necessary.

Reduce business logic inconsistency

As the number of technologies in a stack multiplies, inconsistencies in business logic and variations in process creep in as well. These unnecessary variations create friction points that make it difficult to automate processes reliably.

For example, at one Openprise customer, the marketing ops team managed lead routing, sales ops managed account assignment, and channel ops managed deal registration routing. Three teams used three different technologies to manage three different processes that shared 80% commonality in business logic and interdependencies. This siloed approach caused problems such as deal registration being routed to a sales rep that was not the account owner, and a marketing MQL being routed to the wrong account due to inconsistent routing logic after the sales ops team updated its territory carve rules. Centralizing all three processes in the Openprise platform enabled the teams to standardize on common logic and processes for a more uniform, scalable, and manageable set of automations. 

Minimize required team skills

Implementing a new technology is just the beginning. The Ops team also has to operate, maintain, and upgrade each technology. Those day-to-day expenses add up to the bigger portion of Total Cost of Ownership (TCO). For each technology in the tech stack, you need to either maintain in-house skills or pay vendors to provide them. 

Maintaining a large portfolio of product-specific skills creates many challenges: the time and cost of training and maintaining expertise, larger staff or professional services budgets, and higher cost and difficulty replacing team members. When each team member can only cover part of the tech stack, new projects and daily troubleshooting slow down. Skills become less interchangeable, making coverage more challenging.

A composable architecture is built on a small set of infrastructure technologies. This greatly reduces TCO related to training and maintenance of product skills. At the same time, team members develop deeper technical expertise because they’re not spread as thin. The higher level of shared knowledge increases the team’s ability to execute on new projects faster. You can do more with a smaller team with fewer required skills.

#2 : Be process- instead of technology-centric

Ops should be about executing processes, not babysitting technologies. However, as the tech stack gets more complex, we devolve into being technology managers. Instead of designing the process we need, we fit the process around the technologies we have and fill the gaps with manual tasks, custom code, or middleware. Some Ops professionals even take pride in “orchestrating” a bunch of products together to automate a process. The technology tail is wagging the process dog. A composable approach lets you focus on creating the right process.

Improve process robustness and faster debugging

A typical process Openprise customers create would require 4 to 6 point solutions to replicate without Openprise. The more technologies involved in a process, the more likely it will break, the harder it is to debug, and the harder it is to change. All these challenges increase the solution’s TCO.

A composable architecture lets you implement a solution with the fewest number of technologies, which drastically reduces TCO.

Better monitoring and measurement

Very few companies have reliable and accurate visibility into their full funnel. A main reason is the number of technologies involved in a typical funnel process makes universal monitoring and measurement very difficult. Not impossible, but difficult enough that most companies can’t commit the resources to get it done. Instead, they live with fragmented dashboards and localized metrics. The more complex your tech stack, the harder monitoring and measurement becomes.

A composable architecture makes it exponentially easier to monitor and measure process performance because far fewer technologies are involved, and the orchestration layer often has end-to-end visibility.

Process and task optimized UI, not generic vendor app UI

It’s a common complaint from Ops teams: they give users access to an app, spend time training them, and they still won’t use it. The reason is often that the app’s UI has many features for different use cases, yet each user only wants to use one feature. Multiply this by 5 to 10 apps and the cognitive load becomes too high, especially for apps they don’t use frequently. This is another instance of trying to make the process fit the technology.

With a composable architecture, you build custom apps designed for a single user performing a single task. The best self-service apps are single-button apps where there’s only one button the user can click to complete the task. The app is optimized for the process and its users without placing any extraneous demands on them.

#3: Less vendor dependency, especially AI

How many times have you heard a MOps professional complain that “Eloqua / Marketo / Pardot hasn’t innovated for the last N years”? Then you see teams migrate from one platform to another and wonder why the scenery doesn’t change. The dirty secret in software is that it’s easier to sell you an additional product than to get you to pay more for the one you already have.

You have a structural advantage in the speed to innovate

Once you have the fundamental building-block technologies and the right orchestration platform, you can create custom solutions at a much faster pace than any vendor can. A vendor has to provide enough flexibility in its product to accommodate a wide range of use cases and user personas. You only have to worry about your use case, often just one use case and one user persona at a time. This narrow focus enables you to build composable solutions faster than any vendor can innovate and still have a profitable product.

Can’t afford to bet on AI vendors; need plug-and-play

I consistently hear from customers that AI is evolving so fast that the only certainty is that whatever AI technology you will be using 18 months from now likely won’t be the same ones you are using today. A customer told me last week that he likes to sign multi-year contracts with most of his vendors, but he will only sign one-year contracts with AI and data vendors.

A composable architecture with an orchestration platform gives you plug-and-play capability with AI. This gives you the stability of enterprise-grade automation infrastructure with the necessary scalability, manageability, and security to support whatever best-of-breed AI technologies emerge, while providing the supporting features that most AI products lack today, such as context orchestration, prompt management, and hallucination management.

Ready for the ASI, not the AGI, future

Artificial general intelligence (AGI) is getting all the buzz and getting your personal robot to do all your housework sounds very appealing. However, the reality in the enterprise is likely artificial specialized intelligence (ASI), where companies increasingly build and train AI for specialized tasks such as coding or customer support. ASI solutions will always be cheaper and higher performance than trying to get AGI to do the same task.

A composable architecture makes sure you have the right technology foundation to build your own ASI solutions.

Technology recommendations

If I have convinced you to give composable architecture, or maybe Chinese cooking, serious consideration, let’s talk about the platforms and portfolio of technologies you need at a minimum. Use as few platforms as possible to give you the flexibility you need. Make sure the platform’s skill requirement fits your team’s skill set: for most Ops teams, this means no-code platforms. And remember, a portfolio of technologies from the same vendor is not the same as an integrated platform. A vendor’s product portfolio is often built through acquisitions, and making these products work together is often no simpler than doing the same with products from different vendors.

Composable platforms have three primary capability categories: data, automation, and engagement.

Data layer

Everything starts with data. You will need:

• Data store - A key benefit of composable architecture is minimizing data silos and associated integrations. You need a data store with scalability and flexibility to accommodate a wide range of use cases. If your company is committed to a technology like Snowflake or Databricks, it may be the logical choice. If you don’t have database skills on the team, a platform with an embedded data store that abstracts away the technical nuances may be the better choice.
• Data quality and data orchestration engines - Regardless of how you store your data, it needs to be cleaned, governed, unified, and manipulated. There are many choices in traditional data management software that work for any data from any department. A platform built for GTM Ops may be  better because it is designed for less technical users and usually comes with integrations and templates for common GTM use cases.

Automation layer

The automation layer is where the business logic lives. You will need:

• Integration engine - Building composable solutions requires integration to systems of record, databases, third-party data vendors, API-based enterprise services, and AI models and agents. Look for a large portfolio of out-of-box integrations to the technologies most GTM teams use. Make sure you have the ability to create custom outbound (which calls out to another system) integrations using technologies like Webhook, as well as inbound (another system calls you) integrations like Openprise’s API Factory.
• Automation engine - AI is a type of automation but not all automation is AI. Most AI agent implementations in the enterprise will be composable agents that combine workflow and AI technologies to deliver the appropriate level of agent autonomy. This means hybrid AI and workflow orchestration platforms are necessary. In addition to leveraging AI through APIs, consider a platform with embedded AI models to improve security, performance, and cost.

Engagement layer

Even with AI, people are still key to many GTM processes. You will need:

• Integration engine - Most users want to interact with data in the apps they use frequently, which means the user interface for your composable solution may be an existing business app like a CRM. An integration engine is how you leverage these apps as the user interface for your composable solution.
• App builder - A custom app is often the right user interface for business users to see and interact with data securely and easily. The key to creating self-service apps that users will actually use is keeping them simple and focused. Show users only data that’s relevant for the task at hand. Enable simple interaction so users can confidently use the app even without training. Strive to create “one-button” apps for self-service.

Composable is Ops’ wok and cleaver

In the Chinese kitchen, the wok and cleaver aren’t magic. They work because someone made a deliberate choice to invest in mastering a few versatile tools rather than accumulate drawers of specialized gadgets.

Your GTM stack is at a similar inflection point. You can respond by adding more specialized tools, or you can step back and ask if this is the moment to rethink your architecture. The teams shifting to composable have run out of drawer space. They realized that operational excellence on the wrong architecture is just banging their head against the wall harder. They’d rather invest in building skill than in managing an ever-growing portfolio of point solutions.

Composable isn’t the right answer for every team. But if you’re drowning in integrations, burning budget on maintenance instead of innovation, and spending more time babysitting the tech stack rather than designing processes, maybe it’s time to declutter your kitchen.