Buy vs. Build Revisited, Part 3: From Having Bought to Going to Build

In my third installment on digging deeper into deciding between buying software and building it in house, I want to describe how organizations can transition from a “mostly bought” environment to one where they can productively build bespoke solutions. As an industry we are mildly guilty of repeatedly showing great target pictures but then falling short of laying out a plausible adoption path that accommodates typical enterprise environments. Let’s correct that.

Note: This post is part of a mini-series. If you landed here first, I invite you to read my earlier posts:

• Buy vs. Build, Revisited, Part 1: Three Traps to Avoid
• Buy vs. Build, Revisited, Part 2: Drawing the Line

Enterprise Software Evolution

Most enterprises begin their IT journey by buying software. As we discussed before, this makes good sense because it lets the organization benefit from the vendors’ experience and economies of scale. After purchasing several such commercial software packages, an enterprise IT landscape would look roughly like the following diagram—a set of independent systems (I am using abstract package names to avoid getting mired in semantics; think CRM, ERP, order management, etc.):

Things rarely stay this way for long, though: enterprises routinely customize the software that they buy, initially done via vendor-provided configurations. Also, it’s rare for software to live in complete isolation—“silo” has become a common word of caution in enterprise IT. Hence, enterprises start to build connections between their commercial software packages (originally called EAI , Enterprise Application Integration, this activity has changed names many times). Combined, these trends lead us to an environment that’s both integrated and customized via configuration:

Ignoring data and analytics for a moment—which often run parallel to software—a lot of enterprise IT will look like the above image. However, enterprises never stand still, so the levels of integration and customization tend to increase over time. Sadly, this path leads to two equally common and dreadful IT anti-patterns:

The first anti-pattern is the result of excessive integration, also referred to as the “giant hairball” or, more technically, as IBAR, “Integrated Beyond All Recognition.” This architecture of sorts surely breaks down silos. Sadly, it also makes changing or replacing systems nearly impossible due to excessive coupling and interdependencies between systems.

The second pattern, different in nature but equally nefarious, occurs when customization slowly takes over the purchased software package. Endearingly called “customageddon” or CBAR, “Customized Beyond All Recognition,” this scenario unfolds slowly through increasing customization, often encouraged by vendor consultants who are proud to demonstrate what’s possible on top of the purchased software package. Sadly, brittleness, lock-in, and staggering professional services fees are common symptoms of this state of affairs.

The two anti-patterns aren’t mutually exclusive, allowing enterprises to double dip into a combination of both, which we’d have to describe as nothing short of FUBAR.

Enterprise Architecture 101

Sadly, FUBAR isn’t as rare as it should be. Rather than lament the sorry state of affairs, we should think about what causes smart enterprises to slowly drift into this unhappy condition. Understanding the mechanisms at work can not only help avert disaster. It can also give us valuable hints as to how we can dig ourselves out of the hole.

The root cause of excessive customization and integration is often a mismatch between the software you purchased and your company’s operating model. Although some customization is to be expected and planned for in the commercial product design, once it looks like you are building your own software on top of a commercial software package, you should get suspicious and rethink your strategy.

The best way to visualize any potential misalignment between software packages and the way you think about your IT is to plot the main capability blocks of your IT landscape without regard for the software packages already in place. In a much, much simplified example, this could look as follows:

In this example, your business engages customers across three channels: a website, a mobile application, and interfaces (APIs) for external partners. You prefer to manage these channels uniformly (keyword omni-channel), supported by digital core capabilities such as a product catalog, a shopping cart, and order entry. These capabilities are then supported by transactional back office systems, including fulfillment, inventory management, and supply chain management. Naturally, real life would include many more aspects, such as payments, recommendations, forecasting, etc.

The critical next step is to compare this view to the software packages you purchased. Again, for simplicity’s sake, assume you are operating three major commercial software packages for this part of your enterprise:

You can now overlay the two images to show how well these packages fulfill your functional needs. Because they won’t match exactly, you’ll need to distort either the packages or the capabilities from their nice rectangular shapes. Working backward from your needs, I recommend stretching the packages. You might end up with a picture like this:

Despite using an oversimplified, fictitious example, you can gain several insights from this overlay:

• Third party APIs aren’t covered
• Package boundaries don’t line up with capability boundaries (see “giant hairball” above)
• The core capabilities are covered by a mix of all three packages
• ERP fits fairly well for the back office aside from a small appendix stretching into the core capabilities

If things fit just right, there will be little need for you to build anything by yourself. However, if your capability view deviates from the standard industry view, as was the case with Phil’s and Ishit’s IT landscapes (see Part 1), then you will likely find significant gaps or overlaps between commercial packages and your world view. In most cases, you are making up for these gaps with integration and customization—see IBAR and CBAR above. Such a mismatch might be a signal for your organization to consider what your system landscape could look like if you built your own software.

Developing a capability landscape and mapping it to commercial software packages isn’t something you can ask your software vendors to do. They’re motivated to always make it look perfect and naturally start from their point of view. Hence, this is an in-house exercise and should be daily bread and butter for your enterprise architecture department. If this isn’t something they can deliver, you might have to make a buy vs. build decision for better enterprise architects.

Identifying a mismatch leaves you with two options:

1. You can adjust your operating model to the software packages
2. You can adjust your software landscape to better match your operating model

The first option isn’t as meaningless as it might sound. Many software packages, such as ERP, actually help you adopt more modern processes. Also, you will get the most out of cloud computing if you adjust your existing processes. However, if your operating model is germane to your business’s success, you’d want to work backward from what makes you successful and ensure that you have the right IT to support that. We therefore discuss how to execute option #2 in the rest of this post.

Out with the Old

Replacing an existing application with something new is never going to be easy. One advantage you have when building software is that you can build features and components in the sequence that best matches a possible migration path. As a first step, you’ll modify the map to see what you want to replace and how that new piece fits in. Here’s an example:

In this case, similar to Ishit’s, you are looking to better integrate customer engagement across channels and replace bits and pieces of the web store and the CRM with your new integrated engagement layer (I invite you to pick a catchier name). If you find a commercial package that exactly matches the shape that you’re looking to fill, you might want to carefully reconsider your decision. You get the most bang for your buck when you’re building something that has a very different shape than what’s available in the market, as was the case for both Phil and Ishit.

In our simplified example, you keep a small piece of the web store in place to help manage the shopping cart because that’s fairly vanilla functionality. Whether you should replace this component will primarily depend on your licensing agreement (you wouldn’t want to pay for a whole web store software package just to use the shopping cart functionality) and how easy an integration is. You leave the ERP in place as it matches your needs reasonably well. You might at some point want to extract the catalog functionality from the ERP to make it more scalable and reduce operational costs (the cost per request is likely much higher than with a cloud-based system)—a classic start of a strangler maneuver.

IT architecture is occasionally portrayed as drawing pictures containing many boxes and lines. As long as there’s a clear rationale and set of decisions behind the colorful diagrams, though, they can play an important role in communicating a strategy to a wide range of stakeholders,.

In with the New

Plotting migrations on paper is useful but still a rather poor approximation of the effort involved in an actual migration. The good news is that thanks to cloud computing platforms like AWS, you’re not starting from scratch. We’ll discuss this aspect in Part 4 of our mini-series.

—Gregor
Twitter | LinkedIn | Blogs | Email

More on this topic

Buy vs. Build Revisited, Part 2: Drawing the Line, Gregor Hohpe

Buy vs. Build Revisited: 3 Traps to Avoid, Gregor Hohpe

Don’t Outsource Thinking, Gregor Hohpe

Time to Rethink Build vs Buy, Ishit Vachhrajani