近50年来，计算机领域的技术进步，都基本符合英特尔公司创始人戈顿•摩尔提出的摩尔定律——计算能力每周提升1%，也即用一个美元所能买到的电脑性能，每隔18个月翻两番。这样的进步速度无疑是惊人的。这样的计算机性能发展速度，也保证了各种企业应用技术的提升和完善。不过摩尔定律的副作用也是明显的——摩尔定律对IT环境的管理提出了极高的要求，想赶上摩尔定律的技术更新浪潮，对任何IT管理者而言都是非常困难的。
Pricewaterhouse Coopers的合伙人Bob Zukis这样表示“企业IT 价值持续增长的副产品，就是IT环境已经变得空前复杂。如果一个企业没有办法管理复杂的IT环境，那么这个企业将损失一些其IT开销应得到的回报。而管理复杂的IT环境的能力越差， IT投资回报率方面的损失就越明显。不过一旦企业的IT处理能力跟得上摩尔定律的变化速度，那么整个企业的IT环境就变得非常灵活，可以很好的适应各种应用环境变化。”
Special Olympics 的CIO André Mendes则认为“当你削减了IT环境的复杂程度，你就增加了部署新解决方案的能力。”Accenture的CIO Frank Modruson 也表示“IT环境的日益复杂，导致了过高的成本和管理的难度。如果你能够彻底简化你的IT环境，你的商业应用将更加容易被管理。”
今天，IT环境过分复杂的个问题已经变得非常普遍——IT复杂性的泛滥已经成为一场熊熊燃烧的森林大火，而众CIO则好像消防队员，一起拿着消防水管与大火战斗，越来越多的CIO都陆续加入了灭火的行列。
日益增加的IT复杂性
到底哪些因素导致了IT环境的复杂性不断增加呢？从技术角度来看，Web和客户端技术、移动技术的支持、架构升级，都导致了IT复杂性，还有管理员必须确保分布式IT环境的安全，这也一定程度上导致了IT复杂性。而从商业大环境角度来看，随着全球化的不断演进，每个企业的客户和合作伙伴，对企业信息访问的速度和深度都普遍有着更高的要求。
理论上，CIO可以一个接着一个的处理好上述各个问题，不过现实中，CIO需要同时处理所有的问题，这对于时间和预算都有限的CIO而言，不能不说是一个严峻的挑战。Accenture的CIO Modruson 表示“你不能没有头绪的处理一个接着一个的零散问题，这样做将占用你大量的时间。你必须简化整体IT环境。”
Gartner的执行项目副总裁Mark McDonald表示，简化IT环境，只有简单的几个字。但实际上，多数企业IT系统的建立都跨越了很多年。这些年间，许多与企业合作的IT应用/系统提供商在并购浪潮中都已经不复存在。所以，企业想要简化IT系统，需要用到“IT考古学”，因为简化的过程必须去发掘和理解那些古老的沉积已久的架构和应用技术。当CIO迫切想要改变现状和推进简化进程时，通常倍感挫折，因为IT考古挖掘工作通常进展缓慢。
也许，IT环境简化工作根本不可能有尽头。Wal-Mart 的CIO Rollin Ford表示“我根本看不到复杂的IT环境有什么尽头。各种应用技术一直在改变，各种不同的商业服务需求也不断增长。彻底的简化永远都不可能实现。”鉴于简化任务的独特性和复杂性，任何一个应用或者系统供应商都不可能提出一揽子解决方案，系统复杂的现状也不可能一夜之间改变。不过，CIO还是可以采取一些策略性方法，来尽力避免IT复杂性，而目前为止，他们取得的进展也是可喜的。虽然没有简单的简化公式可用，不过IT经理还是提出了4个原则来简化系统。
一：程序导向架构原则
摩托罗拉的CIO Patty Morrison认为，“一种程序导向的IT架构，对于完成商业目标是非常必要的。每个CIO都非常需要合适的IT架构，这个架构不仅仅是勉强完成任务的基础结构——仅仅为网络、数据流，ERP系统的安全检查点，应用监控的简单组合，这个架构应该是程序导向的。事实上，以前的IT架构通常都没有对于业务程序有足够的适应性。现在CIO的当务之急是改变他们的IT架构，使之以关键的业务程序为导向。”
这并不难理解，我们以飞机来类比。也许从前的飞机设计和制造都比较简单，那时我们多以一种架构的飞机完成各式各样的任务。不过今天，各种各样的需求已经非常丰富了——长途飞行、短途飞行、装载货物或者运载乘客，即便运载乘客的飞机也有高中低档之分。和飞机一样，IT架构在建立的时候如果没有充分考虑到当前的或未来的商业需求，那么IT架构就可能比较局限。而对局限的IT架构的改进以满足设计时没考虑到的需求，一般都需要非常昂贵的费用。
在摩托罗拉，CIO Morrison尽力保证IT架构能够符合商业程序管理原则business process management (BPM) ，并且通过企业级架构来规范这些IT的共同语言。这个企业级架构是一个蓝图，展现了业务、运行和系统层级。摩托罗拉的BPM原则也确保了IT会话不会发展成为架构外的解决方案，这样就避免了日后的架构补丁。
因为通常来讲，IT架构外的解决方案会从两个方面增加IT复杂性。首先，IT执行的业务需求在现有架构能力之外，这导致了多条通路来执行同一件事情，而这些IT进程总是需要用户接口和其他系统连接，这些进程需要大量的调和工作，之间才不会出错。其次，IT复杂性来自IT系统必须翻译那些架构外的要求。这个过程经常出错，比如说落掉一些要求，这就导致了任务容易被数次返工，而且系统上的补丁也使得系统更加复杂。相反的，架构内解决方案则不会遇到那么多问题，Morrison表示“我们应该为解决方案建造一个高效的、交互式的高级别会话，而不是分离的方案。” （待续）
