Right Tool. Wrong Architecture.

There is a question we should ask more often when evaluating new technology: if we can already solve 95 percent of this problem, what is the remaining 5 percent worth?

Not just the difference in licensing cost. What is that 5 percent worth after we account for another platform, another integration, another security model, another place for data to live, another skill set to maintain, and another vendor relationship to manage?

I have always believed in using the right tool for the right job. I still do. But there is a second half to that principle: the right tool also has to be right for the architecture. Otherwise, we can make a series of perfectly rational technology decisions and end up with an irrational technology estate.

When 5 Percent Becomes Another Platform

Consider a scenario familiar to most technology organizations. A company already owns a mature ecosystem. Identity and security are established. The data platform is there. Reporting, workflow, automation, application development, and integration capabilities already exist, along with the skills and governance to support them.

Then another requirement appears.

There is a specialized platform that handles it exceptionally well. Put the products side by side and the specialized platform may win. It may have a better interface, a feature the existing platform lacks, or a more elegant way of solving a particular workflow. The existing environment, however, can accomplish 95 percent of what the business actually needs.

At that point, the question changes. We are no longer asking which product is better. We are asking whether the remaining 5 percent creates enough business value to justify introducing another system into the enterprise.

That 5 percent has to earn its way into the architecture.

I have seen this play out with workflow and low-code applications. A tool is selected because it solves an immediate business process extremely well. Then that process needs data from another system. Reporting needs the data somewhere else. Another related process gets added. Before long, what began as a solution to one problem has become another permanent part of the enterprise architecture.

None of those decisions was necessarily wrong. That is what makes this difficult. The tool can do exactly what it was purchased to do, while the architecture continues paying for the decision long after the implementation project closes.

Complexity Doesn’t Send an Invoice

Architectural complexity is easy to underestimate because nobody sends you a bill for it. You pay when an integration breaks and a business process stops, when two systems disagree about the same customer, or when employees move among six applications to complete what the business considers one process.

Some of these costs can be measured. Many cannot. They surface as support tickets, manual workarounds, duplicated data, additional administration, brittle integrations, institutional knowledge, and hours of somebody’s day.

You also pay years later, when the people who selected the platform have moved on and somebody else has to administer it. We spend enormous energy asking what a system can do on implementation day and remarkably little asking what it will require from the organization in year three.

Individually, none of these costs may be large enough to challenge the original business case. Collectively, they become part of the permanent operating cost of the enterprise.

Eventually, complexity begins charging interest.

But 95 Percent Can Be a Terrible Answer

The 95 percent rule can be abused just as easily as “right tool for the right job.”

Sometimes the missing 5 percent is the job.

A platform can satisfy nearly every requirement on a spreadsheet and still fail at the one capability that actually matters. When that happens, users do not politely accept the architectural strategy. They route around it. They build spreadsheets, create manual processes, buy departmental applications, maintain databases nobody knows about, and move business-critical information into places the technology organization cannot govern.

Now the organization has fragmentation anyway, except this time it did not choose it and did not design it. Unchosen fragmentation can be worse than the complexity we deliberately introduce.

So this is not an argument for forcing every new requirement into whatever the organization already owns. “We already have a tool that can technically do that” is not an architecture strategy. The 5 percent still has to earn its way in, but sometimes it absolutely does.

The distinction is whether that 5 percent represents meaningful business capability or merely incremental product capability. Those are not the same thing.

Consolidation Is Not the Objective

I believe strongly in consolidation, but consolidation is not the goal. A monolithic architecture can be every bit as damaging as a fragmented one if it forces the business into compromises that prevent it from doing what actually differentiates it.

The objective is to standardize what should be standard, consolidate what is unnecessarily duplicated, and specialize where specialization creates enough value to justify the complexity. The goal is not to minimize the number of systems. It is to make the existence of every system defensible.

Five Questions Before You Say Yes

When another platform is proposed, the architecture discussion has to move beyond the feature comparison. There are five questions I want answered before the decision:

1. Does this solve a capability we genuinely do not have, or one we already have slightly better?
2. What measurable business value exists in the missing 5 percent?
3. What does this add to our data estate, security model, integrations, and support burden?
4. Who owns and administers this system three years from now?
5. What happens to the business process when this system or its integrations fail?

Those questions do not automatically lead to consolidation. They lead to intentionality.

Sometimes the answers make the case for the specialized platform stronger. If the missing capability creates competitive advantage, eliminates significant operational friction, or enables something the existing architecture simply cannot do well, the additional system may be exactly the right decision.

But we should make that decision understanding that we are not just buying another piece of software. We are adopting another piece of architecture.

AI Raises the Stakes

This conversation has become more urgent because AI is exposing the accumulated cost of fragmented technology estates.

For years, organizations could tolerate information being scattered across applications because people learned where to find it. Finance knew its systems. Operations knew theirs. Sales knew theirs. Employees learned which application contained which piece of information and, in effect, became the integration layer themselves.

AI does not eliminate that problem. If customer information lives in five places, operational data in four more, documents somewhere else, and critical workflow context is trapped inside specialized applications, building useful enterprise AI becomes considerably harder.

The challenge quickly stops being the sophistication of the model and becomes the condition of the enterprise underneath it. The system we added five years ago because it solved one problem better may now be another boundary our data has to cross before AI can understand the business as a whole.

Which is why the rush toward AI should cause organizations to examine their architecture rather than simply add another layer on top of it.

---

I still believe in the right tool for the right job. I have just come to think we spend too much time evaluating the tool and not nearly enough evaluating what adding it does to everything else.

The next time a new platform wins the feature comparison, ask one more question:

We already have 95 percent. What is that last 5 percent worth?

Connect Data. Manage Systems. Build AI.