企业架构设计之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