Mature Enough
May 11th, 2007
I have been working with several large clients the past month, and have seen again first hand the importance of making storage architecture changes that are consistent with where one is. I know that sounds like bad english…. and it probably is. IT planners and architects want to take advantage of new technologies to improve operations and reduce costs. That is great, always has been, always will be. Just as important as the desire to reduce cost or implement incremental benefits is the proper understanding of what you do well (and don’t do well) today. We often use maturity charts like the one below to help us in that quest for improvements.


There should be no surprise that the maturity progress also links to investment strategies and TCO strategies appropriate to the stage where you currently reside, or one or 2 steps ahead. Quite often we see IT organizations making a quantum leap 3 or 4 steps ahead with advanced concepts aimed at reducing cost, or providing a competitive edge, but what they often get is:
- Missed objectives
- project implementations that take forever to complete, if even completed at all
- Difficult organization and political barriers for radical change
- Processes that are not up to the task of some new technologies
A good example of this might be storage virtualization, thin provisioning, data de-duplication or advanced disk-level encryption. With some of these approaches a solid change control process or chargeback system would be absolutly essential for the implementation of a new technology. Sure the technology exists to deliver this capability, but if the infrastructure foundation of people and processes is not strong enough to support the new initiatives, the projects will fail.
So as new solutions are evaluated, and technologies considered for advanced capability, take a little bit of time to ensure that you are at a level of storage maturity to handle the new function. Otherwise…… “you may not be able to handle the truth…..”

