土八路的逆袭——死或生

    早在十几年前很多软件企业为了走出作坊式生产模式纷纷做出了各种尝试，其中比较有代表性的就是所谓的“配置化二次开发平台”，国内比较成功的有金蝶 EOS、普元 EOS、用友 UAP，这条路到底能走多远，通向哪里？这是一个关乎软件企业生死的问题。。。

    后来这种平台有了新的名字“Business Process Platform”，并裹挟MDA、SOA、ESB等新玩意儿声势浩大的滚滚而来。。。

    本质上来说，这些都来源于全人类的一个共同理想——全自动的软件开发，也就是说将“业务需求规约”到“实际可运行的软件系统”之间的过程傻瓜化、最好自动化、最好一键完成！

    上帝说：要有光，于是就有了光；客户说：要有XXX系统，于是就有了XXX系统。。。

    但是要达到上帝的水平还有很长的路要走，于是很多人形而上学的认为“做不到全自动，能做到配置化半自动也不错啊！”，事实真的如此吗？

生！

1.更高层次的封装，部分解决了软件企业如何积累和重用的难题。

2.技术细节的隔离，更容易实现总体质量管控，前提是要有足够强大的架构能力。

3.生产效率提升，这种优势表现在平台实施的初期和历经磨难后的成熟期（很多企业挺不到这时候）。

4.随需应变，相对比较容易对软件系统修改实现快速反应，前提仍然是强大的架构能力。

5.随着平台标准的普及，形成独立的生态环境，创造全新的商业模式，国内企业希望渺茫。

6.用户可以DIY，客户价值的提升，前提是平台要足够成熟。

死！

1.系统复杂度守恒，平台也好代码也罢，也许通过高级封装后配置化的操作过程让人眼前一亮，但是这样真的让软件系统开发变得更容易了吗？也许人工智能再发展50年后我们可以更轻松，但是现在——平台化更多的是将编码复杂度转换成了配置复杂度。

2.我们假设推行平台化的企业拥有强大的技术架构能力和充足的资源投入，但是一个平台的研发和成熟是要遵循客观规律的，而且这个过程就算有人才和资金的双重保障也不可能一蹴而就。
平台逐步成熟过程中面临的种种问题和不可跨越的困难只能是有苦自知，比如平台化初期带来的测试困难、模式僵化、项目妥协等问题。平台就算有了比较健壮的核心架构，到了实际生产环境中后也必然为了满足实际需求而频繁修改升级，可以说国内90%以上的企业不可能兼备挺过平台成熟期的项目管理能力、架构与技术实力和最重要的外部市场环境。

3.要保证一个平台产品的销售能够获得足够的回报，必须要有大量的客户，而作为产品销售形态，平台产品还需要强大的技术氛围和社会认识。然而不幸的是，在中国要达到这点面临很大的困难。大家往往会怀疑中国能否诞生这样足以形成标准的高端技术。

4.现在各家厂商推崇的平台技术都集中在业务应用层面上，因为这些厂商认为由于中国的客户水平比较低或者业务模式经常发生变化，对这种灵活修改业务架构的产品的需求是中国这一市场的特点，它们希望能够凭借抓住这一机遇而获得飞速发展。
然而，这些厂商的想法颇有些一厢情愿。一方面，这些厂商的核心技术往往采用J2EE技术作为基础，并结合一些SOA或者建模来实现，但这对于国内的用户来说还没有彻底理解，甚至存在一定的质疑，而对于开发人员来讲，要他们抛弃通用的技术，而学习这种看不到未来的技术，也存在相当大的困难。

5.现在这些做企业平台技术的厂商，其处境分为三类，一类是依靠自己原有的客户来进行推广，主要是为了降低开发的成本；另外一类是将自己的产品进行很多针对行业化的工作，从一些行业切入到客户，虽然也有厂商取得了成功，但再要继续扩大规模，形成标准的可能性很小，企业成长的速度也受到限制；第三类便是力图推广成为一种新的标准，这类企业面临的困难最大，而且在中国这种市场上，成功的可能性受到了很多人的质疑。

6.有人说软件企业可以在自己擅长的领域内合纵连横结成同盟，而后再推出标准化平台，一统江湖！要达到这点，企业间的各自利益纷争将成为最大的阻碍。

     总得来说，在国内推行软件平台化是一个九死一生的赌局！但是国内很多软件企业都处于无法突破但又无计可施的状态，未来路在何方呢？

    个人认为，首先要充分而客观的分析评估企业现状和实力，在主流技术领域厚积薄发，形成既符合业界标准又能有效实现企业积累与重用的架构形式，由点至面的逐步提高业务封装水平，借助各种工具和方法完善各环节工作流程，最终形成一套有效的体系帮助企业实现升级和跨越。。。