Technology Consolidation

Avoid growth-through-acquisition concerns by consolidating technology for long-term business growth

Glossary

TTM — Time-To-Market

ROI — Return-On-Investment

Over the years I’ve witnessed two failures in business strategy, both caused by an unwillingness (or a neglect) to consolidate technology, that have led to poor agility, and subsequently, growth. They are:

1. Failure to consolidate after undertaking a product replacement strategy.
2. Failure to consolidate a product(s) after a merger or acquisition.

Let’s discuss them.

Note — DRY Principle

Firstly, some terminology. Mainly, when I describe technology consolidation, I’m really describing the need to follow the DRY (Don’t Repeat Yourself) principle, to reduce waste and complexity. It’s a simple, but extremely important technique; don’t do the same thing twice.

Consolidation after Product Replacement

Consider the following scenario. You work for an established business, providing services to a wide range of customers. The business’ current product has sold well, but it’s now aging and something modern is required to appeal to both existing and new customers. So… you start building a new product.

The business intends to migrate all customers from the old system, across to the new one. However, there are two problems:

1. Building the new solution will take years.
2. Existing customers must still be supported; this includes functional change and extension on the old product.

Note — Monolith Overload

In the past, I’ve seen monolith after monolith created to satisfy this business desire. Each monolith uses (at the time) modern technologies and techniques, yet the net result is the same. The products diverge to a point where the migration effort is unacceptable, and multiple products must be maintained.

There’s a fair chance that the business never performs the consolidation phase, so their customer base becomes strewn across multiple applications, with each successive feature added, exacerbating any prospective migration plan. See Figure 1.

Figure 1 — customers distributed across multiple products of (basically) the same ilk

There is a solution to this problem, which I’ll describe later.

Consolidation through Acquisition

Acquisition (and mergers) is a common business strategy that (attempts to) stimulate business growth. Often, it’s applied to achieve Economies of Scale.

Note — Economies of Scale

Economies of Scale — the act of gaining competitive advantage, by increasing the scale of operation, whilst decreasing cost — is often used to gain competitive advantage by:

1. Protecting your assets from competitors.

2. Reducing pricing through greater efficiencies and better bargaining power.

3. Incentivising existing customers to buy more, at a cheaper price, than if those customers had to source them independently.

When one company acquires another, that business typically swallows up another (including its employees, products, and customers). The acquiring business benefits in three ways:

1. It may now offer these newly acquired products and services to its own existing customers.
2. It now has a larger, more diverse, customer-base to offer its current products and services to.
3. There’s one fewer competitor in the market.

Figure 2 presents this approach.

Figure 2 — Growth through Acquisition

I won’t comment further on this business strategy; I’ll leave that to business strategists. However, I will comment on the potential outcomes of this strategy when the acquired products are software technologies.

Consider the following example. CoreTech is a business wishing to expand their presence into other regions, and thus become more profitable. They currently offer software products A and B, mainly to a core US market. They successfully broker a deal to acquire a smaller, European-centric business, called WolfTech, to bring their product and specialities under CoreTech’s umbrella.

CoreTech now has three key benefits:

1. They have a more diverse product portfolio to offer customers.
2. They have more customers, thus (hopefully) more profit.
3. They now have a presence in another region (Europe) to sell their products/services.

Sounds appealing doesn’t it? But there’s some disadvantages. The products on sale are software applications. We now have three products (good); however, some aspects of those products perform the same job, such as capturing customer details (bad). Figure 3 shows the offering.

Figure 3 — CoreTech’s product suite

Note that all three products all support Users and Customers features (indicated in blue).

As new customers are on-boarded, we find most only need parts of each product. Let’s say a prospective customer (propellor.inc) needs these features from Product D: Users, Customers, Products, Portfolios, Ledger, Carts, Discounts. See Figure 4.

Figure 4 — propellor.inc’s needs

Note that these features touch all of CoreTech’s products. From a business perspective, this seems OK, so we offer them this; why wouldn’t we? However, the problem is insidious, and relates to system dependency management.

To use specific features of each product, we must also manage every one of that feature’s dependencies.

For instance, all three products need a user and customer, regardless of whether it’s functionally useful. See Figure 5.

Figure 5 — semi-consolidated products

Now, let’s say CoreTech use this business strategy (acquiring more businesses and technology platforms) repeatedly, for differing customer needs. We get a spaghetti system, such as in Figure 6.

Listing 6 — big big ball of mud

We must:

1. Deploy them all, to each environment (where each product likely runs on its own infrastructure).
2. Wire them all together. A entirely unsatisfying burden.
3. Manage data synchronisation across systems.
4. Support and coordinate upgrades and migrations across systems.

We’ve forced a coordination and synchronization situation that is complex and fraught with danger.

Note — The Tail Wagging the Dog

To clarify, this approach causes us to duplicate data solely to satisfy each system’s needs for a specific feature. It’s a system-level dependency that the business wouldn’t expect us to manage; i.e. it provides no useful business functionality, only the means to enable part of a system. We’re satisfying the system, not the business — an obvious case of the tail wagging the dog.

Effects of this Approach

With the increased complexity, comes:

1. Additional staffing needs (i.e. reducing profitability) to manage all products.
2. Additional TTM concerns.
3. Poorer ROI.

The end result may be unexpected. See Figure 7.

Figure 7 — Complexity’s path to business woes

Data Synchronization

Data Synchronization across disparate systems is onerous and error-prone. For instance, consider the case where a customer wants to update their personal information. Even if we successfully update their details in products A and B, what should we do if the update in Product C fails? Rollback. How? Proceed, knowing we now have data consistency issues? Would that be smart?

Data Migration

Data migration is also challenging. The migration is too large a task, or too risky, or regression is too costly. We end up with the same customer duplicated across multiple systems, with the need to synchronise data across those systems. The migration task might look like Figure 8.

Figure 8 — the pain of multi-system data migration

A Long-Term Growth Cycle

Some businesses have attempted — and succeeded — to grow through this model; however it’s a difficult one to sustain. A key reason for this long-term failing is — I believe — technical debt. With each new acquisition, we must successfully manage a host of new technical debts. Let me elaborate.

In the early 2000’s several well-known companies grew using the growth-through-acquisition model. Over a relatively short period of time, these businesses drew in, or merged with, many other businesses to create a corporate behemoth. Initially, all seemed well. Profits were good, they expanded into new markets, brand reputation soared. But below the surface, a storm was brewing.

Each new acquisition came with technical baggage. And as the business acquisition rate overtook the business’ ability to resolve the technical debt, some businesses ended up managing hundreds of discrete applications.

To further exacerbate matters, many of these applications contained features that were only slight variants on what others already did (i.e. the same role, but uses a slightly different implementation, or integration model). Typical examples being user authentication, or customer capture.

Note — “Sensible” Forms of Reuse

Although these systems often offer similar behaviors, it’s varied enough in what’s captured, how it’s stored, implemented, or the integration patterns used, that reuse becomes practically impossible, without also pulling in the entire application — something we want to avoid.

The Curse of Duplication

Why is duplication bad? Consider the case where a business has multiple products that expose the same functions (e.g. capture customer information). In this case, we have multiple different mechanisms to capture and store customer details. There’s no easy way to Consolidate, without significant changes.

Now consider that we must implement a governmental directive (e.g. GDPR) to prevent significant financial penalties. So now, we must identify, change, deploy, test, and release, every instance of a customer capture feature across the entire portfolio. Talk about poor Return-On-Investment.

The Cycle

The steps (as I see them) to long-term growth through acquisition are shown in Figure 9.

Figure 9 — long-term growth through acquisition

The typical “growth through acquisition” cycle is:

1. Acquire new business.
2. Sell off (unnecessary) assets.
3. Reduce (unnecessary) staff.
4. Embed acquired technology and products into the parent product suite.

At this point, it’s very tempting to repeat this cycle, but I’d suggest (for long-term sustainability) that you don’t. You should consider the consolidation phase; described next:

1. Consolidate technology.
2. Migrate customers to consolidated technology.
3. Reduce unnecessary staff.
4. Repeat.

Let’s look at the steps.

Acquire New Business

In this phase, agreements are made, due diligence is undertaken, contracts are signed, and the business is acquired/merged. We’ve now got a bunch of new technology products to support.

Sell Off Unnecessary Assets

Any products or services that aren’t deemed of value to the parent business are discontinued, or sold on to others. The remaining products are retained, and ingested into the parent company’s product suite.

The parent company can now offer a more diverse range of products (see later stages).

Reduce Staff Overhead

An unpalatable one, but it’s pretty typical in acquisitions (and one I’ve been at the receiving end of).

The parent company identifies the necessary staff to support the retained products/services (they must retain some experts to manage that product), and discards the remainder. This is mainly about managing profits.

However, it’s worth mentioning that the parent company’s overall staff levels increase to maintain these products.

Embed Acquired Technology into Product Portfolio

In this stage the new product(s) are ingested into the parent company’s product portfolio and can be sold to prospective customers. Additionally, the parent company has expanded their customer-base/revenue from the customers already using the ingested product(s).

The manner in which the parent company now manages its solutions is critical to their long-term success. If solutions are composed from many other large, tightly-coupled (monolithic) applications, then we may have an application sprawl that can hamper sustained business growth (see earlier).

Consolidate Technology

The Consolidate phase is one of the most important. Without it, we may suffer mass complexity, technology sprawl, duplication of effort, and a general delivery and cultural stasis.

There’s a potential paradox here. By attempting growth through acquisition, a business may have hamstrung itself with poor TTM, ROI, and Agility, and no longer support good business practices, like reacting quickly to the changing needs/tastes of customers, or building disruptive products. If a business isn’t lean, in terms of technology sprawl and staffing, how can it react to both growth demands and the need to continually delight existing customers?

Note — Losing sight of Each Customer

As businesses grow, some lose sight of their more humble beginnings. A single customer holds less importance than a large group of them, or the need to keep growing.

However, I strongly believe there’s a need to balance business growth with customer retention. Lean too far towards growth, and run the risk of alienating existing customers (how many times have you felt unvalued as an existing customer when you see a great deal “only open to new customers”?). This can lead to customer dissatisfaction, and eventually, churn. Too far in the other direction, and you never grow, and risk competitors eating up your market share. I never said this was easy …

Neglecting the Consolidation step may cause the following issues:

• A duplication of features to manage; i.e. poor ROI.
• Additional complexities and thus, confusion. Upgrades become a nightmare, so don’t get done.
• An unnecessarily large technology workforce; i.e. eating into profits.
• Resilience issues. Too many dependencies to comprehend (or test) the effect of a change, or a downstream failure.
• Higher ongoing costs. Each change must be discussed in minutia.
• Higher operational costs. Each application needs its own infrastructure. This could also cause branding issues if you don’t correctly scale each system correctly.
• Poor TTM.
• Change Friction. Mainly due to an unwillingness to make a change due to poor stakeholder confidence (e.g. “last time we changed this, it was down for three days, and cost us ten million dollars…”).
• Technical Debts.
• Lack of Innovation. The existing systems suck in all resources, to the detriment of innovation. Additionally, if an earlier incident caused regulator involvement, that involvement can also impact your ability to innovate.
• Noncompetitive. Change takes too long and is too painful. No innovation coming out.
• Difficulties in changing a culture (e.g. unnecessary large workforce).
• GDPR-style projects across all affected systems; terrible ROI.
• Security concerns. You’ve a far wider set of technologies to secure and keep secure, across a plethora of different technologies/infrastructures/hardware. Do you have such a diverse range of skill-sets to support them all, or must you employ them (impacting profits)?

Ways to Consolidate

Consolidation isn’t easy, or quick, which is why it is oft-neglected. The key thing we’re aiming for is a smaller, cohesive footprint; i.e. less to manage. Specifically, we’re looking to identify features that perform similar jobs, and then find opportunities to only use a single one.

As a general rule of thumb, the Consolidation phase is:

1. Identify the similarities.
2. Prioritize their importance.
3. Create a single service to represent all variants of that feature.
4. Route all existing applications to this new service (e.g. Strangler pattern).
5. Migrate data to the new service.
6. Discard the old feature for each application.
7. Repeat.

Note — Approach to Consolidation

Consolidation probably should not be undertaken as a big-bang. You can migrate one application at a time, prove it works, then move on to the next one. You might begin — for instance — with the most heavily used application, leaving applications marked for deprecation till last (if ever).

The result is that applications become leaner, software is consolidated, there’s less confusion, upgrades and releases are simpler and can occur more often, and better long-term (I don’t suggest it’s better short-term…) TTM and ROI.

Migrate Customers to New Products

We’ve now consolidated the technology/product(s) to create functionally equivalent solutions, so we can now migrate the customers on one system to the desired one. Once that’s achieved, we can now discard parts of the old system.

Reduce Staffing Overhead

Sorry, but it’s business, and businesses care about profit. By migrating those customers from the external system onto a consolidated product, we don’t need to support the others products, and thus, we don’t need the staff maintaining them. We can either utilize those staff in other areas of the business, or (legalities aside) lay them off; this can be a significant cash-flow saving.

Repeat

We repeat this cycle. Acquire another business. Sell some products, embed the others. Tidy up. Remove waste. If we’ve been cautious, we’ve minimise debts, and supported sustained growth.

Summary

It’s easy to become lost in the excitement of a fast-growing business. But those days may not last forever. At some stage, the technical debts you’ve accrued may result in (a) an embarrassing branding failure, and/or (b) the inability to move quickly, or be agile.

Each change takes more and more effort, and you end up undertaking more and more unnecessary work just to satisfy the system, and not the business. Change Friction has you in its grasp. The tail wags the dog.

Saying that, there’s also something to be said on lost opportunities. If the business doesn’t acquire, will it get another opportunity? It might be acceptable to acquire and not immediately consolidate. Like much in life, it’s about finding the right balance.