From Build vs. Buy to Buy to Build

Build vs. Buy is an argument as heated as Cloud Vs. On-prem in the software world, but while dodging that bullet with a simple "It Depends" answer, let's look into the way the arguments are evolving as we focus more on API-first stacks in the digital world.

Understanding Build Vs. Buy

For anyone unfamiliar with the topic, firstly, Build Vs. Buy is just a discussion on whether to build a solution/software in-house (think proprietary in-house homebrew CMS) or to buy a solution that's on the market (i.e. a WordPress).

We won't be focusing on this discussion, but it's important to look into why buying software -- particularly cloud-based SaaS offerings -- are such a common and economical option for the masses who don't have super-specific needs that compel them to hire an army of software engineers to build proprietary software.

Rapid digitization drives companies into the "Experience Era", where personalized and consistent communication (omnichannel) across all channels is no longer just a nice-to-have but a requirement. Every organization today is, or should be, exploring a better approach to designing and delivering exceptional experiences across online and offline channels.

The Build Vs. Buy Trifecta by SentinelOne

Traditionally, the preferred approach was to build custom applications in-house over concerns that a third-party solution won't meet their specialized needs. While IT teams are perfectly capable of building tailored software, it's often arguable whether or not that's the best approach. Especially when today, there's quite literally a SaaS for everything.

An example of the Adobe Experience Platform end-to-end architecture from data collection to activation had they opted to build everything in-house.

So let's quickly break down some of the core criteria for "buying" software, specifically buying software components rather than the monolith (another story) before looking into how this is evolving further.

Availability of Mature Tooling

There's a SaaS for everything, just like there's an app for everything. For example, an ERP has long been a love story of building bespoke software in-house. "Our operations are so specific and unique, we need to handle all of it in-house with our IT team". That's no longer the case anymore -- even if companies aren't paying the equivalent of a small country's GDP to get an SAP or Sage instance up and running -- there are so many SaaS options with incredible API integrations that cover Production, HR, Planning, Inventory Management, Reporting, CRM, Sales and Marketing, Automation, Finance, Accounting, Machine Learning, Personalization... you name it.

G2 practically gives you the leaders for each subcategory to build an API-first ERP

Implementation

The time needed for implementing SaaS is relatively short compared to in-house software, which is relatively long. This is because someone else is literally taking the effort of building, maintaining, and upgrading the service(s) you need, so all you need to do is purchase their product, and integrate their API(s) with yours. In most cases, SaaS platforms offer documentation that makes it simple for engineers to make the needed implementation within a relatively short period of time.

Maintenance and Upgrades

Clients do not need to think about updates or security issues in SaaS because the SaaS provider company handles those issues. In contrast to in-house software, organizations and companies need to provide IT experts to deal with those issues.

Continuous Innovation

The features offered by SaaS are limited -- you're only getting features provided by the SaaS vendor -- while the features built in-house could be customized as much as possible. However, what you're actually buying are multiple SaaS products doing a few things extremely well, and following best practices, so you don't have to worry about staying competitive. There's enough competition in the SaaS industry to ensure all vendors stay on the top of their game in rolling out exciting innovations for their capabilities. If not, well, switch them out for a competitor without causing business disruptions.

Scope, ROI, and Budget

It depends 😅

Here's a high-level comparison between SaaS and In-House from a DAM perspective.

Anyways, this isn't the point. Tom Whatley's covered Build vs. Buy in depth over on CXL, which is something I'd recommend reading. Let's talk about Buying to Build.

Composable Architectures, Microservices, and Experience APIs

When I was co-authoring the DXP (Digital Experience Platform) report back in 2020, I had the chance to learn tons about where the modular DXP and microservice-led experience architecture was headed.

Traditionally DXPs have been "full-stack" monoliths that provide an architecture for businesses to digitize their business goals, marketing activities, analytics, and content management. Over time, with the rise of API-driven approaches and the need for omnichannel content distribution, there has been an emergence of modular "DIY" DXPs, which are essentially a loosely coupled combination of best-of-breed products working in harmony.

These DIY DXPs typically saw several components, or microservices, coming together to create the functionality of what an AEM or Episerver (Optimizely) would offer, but purely from a "headless" approach. Usually at a fraction of the cost too.

This got me really interested in the space -- as companies are transitioning towards digitizing and modernizing, alongside breaking down monolithic stacks, the need for finding best-of-breed services to accomplish complex use cases is gaining importance by the day. Commercial personas within marketing, sales, and operations are getting conscious about the tech stacks they're using, and are starting to expect more from APIs rather than just trusting flashy software at brand value. They're getting informed about the modular approach, and are taking a genuine interest in seeing how these "best of breed" microservices combine their capabilities to fulfill business goals.

We're collectively moving from Experience Platforms to Experience Architectures, and these are being carefully built and orchestrated with SaaS platforms & APIs -- we've literally moved from arguing about Build vs. Buy -- and are actively buying to build architectures that are highly tuned to our specific use cases.

Composable Businesses, MACH, and Building Experience Architectures

There's a lot of talk about MACH architectures lately -- that's a discussion for another topic -- however, what's important to know is that MACH (Microservice, API, Cloud-native, Headless) architectures aim to guide enterprises towards building composable architectures using building block APIs like "Legos" to define a stack that works for them.

This entails individual pieces of business functionality being independently developed, deployed, and managed -- all exposed via API -- and cloud-based as a SaaS model.

A typical MACH architecture in eCommerce

These "composable architectures" are what form the basis of the buy-to-build argument -- where companies are utilizing several vendors, buying multiple SaaS solutions that do a few things very well, and building them into DXPs that would typically have been an all-in-one solution. Think stacks, not suites. Think a AAA API CMS + AAA eCommerce API + AAA PIM + AAA Payments API + AAA Cart API + AAA `x` API ... rather than just a Magento, for example.

This brings us to an interesting pivot in the DXP discussion. Going from Experience Platforms to Experience Architectures.

According to Forrester, an experience architecture is a technology strategy holistically applied to the total brand/enterprise experience --- strategies, core technologies, services, and processes that power customer and employee experiences. It's different from enterprise architecture because it goes well beyond the plumbing of back-end technical systems and equips technology and business leaders with a holistic approach to the seamless and continuous delivery of a brand's expression of customer obsession.

The argument here is that multiple teams own multiple aspects of the customer journey. They're all buying and investing in various APIs - Products, Finance, CX, Marketing, Automation, etc. It isn't feasible to manage them all via custom middleware and gateways that lead to data silos and multiple points of failure, they all need to be orchestrated on an "aggregation layer" and delivered to customers on presentation layers that are most relevant.

Technical personas and commercial personas need to start working together in defining these experience architectures together. There's no one-size-fits-all approach to them. Given how specific it is to a use case or company, it isn't something that can be bought from a single software vendor; rather, you build and practice experience architectures. It requires looking across the customer lifecycle and bringing together marketing, commerce, service/support, supply chain, and more to work in service of your customer, rather than in siloed teams or buckets of technologies -- whether bought or built.

Bringing together experience architectures at the aggregation layer using Forrester's "Experience Architecture".

It is quite literally buying multiple (if not hundreds) of SaaS tools, to painstakingly and specifically map them into a custom build that lets them fulfill exactly what you want them to.

So is Buy to Build the new approach we should be advocating for even on the commercial side of the organization? Should we start paying more attention to the microservice and headless conversation that the technical teams have been indulging in for the past few years?