haoxiaobo

从C到C++又到.net, 有一些心得, 和大家交流下...
posts - 50, comments - 538, trackbacks - 1, articles - 6
  博客园 :: 首页 :: 新随笔 :: 联系 :: 订阅 订阅 :: 管理

公告

2011年8月31日

    
    既然已经上线了这样的“标准流程”的核心业务系统,就必然会立即遇上各种地域化问题。前面说过,中国各地发展极不同步,在经济、文化、政治、民间风俗、人文道德水平方面全国各地千差万别,相同的业务要求不同的服务方式是不可避免的。
    比如说我们上线不久遇上的一个事情:这些年政府管控的力度越来越大,不仅管产品,管财务,还要管到各个公司的内部操作流程上,搞得大家都很难受,不知道国家是不是想要回到计划经济的路子上去。就是在这种背景下,我们分公司所在的当地政府的一些监管机关经常搞出个通知,要求在某个业务办理时,所出具的业务材料必须按官方规定的文字向客户进行书面表述什么的。
    新业务系统上线之后,这种小小的需求也必须要向总公司提申请要求修改了。业务系统本来对于操作中的打印件采用了模板技术,如果需要修改内容,只需要修改模板中就可以了,但是问题是这个修改是只对我们一个分公司的,其他分公司没有这样的要求(或是其他的什么要求,都不一样),一但这个模板修改了,全公司都会跟着我们的样式生成打印件。
    这个需求提到总部IT之后,负责的家伙着实地发了一阵子愁,最后还是没有好办法,只好在崭新的系统代码里加上了那个肮脏的“if(strncmp(deptno, “BEJ”, 3) == 0)…”,在我们公司的操作员在操作这种业务时,特别地调用一个专门的模板文件。
    在目前的社会环境下,这种需求一定会很多,不仅有这样特别打印件的问题,还可以设想其他可能存在的同样地域性需要:
    l 在UI上某处为某个地域的操作增加某些特别提醒信息
    l 必要时还要跳出个MessageBox\alter来。
    l 打印外文版文档。
    l 某地区在标准流程中特别插入的步骤。
    l 某地区对某个业务的前置\后置检查逻辑。
    l 某种特别需要的警戒线提示。
    l 特别的数据展示格式。
    l … …
    对于这些域化的需求的解决方案,我在操作系统的设计中得到了启发。
     
    a)        地域化静态资源扩展
    操作系统常常需要开发不同的语言版本,为了简化开发,一般会将UI中所用到的字符串、图片、多媒体文件等做为一种“资源”来单独处理。操作系统中总是有一套Default的资源文件,然后为不同的文化和语言分别准备不同的特定资源。如果当前的文化设定所对应的特殊资源没有提供,那么系统就采用默认的资源,比如英文,如果存在当前文化设定对应的特殊资源,那么就采用特殊的资源。
    这个思想完全可以借签到业务系统的设计中,把分支机构如同操作系统中的一个文化-语言来处理,对于系统中所需要的资源类内容,按分支机构整理。在默认的情况下,系统会加载default资源来处理,而当一个分公司有特别需要时,为其特别定义一个资源,这样系统优先使用这个特殊定义的资源,使得系统可以方便地按地域提供个性的服务。
    应该说我们的系统还是考虑到了一个层面,就是可变的模板让标准内容可以方便地修改,可惜没有进一步认识到各地区差异需求必然性,现在,该为业务系统的设计者提个醒了——当你设计一个要用到全国各地的系统时,地域化支持就成了必然要考虑的问题。
     
    b)        应该考虑客户化插件标准
    还有很多地方对于功能类的扩展要求,也可以参考操作系统的“事件”思想。就是说核心业务系统可以按标准的操作过程执行,但是同时设计一种机制,可以在某些时机来callback触发预定的“额外功能插件”。
    所述的“时机”可能如下的情况:
    l 一个订单生成之前、之后。
    l 操作员登录后、注销前。
    l 某些信息安全事件。
    l ……
    对于这些事件,系统应该有一种标准化的“定阅”协议,使得程序员可以方便地注册定阅程序,这样在事件发生之后,系统根据定阅记录触发注册程序。这些程序可能不只一个,而且可能只是对与某个分支机构有关的事件才会触发。
    这里需要注意的系统的健壮性如何不受callback程序的影响,比如从技术上限定callback程序可以做的事情或不能做的事情,甚至要求callback程序只能是异步执行等。
    进一步地,可以将一些常见的插入任务制式化,比如特别的消息提示,电子邮件通知,存档,简单的表达式计算与数据检查,这些常见任务可以固定为可选用的任务模板,通过预定参数来达到不同的目的。
     
    应该承认,在整个系统中的所有的可能的地方实现这些可定制、可插入,其成本必然是很高的,但是,应该在系统中为这些特性做好技术的准备,你应该把加载资源的函数增加个分支机构代码参数,以备在需要时可供使用。也应该规定好事件触发的技术协议,那怕是通过某个规定的数据表中的记录来传递消息,只要有标准就行。
    如果你在系统设计中没有增加这些特性,那么你在发现自己在第二次在同一个地方写入“if(strncmp())…”时,总应该开始认识考虑这个问题了吧?一个if可能是个偶然的个性问题,两个if出现在同一个地方时,你应该能认识到这是一个值得重构的弹性需求点,及时在这个地方引入地域资源化、事件订阅等设计模式,以免在上线第二个月时,就把你崭新的系统代码挂上一串串的大便。
    

posted @ 2011-08-31 21:34 HAL9000 阅读(1154) 评论(1) 编辑


商业公司的业务同质化很高,市场如战场,谁能快一步应变,谁能给客户提供个性化,谁就得到了业务,谁就能生存。特别是象中国这样各地的经济、文化、政治极其不平均的国家,中央与地方的差异鸿沟巨大,地方特色必然需要。

但是站在总公司的管理角度上来考虑,当然是希望业务流程越规范越好,新花样总是意味着管理上的潜在危险。而对于总部信息技术部门的角度来看,个性化的新花样则是开发工作量的剧增、无止无尽的新需求。

管理与市场、领导与客户、全局与局部、总公司与分公司之间,这个思路方向性的矛盾是现实存在,而且不可避免的。

当然,最后项目还是要按上级的管理意图来实施,于是我们得到了一个全国一致的系统,一个唯一可用的UI,一本统一印发的操作手册。对于常规的业务,按着系统的要求操作就可以满足需要了。但是这个系统不再给机会进行业务、技术的创新,一切新的想法只能做为新需求向上级提出,然后由情绪恶劣的IT人员在程序里加入一个个 “if(strncmp(deptno, “BEJ”, 3) == 0)…” 这样丑陋到暴的代码来完成流程定制化。

 

其实要在同一个系统里同时满足总分公司双方的诉求,并不是不可能,就是把应用系统分为两层:业务逻辑与UI层,业务逻辑层是对业务逻辑的原子化,以实时服务的形式提供。在此业务逻辑服务的基础上,构建界面展现。

这里的关键点在于业务逻辑服务的提供,不仅可以是标准UI对其的进程内调用,也同时需要能够通过webserivce等协议提供进程外服务。对于标准流程,可以由总部来做“典型实现”,而对于有特别需要的分部,则可以方便在业务服务的基础构建业务系统的其他前端外延。

这样,从管理的角度上来讲,业务数据的进出都是通过标准服务来进行的,业务数据质量、业务一致性、合规性都可以通过统一的业务逻辑来得到保证,而分支机构则有机会为不同的业务开发不同的前端接口,以根据市场要求灵活创新。

这种模式特别适合于有外部合作机构的公司采用,如金融企业、电子商务企业等。如果业务系统只有一个UIIO方式,一切数据进出都要通过操作员来进行,那么与其他合作方进行自动化的数据对接就很难实现,一但有这样的需求,只能由交由掌握了底层逻辑的总公司IT从头开发。

现在我们的系统已经上线,可惜的是,系统采用了最简单最直觉的思路开发,几乎要把业务逻辑写在界面里了。事已至此,也不可能有什么改变了,这里只是我有过的想法分享出来,作为讨论。

posted @ 2011-08-31 20:21 HAL9000 阅读(1347) 评论(1) 编辑

摘要: 近一段时间,公司上线了一个全国性的业务系统,这个系统功能覆盖了全部业务流程,用户包括全国32个分公司,可谓是一个把所有鸡蛋放在同一个蓝子里的巨大系统,上线过程多么辛苦不说了,只说上线后的一些问题所带给我的一些关于业务系统设计启发。阅读全文

posted @ 2011-08-31 14:15 HAL9000 阅读(1550) 评论(13) 编辑