Expand my Community achievements bar.

When to Build vs. Buy Enterprise Platform: Risks, Benefits, and Considerations

Avatar

Administrator

10/21/21

Authors: Jaemi Bremner (#Jaemi_Bremner), Wouter Van Geluwe (#wvg_adobe), Jenny Medeiros (#jennyl12901548), and Jody Arthur.

landing-banner.jpeg

This is the first post in a two-part series that explores the challenges faced by CIOs in deciding to build versus buy technology for the enterprise companies. This post provides a clear and comprehensive overview of this debate based on an organization’s needs and expectations, and what CIOs should consider before deciding on the best approach for their team, budget, and business goals.

Digital transformation drives brands into the “Experience Era”, where personalized and consistent communication across all channels is no longer just a nice-to-have but a basic must-have requirement. Every organization today is exploring a better approach to designing and delivering exceptional experiences across online and offline channels. This exploration typically leads to an organization deciding to invest in a unified customer profile that relies on machine learning to power intelligent decisions, in real-time.

Traditionally, the preferred approach to such an investment has been to build custom applications in-house over concerns that a third-party solution won’t meet their specialized needs or connect with existing systems. While IT teams are perfectly capable of building tailored software, it’s often an expensive and unnecessary distraction from more meaningful work. Additionally, IT teams are struggling to continuously upgrade their architecture, integrate new technologies, and capture user data from sources while balancing to stay head of digital innovation and the growing expectation for personalized customer experiences.

These challenges bring CIOs back to the long-standing debate of whether to build software in-house versus buying software from a vendor — a decision that returns a different answer for each business landscape. Enterprise CIOs are expected to lead cost-efficient and scalable technology choices that balance the company’s immediate needs with its long-term growth.

In this post, we outline the considerations and potential consequences of build vs. buy through both an executive and technical lens. Plus, we invite you behind the curtain to analyze a common brand scenario in the hope that it will provide the insight you need to reach the most beneficial decision for your business.

With global enterprise software spending projected to grow 8.2% in 2020, reaching around $466 billion in value, it appears that many companies are finding it more convenient to buy commercial software rather than building it themselves.

Although this approach may work for some companies experiencing similar challenges, others face unique edge cases that can’t be solved by a software solution built for the general market.

Here are four key factors that should guide your approach to answering the question of whether to build vs. buy enterprise software to make an informed decision for long term growth:

  • Cost
  • Control
  • Connectivity
  • Maintenance

Cost

Companies will always lean towards the most cost-effective and efficient solution for their business. Internal IT projects empower the company to decide how much it wants to spend on development — except IT projects have a knack for taking longer than expected and costing far more than estimated.

After factoring in the cost of the initial build, support, bug fixes, upgrades, and keeping up with market trends, it’s no surprise that Gallup reports one in six IT projects have an average cost overrun of 200% and a schedule overrun of almost 70%.

While purchased software can have a high upfront cost or a substantial subscription fee, it’s a known expense for a product that will be ready to use immediately. For many CIOs, this fixed cost vastly outweighs the unpredictability associated with building software in-house.

Control

The biggest appeal of building software in-house is the notion that it can be molded to meet the company’s specific requirements as they arise. What this also means, however, is that you will always be reliant on the developers building it.

It’s unsettlingly common for companies to be left with unusable code bases created by developers who no longer work at the company, adding an ongoing maintenance cost of hiring new developers to rebuild the codebase from scratch.

As a general recommendation: if the requirement fit of commercial software is 60% or more, buy is the way to go. You may not have full control over the product roadmap, but many vendors will work closely with customers when designing or improving their products.

Connectivity

Each company has its own ecosystem of applications that need to be compatible with systems beyond the company, such as marketing destinations. Building your own solution can help ensure that these connections are made, as long as your team is capable of undertaking the extensive process of stitching together multiple, smaller solutions.

Chances are that a more advanced and comprehensive solution already exists on the market. Some commercial software solutions can even act as an extension of your existing ecosystem, rather than entirely overhaul the architecture your IT team has so arduously built.

Maintenance

Building software means not having to rely on an external team to develop new features or roll out upgrades. But most internal teams do not have the same availability or expertise as an external team when dealing with complex architectures typical of global companies.

From multi-tenancy to data compliance, an experienced team armed with best practices and the latest market insights will typically be better equipped to handle maintenance for enterprise-scale software.

As the team behind Adobe Experience Platform we have seen our fair share of companies on the fence when deciding to build or buy. For an honest insight into the situation many companies find themselves in, we will share a common scenario from our own experience — one that may even be similar to your own.

For context, Adobe Experience Platform is the first purpose-built customer experience management platform that collects data from multiple sources to build comprehensive customer profiles. With continuous intelligence and an open and extensible architecture, Experience Platform conveniently delivers personalized customer experiences in real-time and at scale.

In this scenario, we will focus on a brand struggling to unify and understand the customer data streaming from a plethora of channels and devices. They had already invested heavily in an ecosystem that collected data into a data lake, built customer profiles, and even derived insights from it using machine learning.

What they lacked, however, was the connectivity to transform all this collected data into action to orchestrate real-time, contextual, omnichannel customer experiences.

Below, we offer an example of what a platform might look like if the brand’s decision was to build the necessary architecture to bridge the gaps in their existing ecosystem.

Figure 1: An example of the Adobe Experience Platform end-to-end architecture from data collection to activation.Figure 1: An example of the Adobe Experience Platform end-to-end architecture from data collection to activation.

As shown in Figure 1, the complete end-to-end solution involves a complex interconnection of disparate applications that must be seamlessly integrated — a task that requires a tremendous amount of time, money, and expertise.

First, every dataset comes from a different source, which means there are several different pathways to get that data into the platform. Next, we have the main building blocks of the platform responsible for ingesting, unifying, and transforming the data into actionable insights. Lastly, and most importantly, these insights are delivered in real-time to various systems across advertising, marketing, sales, call centers, and point-of-sale environments.

Many brands will tell us that they have already built and integrated all these pieces themselves, but their end-to-end latency is rarely real-time due to the number of custom integrations. There will always be that one component that acts as the bottleneck for real-time action.

For a better understanding of what the brand would need to build on top of their data lake, let’s walk through the diagram to briefly describe each of its key components.

  • Data Governance
  • Identity Resolution
  • Machine Learning
  • Connectors, Ingestion & Processing
  • Profile
  • Segmentation
  • Edge Delivery

Data Governance

This encompasses the people, processes, and information technology required to properly handle data across the enterprise. Data needs to be labeled and every label should have its own policy on where that data can be visualized, used, and edited. This also includes complying with regional data protection laws, such as GDPR  and CCPA. Botching this stage can result in multi-million dollar fines and the loss of customer trust over data privacy violations.

Identity Resolution

Every customer is identified in a different way across the many environments and devices they use to interact with your brand. Identity resolution means that, as a brand, you need to have an identity graph that makes it possible to identify every customer across all those channels and devices in real-time, whether they’re known or not. Additionally, brands with operations across multiple countries and brands need the flexibility to define what identity means for each of those countries and brands individually.

Machine Learning

A machine learning environment needs to have access to high-quality data to build, train, and improve models. When done correctly, machine learning enables marketing teams to move away from human-built prone to errors and rule-based segmentation in favor of a genuine one-on-one approach.

Connectors, Ingestion & Processing

This block holds a collection of technologies and services that form a bridge between the incoming data and the data lake. Here is where the ingested data must first be processed and transformed into a consistent format that enables their entry into the data lake. To keep up with enterprise-scale data, this block must be capable of handling tremendous amounts of data and processing it, both at scale and in a timely manner. While ETL applications are part of the answer to this challenge, they aren’t the full answer. Brands really need a single language to describe all their experience data, to ensure a consistent approach in personalization in an omnichannel world.

Profile

This stitches together a customer’s identity and descriptive information to build a complete profile that supports contextual marketing. The challenge is collecting data from both known and unknown users to generate comprehensive, marketable audience insights.

Segmentation

Customers need to be grouped into specific segments based on common traits to help marketers better target their ads and optimize ad spend. This block is crucial since it is responsible for creating, managing, and activating these audiences in everything from advertising and marketing to sales and support.

Edge Delivery

Creating and delivering exceptional experiences requires everything to happen in real-time. Customers live in the here and now, and just like with conversations, experiences need to be contextual and in real-time. An experience will no longer be contextual if delivered after 15 minutes, let alone 24 hours. So, to achieve real-time delivery of experiences you need edge computing, in which profiles and segments live and are continuously updated in real-time.

Adobe Experience Platform is an integrated solution that encompasses all the above, but like many brands in the same position, this brand was hesitant to adopt an out-of-the-box solution to a problem their IT team had already partly solved in-house.

For precisely this reason, we built Adobe Experience Platform as an open, extensible, and API-first platform that can be integrated across various levels of any tech stack. This flexibility allows brands to swiftly onboard Adobe Experience Platform as a “partner ecosystem” that enhances — not replaces — their existing architecture and leverages their hard-earned data.

In the case of this particular brand, the best approach was to invest in an integrated, comprehensive solution that solves the complexities they were struggling with, without leaving behind investments they had already made in their data lake and machine learning models.

Before entering the build vs. buy debate, CIOs must arm themselves with a complete and thorough understanding of the company’s needs and what is available on the market before reaching a final decision.

To help you navigate this sometimes murky process, we will outline the most important considerations when deciding to build or buy software depending on your current business needs and constraints. These are the considerations:

  • Use cases
  • Readiness
  • Project scope
  • Resources
  • Opportunity Cost
  • Time-to-Value

Use cases

The most important question you need to answer before building software is what use-cases you intend for it to solve. The use-case behind the platform influences who the stakeholders will be and who will use the platform in their day-to-day lives.

For example, when building a platform mainly intended for data collection, machine learning, and reporting; the stakeholders are typically data analysts, data engineers, and data scientists who are deeply technical and feel comfortable working with data. On the other hand, a platform intended to drive customer experiences will have the same technical stakeholders but must cater to business users, marketing users, and others who require a user-friendly interface to comfortably interact with the data.

A proper understanding of the use-cases that need to be delivered by the platform you’re building (or buying) greatly impacts the requirements for the end result.

Readiness

Building or buying a platform is not something that can simply be dropped into an unsuspecting organization. Any new addition to a company brings some level of disruption, the scale of which should be accounted for when choosing to build vs. buy.

Traditionally, most companies operate with their marketing and development teams working in silos, where each team has their own datasets, processes, and established way of working.

As a result, introducing a platform (whether built or bought) without transforming the organizational side of things is a recipe for disaster. While technology is a required catalyst for success for both your teams and your customers, it’s still “just technology.” Your company’s people and processes need to be in a position that enables them to embrace change. This makes it crucial that you first evaluate what organizational changes would be necessary when building vs. buying software.

Project scope

The next thing to consider is whether the problem you are attempting to solve is common to the industry or unique to your company. Many of the problems enterprises struggle with today are already solved in commercial software, but if your needs fall within edge cases beyond what’s on the current market, it could be an argument for the decision to build.

There is also the question of complexity. Most internal teams can handle a reasonable level of complexity, but if your solution must span multiple geographical locations and comply with data regulations, such as CCPA and GDPR, it’s advisable to buy software to save on time and resources.

It’s worth mentioning that a solution that reduces the risk of unintentional non-compliance can often pay for itself when compared to the hefty fines that might be imposed if the one you build in-house fails to provide adequate governance.

Resources

When building software internally, you should ensure the company has enough people, time, and computing resources to see development through to completion — even if it goes over budget.

For example, a platform like Adobe Experience Platform has been in the making for several years. Its creation has involved an incredible number of people ranging from Apache Kafka developers, Java developers, data engineers, UI/UX experts, data scientists, and dozens more. Even today, Adobe Experience Platform continues to evolve to keep up with a market in which a new standard, channel, or destination can appear any given day.

You should also consider the potential impact of pulling resources away from activities that drive the company’s main mission. For many companies, building a platform intended for data collection, insights, and analysis safely aligns with their core business. But a platform that needs to communicate and orchestrate customer experiences, user profiles, and content in real-time would only lead their teams astray.

Opportunity cost

Another important question to ask is whether building this software will significantly distract employees from solving core business problems that are more impactful to the bottom line.

Ideally, your company’s IT teams should focus on data and building the infrastructure to gain, report, and predict mission-critical insights. We consider a company’s “big brain.”. Rather than overload this brain with tasks beyond its capacity, it can offload those insights to a second brain specifically designed for communication and orchestration.

Handing off complex tasks that are beyond your team’s comfort zone will allow them to focus on what they do best, while a specialized company takes care of amplifying your team’s efforts and transforming your data into exceptional customer experiences.

Time-to-value

A shorter time-to-value helps companies keep their customers engaged and position themselves ahead of the competition.

For Adobe Experience Platform, we have encountered many companies that have spent 2–3 years building similar software, only to fall short of the requirements marketers need to use it. It’s all too common for requirements to fluctuate over time and internal teams not being able to shift gears fast enough, or at all, resulting in poor adoption by the business teams and impacting the ROI.

This surfaces the question of whether your team can develop the platform within a reasonable time-frame, and if they can keep up with ever-evolving requirements to ensure the final product truly addresses the problems it was created to solve.

Furthermore, if the challenges your company faces are time-sensitive, you must ask yourself how long the company can wait before those problems adversely affect business. When time is of the essence, buying software will address immediate needs as opposed to waiting years for the solution to be built internally — with the risk of the end-result not solving it entirely.

Building a custom platform can be a smart investment that an enterprise should consider only if it has sufficient time and resources for development. They should also have a strategy to ensure its connectivity with applications outside of the company to ensure long-term viability, along with user interfaces that are available and intuitive for day-to-day use.

When resources are sacred and leading digital transformation is top priority, then investing in a comprehensive, extensible platform can reduce costs and maximize performance more than any homegrown solution ever could. It also guarantees a specialized solution that can be continuously enhanced by a dedicated partner, which in turn supports your IT staff in what they do best rather than distracting them from core business tasks.

In part two of this series, we will dive into the technical challenges brands face when building an architecture capable of generating and delivering personalized customer experiences. We will also reveal how we solved each challenge as we pieced together what is now Adobe Experience Platform.

Follow the Adobe Experience Platform Community Blog for more developer stories and resources, and check out Adobe Developers on Twitter for the latest news and developer products. Sign up here for future Adobe Experience Platform Meetup.
Originally published: Jun 16, 2020