企業架構設計之IFW實踐回顧

前言

　　筆者幾年前曾參與過一套網絡銀行的系統建設以及後續這套系統在信用、雲服務、保險、基金、支付等領域的複用，使用了IFW模型的變體。當時僅僅是根據架構師的設計進行編碼、測試和交付以及後續的維護，沒有對這套模型進行系統化的總結，心中老是有點缺失。這麼多年過去，藉着在組內分享的機會，系統地整理一下這塊的知識，但願對之後的設計建模能有所幫助。
　　限於筆者水平，同時IFW模型其實是很是複雜（以致於對於專業的諮詢公司來講，這套模型的諮詢+分析+落地方案設計費用一般在百萬到千萬級別），短短的一篇博文僅僅是管中窺豹，並且因爲理解誤差也會有錯誤的之處，所以僅做參考。

簡介

　　IFW是IBM的Information FrameWork縮寫，旨在描述銀行業務，能夠看作領域內技術和業務溝通的橋樑。IFW是一套Zachman Framework的變體，後者最經典之處在於5W1H維度下對於6個概念的劃分：

　　這裏對於Zachman Framework不展開介紹，保持聚焦於IFW自己，其所應用的產品不少：

• IBM旗下Industry Models的一部分
• 銀行業與財務市場
  • IBM銀行業與金融市場業數據倉庫(IBM Banking and Financial Markets Data Warehouse，BFMDW)
  • IBM銀行業數據倉庫(IBM Banking Data Warehouse，BDW，是BFMDW的衍生產品，只和銀行有關)
  • IBM金融市場數據倉庫(IBM Financial Markets Data Warehouse，FMDW，一樣是BFMDW的衍生產品，只和金融市場有關)
  • IBM銀行處理服務模型(BPS)
• 保險業
  • IBM保險應用架構(IBM Insurance Application Architecture, IAA)
• 其餘
  • 保健
  • 電信
  • 零售

概覽

整個業務模型框架分爲如下幾個板塊：

• IFW基礎模型
  • 金融服務數據模型(FSDM)
  • 金融服務功能模型(FSFM)
  • 金融服務工做流模型(FSWM)
• 銀行數據倉庫
  • 業務解決方案模板
  • 銀行數據倉庫模型
• IFW集成模型
  • 金融服務業務對象模型
  • 金融服務接口設計模型
• IFW流程模型

　　其中「IFW基礎模型」如其命名，是基礎中的基礎。我的理解，「工做流模型」是指工做流中的各個實體，如節點、跳轉條件等，「流程模型」指的是抽象或具體的某個流程。

FSDM九大數據概念

　　IFW將金融信息分解爲九大數據概念，全部的金融業務中均可以套用到其中。具體的細節可能有差別，我一共參考了兩份資料，下面一共列了11項，其中前7項是公有的，
第8~9份是我所參與項目中使用的，10~11項是另外一份資料中的。其中「渠道」和「業務方向」有重合之處。
　　這部分是我實踐中接觸最多的地方，也是對建模最有幫助的。

概念	簡稱	說明	舉例
參與者	IP	業務往來、信息交互中關聯的各方	我的、機構、櫃員、平臺商、委託方、代理人
位置	LO	參與者相關的地址	家庭住址、公司地址、郵政郵箱、電子郵箱、網址
條件	CD	描述業務開展時須要的前提條件、資格標準、要求、限制、服務參數	需年滿18歲、利率、價格、週期
產品	PD	提供給客戶用以換取任何形式利潤或收益的產品和服務	活期存款、貨幣基金、人身險、實體商品
合約	AR	描述或兩個或兩我的、團體、組織等潛在或實際的協議，申明瞭權利或/和義務	服務協議、產品協議
資源項	RI	各參與者擁有、須要管理和使用的物品項	身份證、借條、房產、通行證
事件	EV	參與者之間、參與者與系統、系統與系統交互的行爲與數據	交易事件、存款事件、收費事件
帳戶	AC	記錄及監控貨幣及非貨幣(如積分等)數量變化的主體	存款帳戶、貸款帳戶、總帳帳戶、公積金帳戶
渠道	CH	多個參與者爲業務通信的通道	櫃面渠道、ATM渠道、網站門戶
分類	CL	數據分類或分組	前臺類目、後臺類目
業務方向	BD	開展業務所在的環境或方式	-

FSFM功能模型

　　包含了500多個銀行的業務功能，不過沒有詳細列出。舉例以下：

• 資源管理
  • 人力資源資源管理
  • 基礎設施資源管理
  • 信息資源管理
  • 金融資源管理
  • 信託資源管理
• 方向管理
  • 控制管理
  • 策略管理
  • 會計管理

IFW流程模型

　　本處指工做流模型+流程模板。模板特色是：

• 獨立於渠道
• 獨立於業務部門
• 獨立於產品線
• 獨立於特殊客戶羣
• 獨立於技術
• 獨立於已有系統或某個 ISV方案

做爲模板化的分析和抽象，咱們在設計中能夠參考這些指導建議。

領域裁剪

　　追求模型的大而全是不現實的，在特定業務主題下實際上只須要部分模型便可實現，如下是幾個例子。

產品管理

產品簽約管理

核心業務處理

客戶關係管理

實踐建議

基於技術選型的再設計

　　建模後限於技術選型的限制，模型可能並不能直接套用。好比DB不支持批量插入或性能不好、字段長度不支持等。這是一個很常見的邏輯模型轉換物理模型時遇到的問題，對於物理模型的組織和存儲，須要進行進一步的設計，固然也有可能影響到邏輯模型。

結構與數據分離

　　對於領域模型很是複雜的場景，建模的最初目的是理解業務和溝通，可能並無考慮到系統間交互的複雜度。在將物理存儲轉換爲邏輯模型時，組裝模型的接口可能會致使系統處理速度降低，特別是在大量信息須要作序列化/反序列化時。在實踐中咱們發現，對於外部只消費數據，不感知具體模型的結構，對吞吐量要求較高；對於內部信息管理，纔會感知到結構，但對吞吐量沒有太大要求。所以能夠考慮將結構和數據分開存儲，對外接口只須要透出數據便可。

緩存化

　　對於常常查詢的信息預先考慮緩存化處理。

能夠可是不必的複雜性

　　模型支持可擴展，但不意味着把全部的處理工做留給本身，建議在保持核心邏輯和原子能力的前提下作擴展，保持內部的高內聚性，減小對外圍邏輯的耦合。下文會提到，「沒有一套模型能解決全部的問題」。

SDK化

　　若是應用IFW的系統僅僅是一個公司SOA化架構中的一環，而非整個公司技術產品的共識，即便是一個核心應用，上下游來對接會很是痛苦——他們不得不理解這套複雜的概念。這裏建議採用共建的形式爲使用方提供SDK，屏蔽複雜的細節，僅僅提供給對方須要的信息和接口便可。

模型裁剪

　　與SDK化相反，若是僅僅關注系統內部流程，是不必徹底實現大而全的IFW的，只須要實現其中使用到的領域便可。

沒有銀彈

　　「沒有一套模型能解決全部的問題，若是強行去作，那麼會致使每一個模型都很是扭曲，這個是咱們在經歷了這麼多迭代後得出的血的教訓。」這是我原先所在團隊的架構師在這套模型多年實踐後總結出的心得。

爭議

　　建設成本與使用成本的權衡。

參考資料

IFW英文wiki：https://en.wikipedia.org/wiki/Information_Framework
Zachman Framework：https://en.wikipedia.org/wiki/Zachman_Framework
Industry Models產品官網：https://www.ibm.com/analytics/industry-models
IFW Overview：http://www.itpub.net/thread-1604106-1-1.html （直接註冊下就能夠下載，這裏有關於IFW的一些討論能夠借鑑）
治理和管理企業模型，第 1 部分：https://www.ibm.com/developerworks/cn/rational/09/0113_letkeman-norris/index.html