架構的意義

模型可以是各種材質做的，例如木頭、黏土、紙張、樂高積木、電子元件、數位檔案。你需要根據建模的參考對象和建模的目的來決定哪個材質最適合。

這個專欄最關心的是模型是「商業模型」和「軟體模型」，它們都是非常適合數位化建模的，而「數位化」形式具有最大的方便性，容易傳輸、容易複製、成本低、還具有未來各種可能性。現在能夠數位化，下一步就有機會自動化，再下一步就有機會智慧化。數位化的好處這麼多，我們當然用數位化形式來做我們的商業模型和軟體模型，而不是用木頭。

數位形式還有一個好處，保存方式和展示方式可以分開，一個數位保存的模型可以有多種不同的展示方式，例如財務模型可以用圓餅圖、條狀圖、表格分別從不同的觀察角度做展示。模型展現出來才能夠讓人們容易理解模型的現狀，在看到模型的現狀後進一步繼續對模型做某些操作，例如新增、刪除、修改、查詢。而模型的操作方式，可能和模型的展示方式有關。例如模型是以百分比刻度尺的方式存在，那麼調整百分比值的方式或許可以透過拖曳刻度游標的位置來做到。

如果你寫過程式，或許你已經發現，上面這段文字說的就是MVC的設計精神。MVC是Model/View/Controller的縮寫：Model是資料模型，View是展示方式，Controller（控制器）是操作方式。設計良好的軟件系統內部最好能夠把MVC三者區分開。

根據使用方式，模型可以分為二種：資料模型、程式碼模型。資料模型的建模對象通常是真實世界的事物，且資料模型在執行的過程中會不斷進行基本的新增、刪除、修改，導致模型持續的變化。程式碼模型的建模對象通常是開發者腦中的想法（演算法），程式碼模型可以被執行，且通常會關聯到其他的資料模型。正常來說，程式碼模型在執行的過程中不會改變自己的程式碼模型，但可能會改變關聯的資料模型。

模型是如何產生的，一種是我們親自建立的，例如程式碼模型；另一種是運作的過程中長時間逐漸累積建立的，例如資料模型。資料模型需要先建立（定義）一些抽象後的類型，這些類型和相關的限制規則集合起來統稱 Schema。前一篇文章我們提到的 Schema.org 名字就是這麼來的。

程式設計和技術架構設計都是在人為地、手動地建立模型，只是程式設計和技術架構設計的目的不同，而且建模的對象也不同。簡單來說，程序設計是為「功能需求」建模，技術架構設計是為「非功能需求」建模。功能需求例如：支援購物車，可以把選購的東西紀錄在裡面，以後才結帳。非功能需求例如：雙十一期間，支持最高峰一秒鐘有十萬人同時上線，系統可用率達到99.95%。

業務架構師也需要建模，建立商業模型。業務架構師建模的目的是為了「分析」業務需求本身。太多公司胡亂地決定要做哪些業務，沒有系統性地思考（也不知道該如何系統性地思考），導致資源的錯誤配置，這往往是企業內許多問題的根源。完整的商業模型分析是非常複雜的。在這個專欄中，我會介紹一個我的商業建模方法，一個很系統化的方法。

業務架構師去瞭解產品、技術、組織結構、資源、用戶、市場、競爭對手後，建立了一個完整的商業模型（Business Model），再決定要做哪些業務，並且把目標也清楚地定義在這個商業模型中，這使得我們對於未來前進的方向有了一個藍圖。根據這個商業模型的規劃，在適當的時間提出適當的需求，技術架構師和程式設計師分別去實現非功能需求和功能需求，組織架構也相應做出調整，避免成為業務和技術的絆腳石。在這個變化快速的時代，通過各種規劃和設計，盡可能地降低風險，這就是架構的意義。