Three years ago, every enterprise system we built was a monolith. One codebase, one database, one deployment. It worked until the client needed that system to connect to something else. The shift to API-first architecture has changed the way we scope and structure every project.
What You Need to Know
- API-first architecture means designing the interfaces between systems before building the systems themselves
- Enterprise clients increasingly need software that connects to existing tools, third-party services, and future systems that don't exist yet
- The upfront investment in good API design pays for itself the first time a new integration is needed
- This isn't about microservices hype. It's about building systems that can participate in a larger ecosystem
The Monolith Problem
There's nothing wrong with a monolith. We've built plenty of them and they work well for self-contained applications. The problem starts when the client says, "Can we connect this to our payroll system?" or "We need the data from this to feed into our reporting tool."
In a monolithic system, adding an integration means modifying the core application. Every new connection point increases complexity, introduces new failure modes, and makes the system harder to test. Three integrations in and you're spending more time managing connections than building features.
16,590
public APIs listed on ProgrammableWeb by end of 2016, up from under 2,000 in 2010
Source: ProgrammableWeb API Directory, 2016
The number of services that expect to connect via APIs has grown enormously. Payment processors, government services, CRMs, accounting tools, communication platforms. The question isn't whether your enterprise system will need to talk to other systems. It's how many, and when.
What API-First Actually Means
API-first doesn't mean building an API and hoping someone uses it. It means designing the interface contracts before writing the implementation. What data goes in. What data comes out. What happens when something fails.
This sounds like extra work, and it is. But it changes the economics of integration.
When we built monolithic systems, every new integration was a custom project. We'd examine both systems, figure out how to make them talk, write custom code on both sides, and test the connection. Expensive and fragile.
With an API-first approach, the system already speaks a standard language. Adding a new integration means connecting to a well-documented interface, not reverse-engineering the internals. The second integration costs a fraction of the first. The third is almost routine.
The MuleSoft Reality Check
$3.5T
estimated lost productivity from system disconnection across US enterprises
Source: MuleSoft Connectivity Benchmark Report, 2016
MuleSoft's 2016 connectivity report put some numbers to what we'd been seeing on every project. Organisations run dozens of systems that don't talk to each other. People fill the gaps manually, re-keying data from one system into another, exporting reports from one tool and importing them into the next. The productivity cost is staggering, even in small organisations.
For our enterprise clients in New Zealand, the pattern is the same at a smaller scale. A grant management system that doesn't connect to the finance system. A project tracker that can't pull data from the HR platform. A customer portal that requires staff to manually update records in two places.
Every one of those gaps is a place where errors happen, time is wasted, and data goes stale.
How We're Building Now
Our approach has shifted over the past year. For any enterprise project where the client has existing systems or foreseeable integration needs, we start with the API layer.
Design the contract first. Before writing any implementation code, we define what the API will expose. What resources, what operations, what data formats. This becomes the documentation for anyone who needs to integrate later, including us.
Build the API as a real product. Not an afterthought bolted on for the mobile team. The API is the system. The web interface is one consumer of it. A mobile app would be another. A reporting tool would be a third.
Version from day one. APIs change. New fields get added, old ones get deprecated. Without versioning, every change risks breaking something downstream. We version the API from the first release so we can evolve without fear.
Test the integration points, not just the UI. Automated tests against the API catch integration issues before they become production problems. We can verify that the contract hasn't been broken without clicking through the interface.
When you design a system to participate in an ecosystem rather than stand alone, it gets more useful over time instead of less. That is the difference between architecture that compounds and architecture that decays.
John Li
Chief Technology Officer
What This Means for Enterprise Clients
If you're commissioning an enterprise system in 2017, ask your development team about their API strategy. Not because you need integrations today, but because you will.
The government is moving toward API-enabled services. Accounting platforms like Xero are API-first. Communication tools like Slack expose everything via API. Your system either participates in that ecosystem or it stands alone, requiring manual effort to bridge every gap.
The cost of building API-first is marginally higher upfront. The cost of retrofitting API access onto a monolith is significantly higher. We've done both, and we know which conversation we'd rather have with a client.
The monolith isn't dead. But the isolated monolith, the system that only talks to itself, is increasingly hard to justify for enterprise work.