I once watched a small company's online store stop accepting orders because, on the other side of the planet, a service that determined a visitor's country by IP address changed its response format. The store did not sell abroad. It did not really need the visitor's country at all. But a long time ago a developer had added this check "just in case", and now the checkout page depended on it. None of the company's employees even knew this service existed. They found out when sales stopped. I often recall this story when I talk about the complexity of the modern world.
The butterfly effect is no longer a metaphor
The scientist who came up with the image of a butterfly whose wing flap causes a hurricane on another continent was talking about the weather. But today that image describes almost any technological system. Your accounting software depends on libraries written by thousands of strangers. Your website depends on hosting, on the domain name service, on the payment gateway, on the mailing service, on browsers that update without Your consent. Each of these links, in turn, depends on dozens of others.
And this is not only about technology. Business works the same way. A supplier delayed one part, and an entire workshop stopped. A marketplace changed its rules, and sales fell in three regions. One key employee left, and processes everyone thought ran by themselves stopped working. The world consists of components connected to each other far more tightly than diagrams show.
Why complexity cannot be cancelled
Many managers' first reaction to such stories is: let us simplify everything, remove unnecessary connections, do everything ourselves. It is an understandable wish, but a naive one. Giving up external connections means building a fortress that produces everything on its own, and losing to those who use ready-made services and spend their energy on what matters. Complexity is not a bug that can be fixed. It is the price we pay for capabilities. The more connections a system has, the more it can do, and the more points where something can go wrong.
So the question is not how to get rid of complexity, but how to live with it so that a local failure does not turn into a catastrophe. And here engineers have a lot to learn from nature and history.
Lessons from shipbuilders
Ships have long been built with watertight bulkheads. The hull is divided into compartments, and if a breach floods one of them, the rest keep the vessel afloat. This solution did not come from a love of complexity, but from bitter experience: a ship without bulkheads sinks from a single hole. Exactly this principle underlies resilient software systems.
A good system is not one in which nothing breaks. A good system is one in which the failure of one part does not sink all the others.
In practice this means a few simple rules we apply in our projects:
- module isolation: catalog, orders, warehouse and payments are built so that a failure in one does not stop the others; if the recommendations module goes down, the customer can still place an order;
- protection from external failures: if a third-party service does not respond, the system does not wait for it forever, but after a short time switches to a fallback scenario or shows a clear message;
- optional stays optional: a check You can live without must not block a critical process, as in the story with the country detection;
- observability: the system itself reports where it hurts before clients notice.
See the connections before they snap
The most dangerous thing in complex systems is invisible connections. The ones nobody remembers, which appeared once for some random reason and quietly live on for years. That is why one of the most important parts of an architect's work is not so much inventing new things as making the existing ones visible. Drawing a map: what depends on what, which external services are used, where data flows, which process will break if this particular link disappears.
I regularly suggest a simple exercise to clients: write down every external service and every person without whom their business would stop for even a day. The list almost always turns out longer than expected, and almost always contains a couple of items the director is learning about for the first time. It is unpleasant, but much more pleasant than learning about them at the moment of failure.
What to do with this knowledge
The world will not become simpler. It will only become more complex and more connected, and honestly, I like that: there is a lot of beauty and opportunity in it. But there is only one way to run a company in such a world: accept complexity as a given and build systems that are ready for it. Divide into compartments. Know Your dependencies. Have fallback scenarios for what matters most. And do not connect "just in case" what You can do without.
At Systems we start any architecture with a map of connections, and we build modularity into the foundation instead of bolting it on later. Fractal helps here, because a system is described as a set of models with explicit relations, and invisible dependencies simply have nowhere to hide in it. Butterflies will always flap their wings. Our job is to make sure that does not start a hurricane in Your business.
