The Archipelago
A metaphor for how to talk about IT in business systems
Modern IT infrastructure has gotten really complicated, honestly, it’s so complicated that most executive teams don’t really understand exactly what’s going on under the hood – and most IT teams don’t exactly know how their work supports business outcomes. My solution? Introduce a metaphor and belabor it to the point where it risks becoming a burden. Hope this helps!
From a technology perspective, your service business is essentially a series of islands, like an archipelago out in the ocean somewhere. The islands are the functions that keep it running, accounting, project management, client relationships, design, human resources, operations. These islands have existed for as long as businesses have. They have their own traditions, cultures, artifacts; and hopefully they are operating under some unified government that is trying to reach some sort of a shared objective. If not, that’s a different problem and I don’t know the answer.
In order to deliver work for your clients, stuff has to get gathered from the islands and packaged together into some sort of finished good that gets delivered to your clients by your teams. Some stops are for refueling, some are for communication to and from the outside world, and some are just providing raw materials for final assembly; but your business is essentially an endless navigation between the various islands. It’s really easy to focus on the islands, especially when you live on one – but the interesting stuff, the stuff that is truly unique to your business is what happens as you travel.
Raw Land
Before software, the islands were undeveloped.
Each island held information in raw form. The only way to use that information somewhere else was to send a person by boat to get it.
That person (the professional, the analyst, the coordinator, the associate) would visit one island, gather what they needed, carry it to the next, interpret what they found, and eventually produce something useful. A memo. A report. A recommendation. A set of documents.
The route between islands was the business process. Some routes were routine, repeated daily. Others were improvised when a new problem required pulling information from places nobody expected. Often the boats took different routes depending on the weather or whether or how much time they had for travelling.
The people responsible for the deliverable were building it by hand, on the boat, while they navigated.
Eventually they made their way to the client and they delivered the goods. Quality depended on the interactions at each island along the way, and on how good the craftsmen were on the boat.
Cities
Software built cities on the islands.
An ERP did not invent accounting, just like cities didn’t invent people. It built infrastructure on top of it; enforcing double-entry bookkeeping, organizing transactions, producing structured records that could be audited and queried. The raw land became civil society.
A CRM built a city on the client relationship island. A project management platform built one on scheduling. You get the drift.
Each city did the same thing: it took information that had existed as raw notes and documents and turned it into structured data, validated records, governed workflows. The island’s output became more reliable, more consistent, more useful to anyone who arrived looking for it.
What cities didn’t change is the travel between the islands. The employee visiting three cities, gathering outputs, combining them into a product; all of that work still required a person in a boat. The cities refined what each island produced. They did nothing for the person navigating across them.
Ocean travel still took forever. These were the days of adventure travel by sail and trade routes that built economies.
I guess there’s a factory on the boat in this metaphor
Software also changed the boat itself.
Word processors replaced typewriters. Spreadsheets replaced ruled paper. Drafting software replaced T-squares. The hand tools a professional carried on the boat became machines. The craft bench became a small factory floor.
The person still chose the route. Still decided which islands to visit, what information mattered, how to combine it. But the production steps became faster because machines handled the mechanical work.
This is what most file-based applications are. They don’t manage work across the organization. They help one person produce or edit one deliverable once they’ve gathered the inputs. They are machines on the boat.
Bridges
When certain routes became common enough and predictable enough, organizations built bridges.
A bridge replaced repeated boat travel with fixed infrastructure. Travel by bridge is just a heck of a lot more predictable and trains can pull a lot more cargo than boats. Also, something about how it’s probably easier to run a factory on a train; but the metaphor is starting to crack under the weight of all this.
Integrations, APIs, data warehouses, automated workflows — all bridges. Each one encodes a route that used to require a boat.
But building a bridge requires understanding the route first. Someone has to run it enough times by boat to know where the stops should be, what gets picked up at each island, what the output should look like. Only then does it make sense to invest in a bridge.
Not every route gets a bridge. Only the high-volume, predictable ones justify the investment. The rest stay on the water, run by people who know the way. These are the boats led by the storied old sea captains, they know the ocean by name and they’ll get your cargo where it needs to go. Also, interestingly enough, this is where the pirates running cigarettes in speedboats to avoid taxes tend to operate. These are your shadow systems like the spreadsheet nobody sanctioned, the workaround nobody approved; all running outside the official routes because the official routes don’t work. Heads up there.
New Islands
Some organizations go further. They build entirely new islands.
Each city is good at its own island’s work. But the deliverables that clients actually pay for usually require combining outputs from several cities. That assembly happens during travel between cities. A new island moves that assembly onto land.
Instead of a person visiting five cities on every project, transport lines bring the materials from each city to a specialized island where factories combine them according to the firm’s own logic. The assembly that used to consume hours on every trip becomes a stop on the route.
This is where the most durable advantage in a service business tends to live. A new island encodes your logic — the specific way your firm combines information from multiple domains, the methodology that makes your work yours. The value isn’t just the connections to existing cities. It’s the assembly logic inside the factories.
Building new islands requires people who understand both the domain and how to construct the systems. That combination is rare, which is why most firms haven’t built any. But when one does, the work that used to be the most expensive and time-consuming part of every engagement becomes a pickup at a single stop.
This is what custom software does. It goes beyond working within the constraints of a given city and starts to think about what could be built if you started a new city with new rules that were specifically set up for your business processes.
Where You Probably Are
Most businesses have cities on their major islands. You probably have an ERP, a CRM, a project management platform, maybe some design or document management software. These are real and they work. They are not the problem.
You have bridges, maybe a lot of them. They are also not the problem.
You probably have no new islands. Almost no one does. The assembly work that defines your deliverables still happens over the water.
And the vast majority of your professional staff spend the vast majority of their time travelling between islands.
Your cities likely got built because software vendors had a business model for building them. Someone showed up one day and asked if you’d like a city and you agreed. Salesforce wanted to sell you a CRM. Oracle wanted to sell you an ERP. Each vendor picked an island and built a city on it.
Nobody had a business model for navigating the water. The work between your platforms was always left to your people and their boats. Not because it was less important. Because it was less sellable as a product.
That is where your business actually lives, and it’s the part that has had the least infrastructure investment for the longest time.
What AI Changes
AI does three really useful things in the archipelago right now.
First, it upgrades the cities. Every platform vendor is adding AI capabilities within their product. Your CRM drafts emails. Your accounting system flags anomalies. These improvements are real, but they’re confined to individual islands. Every competitor using the same platform gets the same upgrades. The cities get better; the water stays the water.
Second, it upgrades the machines in your factories. Whether the factories are on a boat, a train, or an island, the production step becomes dramatically faster. A professional who used to spend an hour assembling a deliverable from three sources can describe what they want and evaluate whether the result is right.
Third, it makes new routes visible. When the factory is fast enough, professionals spend less time on production and more time navigating. Patterns emerge. You start to see which routes your people run repeatedly, which assembly work follows the same logic every time, which cross-domain combinations keep recurring. Those patterns are the signal for where to build next (like a bridge, or maybe a new island.)
What AI doesn’t change
Also, what AI is doing right now is distracting from the useful work I just outlined above. There are a fair number of citizens in your country are talking about autonomous helicopters and robot longshoremen at every port. There is a lot of pressure to give AI broad access to your systems; to let it move across your platforms at top speed.
This is just not a good starting place. Just because a helicopter can travel across water quickly and without a bridge or a pilot doesn’t mean it knows where to go. This approach assumes that you have clear direction and that the travel time was your problem. The reality is that your sea captains are still running the show for most of the business and they didn’t really write down what they were doing.
Your people have been running these routes for years. They know where the stops are. They know which assembly steps follow the same logic every time and which ones require judgment every time. That knowledge is the blueprint for everything you build next. Skipping over it to get to autonomous helicopters is skipping over the part that makes the helicopters worth building.
The Map
That’s the archipelago.
The point is not to prescribe what to do next. The point is that your business is a system for shipping product, and most conversations about AI skip straight to the technology without understanding the system it’s being applied to. Upgrading the factories doesn’t help if you don’t know which routes matter. Building out amazing cities doesn’t make it easier to ship product if they all speak different languages and think the other cities are run by pirates. Building bridges is a waste of time if the boats didn’t go there in the first place. And buying helicopters definitely doesn’t help if you don’t have any idea where to land them.
Before you invest in any of it, understand the geography. Know which islands you have, what your cities do, where your people are travelling and then have an informed conversation as a leadership team about how to selectively apply technology to the highest leverage points in your company. Otherwise, you end up advocating for something that is the functional equivalent of building cool robot trains that you drive straight into the ocean.