So what exactly is everybody’s problem with Silo’s? Not a particularly warm-received phenomenon among IT specialists and consultants. Any junior writer of IT marketing material knows it: first you launch some platitudes about globalization, increasing competition and changes that occur faster and faster. And right after that, it is time to deal with silo’s. Silo’s are evil. Our legacy systems resemble them. Isolated and compartmentalised, they lead an utterly useless existence. Luckily, now we have the principles of object orientation and service oriented architecture to battle these immovable pillars. We recreate them into a collection of loosely coupled objects (or components, or services, whatever we want to call them) and thus gain in flexibility, maintainability and overall coolness.
Sounds feasible, doesn’t it? And indeed, many an IT strategy contains – often risky and complex – plans to get rid of silo’s. In the meantime, more and more the question is raised whether silo systems are really that bad.
Obviously, the silo is just a metaphor. But let us elaborate a bit more on the very nature of this useful construction. A silo is especially build to store non-perishable materials for a longer period of time. Think grain, coal, fertiliser, sand and cement. If we take a look at most IT systems, we also see many elements that have a low turnover rate. These are elements that contain information and business rules that stay relatively stable throughout the years. Only very few changes will occur. Furthermore, although these elements are at the very core of business, they typically do not deliver much differentiating value.
Ideal material to store in silo’s, neatly protected from interferences from the outside world. Many implementers of ERP packages – like SAP – have learned this the hard way, already years ago: you just leave the big, basic modules undisturbed as much as possible. Every five year or so a major update of functionality and technology platform, nothing more fancy than that. SOA is then used as a tool to literally create hatches into the modules. And through these hatches, a more modern generation of applications can be build, for example with technologies for business intelligence, flexible business rules, process management, collaboration, role-based portals, and mashups. These are technologies that allow the construction of small, more focused solutions with a shorter lifespan. The solutions are highly flexible, so that they can easily adapt to the more quirky part of business. And if you don’t need them anymore, you simply throw them away.
So maybe, just maybe, silo’s are not as discreditable as we tend to think. What is meant to be in silo’s should stay there, safe and dry. It will relieve us of the daunting task to fully rework our core systems. It will make our architectures simpler and more manageable. For the rest, all we need are a few hatches.