X5档案-参加业务架构平台研讨会后记

 

我一直工作在行业信息化领域，也就是大家常说的管理软件。有人说是玩增删改的，有人说是玩SQL的，也有人说是玩数据库的。当然，也有人折在了关系销售门槛外，也有人折在了被需求淹没累死耗尽，也有人折在了项目管理混乱最后收不了场双方争目的结果。好似这个行当说难不难，不难也难。好似难在软件功能不断增加，又好似主要成功应该在软件之外。

 

废话不说了，今天说管理软件业务架构。做管理软件的，都想有个业务架构，然后寄望用户的需求就如同一个个的小砖头块，都往这个架构里塞。架构稳固，软件就不倒，基础运营良好。架构的重要性，是每个开发人员都明白的，不需要多说。

 

今天，CSDN和起步、K2、普元在过去举办英雄大会的知春路丽亭华苑举办了一场关于业务架构平台研讨会。我多年关注架构，自己也搭建了两代架构，如何更理想什么方法更好，是我特别想知道的，所以肯定要赶过去学习。过往经历研究U8架构、NC架构、K3架构、BOS架构、普元BOS架构、起步X3架构、SAP R3架构、用友华表E-CELL架构、浪潮楼上、金富瑞，甚至去年还又瞅了一眼大连雅奇（94-97年的玩计算机的人都知道），等等等等。梳理大家的共同点，不同点，着重点。

 

我赞同起步马总今天讲的一句话：准确语义文本描述化、标准化、图形化。

 

马总还说了一句话很深刻，让我也很深思：做机械设计，你需要懂很多规格很多标准很多理论才能做。好似做软件，只需要学学几下开发语言学学SQL就能上手。

 

我从中反思了一句话：做管理软件，好似客户说什么需求，然后就实现成计算机辅助工具进行数据存取与计算。理论体系呢？管理软件，里面的管理体系呢？我们看到好多管理软件，只能讲功能，而不能讲出管理体系。只能讲出管理概念，不能讲出管理体系。应该随管理软件，有其匹配的管理体系书籍和方法论书籍。但是，很遗憾，没有。我做了客户关系管理多年，有个朋友问我读什么客户关系管理书籍比较好，我竟然找不到理论和现实结合的好书。要么是案例对不上理论，是强把一些案例按到客户关系管理的头上，要么理论就是一些些散点，根本无法实现管理软件。

 

我很理解马总说的语义文本描述化。代码写死，还得编译，发现需要修改，还得IDE，还得程序员看代码改代码，还得编译、部署。麻烦的很。所以，我过去尽量存放在数据库，大量的配置、页面描述、报表格式都存放在数据库，而且尽量用SQL、视图、存储过程来操作业务数据对象。在B/S软件中就尽量用HTML、CSS、JAVASCRIPT、XML，这样就不用IDE，不用编译，直接修改就OK。

 

但是，这些都是自己的土格式，只在自己产品里转没有问题，反正都是自己的。

 

但是，起步是做业务架构平台产品的，就不能自己定义个自己的，不通用，而且还可能定义的不完备。老宋列出了一张列表，上面是X5选择的技术格式标准，很多过去写死的东西，都可以XML化（我现在也理解了BPEL的流程要用XML表示的原因了）。老宋说别看小小一张列表，他几乎花费了10年的功夫。

 

是啊，我深有同感，我非常感叹，也很佩服老宋的韧性、耐心、坚持、专业、深度。要知道，选择什么样的技术标准，你需要把各个技术标准都需要阅读，而且得阅读懂，阅读通，而且能明白各自的优缺点，然后才能选择。不知大家阅读过技术标准没有？如果有人阅读过，你会明白，阅读过程大量都是英文，枯燥、难懂、大量关联。阅读文档很容易放弃，很容易心烦，很容易囫囵吞枣。老宋能坚持下来，并且实现为产品，做、想、写、说，老宋都做到了，难于上青天。但毕竟X5来临了，背后心血几人知晓。

 

马总还说了一句很好的话：业务架构平台的核心目的是有一个基础稳定坚实可扩展的业务架构。基于这个业务架构基础之上开发应用就非常安心了。

 

我想：如果我们没有微软给我们建设.net framework强大的类库，让我们自己来写一个应用，费死牛劲。想当年JAVA没有出现的时候，SAP要研发R3，面对的客户是异构数据库、异构硬件服务器、异构服务器与客户端操作系统、异构硬用软件，SAP怎么办，只能自己建立统一UI、建立持久化层、建立能运行在各个硬件各个操作系统之上的开发语言和业务组件，实质上，是SAP自己实现了一套适合自己的虚拟机和开发语言和基础类库。最后，R3出来了，JAVA也出现了。SAP后悔死了，但重资已经投入不能回头，最后，终于狠下心来研发了Netwaver。研发顺利多了，就是因为在JAVA之上构建，很多东西不用自己实现了。

 

有的人认为业务架构平台是为了复用，有的人认为业务架构平台是为了快速开发，有的人认为有了业务架构平台就可以不需要程序员了，懂业务就能自己设计设计最后搞出一套应用。这是要废掉程序员啊，当然，干IT的人坚决抵制、冷观、落石下井。

 

可以这么说，业务架构平台的最重要的作用就是提供一套基础的公共的框架，基础牢固，业务应用在上生长不会是一盘散沙。另外，有了这个基础框架，很多事情就不需要应用业务自己写了，在底层都自动做好了，或者有工具和类库提供，直接调用就可以了，不需要自己重复写一套代码了，所以开发快了，也修改灵活了。但复用，这个说不好。基础架构平台自己当然能复用，业务应用模块复用，这个不是很理解。另外，废掉程序员，让普通人就能出一套系统，那SAP的那些应用开发伙伴就不要活命了。但是，就算对业务架构平台如此深刻研究的SAP，也没有废掉定制开发伙伴，而且定制开发伙伴越做越大。所以，有人想买套业务架构平台废掉程序员，这个就太幻想了。当然，程序员也不要如此担忧。

 

马总还说了一句话很好：业务基础平台提供了一套统一的分析需求方法论和设计工具，可以让用户和程序员一起在一个统一方法统一视图统一工具的基础上工作。

 

我也一直在琢磨这个问题，SOA也在琢磨这个问题，UML、RUP都在琢磨这个问题、MDA也在琢磨这个问题、BPM也在琢磨。开发人员最擅长看的是代码，讲的是软件功能。而用户最擅长讲的是需求，看的是直观的输入表单和输出报表。

 

SOA强调用户和程序员从服务的角度上看问题，但还是太抽象，我都没有明白，我只知道SOA是更高抽象层次的组件规格标准、组件互动标准、有SCA定义组件，有SDO定义互动间的数据交互，有BPEL驱动业务执行让SCA们自动调来调去完成运算，有ESB充当SCA组件的管理容器和框架。

 

UML和RUP本来很好，但它由于想描述一切软件，反而很抽象了。所以，需要面向领域的分析方法和描述方法。而业务架构平台，做信息化很上手，很容易理解，这就够了。

 

由于现在技术各异，有PB、DELPHI、C#、asp.net、JSP、PHP、FLEX，所以描述业务流程、输入表单、输出报表，很难描述，不具有可移植性。换个语言，就需要重复全套开发一次，这就太不值了。

 

所以，必须XML化、标准化、图形化，而且要有用户和程序员都能接受的工具来大家统一分析方法统一设计方法统一设计工具。这是X5想要达到的。

 

研究了不少国内业务架构平台产品，发现还是太偏开发人员，很多名词和解释和思路都透着ID、英文名、数据表字段、JAVA文件等等。还有，很多做业务架构平台的，大部分都是自己用来开发应用的，捎带想卖这个平台产品，所以平台产品做的挺粗糙的。只有类似X5之类的产品，由于定位就是在独立的可销售的业务架构平台，所以成熟度会高一些。

 

我想了想，到底起步是做平台的，而且一做这么多年，在平台产品的核心使命、平台的标准化都有自己深刻的理解，我学习了许多，也让我打通了不少过去的思路。

 

不过这个产品，既可以中型和中小型信息化软件企业使用，又可以给企业信息科使用。但这两个群体的技术能力和考虑重点不是一码事。所以如何给客户销售宣传是个问题。

 

而且，许多人不想给license付费，想10万块拿下。而且对于软件企业，还想要源代码能够自己为它所服务的行业而订制一些行业计算类库。

 

客户需求就是如此的现状。怎么解决，是要好好想想，可以分层次，分不同人来区别对待，不用一个统一标准卡死。

 

既能开发平台又能开发应用，在中国，大量的软件公司根本没有这么多人和钱和时间，大量的做项目挺大的软件公司也没有力量做一个和X5媲美的平台，但都想要平台，但都碍于价格和源代码而止步。业务架构平台是有希望的，未来一定会分工，就如同.net framework、业务架构平台、应用开发这样的层次顺序。谁能巧妙的解决好价格和源代码，就如同支付宝解决了支付安全和信用评价，这么巧妙，谁就能突破目前的尴尬境地。

 

SAP自己研发平台，IBM之类做咨询，东软、埃森哲之类做定制开发，XX实施做项目管理、培训教育认证，XX做服务支持。是一个产业链。但中国，这样的产业链不容易形成，因为产品无法打向高端，利润不支撑大家在一个产业链生存。现在国内业务架构平台厂商，都是自己边开发平台，边拿平台做项目夯实平台验证平台并且赚钱运营，实在很辛苦。但那又能怎么办呢？唯一缓解的办法就是如何在做项目中，让用户参与进来。这样，把用户的人当作自己的人，这就又快又省了。

 

没有枪，没有炮，敌人给我们造。

 

X5是好产品，起步也是理论与实践相结合最好的公司，如何创新性思维，需要开放和统一战线。

 

附带一句：把B/S往C/S样子去做，可能是个不对的路子。WEB就让它成为WEB。反正大家都熟悉了新浪的这样网页，谁也没觉得奇怪。现在各种富客户端，都存在效率问题。效率问题，有时候不是优化能做到的，很可能就是最初的设计根源。根上出的问题，是改不了的。而且效率会毁了一个产品。VISTA就是如此。当然，VISTA易用性也不好。如果易用+效率都不行，还不太实用，就彻底歇了。还有，架构平台的功能如何一块块的卸载和加载，就如同ecplise的插件一样，我看X5提供的功能过多，而在某些特定行业又在某些特定的功能上提供的太少，所以免不了先减后增，一上来就是这个一整套，有问题。太重型。比较难用起来，一用就得一整套，框在X5里憋屈的慌。

再带一句：K2是做工作流的，和业务架构平台还不是一码事，可以做，但不是专门干这个的。普元胡长城的演讲因为有事我没来及听先走了。普元重点关注SOA业务组件的，和业务架构平台还有一点点区别。

 

 

这是豆瓣评论

http://www.douban.com/subject/3319935/

《走出软件作坊》网上订购：

互动网：http://www.china-pub.com/508874

卓越网：http://www.amazon.cn/mn/detailApp?prodid=bkbk812538&ref=GS_TS&uid=168-8093432-0389064

当当网：http://product.dangdang.com/product.aspx?product_id=20435119