软件开发工具有哪些，例如，代码编辑器、建模工具、部署工具等。这些工具常常被集成在一个IDE中。什么是工具呢？工具就是我们做事时的帮手。在我们做完事情后，这些工具不应该在我们做的事情上留下任何影子。就像改锥，拧好螺丝，事情就完成了。我们不会把这把改锥搭在机器上一起卖掉，也不会因为我们的手中只有那把改锥，所有的螺丝就得按这把改锥的型号来设计。我们有权随时更换改锥。在我的软件开发生涯中，碰到过不少号称工具的软件。在这些工具中，有些很好用，如MDA工具，它会自动生成代码，生成好了，就脱离了和系统的关系；有些则很烂，如业务规则管理系统，通过业务规则管理系统创建的规则，离不开特定的脚本解释器、离不开特定的规则引擎，最后，我们还不得不把规则脚本嵌入应用系统中。 

正如改锥和螺丝的比喻，选择软件开发工具时也应该遵循这样一个原则，那就是在使用过这些工具之后，不能在应用系统中看到它的影子，就像我们永远也看不出哪一段代码是用Eclipse开发出来的一样（除非连Eclipse代码编辑器自动生成的注释也懒得去删）。 

我不反对使用软件开发工具，但是我反对那些绑定到应用系统实现的工具。为了更好地解释这个想法，我将以业务规则管理系统（Business Rule Management System,BRMS）为例，来谈谈那些嵌入应用系统实现的工具会给系统带来怎样的麻烦。 我将从以下四个方面来展开：什么是BRMS；BRMS如何工作；BRMS的问题；什么是更好的方案。什么是BRMS？首先要声明，在应用系统中业务规则是大量存在的。例如，银行的贷款业务，当自动化审核贷款申请的时候，牵涉大量的规则：贷款人的年龄、收入、以往的信用记录，甚至贷款人所在的地区，种种因素决定了贷款的额度。BRMS的目标之一，是把业务规则从应用系统的其他逻辑中剥离出来，并对这些规则进行统一的管理（规则库、历史版本、安全控制等）。我赞同这个想法。可是，BRMS的问题在于，随着它的畸形发展，这个软件开发工具被赋予了越来越多的使命，软件开发项目设计流程要注意的事项，甚至为了市场而不惜添油加醋地编造谎言。 

BRMS最离谱的谎言，就是要把自己打造成业务人员（客户）的工具。据说，使用了BRMS，就可以让业务人员（客户）直接参与应用系统的实现。这听上去是个不错的市场噱头。稍后，我会解释为什么这个说法是一个谎言。 BRMS如何工作呢？ 让我们来看看，BRMS到底包含了一些怎样的内容。