In the last post I looked at consolidation, the different types and what you would expect to get from each type. In that post, the scenarios were all positive. It was a good thing to take different IT components and combine them together. It simplified the landscape, reduced complexity and costs.
Is simplification always the same as consolidation? Can consolidation result in the opposite of simplification? Can it result in complexity? I think it can - by over-consolidating. Over-consolidation is when we try to make two things the same that are fundamentally not and we get a conflict. Some examples of this are:
- Consolidating different systems onto the same hardware platform that have different service levels
- Bringing two business processes onto a single application that are fundamentally different and where the application cannot accommodate the differences easily.
A recent example with a customer I saw was around data warehouse with a low service level. It was non-critical to the business and the infrastructure was designed with this principle in mind to conserve costs. An addition was proposed of a critical operational function to it (it used the same technology). The warehouse did not have the redundancy, the support models (or even the technology) to support such an addition. There are two solutions here, increase the service level of the warehouse to meet the new requirement or isolate the new requirement on its own infrastructure with a higher service level. My advice, given the cost of the former, was to establish a "gold" tiered platform. The current environment would become the "silver" tiered platform. Different service levels with different needs. Could there be a case in the future to consolidate these? Perhaps - but I think it would need lots of "gold" use cases to justify that.
Isolation then becomes an important tool for architects to use to enable simplification. Sometimes simplification means the opposite of consolidation - to separate or abstract. Creating well defined interfaces between different components in an architecture provides clean breaks and abstraction that simplifies an architecture. We do this all the time in IT, think of TCP/IP, Multi-tiered architectures or even Enterprise Architecture itself with its multiple layers. When we translate this to an Enterprise Architecture we don't need to combine everything into a single application or single server. Most often we don't want to do this.
Another manifestation of this concept is Gartner’s Pace-Layered Application Strategy (http://www.gartner.com/it-glossary/pace-layered-application-strategy) or Bimodal IT (http://www.gartner.com/it-glossary/bimodal). These concepts deal with separation of concerns in an organisation’s application strategy based on the speed of change required. I might explore these in a bit more detail in a later blog post, for now I am just going to use these as examples. Both of the options seems to go against the notion of consolidation being about simplicity. These models are designed to provide an overall benefit to organisation, to allow it to deal with different kinds of systems (systems of record, legacy etc) and still be able to get things done in a timely fashion.
All this leads me to think that consolidation is like a pendulum with simplicity in the middle and complexity at both ends - swing it two far either way and it can lead to the opposite affect of what was intended. IT needs to find the "golden mean" between the two to decide what meets the requirements most acutely.
