Tech Canvas

Build, Buy, or Accelerate

September 11, 2026

Three proposals arrive for the same business outcome, each argued on its technical merits. The decision does not turn on the technology. It turns on how the work is organized and on who is out of pocket if it is late.

The Decision

What Is On The Table

Your technology team wants to build it. AI tools have made development far faster, the cost is one-time, and they price it at roughly two years of licensing.

Your consulting partner proposes their own orchestration platform, or a formal process to survey the market first.

Your architecture team recommends an accelerator, which is the option most likely to be unfamiliar.

An accelerator is a partly finished solution to a specific business problem in your industry. The common work is already built — the process itself, the rules everyone in your sector shares, the connections into the systems everyone in your sector runs. What remains is fitting it to how you work, and the vendor’s own engineers do that inside your business rather than shipping software over the wall.

It is not a platform that replaces your systems, and it is not a blank page. You license it a piece at a time, pay for what you use, and it runs on your own systems with your data staying where it is.

One option can go immediately. An orchestration platform carries no knowledge of your business, so everything that makes your outcome yours still has to be built on top of it — you pay for the foundation and still owe the building. Ask them to show it solving your problem, in your industry, for a customer in production. If that does not exist, you are buying plumbing.

The key point:

A platform with no domain knowledge in it leaves the real work undone.

What AI Changed, and What It Did Not

The build case is stronger than it was two years ago, and your team is not exaggerating that part.

What moved is the time to write software.

What did not move is the time it takes your organization to agree, decide, and hand off. On most builds, that is the larger number — and it is the number nobody puts in the estimate.

The key point:

AI writes software faster. It does not make ten leaders agree faster.

Count the Reporting Lines

Ask who owns the build and you will hear a name, usually the CIO. That settles nothing. Eventually everyone reports to the CIO.

The question is how many separate lines the work crosses before it reaches that person.

Infrastructure, networks and data sitting apart is normal, and projects survive it. The narrower test is the five functions closest to the work: the person defining what to build, the people building it, the people testing it, the people connecting it to your other systems, and the person coordinating all of them, who usually sits in a group of their own.

Five functions in one line is a team. Their estimate probably holds.

Five functions in five lines has no single place where a decision gets made. Your sponsor can convene, escalate and ask. They cannot direct. The project turns red gradually and nobody can tell you which week it happened.

The key point:

Everyone reports to the CIO eventually. Ask how many lines the work crosses before it gets there.

Who Writes the Definition

You know what happens when requirements are weak. The part worth noticing is what AI did to that problem.

Nothing.

AI turns a definition into software very quickly. It does not produce the definition. So the constraint that was always there is now the whole constraint, and it decides most builds.

Which makes the question concrete rather than philosophical: name the person who will write it, and confirm they are available for the duration.

If you cannot, a product is somebody else’s definition, argued out across many customers before you arrived. Reacting to that is a far easier thing to ask of a busy organization than starting from a blank page.

It also arrives with an edge. A product does what it does, and crossing that line has a price attached to it. A build has no edge, so every request is possible and every request gets discussed. That is not indiscipline. There is nothing to refuse against.

The key point:

AI turns a definition into software. It does not write the definition.

Who Is Late At Their Own Expense

This is the part that rarely gets said out loud.

An accelerator vendor does not get paid until it is running. Their revenue depends on your deployment date, which puts their money at risk on your timeline.

On an internal build, nobody’s money is at risk. The team is paid the same whether it ships in March or September.

Two more things come with the vendor. They start closer to the finish line, so the work is configuration rather than development, done by people who have done it before. And their team reports to them — the coordination problem you were just counting lines for is theirs, already solved.

None of which makes the accelerator automatically right. It still has to meet real criteria on pricing, deployment and engineering model, which I have covered in what the model is and how to select a vendor for it.

The key point:

A vendor who gets paid on delivery has something at stake that your own team does not.

Final Thoughts

The discussion in the room will be about technology. Almost none of it decides the outcome.

Three things do. How many organizations have to cooperate. Whether anyone can say precisely what the system should do. And whose money is at risk if the date slips.

All three can be answered without knowing anything about the technology, which is the point. You are not being asked to evaluate an architecture. You are being asked whether this organization, as it is currently arranged, can deliver what is being promised.

A build under one leader with a real definition behind it is often the right answer, and more often than it was two years ago. A build spread across five organizations with nobody to define it is a red project that has not started yet, and no amount of AI changes that.

And if only one option reaches you, that is its own answer. Send them to survey the market. Surveying it is a delay when you already know the alternatives, and the only sensible step when you do not.

Ask how many lines the work crosses.

Then decide.
Before You Fund the Platform

September 12, 2026

You are being asked to fund a foundation so that the work after it goes faster. The technology is real and the team asking is sincere. Three things to check before you approve it.

.

You are being asked to fund a promise

The value in the case is conditional. Nothing arrives this quarter, and the teams that would benefit are described in the future tense. That is not a technology judgment — it is a claim about what other people will do later. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027, mostly for escalating cost and unclear business value.

The spending is not reaching earnings

McKinsey’s 2026 survey of more than 1,700 leaders found 37% reporting any EBIT impact from AI, and 6% reporting meaningful impact. Both numbers were unchanged from the year before, while investment kept rising. Meanwhile 80% of users reported personal productivity gains. The money is moving. It is stopping at the desk.

The ones getting results did something else

Within that 6%, around three in four had redesigned the actual work rather than adding AI on top of it, and they were roughly twice as likely to have a defined way of measuring whether the output was any good. Neither of those is a platform.

Fund the use case. Generalize on the second.

Pay for one outcome that ships. When a second team needs the same thing, you will know what is worth sharing, because you will have built it twice and watched what repeated. Before that, the shared design is a guess — and guesses are what produce platforms nobody adopts.

Build once, reuse many was an economics argument

It held when building was expensive: you built once because building twice cost twice. Building is now far cheaper, and what you would standardize on is changing faster than you can build it. The conclusion does not survive its premise.

They will offer to share the cheap parts

Document reading, the pipelines, the plumbing that reaches the model. Those are days of work now, mostly configuration of something you already pay for. What is genuinely worth sharing is how you decide the output is good enough, and one place where that shows up for everything you run.

Most of it arrives anyway

Gartner expects a third of enterprise software applications to include agentic AI by 2028, up from less than 1% in 2024. Much of what is being requested will arrive through renewals, inside software you have already bought. Waiting a quarter costs less than it used to.

Ask for value every quarter

Release the money in quarterly tranches against delivered outcomes, and define what counts before the first one. “The gateway is deployed” is not value. “This process now runs at this volume, with this share going through without a person confirming it” is.

Final Thoughts

Nobody in the room is wrong. The ask is sincere, the technology works, and the team is usually right that something will eventually be worth sharing.

What is missing is evidence that value arrives before the money is gone.

Fund the outcome.

Generalize when the second one shows up.
The Enterprise Without a Bridge

September 12, 2026

Part one of three on the shape of the enterprise technology organization.

The constraint on how fast a large company can change itself has been technology capacity for thirty years. That is ending, and what replaces it is an organization that looks considerably less like a technology department and considerably more like the business it serves. This is written for enterprises anchored on large systems they did not build.

The Enterprise This Is Heading Toward

Thirty or forty small teams, each owning a piece of how the company actually runs.

Admission. Claims denial. Pricing. Store fulfillment. Each team four to eight people, led by someone who knows that part of the business, sitting inside the business rather than alongside it. Each able to define what should happen, build it, test it, connect it and see whether it worked — without leaving the team.

Underneath them, three utilities: infrastructure, security and identity, and the data platform. Consumed on demand, the way a company consumes electricity. Not queued for.

Above them, the ordinary management structure of any large organization — engineering leaders owning groups of domains, running down the business lines rather than across the technical functions. The hierarchy does not disappear. The leadership bench does not shrink. It stops being organized by what people do and starts being organized by what they are responsible for.

And then the consequence that matters outside the technology organization.

Changing how admission works becomes a decision rather than a program. It is made by the person accountable for admission, executed by the team that reports to them, in weeks.

The key point:

The limit on how fast the enterprise can change stops being technology capacity and goes back to being judgment.

Why This Is Possible Now, and Was Not Before

Every enterprise technology organization exists to close a gap — between what the business wants and what the systems actually do.

That gap was real, and it was wide. Spanning it required analysts, developers, testers, integration specialists and the managers to coordinate them. The organization was the bridge.

Two decades of reorganization were attempts to build a better bridge. Centralize for efficiency. Decentralize for responsiveness. Shared services. Centers of excellence. Agile at scale. Value streams with a platform organization behind them.

Each one improved coordination. None shortened the distance, because none could.

Then the distance closed, and not because anyone redesigned an operating model.

The vendor took the systems. Nobody staffs a database tier for Workday or writes a scheduling engine for an EHR. The hard subsystem now sits inside software you license, along with the specialists who used to tend it.

AI took the translation. Writing the requirement down, interpreting it, building to the interpretation, checking the interpretation was right — most of that chain is translation between people who cannot see each other’s work. Translation is what this technology does.

What remains at the two ends is knowing the business well enough to say what should happen, and judging whether what came out is good enough to use.

Both are business judgment. Neither is a bridge.

The key point:

How the bridge was organized was always a constraint. It was never the unlock. The unlock is that the gap closed.

Why the Current Shape Cannot Get There

A health system set out to automate admission. Twelve months, six business groups, ten technology groups — product ownership, development, testing, integration, data, network, cloud, middleware, robotic process automation, project management.

The result was partial automation and a queue of exceptions.

The exceptions were not technically hard. They were undecided. The payer response does not match what the patient said, the coverage is unusual, the situation had never been defined — so it could not be automated.

Every one of those ten technology groups could build. Not one could decide.

That is the failure mode of the current shape, and more people will not fix it. Neither will faster tooling. The project automated what had already been decided and queued everything that had not, because deciding required standing with the business that no technology group had.

The key point:

The exception queue is the organization chart, re-expressed as work.

The Lineage, and What Changes

Almost every operating model an enterprise has adopted in twenty years was written by people building their own software. Agile, Scrum, scaled agile, DevOps, platform engineering, Team Topologies. All of it assumes you control the codebase, the release cadence, the architecture and the backlog.

Anchor a company on an EHR or SAP and it controls none of those. The vendor sets the release calendar, the data model, and what is configurable at all. So enterprises run ceremonies designed for teams who can refactor, over work that is mostly configuration, validation and workflow design. Sprints exist, and the release date belongs to the vendor.

Team Topologies described teams aligned to value, with platform and enabling teams beneath to carry the load those teams could not.

That was right, and it was written for organizations that build and run their own software. The platform team existed because the cognitive load was genuinely too high for one team to hold. Enterprises then adopted platform teams from a framework written for people who needed to build a platform. They already had one. They had licensed it.

The vendor now carries that load. So does the machine.

What follows is a simpler structure than the one it replaces. Two kinds of team, not four. Domains that own a piece of the business end to end, and utilities that are consumed rather than requested.

The suppliers reached this conclusion before their customers did. Five of them launched units this year staffed by engineers who sit inside the client organization and work directly with the business — Accenture with Google Cloud in September, Microsoft and Amazon before that, OpenAI and Anthropic with their own. They are not selling more platform. They are selling proximity to the decision.

The Hard Question This Raises

If every domain owns its own work, who owns what crosses between them?

The patient’s experience of being admitted and then billed spans four domains. Each has its own leader, its own priorities and its own backlog. Autonomy inside a domain does not answer what happens at the edges of it, and the old shape at least had a program manager who could force a sequence.

The towers never solved this either. They made everything slow enough that the seam was not visible as a separate problem.

This model makes it visible, which is progress and is not a solution. Part three takes it seriously.

Final Thoughts

The organization most enterprises run today was built to supply resources to demand. An idea becomes a request, a request becomes an allocation, and the outcome is whatever survives sixteen groups touching it part-time.

Nobody built that badly. It was the correct design for a problem that no longer exists.

For anyone approving a technology operating model, there is one test worth applying, and it needs no technical knowledge. The last time an automation effort ended in an exception queue — were those cases hard, or had nobody decided what to do with them?

If it is the second, more technology will not help. The shape is the answer.

Part two covers where the system boundaries belong, and why a shared system is a shared queue however the organization above it is arranged. Part three covers the people the model depends on, and why the current shape has hidden them.
Where the Lines Should Be Drawn

September 13, 2026

Part two of three on the shape of the enterprise technology organization.

An organization can collapse every reporting line it has and still be slow, because the systems underneath have boundaries of their own. Those boundaries were drawn on a cost argument that no longer holds.

A Shared System Is a Shared Queue

Take a firm with clinics, a manufacturing operation, and the usual enterprise functions. No single application covers that. There will be an EHR, a manufacturing system, SAP or Workday, and if the firm sells direct, commerce and order management as well.

Give every domain its own team and its own leader, exactly as part one describes. Then put two of them on the same SAP instance.

They now share a release calendar, a change board, a regression cycle and a configuration namespace. Neither moves without the other. The reporting lines are clean and the queue is still there, because the queue was never really about the people.

The key point:

A shared system is a shared queue, however the organization above it is arranged.

The Argument That Built Those Queues

Consolidation won for a good reason. Every extra system meant another integration, another reconciliation, another environment, another team who knew how it worked. One platform serving three domains was genuinely cheaper than three.

So arguments about where a boundary belonged got settled that way — by whichever system was biggest, or whichever leader argued hardest.

Two things changed. Building and maintaining got far cheaper, and the reconciliation that once required identical systems now happens in the data platform afterward.

License cost did not change. But license cost is a line item and dependency is a constraint on the business, and enterprises have spent twenty years optimizing the line item.

The Rule

No system sits inside the workflow of more than one business line.

This is about what a system runs, not which vendor supplies it. One finance instance serving every business line is correct — that is the ledger doing its job. Where the same product is customer-facing, separate instances per line are usually the cheaper answer: two lines on the same CRM with their own configuration and release calendars stay independent of each other.

The simpler version — one system per domain — is also wrong. Epic spans scheduling, clinical documentation and revenue cycle, and that is correct: one value chain, one business line, and revenue cycle in healthcare moves with clinical workflow rather than with finance.

The violation looks different. SAP running the general ledger is finance doing its job. SAP running patient revenue cycle puts a finance release calendar inside a clinical workflow, and the clinic has lost control of its own speed.

The same test kills the obvious efficiency on the retail side. Patient billing and eyewear order billing look like one capability. They serve two businesses with different cadences, regulators and customers. Share the system and retail waits on a clinical release.

Duplication is the price, and two horizontals make it affordable. Identity, because the same person is a patient and a customer. The data platform, because independent systems do fragment reporting — and that is answered by converging at the analytical layer rather than the transactional one.

Independence where the work happens. Convergence where the questions get asked.

The key point:

Enterprise systems receive results. They do not run workflows.

When Nothing Owns the Experience

Where one system spans a business line end to end, it owns the customer experience too. A health system on a single EHR has a natural home for scheduling, results and balances. Take that when it exists.

Three chains on three EHRs is the harder and more common case. The conventional answer is a multi-year consolidation program where the patient notices nothing until the end.

The alternative is to build the digital layer and leave the EHRs different. It breaks no rule — a layer spanning three EHRs serves one business line that happens to run on three systems. And it changes the strategic position: consolidation becomes optional rather than a precondition for improvement.

Two constraints worth stating. Reading across systems is achievable; writing back is hard, and scheduling is the worst of it. And identity is the precondition, because showing one patient another patient’s results is the failure that ends the program.

The key point:

The digital layer is the alternative to consolidation, not a step toward it.

Who Owns It, and What Is Left

The digital layer is a domain team with a business owner, not a service bureau. Each clinical domain exposes a contract — appointments, results, balances — and the digital domain consumes contracts rather than reaching into an EHR.

That distinction is the whole thing. The digital team owns the patient-facing product. Domains own their capability and their content. When billing wants to change what a patient sees about a balance, billing changes it.

The failure mode is specific and it happens every time: the digital team starts building on behalf of a domain because that domain is slow. At that point it becomes the queue everyone waits in.

And something real remains. Two domains sharing a contract still have to agree on when it changes — two backlogs, one release, a conversation between two leaders about sequence. No structure removes that. It is genuine coupling, not organizational residue.

It can eventually be automated, but only afterward. Automating the handoff while sixteen groups still exist is what produced middleware and robotic process automation, and how a twelve-month project ends in an exception queue.

Final Thoughts

For twenty years the answer to where a system boundary belonged was whoever argued hardest, defended by a cost case nobody could check.

That cost case has changed. What replaces it is a principle: boundaries follow business lines, duplication is affordable, and convergence happens where the questions are asked rather than where the work is done.

Collapse the bridge first. Then automate what remains.

Part three covers the people — who the model depends on, and why the current shape has hidden them.