When Silos Make Sense

Separation of Concerns in the real world

Separation of Concerns is a well-known concept in application architecture. Over the years, application structures have evolved from monolithic to modular, using techniques such as encapsulation and abstraction to reduce coupling and increase cohesion. The purpose of doing so is quite simple – it yields software systems that are easier to understand, change, and enhance.

Within a monolith, all changes must be made in context of the whole. As that whole increases in size, the ability to understand the effect of a given change decreases and risk increases, even in the absence of complex logic. Complex processes, obviously, compound these effects.

With all this in mind, competent and responsible architects encapsulate, modularize, and partition code. Likewise, databases shared across multiple applications are seen as the anti-pattern that they are. Unfortunately, some seem to forget the principles and benefits of separation of concerns when it comes to infrastructure.

Without a doubt, server consolidation can save on licensing, administration, and hardware costs. However, the concepts of coupling and cohesion apply to the platform as much as the applications it supports. All applications sharing the same hardware environment are subject to a form of coupling. Whether that coupling is logically consistent (cohesive) or not can impact operations and customer satisfaction. It might be uncomfortable explaining why a critical line of business application is unavailable (if only briefly) because of a bad release of the intranet suggestion box.

Maintaining application cohesion on the platform also enhances your ability to keep the platform current. An environment hosting a family of applications maintained by the same team should be more easily maintained than a grab bag that’s home to a wide variety of systems. As with any chore, the more painful it is, the less likely it will be done. Failing to keep the platform up to date is a fast track to legacy status.

Paying attention to the following factors can assist in keeping platforms cohesive, maintainable and healthy:

  • Organizational Concerns: As noted above, systems sharing a homogeneous audience as well as the same (or at close on the org chart) support team will make for better roommates.
  • Technology: Some applications (particularly platform applications such as database software) don’t play as well with others, preferring to control the lion’s share of resources. These are poor candidates to be deployed to the same host/cluster as others applications. Likewise, dependency conflicts will affect hosting decisions. Stability is also an important factor – less stable systems should be isolated.
  • Security: Not hosting applications with different security profiles on the same machine(s) should be self-evident.
  • Criticality: Those responsible for disaster recovery will be much happier if the high-priority systems are not intermingled with the low-priority ones.
  • Resource Utilization: Usage of CPU, memory, storage, and network bandwidth should all be accounted for to avoid overloading the infrastructure. The fact that this utilization isn’t a steady state should also be borne in mind. Trends may edge up or down over time and some applications may have periods of higher than normal use.

While it doesn’t help with licensing and administration costs, virtualization can provide isolation without driving up hardware costs. Where appropriate, cloud offerings may also help with managing licensing, hardware, and (depending on the solution) administration costs. In all cases, savings must be evaluated against risks in order to get the full picture.

Advertisements

8 thoughts on “When Silos Make Sense

    • The short answer would be the architect’s default – “it depends”

      A longer answer would involve matching the criteria above to the context and then explaining the costs and benefits. Some boundary cases that may help illustrate:

      – A small mom and pop organization – unless you have technical or resource-usage issues, don’t bother
      – The NSA – silo everything, then hide the silos 😉

      For enterprises that fall in between, I’d suggest partitioning by organizational units or at least, back-office vs customer facing, even in the absence of other concerns. In my opinion, the different availability needs will probably justify the expense.

      Like

      • Nice article and comments, although I have to inject that partitioning by organizational units as you suggest can be counterproductive to building an “Enterprise” architecture. I realize that you are only referring to IT architecture here, but enterprises become less functional when the technology is built to re-enforce departmental separation . . . communication suffers. The same is true of “back-office” vs. customer facing. In today’s modern online organization many processes (and therefore systems) at least partially face the customer. While it makes some sense to have these system on separate physical environments I think it is best to design systems to integrate and operate easily to provide the maximum benefit for the enterprise.

        Like

      • Scott, the focus of the post was partitioning in terms of choosing hosts for the various architectural components, not inter-app communication (I’d be leery of any design which required apps to be co-located in order to communicate).

        I disagree that an effective enterprise IT architecture should not take organizational structure into account. Autonomous systems focused on business functions (which will likely align with specific business units) with well regulated service interfaces should promote, rather than hinder communication. Likewise, a hosting scheme that promotes robustness should enhance the ability of the enterprise to composes effective systems of systems.

        Like

  1. ” Autonomous systems focused on business functions (which will likely align with specific business units) with well regulated service interfaces should promote, rather than hinder communication.”
    I would agree with Gene’s comment…that is the whole reason behind SOA!

    Like

  2. Pingback: When Silos Make Sense | Iasa Global

  3. Pingback: Storming on Design | Form Follows Function

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s