Everyone is busy adopting. Far fewer are deciding where the technology belongs.

The pattern repeats often enough to be predictable. An organization buys a platform, runs a pilot, and gets a demo that works. Then it hits the wall. The data sits in silos. Nobody owns the governance. The workflows were never written down in the first place. The pilot stalls, and the next conversation is about why the technology did not work here.

The technology worked. The foundation was not there.

Activity is not strategy. Adoption is not architecture. Speed without direction is expensive motion.

The question that belongs before the purchase

If a strategy is a list of tools that were bought, it is not a strategy. It is a shopping list.

Tools are easy to buy. A platform demo takes an hour. A licensing agreement takes a week. Showing a board that the company is investing in something takes a slide. Building a data foundation takes months, and getting cross functional agreement on governance takes leadership that many organizations are not structured to provide. Nobody sends a demo for that.

One path looks like progress. The other one is progress.

The organizations that build real capability do not start by asking which product to buy. They start with a harder question: which decisions are we trying to make better, and what would our data need to look like to support them?

That question has no vendor attached to it. It requires someone who can see across the whole technology landscape and connect the business problem to the infrastructure underneath it.

The real decision is where in the stack to build

The build or buy debate is usually framed as a single choice. It is the wrong frame. The useful question is where in the stack to build.

The instinct to build everything is understandable. Full control, no platform dependency, your own data and rules. But most of what gets built that way is plumbing that platforms have already solved: hosting, orchestration, security controls, compliance certification. That is expensive engineering spent on capability that will never differentiate the business, plus a permanent treadmill of keeping pace with a landscape that shifts every quarter.

The instinct to hand everything to a platform carries its own trap. Platforms are genuinely strong at the infrastructure layer. They are not going to build a data foundation for you. They do not know your workloads, your integration points, or the governance your business actually requires. Adopt the platform without building those layers and the result is an impressive demo that never becomes production value.

Use platforms for what they are good at. Put build energy where no platform can go: the data foundation, the integration into the workloads the business actually runs, and the automation logic that reflects how the work is really done.

This is not only a question about new technology

The same discipline applies to infrastructure, core applications, data, integration, governance, and custom software.

Every capability an organization owns has a lifecycle. Some are growing. Some are mature and productive. Some are declining while still generating enough revenue that nobody wants to name the decline. And some should have been retired a while ago, kept alive by inertia and by the fact that someone built a career on them.

Deciding what to invest in, what to sustain, and what to retire is harder than adding another item. Adding is easy. Anyone can pile on new capability. The hard part is looking at the whole portfolio honestly and asking whether each part still produces value, or whether it is being maintained out of habit.

Comfort and relevance do not stay in the same house for long.

Working principles

  • Start with the outcome, not the product category.
  • Design for the system that must operate after launch.
  • Make integration, governance, and ownership first-order decisions.

Architecture gives adoption a direction. Without it, adoption is just motion that happens to be expensive.