前言
笔者几年前曾参与过一套网络银行的系统建设以及后续这套系统在信用、云服务、保险、基金、支付等领域的复用，使用了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项是公有的，
第89份是我所参与项目中使用的，1011项是另一份资料中的。其中“渠道”和“业务方向”有重合之处。
这部分是我实践中接触最多的地方，也是对建模最有帮助的。
| 概念 | 简称 | 说明 | 举例 |
|---|---|---|---|
| 参与者 | 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