你的团队成员可能会说他们不喜欢他们现在使用的一些开发工具。他们坚持说使用不同的开发工具他们就能更快的完成项目。但如果他们说的是实话的话，那么是不是你就应该马上跑出去然后购买任何看起来效率更高的新工具呢？

这在被技术驱使前进的人们中是一个非常经典的矛盾。你应该在什么时候使用测试过的硬件，软件，和开发工具，又应该在什么时候转移到更新的，不同的工具上来呢？首先，让我们讨论一些比较极端的案例。

一些软件工厂还在使用过时的开发环境。我在这里指的是一些还在使用多年前的开发工具的企业，它们之所以不进行升级是因为习惯的影响和缺乏长远的眼光。这些企业的业务往往会因为老的技术和技能无法解决新出现的商业问题而受到损害。

另一个极端是没有任何开发传统的软件作坊。在这种情况下，项目团队反过来驱赶技术。当开发团队发现Java适合他们的时候，他们就会去搞Java工具和服务器。如果一个建模工具能够有所帮助，他们就会去把它买下来。许多时候购买工具的决定并不是基于业务的需要而是看这种工具用起来是否比以前的工具要舒服。这些公司总是充满了重覆的技术，而你却又无法找到拥有适当的技能来支持多个项目的人。整个企业在员工的技术，软件版权费用，和员工安排的灵活性方面都是低效率的。

我想我们大家都会同意处在这两个极端中间的某个地方是最好的。你需要有一个正式的（或者即使是非正式的，你也应该有一个）技术架构来提供缺省开发环境的结构，但是你还需要一种途径来基于业务的需要改变你的开发环境。让我们更仔细的来讨论一下。

开发环境的架构

许多开发者都顽固的坚持他们所信奉的东西将成为开发界的圣经。其实大可不必如此。建立一个开发架构只是意味着你理解所有现存的开发技术并知道它们是用来干什么的。例如，你使用什么样的开发语言？如果你使用两种语言，那么你清楚为什么要使用这两种语言么？这是很有意义的。在我工作过的一个公司，我们在主机上使用Cobol，在AS/400上使用PRG　III并在客户／服务器程序上使用PowerBuilder。三个工具，其中的每一个都找到了它们的用武之地－－没有重覆。

但是让我们假设你有三个建模工具。如果其中的两个几乎是做两样的事情的话，你就不那么好作出决定了。一个技术架构能够避免你购买功能与你已经使用的其它工具相似的新软件。

一个技术架构应该足够灵活从而随着时间而改变，但它不应该随着项目团队的意愿而改变。这些改变应该根据业务的需要来进行而且应该首先合理的评估现在的架构看它是否能够满足这些业务需要。 避免开发工具的混乱
现在回到我们开始的问题：一个团队是否应该采取主动去获取完成一个项目所需的工具呢？一个简短的回答是不。基于一个个单一的项目而作出的技术上的决定将使整个企业开发工具泛滥并产生混乱。你应该问的问题是你的团队现在有哪些工具？然后想想这些工具能够用来满足的项目的业务需求。它们可能不完美，但是它们能够满足至少百分之八十的需要么（这是一个古老的80/20定律）？如果它们能够，那么你应该继续使用当前的技术。

如果你认为这些工具无法满足你的业务需要，你就可以开始考虑不同的能够满足这些需求的替代品了。这是一个业务过程的开始。最终，你应该根据新工具的价值是否值得它的花费而不是根据版权费用，获得途径和培训费用来作出决定，你还应该考虑它对整个开发环境的影响。这个工具是不是只能在你的项目团队中使用，还是可以将来为其它的团队所使用？

所有这些工作都应该在决定使用新的工具开始以前做完。许多公司有一个专门负责理解和管理开发架构的团队。他们管理的还包括已经过时的退了休的开发工具。有时，他们还负责为版权和软件维护费用付款。但是，即使没有这种正式的部门存在，项目团队和经理也应该自己负起这些责任来。

更应注意的问题

仔细的评估你对开发工具的需要并基于业务需要来做出决定。你还应该确保对项目团队带来的短期好处不会在长期的方面对整个企业产生损害。