构件化与SOA推进软件“福特模式”生产力

　　引子：

　　伴随福特流水线模式的百周年，回顾软件业也已经走了近四十年的光景。而全球软件行业似乎已进入到了中年期，成熟的商业模式，缺乏雨后春笋般的创新型小公司，大公司增长乏力进而带来诸多的并购等。这些都让我们感受到软件行业早已今非昔比，大部分的软件公司都变成了鸡肋。软件从业人员也都从梦想的憧憬回到了实际的运营成本控制中。即使近几年炒得火热的SOA也无法为软件公司带来多少的利润和股价提升。难道软件业真的就这样了，还是在等待新的一次飞跃？

　　我们小时候都读过这段“生产力的提高会促进生产关系的改变，而生产关系的改变又会反过来促进生产力的发展”，所以我们看待软件业的未来发展还得要从最为本质的提升软件生产力和改变生产关系入手。

　　构件化通过模块化、层次化和专业化，质变软件生产力

　　工业化相比较之前的生产方式，给了社会生产力质的提高，而福特的流水线模式正是工业化的代表作。这让我们清晰地看到对于复杂业务的高效处理方式，就是通过层次化设计和模块化分工把复杂的问题分层和模块分解，然后通过‘流水线’协同的方式再层层组合，完成整体的任务。而处于某个层面的被分解的模块，就会有相应领域的专业份子来解决，这个模块又可以再继续递归细分到更小的模块来分解问题。这样某个层面的模块就可以专注于自己所处的相对环境和自身的目标问题。这种模式从本质上改变了模块之间的生产关系，专业化解决相对的问题，从整体提升了解决问题的能力，尤其是解决复杂问题的整体能力。

　　由此，我们要提升我们的业务和管理生产力就得从此着手，软件世界中的构件化（Componentization）正承担了这一使命。原来的应用系统则不断地被构件化所打破，企业逐渐走上‘一个应用’的进阶。企业渐渐不再有固定的应用系统，取而代之的是处于各个层面的模块构件来实现某个层面的相应功能。下图是构件化企业应用的一个范例。

　　企业应用通过底层的技术构件来作为实现应用的基础技术功能，技术构件的适用性往往是最为广泛和跨行业的，在各种应用中都会被高度复用。而再上一层的则是企业根据业务总体模型设计出来或是在不断的应用项目实践中不断提炼归纳出来的某个业务或是管理域的业务构件，这些业务构件往往是企业最为重要的资产和竞争能力。有了这些业务构件，企业就可以根据具体要实现的业务和管理流程，组成具体的应用实现，满足业务的需求。

　　业务构件化和技术构件化的逻辑模式首先让企业可以开始不断规划设计、项目积累和梳理回归不同层次上的技术构件、业务构件和业务流程，通过专业化分工和流程协同达到组织级能力的提升。并且在此过程中和基础上可以更为精细化地运营和管理。企业根据需要灵活注入对于业务和技术构件的管控和治理策略，从而找到自身的核心能力模块，找到自身的高利润业务职能模块。进而不断投入、扩展和优化自身的核心优势能力，限制、调整和外包自身的劣势能力，达到不断提升企业整体竞争能力和赢利能力的目的。

　　构件化通过模块化和层次化，梳理优化生产关系；通过专业化和流程协同提升组织级生产力。

　　SOA通过构件标准化和服务契约化，推进软件生产力

　　构件化在不同的技术背景和时代有着不同的能力表现，在SOA到来之前构件化只能有效实现技术层面的模块化、层次化和专业化的能力水平。而SOA时代则真正带来了业务和管理的模块化、层次化和专业化。下图就是SOA编程模型SCA中定义的标准原子构件。

　　很显然它的技术无关性和消费使用（Consume）特征，如：服务、引用、属性、实现，是实现业务构件化的关键所在。原子构件就可以是一个事实上的业务构件，当然也可以在原子构件的基础上进行业务组装形成更大粒度的组合构件（Composite）。进而若干个组合构件和资源配置文件形成构件包（Contribution），成为独立可部署的业务功能模块。业务功能模块有了SOA标准下的逻辑构件形态和物理构件形态后，就可开发、可部署、可运行和可管理了，也就真正实现了标准的业务构件化。

　　下图是一个构件化SOA应用的范例。