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

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

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

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

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

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

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

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

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

作者簡介


Advertisement

更多 iThome相關內容