The SOA Promise: Why Trust Held It Back, and Why AI Agents Make It Unavoidable

The SOA Promise: Why Trust Held It Back, and Why AI Agents Make It Unavoidable

01Introduction

Service-oriented architecture (SOA) is the idea that software should be composed from independent, reusable services rather than built as one large codebase, with each capability consumed over a network interface instead of owned and maintained in-house. The promise was simple: teams focus on what makes their product different and consume everything else as a service.

Twenty years later, most engineering teams still default to building or bundling instead of consuming. The reason was never the technology. The reason was trust. There has never been a reliable way to verify what an external service does with your data, where it runs, or what it retains, so teams treated services as a risk and paid the maintenance cost of ownership instead.

That trade-off is now breaking down. AI agents generate code and compose services at a volume no team can maintain by hand, and EU regulation increasingly requires proof, not promises, about every vendor in the chain. This post walks through what SOA promised, why trust blocked it, and what has to change for engineering managers to finally get the advantages it described.

02What SOA Actually Promised

Service-oriented architecture emerged in the early 2000s with a clear thesis about how software should be assembled:

1. Composition over construction. Products are compositions of capabilities: file conversion, data validation, invoicing, OCR, currency exchange, enrichment. Almost none of these capabilities differentiate the product. SOA said: consume them as services and spend your engineering effort where it matters.
2. Best-in-class per capability. Instead of one team being mediocre at twenty utility problems, each capability is delivered by whoever solves it best, and everyone benefits.
3. Less code owned per team. Every line of code a team does not own is a line it does not patch, monitor, upgrade, or answer for at 3am. Consuming a service moves the operational burden to the party best equipped to carry it.
4. Loose coupling and replaceability. Services behind stable interfaces can be swapped, scaled, and evolved independently, without a rewrite of everything around them.

The vision was right. Modern cloud platforms, microservices, and API-first products all descend from it. But the full promise, where teams routinely consume external capabilities the way they consume electricity, never fully arrived.

03Why It Never Fully Arrived: Trust Was the Blocker

Every team choosing how to obtain a capability faces three options, and each trades maintenance for risk:

Notice the asymmetry at the right end of that gradient. Everything a team does not build itself arrives through a supply chain, and that chain has two halves. Packages got an entire tooling industry: lockfiles, SBOMs, provenance attestations, content hashes. A package can be pinned, diffed, and scanned. Services got none of that. A third-party API is whatever the endpoint returns today. Its privacy policy can change without notice. Its sub-processors are invisible. Its infrastructure can move to a different jurisdiction between two calls, and no signal reaches the consumer.

So when SOA asked teams to hand their data, their users, and their compliance posture to external services, the honest answer to "how do you know this service is safe?" was: you don't. You read a marketing page, maybe a stale SOC 2 PDF, and you hoped. Security teams and procurement understood this, which is why external services ended up gated behind months of vendor review, kept at the edges of the system, and limited to a few large, brand-trusted providers.

The result: most teams defaulted back to build-or-bundle, and paid the maintenance tax instead. The bottleneck of SOA was never discovery or tooling. It was that trust between a consumer and a service was informal, unverifiable, and static, in an architecture that needed it to be explicit, verifiable, and continuous.

04The Maintenance Tax: What Refusing SOA Actually Costs

The alternative to consuming services is owning code, and owned code bills you forever. Industry estimates commonly place ongoing software maintenance at 15–30% of the original build cost every year, for as long as the system runs. That covers dependency updates, security patches, compliance reviews, incident response, and performance work. None of it is optional, and none of it ships features.

Bundling open-source packages does not escape the tax; it converts it. The 2025 Shai-Hulud npm supply-chain attack, documented by CISA, saw a self-replicating worm compromise 500+ npm packages, harvest cloud credentials from developer machines and CI pipelines, and publish stolen secrets to public repositories. Follow-up waves through late 2025 and into 2026 spread across thousands of repositories. Teams that "avoided vendor risk" by bundling packages inherited a dependency graph they never fully read, shipped it to production, and trusted it with customer data.

Every one of the three options carries risk. The question is which risk is manageable at scale. Owned code and bundled packages put the burden on your team, permanently. Consumed services put the burden on the provider, permanently, if and only if the provider's behavior can be verified.

05Why This Matters More Now: Agents Changed the Math

Two things happened between the first SOA wave and today, and both push in the same direction.

First, software creation collapsed in cost. A coding agent can generate a working utility service before lunch. It will not patch that service's dependencies for the next five years, respond to a security questionnaire, or notice when one of its transitive packages is compromised. AI removed the visible part of the software loop, the effort, and left the expensive part, the ownership. More code, generated faster, with less human comprehension between it and production, means the maintenance tax is no longer a line item. It is the dominant cost of software. At this volume, "build everything yourself" stops being a preference and becomes an impossibility. Composing from services run by someone else is the only arithmetic that works.

Second, agents became consumers of services, and agents cannot do informal trust. A human evaluating a vendor reads between the lines: brand reputation, a familiar logo, a gut feeling. An agent has none of that. An agent selecting an API mid-workflow needs a verifiable, current, machine-readable fact about the service, or it has nothing to go on. It will not pause on an unfamiliar maintainer or a suspicious domain. It optimizes for "does this complete the task," not "should I trust whoever runs this." The Shai-Hulud campaigns already showed what happens when automated systems pull in whatever gets the job done.

So the agentic era makes SOA both unavoidable and, under the old trust model, unsafe. The volume of software demands service consumption. The consumers of those services increasingly cannot evaluate trust the human way. The only resolution is to make trust a property a machine can check: structured, machine-readable, and attached to the service itself.

06Regulation Now Demands the Same Thing Agents Do: Proof

Engineering managers in Europe do not get to treat this as a philosophical question, because regulators arrived at the same conclusion from the other direction. A cluster of EU rules now requires organizations to demonstrate, continuously and on paper, exactly the vendor-chain visibility that informal trust never provided:

• DORA (the Digital Operational Resilience Act) has applied since 17 January 2025 and covers over 22,000 financial entities in the EU plus their ICT third-party providers. It makes ICT third-party risk management a supervised, board-level obligation, including registers of information on every ICT provider supporting critical functions.
• NIS2 extends cybersecurity and supply-chain security obligations across 18 critical sectors, explicitly requiring covered entities to address risks in their supplier relationships, with personal liability provisions for senior management.
• The EU AI Act, in force since 1 August 2024 with obligations phasing in through 2026 and 2027, places documentation, transparency, and risk-management duties on AI systems, which in practice means knowing and being able to evidence what every component and service in an AI-driven workflow does with data.
• The Data Act, applicable since 12 September 2025, adds rules on data access, switching between data-processing services, and safeguards against unlawful third-country access to non-personal data, which makes "where does this service actually run and store data" a legal question, not a curiosity.

The pattern across all four is the same: proving your vendor chain, continuously, instead of trusting it once at onboarding. A SaaS company selling into a bank, a hospital, or a government body now inherits these requirements from its customers, whether or not it is directly regulated itself. Every unverifiable service in the stack becomes a blocker in procurement and an open item in an audit.

For an engineering manager, this reframes the SOA question entirely. The old objection to consuming services was "we can't verify them, so we build instead." But regulators are no longer only asking about external services. They are asking about everything in production, including the code you built and the packages you bundled. Owning more code no longer avoids the scrutiny; it just means you carry the burden of proof alone.

07What Trustworthy Service Consumption Actually Requires

If trust was the missing layer of SOA, it helps to be precise about what that layer must contain. A service is trustworthy for production use when its non-functional properties are stated in a form that both a human reviewer and an agent can check:

1. Data residency. Where, geographically and jurisdictionally, is the payload processed and stored? "The cloud" is not an answer under the Data Act or DORA.
2. Retention period. How long is submitted data kept? Is it persisted at all, and is deletion verifiable?
3. Sub-processors. Which third parties sit behind the service, and do their properties match the ones advertised at the front door?
4. Standards alignment. Which frameworks does the service's handling of data align with: GDPR, SOC 2, ISO 27001?
5. Machine readability. All of the above must exist as structured data attached to the service, not as a PDF in a sales folder. A certificate a machine cannot parse is a certificate an agent cannot use.
6. Validity and currency. A trust claim has a timestamp. A certification from two years ago describes a service that may no longer exist in that form.

In a machine-readable form, a service's certification looks something like this (illustrative example, simplified for readability):

{
  "service": "pdf-generation",
  "certificate": {
    "data_residency": "EU",
    "retention": {
      "payload_stored": false,
      "retention_period_days": 0
    },
    "sub_processors": [],
    "standards_alignment": ["GDPR", "SOC 2", "ISO 27001"],
    "issued_at": "2026-05-14",
    "valid_until": "2027-05-14"
  }
}

The difference this makes shows up in the consumption path itself. Instead of trust being a one-time human judgment before integration, it becomes a check at the moment of use:

This is the layer SOA always needed and never had. With it, the original promise becomes practical: consume capabilities freely, because verifying them is no longer a three-month procurement exercise. It is a property of the platform.

08Where ApyHub Fits

ApyHub is built as exactly this layer: the trusted API layer for external services, where APIs are curated and certified before they are available for consumption.

The catalog covers 200+ APIs and 1,000+ endpoints across the utility capabilities most products need and few products differentiate on: document generation and conversion, data validation and enrichment, extraction, OCR, and more. Every API in the catalog ships with machine-readable certification describing its non-functional properties, including data residency, retention, sub-processors, and alignment with GDPR, SOC 2, and ISO 27001, so the evaluation that used to require a vendor questionnaire is readable before the first call is made.

Consumption is unified rather than fragmented: one subscription covers the whole catalog, priced in atoms, a unit that scales with what a call actually does, so a 200-byte validation and a heavy document conversion are billed honestly rather than identically. One bill and one operational model replace a per-vendor sprawl of dashboards, contracts, and renewal cycles.

And because the catalog is MCP-native, agents work with the same structured environment humans do. An agent can discover APIs, read what each one does and how it handles data, and consume it within defined boundaries. The trust signals that satisfy a compliance reviewer are the same signals an agent checks before it acts.

The platform serves 65,000+ developer workspaces monthly, and the free tier requires no card, so evaluating whether the model fits takes an afternoon rather than a quarter.

Explore the catalog →

09A Practical Path for a Hesitant Engineering Manager

Adopting SOA in 2026 does not mean a big-bang re-architecture. A realistic sequence:

1. Inventory the utility layer. List the capabilities in your codebase that do not differentiate your product: conversions, validations, file processing, enrichment. This is your maintenance tax surface.
2. Price the ownership. For each capability, estimate the yearly cost of keeping it alive: patching, upgrades, on-call incidents, compliance answers. The 15–30% annual figure is a reasonable starting assumption to sanity-check against your own numbers.
3. Set your non-functional requirements once. Write down what any external service must satisfy: residency, retention, standards. This is the checklist from the previous section, adapted to your compliance reality.
4. Consume where the certificate matches. Replace owned utilities with certified services where the machine-readable properties meet your requirements. Keep building only what genuinely differentiates you.
5. Extend the same rule to agents. If agents in your workflows call external services, restrict them to services whose properties are verifiable. An agent should never be one prompt away from an unvetted endpoint.

10Conclusion

SOA was never wrong. Composing software from best-in-class services was always the most efficient way to build; it was just not the safest, because trust in external services was informal, static, and unverifiable. So the industry spent two decades paying the maintenance tax instead. That option is now closing. AI agents generate more software than any team can own, agents consuming services need machine-checkable facts rather than brand feelings, and EU regulation demands continuous proof of the vendor chain. The missing layer of SOA, verifiable trust attached to every service, is what finally makes the original promise usable. That is the layer ApyHub is built to provide.

Try ApyHub →

11FAQ

What is service-oriented architecture (SOA)? SOA is an architectural approach where software is composed of independent services consumed over network interfaces, rather than built as one owned codebase. Each capability is delivered by the party best positioned to run it.

Why did SOA never fully succeed? The blocker was trust, not technology. There was no reliable, verifiable way to know what an external service did with data, where it ran, or what it retained, so teams limited service consumption to a few heavily vetted vendors and built the rest themselves.

What is the software maintenance tax? It is the ongoing cost of keeping software alive after it is built: patches, dependency updates, security work, compliance reviews, and incident response. Industry estimates commonly place it at 15–30% of the original build cost per year, for as long as the system runs.

Why do AI agents make SOA adoption more urgent? Agents multiply the volume of software entering production far beyond what teams can maintain themselves, which makes consuming services the only scalable option. At the same time, agents cannot evaluate vendors informally the way humans do, so the services they consume must carry machine-readable trust properties.

What is a machine-readable API certificate? It is structured data attached to an API that states its non-functional properties: data residency, retention period, sub-processors, and alignment with standards such as GDPR, SOC 2, and ISO 27001. Both humans and agents can check it before calling the service.

Which EU regulations affect how teams consume APIs? DORA (financial sector ICT and third-party risk, applicable since January 2025), NIS2 (cybersecurity and supply-chain obligations across 18 critical sectors), the EU AI Act (in force since August 2024, phasing in through 2027), and the Data Act (data access, switching, and third-country safeguards, applicable since September 2025). All four push toward continuous, evidenced vendor-chain visibility.

Is consuming external APIs riskier than building in-house? Every option carries risk. Built code carries a permanent maintenance burden; bundled packages carry supply-chain risk, as the 2025 Shai-Hulud npm attacks showed; external services historically carried unverifiable trust. Certified services with machine-readable properties shift the operational burden to the provider while keeping the trust decision checkable by the consumer.

How does ApyHub make external APIs trustworthy? Every API on ApyHub is curated and certified before it is available. Its certification states data handling, residency, retention, and standards alignment in machine-readable form, and the MCP-native catalog exposes the same trust signals to AI agents that human reviewers use.

12About ApyHub

ApyHub is a curated API catalog and trusted operational layer where developers, teams, and AI agents discover and consume production-ready APIs. The catalog spans 200+ APIs and 1,000+ endpoints, available under a single subscription priced in atoms. Every API ships with machine-readable certification covering data handling and alignment with GDPR, SOC 2, and ISO 27001, and every endpoint is MCP-ready by default. ApyHub is headquartered in Amsterdam, with offices in the Netherlands, Greece, and India, and serves 65,000+ developer workspaces every month. The free tier requires no card.

API builders can publish and monetize their own services as ApyHub providers.