Islands of automation

By Andrew Clifford

We use the phrase "islands of automation" to describe systems that are not connected. We all know that islands of automation are a bad thing. Or are they?

I first came across the phrase years ago when people were selling me data warehouses. Our existing systems were islands of automation, we had no coherent view across them, and we needed a new database to bring them together (or so the salesman said). I have heard it used to promote component-based design, that does away with old-fashioned silo thinking. I am sure I have used it to argue for the purchase of middleware. Everybody knows that islands of automation are a bad thing, and anything that overcomes them must be good.

But I think we might have got this wrong. Perhaps islands of automation are exactly what we need.

There are many things about islands that make them a good analogy for effective systems design.

• Identity and clear boundaries. Islands have names. There is no doubt where islands start and end. Islands are clearly separated.
• Clear role. Small islands have well-defined economies - fishing, tourism, possibly farming. It is easy to understand the purpose of the island.
• Clearly defined communication. Movements in and out of the island are very controlled -- air services, sea services, and so on. You can not just wander into an island and borrow stuff without asking.
• Self-sufficiency. Island communities have to cope with periods of being cut off from the mainland. They have to provide for all their basic needs.
• Clear security. It is hard to get to the island except through the defined communication links. On a small island, there is a clear distinction between trusted permanent inhabitants and "outsiders" such as holiday makers. Roles are simple and clear, and intruders are easy to spot.

There is one obvious drawback to islands. They can be isolated, with insufficient communication to the rest of the world. In our system-as-island analogy, we need to tackle this weakness by building a rich set of communications to and from the islands. We need "well-connected islands of automation".

Some of the alternatives to islands of automation have many more drawbacks.

• Shipwreck of automation. To avoid isolation, you can break down system structure, and release functionality into a sea of reusable components. This become unmanageable, with business capabilities scattered unowned all over the place.
• Gridlock of automation. Another approach to avoid isolation is to draw up a grand central plan, showing all the parts and their proper interconnections. But we are not that clever. Our plans do not survive the onslaught of unexpected business change, such as mergers and acquisitions. Our attempts to centralise build high dependencies between systems. We end up in design gridlock, as multiple systems need to be changed to achieve even the simplest of business changes.

We need well-defined, purposeful, self-sufficient systems, with rich and clear connections to others. Given the alternatives, well-connected islands of automation are a good analogy for how we should approach systems design.

Subscription