分类: 服务器与存储
2008-07-13 17:01:17
针对每项需求的功能描述及注解;
以某一个时间段为限,各项需求的优先级别;
加一栏备注,参照本企业的需求,对所有存储厂商提供的解决方案逐一进行评估,将结论填写在备注栏内。
如果有充足的时间、资金或人力资源的话,不妨在自己的操作平台上安装每一家厂商提供的SRM解决方案,进行实验。很多公司都是单纯地参考存储厂商针对企业的信息征询(RFI - Request for Information)所提供的信息,就做出了购买决定,这并不好。
除此之外,你也可以考虑将SRM解决方案整合到操作平台现有堆栈的链式存储结构内,比如基于应用程序、逻辑卷管理、文件系统、主机信息或存储设备支持的堆栈,等等。记住,眼光要放长远一点,不仅要考虑到企业目前的需求,新的解决方案还应该能够适应公司在未来一段时间内的业务发展需要,与企业的操作规章及技术生态环境不会发生抵触。
回首上世纪80年代末90年代初波及全球的平台与架构大战,无论是哪种系统架构,都捆绑了极其丰富的功能,但是,即使是大型企业用户,也未曾考虑过列举详细的需求书,并根据它们来选择架构。结果呢,他们不知道应该挑选哪种系统架构,也不知道如何将它们应用于本企业的商业运作当中。大多数的IT管理人员都存在一个误解:以为架构是什么灵丹妙药,可以包治百病,替他们解决掉日常工作中遇到的一切头痛难题。但是,事实却是,引入架构机制之后,仅仅是把事情搞得更复杂更难以理解,即使是实施最简单的管理解决方案,比如说安装一个简单的事件控制台(event console)软件,都需要与架构供应商们反复磋商才行。后来,架构供应商也终于意识到用户的诸多不便,将捆绑了庞大软件工具的解决方案进行了肢解分类,作为单点产品(point prodUCt)推出。现在的SRM产品就跟当年的架构机制有几分相似,一样是包罗万象,一样是功能齐全得不得了,而且,未来的SRM或许也会走上跟它一样的发展路线,存储管理解决方案中捆绑的各类软件工具将被逐一拆分出来,单独出售,以适应部分企业的特殊需求。