目前国内应用软件经历了这些年的发展，很多软件企业都在谋求提高开发效率，能够快速响应用户需求，因为任何软件项目拖期都将导致客户满意度的下降，而且项目成本直线上升，因为过度竞争本来就利润率下降厉害，不能快速完结项目将是雪上加霜。

　　软件企业盈利越来越难，不得不千方百计来提高开发效率，构件、中间件、模式、MDA等等概念层出不穷，无非是想尽可能把软件生产过程分层分块，自动化产生一些较复杂的框架程序，降低软件开发过程对程序员主观人为因素的依赖性。其最核心的理念应该是化整为零，把软件生产过程分解成“零件”，构件化最能体现这一思想的开发手段。

　　软件生产过程其实和普通的劳动生产没什么两样，只不过软件生产过程更抽象，更依赖于人的大脑。试想n年以前，我们的织布、耕地都是手工劳动，如何走向了工业化生产？实现了自动化？成倍的提高了工作效率？不就是研制出了织布机、大型农业机械这样的工具么？

　　软件开发到底需要什么样的开发工具呢？借助什么样的工具才能实现软件生产效率的大幅度提升？应当看到国际IT巨头把持着数据库、应用服务器、大型专用中间件等系统一级的软件，国内厂商已经很难达到同样的竞争水平，但是这些仅仅是应用软件运行的平台，软件最复杂最多样化的还是应用需求，在具体应用需求方面IT巨头们也没能提供非常好的开发工具，直接帮助开发者轻松解决各种软件需求，都需要程序员去编写业务逻辑。从软件开发面对需求角度出发的，如果对需求进行合理抽象分类分解，每个需求问题领域都提供一种对应工具支持，就能面向需求问题借助工具快速实现软件开发过程，而且提供随需而变得能力。

　　总结我们面对的软件需求，都可划分为业务流程、信息交互界面、文档信息处理、报表统计、复杂数据业务逻辑这几类。因此，只要提供对应的“工作流引擎+表单设计+协同文档+报表工具”四种开发工具，再加上数据库开发技术，软件厂商就可以借助工具实现几乎所有常见的企业应用需求的开发，而且能够提供足够的快速响应和随需而变，依靠这种开发模式，能够很大程度上实现软件工厂化的的应用软件生产模式。

　　各种应用软件，从数据形态划分，不外乎两类：关系型数据和非关系型数据。大多数IT企业都是在做关系型数据的应用，比如：企业ERP系统，银行的核心业务系统、信贷管理系统，电信行业的BOSS支撑系统等等，这些系统的特点是紧密依赖关系型数据库。另外一类就是OA系统为典型代表的非关系型数据的应用，主要管理对象是文档，文档审批流转的过程通过表单来记载并传递信息，是通过文档型数据库来实现的。非关系型的应用还有更高层次的内容管理，不仅仅把文档保存起来，而且关注文档内在体现的知识价值信息，还关注文档生命周期反映的管理活动过程。比如：协同文档管理、知识管理系统等。

　　所有业务数据主要是通过业务流程的方式进行信息流转的，自然需要一个工作流系统来传递业务数据信息，大量的非关系型数据的传递都必须依赖工作流，也有的偏重逻辑计算方面的业务数据直接在关系型数据库中实现数据处理，但为了能适应业务流程灵活的调整，关系型数据业务系统也往往引入工作流引擎驱动，以文档信息为主的应用更是需要用工作流穿起整个业务过程。

　　这里提到四种工具是从开发解决的软件需求自身分类特点出发的。工作流聚焦流程变化的问题，业务流程和业务逻辑单元分离；表单设计是提供可视化简洁界面设计工具，并提供与数据库字段的映射能力；协同文档是解决非结构化业务处理，并且自身带有工作流程支持，或者与工作流引擎配合实现，而目前的文档管理产品（如Domino Notes）都是自身集成流程功能；报表工具关注灵活可调整的数据统计展现，尤其是中国式报表有不同于西方习惯的特殊性。

　　工作流引擎、报表工具都是好东西，可以在工具本身解决流程、报表的复杂性，简化开发，灵活应对需求变化；协同文档解决了非关系型数据业务处理的复杂性；开发中必不可少的需要做一些客户化的界面，最直接的就是提供一个可交互的表单，表单上交互的字段域对应后台的数据存储，所以表单设计不可缺少，而且表单可为工作流、协同文档、报表工具解决各自客户化交互界面的设计问题；复杂的关系型数据业务逻辑离不开关系型数据库，数据库开发技术无论如何也绕不过去，不过SQL语言本身已经提供非常高效的数据库逻辑开发手段。前面三种工具再加上传统的数据库开发技术就能完成绝大多数管理应用的开发，最后一步就是应用系统数据的查询展现问题了，这就是报表工具需要干的活。

　　用这些工具就已经把开发过程复杂度降低了。开发人员不需要太高深的编程开发技巧，只需要会用这几样工具写程序就行了，而且开发出的程序质量也会非常高，因为最复杂难处理的环节都通过这几种产品化工具解决了。高级设计人员只要调研清楚用户需求，写出设计文档，程序员也不会写程序走样的，最复杂的业务实现都是通过这些工具功能或API接口调用实现的，设计人员输出的设计文档是关于使用工具哪些特性实现业务逻辑，编码人员写代码的过程就是按照设计文档使用工具的过程。编写代码的程序员主要工作就是负责翻译和装配，最难处理的部件都由工具本身功能特性实现，装配工作的技术含量降低，难度降低，质量提高。

　　组合使用这四种工具和数据库开发技术就能完成各类应用软件的开发。比如： 协同文档+工作流引擎+表单设计，就可以解决OA类的应用开发；工作流引擎+数据库开发技术+报表工具+表单设计，就能解决银行信贷系统之类复杂业务系统的开发。甚至单独使用协同文档就可以解决文档应用类的需求；单独使用报表工具就可以建立专门的报表系统，创建一个企业报表中心。

　　这几种开发工具也不仅仅是从软件开发商角度说的，这些工具都提供可运行环境的服务引擎软件（或者就是某种应用服务器），如：工作流引擎、报表引擎、文档服务引擎。最终用户都可以把这些工具的服务引擎作为自己应用系统运行的基础设施。 最终用户具备这四种“工具”，一些简单应用和需求变化发生，自己动手就可以实现，对用户的技术知识要求并不高，像修改excel表格一样就可以自己做调整；如果重大需求变化或新开发，再找个软件开发集成商，用最简单的业务逻辑代码做一些外围或衔接类的工作就实现了业务需求。

　　当然如果软件开发商手中有这四种工具，开发效率成倍提高和成本成倍降低，就可以从容应对用户的需求和需求变更，快速响应实现，而且软件工厂化生产也并不是梦。

　　几年前笔者曾经在一家国内较大规模的IT公司扛活，当时的公司老板曾经提出建一个软件工厂化生产车间，走软构件的道路。最近通过仍在这家公司的朋友了解，似乎投入非常大建立的一个软件生产车间运转效率似乎也很成问题，所能提供的所谓软件构件也仍然还是那几样，被包装成各类应用中间件。

　　现在细想起来，走软构件之路的方向应该是没有错的，但我离开的这家IT公司的所谓构件中间件产品太杂了，不成体系，什么技术时髦就跟什么，冠以很好听的名字，真正应用广泛或具有推广价值的构件产品只不过两、三种。另外制约其发展的原因是国内IT公司的通病，人员流动性太大。做构件的人对对应领域的问题需要了解的非常专，没有几年功底根本不可能做的好，没有做应用开发经验的人也开发不出好的构件。

　　建议国内的IT软件企业更应该专注于应用需求类的构件产品或开发工具研发，虽然系统软件层面的“大家伙”是国际IT巨头的强项，但应用构件产品或工具是IT巨头们顾及不过来的，因为需求领域的问题太复杂太个性化了，他们都很难全都涉足，而且很多业务需求问题还都带有中国特色，反而一些有自己特点的应用层面的工具性产品非常有生命力。因此，只要我们用工作流引擎、表单设计、协同文档、报表工具这四样武器把自己武装起来，另外加上传统的数据库开发技术，我们国内的软件IT企业就能拥有大家梦寐以求的快速响应需求、随需而变的“一流武功”。