架构的意义

模型可以是各种材质做的，例如木头、黏土、纸张、乐高积木、电子元件、数位档案。你需要根据建模的参考对象和建模的目的来决定哪个材质最适合。

这个专栏最关心的是模型是「商业模型」和「软体模型」，它们都是非常适合数位化建模的，而「数位化」形式具有最大的方便性，容易传输、容易複製、成本低、还具有未来各种可能性。现在能够数位化，下一步就有机会自动化，再下一步就有机会智慧化。数位化的好处这么多，我们当然用数位化形式来做我们的商业模型和软体模型，而不是用木头。

数位形式还有一个好处，保存方式和展示方式可以分开，一个数位保存的模型可以有多种不同的展示方式，例如财务模型可以用圆饼图、条状图、表格分别从不同的观察角度做展示。模型展现出来才能够让人们容易理解模型的现状，在看到模型的现状后进一步继续对模型做某些操作，例如新增、删除、修改、查询。而模型的操作方式，可能和模型的展示方式有关。例如模型是以百分比刻度尺的方式存在，那么调整百分比值的方式或许可以透过拖曳刻度游标的位置来做到。

如果你写过程式，或许你已经发现，上面这段文字说的就是MVC的设计精神。MVC是Model/View/Controller的缩写：Model是资料模型，View是展示方式，Controller（控制器）是操作方式。设计良好的软件系统内部最好能够把MVC三者区分开。

根据使用方式，模型可以分为二种：资料模型、程式码模型。资料模型的建模对象通常是真实世界的事物，且资料模型在执行的过程中会不断进行基本的新增、删除、修改，导致模型持续的变化。程式码模型的建模对象通常是开发者脑中的想法（演算法），程式码模型可以被执行，且通常会关联到其他的资料模型。正常来说，程式码模型在执行的过程中不会改变自己的程式码模型，但可能会改变关联的资料模型。

模型是如何产生的，一种是我们亲自建立的，例如程式码模型；另一种是运作的过程中长时间逐渐累积建立的，例如资料模型。资料模型需要先建立（定义）一些抽象后的类型，这些类型和相关的限制规则集合起来统称 Schema。前一篇文章我们提到的 Schema.org 名字就是这么来的。

程式设计和技术架构设计都是在人为地、手动地建立模型，只是程式设计和技术架构设计的目的不同，而且建模的对象也不同。简单来说，程序设计是为「功能需求」建模，技术架构设计是为「非功能需求」建模。功能需求例如：支援购物车，可以把选购的东西纪录在里面，以后才结帐。非功能需求例如：双十一期间，支持最高峰一秒钟有十万人同时上线，系统可用率达到99.95%。

业务架构师也需要建模，建立商业模型。业务架构师建模的目的是为了「分析」业务需求本身。太多公司胡乱地决定要做哪些业务，没有系统性地思考（也不知道该如何系统性地思考），导致资源的错误配置，这往往是企业内许多问题的根源。完整的商业模型分析是非常複杂的。在这个专栏中，我会介绍一个我的商业建模方法，一个很系统化的方法。

业务架构师去了解产品、技术、组织结构、资源、用户、市场、竞争对手后，建立了一个完整的商业模型（Business Model），再决定要做哪些业务，并且把目标也清楚地定义在这个商业模型中，这使得我们对于未来前进的方向有了一个蓝图。根据这个商业模型的规划，在适当的时间提出适当的需求，技术架构师和程式设计师分别去实现非功能需求和功能需求，组织架构也相应做出调整，避免成为业务和技术的绊脚石。在这个变化快速的时代，通过各种规划和设计，尽可能地降低风险，这就是架构的意义。