Matrixed Tech Stacks with Both Horizontal and Vertical Aggregation Platforms

0
29 views

Share on LinkedIn

Last year, I wrote about a pattern of aggregation platforms growing in martech stacks. The two key characteristics of an aggregation platform:

  1. It centralizes a cross-departmental capability (e.g., a cloud data warehouse).
  2. It grows in value as you connect more apps in your stack to it.

That second point is important, and not only for the obvious network effects. To me, this triggered — or was triggered by — the recognition that tech stacks are growing in diversity, not consolidating into a handful of mega-apps. Instead of futilely fighting The Great App Explosion, aggregation platforms embrace it. They help companies organize, harness, and govern it.

But I was really only talking about aggregation platforms at one of the four layers of data, workflow, UI, or governance. In thinking more about this, I realized that these were only horizontal aggregation platforms. They’re aggregating in that layer across many different departments or domains within the organization, from sales and finance to engineering and human resources. But just within their layer.

However, we also see aggregation platforms within a specific department or domain. For example, a CRM platform for marketing, sales, and service. Or an ERP platform for finance and operations. These are vertical aggregation platforms. They collectively aggregate data, workflow, UI, and governance services all within their platform. But mostly just in that domain. You’re probably not using your CRM to manage to your continuous integration and deployment pipeline.

Vertical aggregation platforms can often be recognized serving as the “home base” app for a particular department or team. Most major marketing platforms over the past couple of decades fit this model.

What’s fascinating is the realization that most organizations now have both horizontal and vertical aggregation platforms within their stack. And while the nature of any aggregation platform is to become the “one” center of gravity within its layer or domain — ideally, there’s only one single sign-on (SSO) service in your stack, and only one CRM — horizontal and vertical aggregation platforms peacefully co-exist. They may compete in some overlaps, but they mostly complement each other, especially when they’re integrated together.

This is a “matrixed” tech stack, where teams are often leveraging a combination of vertical and horizontal platforms in their day-to-day work.

It reminds me of The Spotify Model for large-scale agile software development. All of the product people working in a particular area (domain) are part of a tribe. Different tribes focus on different areas of the product. But within each tribe, there are different specialists, such as UX designers. A guild is formed from all those particular specialists working across many tribes.

Similarly, we can think of the departments and domains served by a vertical aggregation platform as all belonging to a respective “tribe.” The HR tribe. The IT help desk tribe. The marketing tribe. Meanwhile, everyone in those different departmental tribes who is focused on data management might also be a part of a data layer “guild.”

As a marketing ops person, my tribe is marketing. A CRM platform and/or a marketing automation platform is my vertical aggregation platform. But when it comes to data, I might participate in a guild for data warehousing and analytics that spans multiple departments. Within that guild, I’ll rely on horizontal aggregation platforms for data warehousing, data pipelining, metadata management, and company-wide business analytics.

Vertical aggregation platforms work best when they’re adopted by all the users in a given department or domain (e.g., marketing). Seat-based pricing is the dominant model.

They aggregate by integrating with all of the other popular apps used in that domain. So for marketing, this includes integrating apps for event marketing, online advertising, content-creation tools, affiliate management, etc. It’s often labeled the “system of record” and/or the “system of engagement” for that domain.

If the domain is a customer-facing one — such as marketing, sales, customer service, digital product, ecommerce, etc. — vertical aggregation platforms in the domain often serve experiences directly to customers. For instance, an aggregation platform in the customer support domain will likely render the interface for customers to file help tickets, check a knowledge-base, and engage with customer service agents.

Horizontal aggregation platforms, however, work best when they’re adopted by all the departments across a company — but are not necessarily directly used by everyone in each of those departments. The exceptions tend to be horizontal aggregation platforms at the UI/UX layer, such as collaborative communications platforms like Slack or Microsoft Teams, that work best when everyone in the company uses them.

In my experience, there tends to be more API-based activity with horizontal platforms in the other layers. Their very nature is to coordinate through integration across many different vertical platforms. Their human UI is usually tailored to specialists who run the “ops” for that particular cross-org capability. For instance, a cloud data warehouse platform might ingest data from and deliver data to every major domain throughout the company. But it’s typically only data ops people who are interacting with the warehouse’s UI directly.

Operating internally, horizontal platforms are less likely to directly serve customer-facing experiences. But they often power them further behind-the-scenes.

While some horizontal platforms use seat-based pricing, especially at the UI layer (e.g., Slack), it’s not uncommon to see consumption-based pricing in the other horizontal layers. In the data layer, how much data are you working with? In the workflow layer, how many automations are you running? In the governance layer, how many apps are you managing and monitoring?

What about the overlaps between horizontal and vertical platforms?

In theory, it might be ideal to have no overlapping functionality between products in your stack. Reality is pretty far away from that though. In the boundaryless, hyperconnected digital universe, the swim lanes for different software products and categories are highly fluid. Where they overlap, you often end up with more than one way in which you can implement something.

The downside of this intermingling between vertical and horizontal platforms is greater complexity in your stack and challenges with governance (visibility, monitoring, guardrails) split across multiple dimensions.

The upside, however, is greater coverage of capabilities (the union of the Venn diagram of use cases above) and greater flexibility and adaptability in your options for solving a particular problem with overlapping capabilities. This optionality also has the benefit of hedging your relationships with vendors by balancing concentration risk. Having strong vertical and horizontal platforms both in your stack helps keep them each in check.

Good ops leaders — marketing ops, sales ops, rev ops, business ops, finance ops, data ops, and pretty much every other Big Ops specialization — can mitigate the downsides of a matrixed tech stack while extracting the maximum value from it.

LEAVE A REPLY

Please enter your comment!
Please enter your name here