供应商陷阱
如果某个合适的解决方案不能通过商业化方式取得，我们就会寻求外部开发者的参与，但是这种方式却问题多多。从正面来看，外部开发者帮助我们避免了增加内部员工的开发工作量；但另一方面，我们则会冒着越来越依赖外部开发者的风险。
对于中小组织而言，找到合适的一流和二流水平的供应商是一个挑战，而且我们当中的任何一位CIO都在被迫使用三流供应商，确切地说应该是相比那些大型同行规模更小且大多管理不佳的供应商。
我可以用一个我原创的电影式场景来说明这种情况：我们把一份合同给了一个报价更低的竞标者，这是一家只配备了几名关键程序员的小型公司，我称它为A供应商。A供应商容易和你打成一片，并且在应用说明书里声称自己的产品整合了“轻松拥有”的特性，通过这种办法他们赢得了我们这样的用户。当我们需要新的应用时，我们在原来的订价和已经建立的良好关系基础上继续使用A供应商的方案。的确，我们感觉它现在就是我们的一部分。
随着我们规模日趋壮大，到了升级部分平台的时候，A供应商的开发力量却面临一系列的挑战——不管是从员工个人水平，还是从专业高度上都是如此。他们变得心烦意乱、不够可靠，并且有时候你根本找不到他们。他们已经难以赶上我们工作的进度，并且不能满足我们的新需求，但是他们却是唯一理解其应用程序如何工作的人。这个时候，我发现我们在依赖某个供应商的同时，没有为自己留有任何回旋余地和“板凳深度”。
如果你发现你正在沿着这条道路行进，那么请你马上停止现在一切正在做的事情，开始着手找到扩充内部开发力量的方法，并且寻求关键应用的第三方服务支持。
自我救赎的过程可能会花费你很长时间，甚至可能需要几年，但是不管多么耗费时间，你都应该勤勉地打造容纳多家供应商的供应商集群。
作为CIO，我的工作关键在于说服组织，让组织明白在健康的程度内，保持对任何单个供应商的不依赖是多么重要。我们不允许自己为无法预料的灾难或不正常的业务关系做无谓牺牲。此外，我们已经吸取教训——在为每个开发项目设置里程碑的时候，阶段性代码审查必须同时完成，以确保我们将来需要自己进行服务支持时，能够保证应用程序的代码质量和开发文档的清晰性。
