回顾篇：SOA一致受追捧

　　SOA的概念在这几年持续升温，管理软件厂商也频频借用SOA包装亮相。确实，SOA和管理软件关系很密切，甚至可以说，管理软件业是最有资格来推动SOA的实践和应用的。

　　首先，从企业的角度看，随着计算机的普及，企业的信息化建设已经由原来的部门级应用，逐步过渡到企业级规模的应用。以前的“部门级”应用通常局限与财务部使用的财务软件、人力资源部使用的HR软件。

　　随着企业的成长，部门级的应用已越来越难以满足管理者的对企业资源全方位掌控的需要，并且部门级应用造成的信息孤岛现象也逐步成为令人头疼的问题。解决这个问题的出路有多条，例如抛弃原有的应用，实施ERP，或者利用SOA技术改造原有系统，以较小的代价整合零散的应用，达到应用一体化的目的。

　　在SOA架构下，服务是最底层的基础，服务与服务之间通过企业服务总线（Enterprise Service Bus 简称ESB）进行组装，从而根据企业的不同需求实现不同的应用。企业的IT系统摆脱了原有的紧密藕合，服务与服务松散地结合在一起，根据需求的不同随时地进行应变。这使得企业的IT架构更加灵活，应对业务的变化也更加轻松，这在管理软件领域发挥着更大的作用，因为管理的流程变化的频率更快，对IT灵活的需求更强。

　　其次，对于管理软件厂商而言，在产品中使用SOA技术除了能保护用户向企业级应用过渡的长远利益外，对自身产品的整合也有着非常深远的意义。

　　我们知道，目前主流的管理软件厂商已经将应用开发范围从常规的ERP领域延伸到诸如HR、CRM、电子商务等领域，厂商正在把所有的这些集成在一起，作为一体化的解决方案提供给客户。在其产品中，诸多的子系统之间、以及各个模块之间就必然存在着错综复杂的数据流转和功能调用关系，因此SOA将会成为一个非常重要的服务中枢。

　　现在已经有好几家厂商都不约而同地将SOA作为软件的数据总线来对待，估计会在不远的将来，我们会以当年对待组件的概念那样，很平常地来对待SOA。

　　新技术改造

　　SOA来了，EJB 3.0来了，Vista来了，Framework 3.0来了，Web 2.0来了，在这些新概念、新技术的背后往往蕴藏着巨大的商机。对于管理软件厂家而言，除了机会以外，还意味着一项更为艰巨的工作：那就是对产品的技术改造。

　　事实上在这几年中，各厂家的技术改造工作几乎就从未停止过，新技术改造工作就象一条永远饥饿的鲨鱼，消耗着开发者大量的精力、吞食着厂家的巨额利润，更有甚者，技术改造总会遇到失败，结果失败后又推倒重来，技术转了一圈又回到原地。这从2006、2007这二年厂商的技术动态中可以看出一些端倪。

　　管理软件行业的技术方案的选择是一个非常严肃的问题，尤其是ERP类的产品，有着行业中太多太多的特殊性。产品不能靠技术来呼悠，当然也不能被概念炒作所呼悠，大部分厂商已经懂得了这一点。我们也看到如今技术改造工作仍在如火如荼地进行着，但愿这项工作不再是梦魇。

　　技术手段多元化

　　在主流技术多元化的今天，管理软件厂商有了更多的选择余地，来为自己的产品找一条最适合自己的技术路线，不像当年，在平台上除了Windows还是Windows，在展现方式上，除了Web还是Web（国内叫“B/S”）。

　　就拿“B/S”来说，很多人都认为互联网就是“B/S”，甚至简单地以此来判断产品的先进与否，但是在管理软件行业，尤其是ERP领域，时至今日都未曾出现过令人折服的基于纯页面的产品，大家普遍在反思，直到现在终于明白了软件工程领域中先知的预言：No Silver Bullet（没有银弹）！

　　在Web 2.0应用大潮席卷而来的今天，我们仍可以说，在管理软件领域，Web就像是金钱，它不是万能的，但是离开它却是万万不能的。于是，基于Internet的各种实现技术开始相继登场，例如智能客户端方案、基于远程桌面的解决方案，还有其它行之有效的胖客户端方案等等。毕竟，技术原则上是为应用服务的，最终用户关心的不是技术本身，而是软件产品能否帮助企业提升其管理水平、能否提高其工作效率等问题。软件始终是工具，而软件技术则是工具中的工具。

　　不难发现，有一些热门技术的本身也存在轮回现象，例如目前很多厂家普遍把Ajax技术融入到产品中，以改善产品的交互性。但是，Ajax是新技术吗？不是，它只是一些传统技术的重新组合。并且在1998年微软推出的Visual Studio 6中包含了一个叫“XML Data Island”的Web方案，该方案已经具备了相当多的Ajax特征了，只是普遍被忽略而已。

　　展望篇：胖客户端技术将大行其道

　　我们知道，采用纯页面技术（例如ASP.Net、JSP和PHP等）的产品只能应用在交互相对简单的场合，但是管理软件中有很多应用场景却完全是另一番景象，真正做过开发的人可能对此深有体会，应用服务器端的开发相对简单，有相对固定的模式，而客户端交互的开发却要复杂得多，甚至无章可循，其难度比应用服务器端要复杂的多。

　　这个问题其实也不仅是管理软件中存在的问题，而是一个普遍存在的问题，目前软件界有关这方面又多了一个新的概念：富因特网应用（Rich Internet Application 简称RIA）。当前，几家国外IT巨头同时往这个方向发力，如Adobe的AIR，微软的 Silverlight，Mozilla的XUL，Sun的 JavaFX。可以看出今后

　　胖客户端技术仍将受到业界的高度重视。

　　除了智能客户端、远程桌面方案外，管理软件厂商的技术今后的选择余地可能会更大，不过这些技术发展到最后可能会走向统一。

　　应用软件平台仍会是焦点

　　管理软件业的厂家中有相当一部分是产品型的公司，产品型公司的开发模式是完全不同于加工外包型公司和项目型公司的，产品型公司所开发产品的目标客户是一个群体，而不是个别客户。一般来说，产品功能所涉及的企业业务部门越多、客户所在行业分布越杂，那么产品在分析阶段不可预测的需求就会越多、产品在后期修修补补的工作量也会越大。

　　典型的就是ERP行业，国内ERP厂商的开发队伍往往达几百人甚至上千人，他们不断地分析、编码、测试，用户试用不满意，那么再迭代…永无休止。应用做得完吗？恐怕上帝都会说：不可能！

　　很多厂家都已经意识到了这个问题，于是应用软件平台在这几年成为大家投入的重点，平台尽管不能彻底消灭需求多变性带来的挑战，但是确实能有效地减缓需求多变的压力。它帮助厂商从疲于编码中解脱出来。但是我们到底需要一个什么样的平台，平台给什么样的人使用，采用什么样的架构，应该具备什么样的功能，这些问题很关键，应该由平台设计师们来回答。应用软件平台既不同于开发平台，也不同于普通的中间件平台，从软件建模这个高度来看，应用软件平台涉及面很广，开发难度也很大。无论如何，平台的完善性很有可能成为应用扩展中的关键性问题。

　　软件开发应该是十分优雅的，而不是现场忙于救火式的;软件结构最好也是积木式的直观，而不是大段源码的堆积，当然这是我们的理想而已，但是如果管理软件靠成百上千程序员这种人海战术炼成的，那么这和上千工人修水库又有何区别呢？