对业务建模的思考——为什么要业务建模 (转)

我没什么经验，所以都是推测或者说是臆测。
btw:我也不知道怎么到这个话题上来了，我本来只是想提提xp可能不用业务建模的，弄到最后成了单纯说业务建模了，:)。

对这篇文章很有感触！
最近的一个项目就遇到了“业务”问题，我们这个项目“发起者”和“最终用户”是分开的，而且完全不在一个部门（领域），我们开发小组成员对于这个“领域”也是完全陌生的，项目催的比较急，领导们整天说“赶紧把总体方案”拿出来，可是我们这个Team对这个领域太陌生了，而用户方很忙（他们确实很忙，而不是有意阻碍），关于业务这方面交流有限，更谈不上“对业务流程建模”了，我们想跟着用户，在他们的日常工作中探索业务，可是由于种种不可抗拒的因素，如密级很高，而无法实施！
    针对于这种项目如何实施“业务建模”？！而且用户对于自己业务流程的把握也不是很到位，举一个极端的例子，如：作战时物资的调配与供给，没在这种环境下就很难把握住“正确的流程”，更何况战场错综复杂，何种是正确、何种是错误很难说得清楚！
    不知道我举的这个例子恰当不恰当？！总之，业务建模是非常好的，但在一些情况下是很难实现、很难把握的！
    不知道有没有朋友遇到过和我类似的情况！

行业和行业之间有很大的区别，不过也还是有相同点的。

象MartinFlower分析模式中所将到的种种业务模型，虽然模型的来源是医院和金融行业的项目，不过很多东西稍加变换，或者换一种思考方式，也是可以应用到其它行业上的。

象楼上的情况，只有尽量寻找之前做过的项目和资料，看有没有相似的模型和模式可以套用，然后再对其针对自身特点进行逐步的迭代改进。似乎没有很好的办法。

如果本身就不熟悉业务，又不能从客户那里深入了解到业务，真想象不到，该如何做这样的项目。呵呵。

用户忙绝对不能做借口,谁不忙啊?
"日常工作中探索业务"--我认为不行,谁愿意工作时带着个跟批虫,
工作中不行,可以在日常生活中探索业务--再忙他也得吃饭吧,请他吃饭遍吃遍谈...
忘了谁说过这样的话:人最乐意对一个外行谈论的话题是自己的工作...

呵呵，随便说说。

作战时物资的调配与供给需要的不是一套计算机系统，而是一套独立的安全的电话网络，有双重路由备分，有保密机制。

其实你的问题和做不做业务建模没有太大的关系，业务建模只是一种方法，你不建模也得调研啊，你总得有个方法表达用户需求啊。
如果按照你所说的，根本触摸不到用户需求，那就只有两条路了：要么不做，要么尽己所能，能做多少是多少。

需求分析是纯粹分析客户的业务,业务建模应该在需求分析之后.

典型的瀑布思维方式。
业务建模及其产生的业务模型非常可能是在你还没有接触客户而只是接触了领域的时候就产生了的，这一点非常的好理解。而对于从业务模型上推倒出的实现领域模型，也非常的可能在需求分析之前就已经产生的。而且这些模型越是早的产生，就说明这个组织对于领域和业务的积累深厚。到真正面向实施的时候，由于已经存在一个系统化的业务和开发框架，实施起来就会轻松的多。

这篇文章我很早就想作一个点评，但是当时我没有时间。现在好了，我来作一个我自己的阐述。

这段话有问题。这个目标是没有必要达成共识的。而是要理解不同的涉众各自不同的目标，而这些目标很多时候是相互矛盾的（比如卖方和买方的矛盾，管理者和被管理者的矛盾，业务方和竞争对手的矛盾）。实际我我们操作的时候需要的是找到最应该满足的那部分涉众的目标，并且在一定程度上去满足这些目标的非对抗目标。但是实际上这个问题还需要特别的考虑。如果你是在项目前对于领域进来了解的时候进行这个业务建模（我更愿意叫做领域建模），这个时候得到的模型应该非常明确的反映出这个对抗的关系，以便于在具体针对项目的时候进行有目的的权衡。
而由于作者在最初的基本出发点上就存在这样的未深刻理解，所以在后面的论述中存在非常多的微妙的错误，而且造成的影响很多是本质上的问题。


为这里作者实际上阐述的有些不清楚，很多情况下业务主角并不是顾客，比如你要建立的模型是为财务管理服务的。
实际上这里隐含一个作者的想法，这一点大概也是RUP的一个问题。那就是过早的划分出了一个模型所要针对的需求对象。而在我这里，业务建模如果是在项目的前的领域分析的时候，特别是在建立分析模型的时候，关键的是在描绘场景，而非过程，或者是业务领域中有些什么对象（概念模型），而不是有些什么过程（业务流程）。这是由于业务流程会随着业务的实施具体环境的不同有所不同，过早的具体化会造成后期对于真实用户业务过程理解的污染。但是我们也清楚实际上这个业务过程是非常重要的一个业务领域中的概念，如果不在早期就有所准备，那么后期的工作也会非常困难。解决这个问题的方式就是尽早的建立业务规则库，这个问题我会在今后作专门的阐述。


明显的作者这两段话之间是有矛盾的——前面一段是隐含者说业务建模是需求建模的一个部分，后面则又在说业务建模可以在项目前就产生。是什么原因造成作者的这个矛盾呢？
根本原因还是在于作者没有跳出瀑布思想的束缚，依然将对于业务和领域的工程化分析强行的加入需求工程中来。我们知道需求是客户的真实需要，而没有客户也自然不会有需求，当然没有项目自然就不存在客户。当然有些产品的开发虽然没有确定的真实客户，可是还是存在着假想的目标客户。而我这里所说的，恰恰是在业务建模的有些时候，特别是项目前的最初阶段，你不应该确定 你需要满足的个别人群，而是要阐述在业务场景中所有涉及到的群体。
同时这里作者的一个观点我是同意的，就是有些时候需求不清楚，是由于如何实现需求不被我们理解。但是问题在于具体的业务实现是不可能被你提前完全的解释的。你只能在现实的环境中去针对性的达成业务过程。而实际上解决这个问题工具就是我前面提到的分析模型和业务规则库。你要作的是依照客户的实际情况，对于分析模型进行裁减，再比对规则库进行建立现实化的需求模型。
比如我们要设计一个会计程序，我们会发现其分析模型是再中外都基本一致的。但是由于国内外的政策和法律等方面的原因，规则会不同。那么这个时候你要作的是同时维护两个基于业务过程的模型，还是维护一个分析模型和一套包括中外不同国家的会计领域的规则库呢？而同时我们还知道，由于法律和社会习惯的原因，规则是会发生变化的，那么是不是你的那个基于业务流程的模型也需要不断的随之全面性的变化呢？而不是向你实现分析模型和规则库的分离。同时我们还要考虑到规则的变化很少会发生全面的变化，那么维护一个规则库实际上就只是在环境变化时，去修改个别的规则。
同时作者最后还犯了一个根本性的错误，认为对于业务不了解就不能建模。他看来完全的忽略了建模的一个目的就是去了解业务，或者说了解业务就是从建模开始的。


看来作者还是不能跳出瀑布的思维方式，依然认为在直线的思维中转圈。


这里作者证实了他吧业务也划分为需求的领域的观点。而这一点是我这个点评所最需要批判的。


而这里作者又说要把业务从需求中分离出来，显然他还没有真正的考虑明白他到底应该作什么。同时他还忽略了，很多功能是跨越多个业务过程的，或者为多个业务过程所涉及的。同时对于功能的组织也非入作者暗示的那样只是需要业务的指导，还要考虑到其他非常多的因素，比如硬件环境，软件环境，人力资源环境等等。同时很多时候既便开发者没有业务的概念，也不是 不能设计出合乎业务的功能，同时也不是就不能对用户下一个需要应该的功能作出指示。而往往是用户的功能被他们的需求完全的锁定，而不能考虑到会发生的变化，以及可能的其他选择。这一点也是其从根本上还是不能看到他的所谓的业务模型没有解决他要解决问题的能力。


作者在这里还是在犯把业务分析过程和需求分析过程混淆的毛病。
同时一个问题他不知道是理解错误，还是他没有提及。实际上需求建模就是需求分析的过程，分析的目标就是建立一个模型，而这么模型的主要目标不是为了需求分析的更清楚，而是为了使下一个开发阶段的工作能更好的理解需求，并且按照这个模型建立程序。无论从瀑布的观点和迭代的角度，这一点都一样。而只有分析模型和规则库才是为了使你能更好的分析需求。



作者不断的提醒大家不能把业务建模和需求分析混在一起，可是他自己就完全的不能区分开两者的关系，这一点非常值得我们思考。而在这里他又为业务主角和业务角色的纠缠不清，其实根本问题在于他过早的引入了业务用例的。实际上如我在前面强调的业务分析，或者领域分析所使用的技术是明显对象的分析，和基于规则的分析，得到的工件是分析模型（类型图）和规则库。这一点是那些顽固的坚持在RUP的圈子里面，而不是运用RUP的思想去分析问题的人的通病。
同时作者在这里还涉及到了系统在业务过程中的地位，他在这里也有所偏差，我会在以后介绍业务用例中系统的地位。

这里显然作者还是在说用例，而恰恰是他还不能理解用例的一些基本的概念。任何的角色必须具体到个别而具体的人，这是常识性的错误。

为什么作者在我的分析中犯了众多的基本错误呢？我认为这大概就是目前很多人习惯性的受到瀑布思维方式的影响。而还有一个原因，就是这些人往往是自学成才，而又不能去理解新方法的意图。他们过于追求形式的相似，而不是思想的统一。

领域分析应该是独立于需求工程的单独部分，应该使用面向对象的方式和基于规则的方法，提交的领域分析模型和规则库。这两个工件是独立于项目的，并且不断的被维护和积累的。是公司在一个行业中的核心资产。

1.瀑布思维没什么不好,至少在某些地方很适用.
2.可能接触的行业不同,你说"接触了领域的时候就产生"中的领域具体是个什么概念?"产生"又是怎么产生的?
需求都没搞清楚,客户想要什么都不知道就建模有点本末倒置.

请举出一个适应瀑布模型的例子。

我已经阐述的恨明确了，就是你还没开始你的所谓项目的时候。也许那个时候你的项目还根本就没有，也许你们的公司只是希望到某个领域发展。

建模的一个目的就是希望把模型所反映的问题进行理解和研究，如果你已经很明确的搞清楚了需求，那么这个时候你对于需求的建模在需求本身来说已经意义不大。不要为建模而建模，那样毫无任何意义。