SOA, boundaries and segregation

If there is one principle that architects agree on, is that silos should be avoided. Instead of building systems from the top down, shared services should be reused. Each project should identify reusable capabilities and contribute to build a service-oriented architecture (SOA).

Some classical examples of SOA capabilities are identity and access management, master data management, business intelligence, messaging, data integration, orchestration, complex event management. Many applications can then be built or extended just by reusing these capabilities.

On the other hand, systems have a life of their own. A system owner typically wants to have maximum flexibility which means as least dependencies as possible. A silo is much more appealing both to a project manager and a system owner because they know that they will control the development process and the final product respectively.

Then there's the security viewpoint. Sharing can of course lead to the propagation of vulnerabilities. A vulnerability in one shared service may of course have an impact on each one of its consumers. But sometimes also a vulnerability in one of the consumers can lead to the shared service being compromised and consequently all the other consumers and possibly other services as well. There are many ways of mitigating risks but the only way to avoid them is by segregating systems, which leads to more fragmentation - sometimes even more than the system owner wants.

All of these views are perfectly valid. Highly critical systems may in fact need to be isolated because the cost of doing so is less than the risk of data leakage, manipulation or unavailability. But that is rare. Shared services need to support the highest requirements of each consumer so over time they tend to be much more available and secure than any individual system can afford to be. Moreover, it is usually not a whole system that has such high requirements for specific qualities that it cannot be provided by shared services. At most it's a small subset of its data that is highly sensitive - e.g. credit card information, plans for new products, medical records.

So how are boundaries defined in an SOA? Let's say an application uses these services: an enterprise service bus, a reporting engine, a document management system, a database cluster, an application server, the virtualised infrastructure and the disaster recovery standby site. For all of these services operational level agreements (OLA) are defined that guarantee the final service level agreement (SLA) with the customer. 

As for security, the risk profile of a shared service must be communicated transparently not only to the stakeholders of that and other impacted services, but also to its consumers before they agree to use it. For example if a known vulnerability exists in the document management system, then the medical department may not want to store personal records there until the risk is mitigated.

The conclusion is that silos can be broken if and only if the governance framework allows it. Otherwise they just can't. That is why an architect should not support, unless in exceptional circumstances, any kind of low-level "reuse" such as federated databases, database links or direct connections to the Internet. For example if one system's database is hard-linked to another (e.g. because a sales manager decided to add more information to its CRM system), it is impossible to guarantee performance, availability, security or in fact any kind of service level. Just one simple query issued at one system may break the other; one field allowing an SQL injection attack on one system may lead to data leakage from another one; maintenance windows of both system must be synchronised because unavailability of one breaks the other; and so on.

In summary, silos should not be built if reuse is possible, but reuse is not possible without service contracts. In other words SOA is the only way of reducing costs by consolidating systems.