Tuesday, October 6, 2009

Tiered Infrastructure Architecture

Thanks to the recession, CIOs are busy but not to support the growing demands of business, but instead identifying how and where to save costs and bring sustained value. When the going is good, it seems to pay better to throw more hardware, software and labor at any business requirement because business is growing and someone will pay for it. Studying delta savings and incremental benefits are more of overheads, where the cost of managing them seems to outweigh the benefits accrued. Not any more in these times!

One of the things I have consistently observed is the lack of a consistent approach to a tiered infrastructure architecture. IT infrastructure is mostly set up as chunks of monolithic or patchy systems with no stratification or gradation of the infrastructure or the service quality provided on top of it. While many banking and other enterprises do have "A Class" infrastructure or service for "A Class" business applications, the rest of the applications and their underlying infrastructure is most often a mix of systems acquired over time. It is often not possible to say that we have three kinds of storage infrastructure --- A, B and C which caters to different kinds of storage requirements in terms of these metrics 1. ..... 2. .... and .. 10. ...

An efficient environment should have an enterprise divide its IT infrastructure into two or three grades. Each component (hardware, software, labor) should fall into one of these buckets. It may not be possible to have an air tight environment with no overlap but having at least 80% discipline from the current 10% (or none) will result in cost efficiencies and better manageability. It will also ensure IT is more responsive and participative in growth --- next time a project estimate is made for (say..) setting up a new back office, the project cost would be more reflective of how critical that operation is to business. IT team would first ask how critical that environment is, operational requirements, redundancy requirements etc. for all aspects of IT environment to plan for an optimal set-up instead of an one-quality-fits-all approach where that "one quality" is often an expensive service requirement.

No comments: