5.5　关于建模原则的探讨

目前主流的软件设计方法其实都是模型驱动开发（Model Driven Development，MDD）形态的，无非是建模工具、建模方法的差异。那么我们如何更好地掌握业务建模方法呢？本节我们来探讨这个问题。

5.5.1　建模原则

既然业务模型对业务架构、系统设计如此重要，那么建模是否存在什么“秘籍”呢？很遗憾，没有。这不仅是笔者个人的理解，不少关于建模的书中也都提到过，建模看似有很多种方法、标准可以遵循，但是模型质量与建模者的经验息息相关。

虽然建模没有捷径，但还是有两个原则需要读者时刻注意。

1.整体性原则

做模型切忌快速上手，不要轻易被业务细节吸引，更不要被立刻解决问题的冲动所左右，一定要将问题域（或者说建模对象）通盘考虑清楚，先了解问题的整体轮廓，再考虑局部设计。在管理课上，老师讲沟通时经常会举一个“做飞机”的例子：先将听课的学员分成若干组，每组设计飞机的不同部分，比如机首、机身、机翼、机尾，而不给出整体要求，也不允许组间沟通，最后将各组的设计拼接起来，很可能会看到如图5-8所示的这种结果。

图5-8　拼不上的大飞机

没有整体性原则做指导，就会做出不仅飞不起来，而且还极其“丑陋”的飞机。企业中常见的“竖井式”开发也会遇到这样的情况，每个子系统独立工作时都很正常，却无法协作，因为这种设计不符合整体性原则。

2.合适性原则

“将世界上最美的五官凑在一起，并不会成为世界上最美丽的脸”，这就是合适性原则。如图5-9所示，美丽的脸通常指的是五官比例合适的脸，也就是说，模型中所包含的各个部分、各类元素要有机地结合在一起，而不能在设计时为了图新潮、赶时髦，甚至为了建模者个人的“执念”，放大需求、胡思乱想、生搬硬套，只进行“理想”的实现，而不进行“合适”的实现，漠视客观现实和循序渐进而导致设计结果“无用”。

图5-9　五官比例合适更重要

业务模型是为业务架构服务的，所以细心的读者也一定注意到了，这两条原则其实也包含在企业架构设计的重要原则中：全面和结构化。唯有不断练习，不断参与项目实践，获得对建模成果的重要反馈，建模能力才能有所提高。我们经常将不重视实现结果的架构师称为“PPT架构师”，其实建模也是一样，若不能在开发过程中得到反馈，那么建模者也会成为“PPT模型师”。实践是理论之源。

5.5.2　如何权衡建模方法的切换

业务架构的任务是搭建业务与技术之间的桥梁，所以作为业务架构在结构化表达方面不可或缺的工具，业务模型必须同时照顾业务与技术双方的感受，也即表达能力丰富、兼具业务和技术友好性的建模方法对业务架构而言更为合适。如果企业在以往的技术实现中已经习惯于采用某种建模方法，犹豫是否要进行模型方法层面的大调整，则要考虑如下因素。

1）是否可以对原有方法进行改造以弥补缺陷。如果原来的方法太过面向技术端，那么能否增加一些更适合面向业务端的展现方式？如果对改造效果的评估或者试验不乐观，那么还是建议切换建模方法。

2）原有的模型成果是否还有复用的价值。如果企业决心进行大规模转型，那么原有的模型成果除了提供初期分析的信息输入之外，复用可能性就很小了，此时就可以没有顾忌地切换建模方法了。

5.5.3　如何更广泛地应用建模思维

做过建模的人都能理解，认真建模是一件既枯燥又烦琐的事情。前文也曾提到过，业务架构设计可以帮助业务人员提升逻辑思维能力，应该让业务人员多参加。那么对于广大业务人员而言，投入这么大的精力参与这么枯燥的工作，项目完结之后，这些技能还能用得上吗？答案是肯定的，模型思维将终身受用。

笔者总结出的，在各类工作中都值得借鉴的模型思维有如下3点。

1.把握整体

把握整体的重要性，这里不再赘述。其应用场景很多，比如，对于领导交待的任何工作，尽可能不要第一时间就去执行，而是要先抽出点时间考虑事情的来龙去脉、前因后果，这样才能把握好工作的度，以免过犹不及。时间和人力是企业最宝贵的资源，不是所有事情都值得投入最大的精力去追求满分效果，而是要从整体着眼来评价工作事项，尽量杜绝过度“敬业”导致的时间和人力的浪费。

2.穿透现象

露出水面的往往只是冰山一角，能够透过现象看本质是对建模人员的基本要求。这种注意事物内在联系、本质差别的能力，有助于读者拨开笼罩在现象表面的“迷雾”，找到解决问题的最佳方案。这种思维方式在任何工作中都是可以用得上的，多进行建模工作也许能提升这种能力。

3.实现为王

架构不能只是停留在口头或纸面上，真正了解架构本质的人，无论做出什么样的设计方案，都会以落地实施为前提。虽然很多人会觉得企业架构设计过于宏大，但是“宏大”并非架构设计的目的，正如Zachman框架揭示的那样，架构的“宏大”是为了更好地识别架构元素之间的联系，从而提升架构决策的科学性，这正是为了更好地落地架构设计。对应到日常工作中，就是不要害怕提出宏大的工作建议，宏大是一种“远见”。但是不能只是空谈，而要为其实现负责。

本书关于模型的一些基础介绍先到此为止。书中所讲的业务架构都是使用业务模型来构建的。虽然业务架构与模型之间关系紧密，但是必须明白的是，架构不等同于模型，模型也不等同于架构，不要将二者简单合并为一。架构相当于思想，模型则是思想的表达。实践中如果遇到问题，一定要先想清楚原因，不要因为模型表达方式不理想而认为架构无用，也不要因为架构设计不理想而埋怨模型方法。如果觉得哪个不妥，要具备自己动手改良的能力和精神。

除了用于表达业务架构的业务模型之外，应用架构会用到应用分层、服务模型，技术架构会用到技术分层、组件关系等，这些都属于模型化的表达，可以说，整个企业架构就是一个模型体系。结合4.1节中对架构观的介绍，笔者认为，企业架构就是努力用“结构-关系-原则”这一基础视角，形成对企业认知的一组互相连接的架构观点体系（包括业务视角、应用视角、技术视角、治理视角等），并将其以模型的方式最终表达出来，如图5-10所示。

图5-10　模型化的多视角企业架构