技术相关：从报表工具的选型说起
--王珏原创

    反思最近5年来的项目经验，想起了我们项目组的“报表工具”的选型。非常有意思的是，我所在项目组的“报表工具”总是能够在公司范围内得以推广，但推广后却又招来一片骂声。
    最初我们使用的报表工具是“明宇报表”，这个报表我没太多的体会，因为我到这个公司的时候，公司内部已经在使用这个报表工具了，它的选型以及在公司的退出和我没有任何关系。
    故事真正的开始在2004年低，我们公司接到某省电信的一个所谓“综合资源管理系统”的项目（开拓性的项目）。当时的设计目标差不多就是（我主要从技术角度说明问题，不提或少提那些电信业务）：

1. 整合。整合历史遗留的多个资源管理系统。

2. “想怎么查，就怎么查”。说的具体点，就是查询条件不确定（不是条件的值不确定，而是条件本身不确定），备查对象也不确定。说的抽象点，就是不满足于作业控制层的信息系统，需要构建知识管理层以上的信息系统（参见：需求相关：以“信息库”的思想建设“管理系统”）。

3. 其他就是所谓的电信的“支持前端”之类的业务要求（于本主题无关，在此不在赘述）。

    大概一看到这种需求，第一感就是：“整合”这种需求需要按照数据仓库的模式来，啥ETL，数据复制呀之类的。“查询”需求需要DSS之类的工具，而我直接 接触过的DSS工具还是大约在98年在深圳做程序员时使用的Delphi中所内带的DSS工具。经过一些简单的选型工作（1、内部同事推荐。2、上网搜搜 哪个BI工具市场占有率高）很容易就找到了Microstrategy的产品MSTR。找到这个工具后我才发现，原来此电信早就在其一个专业资源系统中使用了这个工具。剩下来的就是我们项目组的与众不同了：

• 整理的所有的业务数据，按照“维度”，“度量”，“层次”等概念进行建模。（至今我还保留着我绘制的MindManager的模型脑图，这也是我们项目组作重要的文档（参见：配置管理：文档配置库不是历史的垃圾堆））

    其实这些工作，也就是简单到“按照MSTR的说明书”办事。正如，规范设计，规范施工就不会有房屋质量问题一样。奇怪的是，客户以前虽然也用 Microstrategy但却拿它当报表工具用，自然也指出了MSTR一大堆的不是。然而，随着我们项目在使用MSTR方面取得的成功，不仅仅使得客户 对MSTR这个产品异常喜欢（还单独购买的MSTR的license），而且我们公司内部也立刻把Microstrategy作为主力工具进行推广（包括 商务上的推广）。然而，没过多久（我们项目组完成项目后的自然解散），在其他项目组中，当Microstrategy沦落为报表工具以后，大家也就骂声一 片了。

    第二个故事是在2007年，那时我接手一个“互联网业务分析系统”，业务需求简单来说，就是要在应用层进行协议分析，自然也需要进行“报表”以及“数据分 析”的工作。Microstrategy被否认的直接原因有两个：1、花费太大（主要原因）；2、Microstrategy是一个独立的系统，无法和我 们的网管系统有效整合（这还是个次要原因）。
    这样我们项目组就有面临对于报表工具的再次选择，公司给我们的要求是：1、开源；2、Java实现的便于和我们的网管系统整合。选择过程也不复杂，经过1、个人推荐；2、上网搜搜当下最流行的报表工具。而我又给加上了一个要求，必须选择一个BI工具，原因是：

1. 适应“需求的变化”。我们的项目需求存在很多不确定性因素，而单纯的报表工具没法适应需求的变化。
2. 开发人手紧缺。单纯的报表工具报表要一张一张的开发浪费成本，而BI工具在模型建立完成后，剩下的工作就不多了。
3. 开发过程必须适应“敏捷”。为了让项目过程“可视化”，必须要求在每一个阶段（差不多每一个月）都能有“看得见进展”体现在“可运行的系统”上。
4. “内 容”比“形式”更重要。在我看来，内容正确了，形式可以再进行调整；反之，内容失败了，项目也就失败了。极端情况，即使当BI工具开发出内容合适的报表， 但用户就是不认可其形式，我们再用其他开发工具再把这报表的格式调整到用户满意（可以充分适应需求的变化），所花销的成本都是可接受的。（这也是我的开发 理念：需求相关：以“信息库”的思想建设“管理系统”）

    经过上面的要求，我们项目组很容易就锁定了“JPivot+Mondrian”，同样当我们建立了MDX模型后，后面的项目过程也就一帆风顺（除了被领导、QA们经常指责我们的系统“太丑”以外）。
    随着JPivot+Mondrain这种BI工具在我们项目组的成功，此价格便宜量又足的工具又在公司内部进行大力推广。遗憾的是，随着时间的推移，这对工具又是骂声一片。原因很简单：

1. 做报表太过于复杂。不建模就做报表，当然复杂喽。
2. 报表样式不符合“需求”。

    当BI工具沦落为报表工具，这也就是它们的宿命。那么从技术选型来看，常常犯的错误又是什么呢？我个人认为大约有如下几点：

1. 拿某个“工具”当万金油，以为它能解决所有问题。（判断标准，可以参见： 银弹规则在技术选型时的运用）。
2. 不能深入理解一个工具存在的意义，换句话说就是它的优点是什么？不理解它适合于做什么？
3. 缺 乏分析设计，越高级的工具，起到的负面作用越大。换句话说，越是高级的工具，需要的技能越多，学习周期越长，为了有效的利用这个工具，需要的设计规划也越 多。举例来说，用电脑打字，在很多情况下并不比纸和笔更好用，如果做一个有“规划”的文字编辑工作，电脑就比纸和笔强很多了。

上述所谓的“BI”混淆了“BI展现工具”和“BI”概念区别，这样有助于说明本文的主要问题。完整的BI应该是：ETL、数据仓库、OLAP、数据挖掘、数据展现等技术的综合运用（参见：wiki商业智能）。但由于项目的规模，数据量的规模，以及一系列的限制条件，因此在项目中首先遇到的一般都是BI数据展现部分，因此我本文中不对此作出严格区别。


Link URL: http://blog.sina.com.cn/s/blog_592060b50100e005.html