业务架构
是跨系统的业务架构蓝图，
应用架构、数据架构、技术架构
是解决方案的不同方面。
多年来，全球业界已在业务架构、应用架构、数据架构、技术架构方面积累了大量经验。
近几年，数字化转型呼唤“懂行人”
打通四种架构
，确保技术支撑业务、业务支撑战略。
本文就带大家来厘清这几种架构之间的脉络关系。
其中，文中涉及的缩写全称如下。
-
BA
：Business Architecture，业务架构
-
DA：Data Architecture，数据架构
-
AA：Applications Architecture，应用架构
-
TA：Technology Architecture，技术架构
以下内容节选自
《
业务架构 应用架构 数据架构 实战
》
一书！
▼扫码获取本书详情▼
▊
战略、BA、DA、AA、TA五者的关系
现在，我们来总览一下战略、BA、DA、AA、TA五者之间的边界与关系。如下图所示。
首先，公司管理层是战略的提出者和总设计师。
例如，一家大银行的全局战略规划出自何处？
答
：管理层是规划者，规划发展部是协助者。规划发展部持续研究行业政策方向、持续关注宏观环境变化、持续跟踪友商发力动向。
其次，业务架构师是业务架构蓝图的设计师和描述者。
例如，一个在银行的信息科技部工作的业务架构师。要研究战略、领会战略，把战略作为推动业务架构设计的原动力，定义出详细的业务架构蓝图。
最后，解决方案由专业分工更细的数据架构师、应用架构师、技术架构师负责。
例如，银行的信息科技部一般有架构办公室，部门中有专职或兼任的数据架构师、应用架构师、技术架构师，还要有专门的安全架构师。
所以，战略、BA、DA、AA、TA这五者，实际位于以下三个层次上：
公司战略；
业务架构；
方案架构。
这五者的核心关系，概括为以下几点：
战略是公司高层的设计，却是业务架构师的需求；
业务架构师的工作是“战略进，业务架构出”；
业务架构是业务架构师的设计，却是数据、应用、技术架构师的需求；
环环相扣，上层驱动下层，下层支撑上层。
▊
BA、DA、AA、TA的实际工作内容
承接上文，公司战略层——业务架构层——方案架构层，三层大局已定。
那么，
战略、BA、DA、AA、TA这五项工作，具体的内容有哪些呢？
例如，确定战略驱动因素（Driver）之后，业务架构师应做哪些分析？
例如，组织结构分析在哪里？应用项目划分在哪里？技术选型在哪里？
下图总结了BA、DA、AA、TA的实际内容。
1. 公司战略层。战略是业务架构设计的驱动力。
眼尖的朋友从上图中可以看出：战略规划需要广泛的外部分析、内部分析、基于SWOT的战略决策分析、最终制定出产品战略、服务战略、合作战略、渠道战略、市场战略、竞争战略等方面的具体方针。
2. 业务架构层。业务架构蓝图必须有企业标准，笔者推荐给企业的标准是5要素。
组织结构+业务功能+业务流程，这是经典的“老三样”，对应于“谁”“干什么”“怎么干”，符合国内老一代信息科技老总们的口味。
在业务架构蓝图中，应加上商业模式。九个格子的商业模式画布，比较新，有用且好用。我们后续再讲。
在业务架构蓝图中，应加上业务数据。
有利因素是，业务数据和业务功能、业务流程紧密相关，也属同一思维层次。不利因素是，有人争辩业务数据应属于数据架构。我看中的是有利因素，照顾的实践是：业务架构师的工作产物《业务架构书》要包含业务数据才完整。
3. 方案架构层。涉及数据架构、应用架构、技术架构。
数据架构的核心
是数据类型和来源。
例如，一家电商企业要把员工角色数据、员工操作日志、商品数据、订单数据、用户登录记录、用户搜索记录、用户评价记录、用户投诉记录等多种要管理的数据类型识别出来，才能有针对性地设计数据模型、数据存储与分布、数据流等。数据流是场景化的，业务功能不同，相关的数据流可能不同。数据流又常涉及数据产生、数据使用、数据加工、数据存储等。
应用架构的核心
是识别出应用功能，并映射到应用项目。
技术架构的核心
是识别出技术需求并映射到技术选型。笔者推荐的技术架构5要素包括：
技术需求——技术服务列表，或结构化地画出技术参考架构、技术栈。
技术选型——技术平台、技术产品、技术框架、中间件。
物理选型——硬件选型、网络选型。
分布设计——部署结构、负载均衡。
选型管理——面向行业的技术指标、企业中长期的技术选型标准。
▊
从战略到架构，再到实施的实际过程
1. 从战略到架构
首先，看看战略、BA、DA、AA、TA五个环节对应的岗位和产物，如下图所示。
例如，银行、保险、证券等企业，都有自己的信息科技部，鲜有例外。架构办公室这个部门，是CIO的左右手。架构办有专职或兼任的业务架构师、数据架构师、应用架构师、技术架构师，还有专门的安全架构师。
业务架构师负责设计业务架构，内容包括业务功能、业务流程、商业模式、组织结构和业务数据等。业务架构师的输出，有的企业叫《业务架构书》，有的企业叫《业务需求书》。
业务架构师的输出，是数据、应用、技术架构师的输入。最典型的例子就是业务流程。BA架构师设计业务流程，数据、应用、技术架构师思考完成业务流程需要的数据支撑、系统协作、技术平台。
2. 从架构到实施
下面，重点看架构路线图环节和实施规划环节。如下图所示。
要点是钉到岗位，落到文档，细到机构调整、技术采购、项目研发等工作包。
环节1：战略。
公司管理层牵头、规划发展部全程支持。产出物：《xx-xx年战略规划书》。
环节2：业务架构。
信息科技部的架构师团队的业务架构师负责。产出物：《业务架构书》。
环节3：方案架构。
信息科技部的架构师团队负责。产出物：《技术方案书》。
环节4：架构路线图。
涉及预算，CIO牵头制定、董事会批准。产出物：架构路线图。
环节5：实施规划。
CIO牵头制定。产出物：实施计划。
环节6：项目管控。
采取研发的项目由PMO负责，采取购买的项目由总经理办公室（总经办）负责。
▊
业务驱动——小试业务流程驱动的DA、AA、TA设计
0. 案例背景
前文，我们弄清了BA、DA、AA、TA间的脉络关系，但太粗。
在此，我们“细看”业务流程在BA、DA、AA、TA间“穿针引线”的过程。总体而言：
在BA设计环节——业务流程被详细定义
在DA、AA、TA设计环节——业务流程是设计的驱动因素
本节的例子，仅围绕“买入股票”示范从业务流程到应用程序，又到数据实体，再到技术组件这条主线设计。
1. 业务架构
作为示例，笔者简单画一下“买入股票”的业务流程图。
用Archimate语言建模，如下图所示。
业务功能——买入股票。
业务流程——由买入挂单、规则检查、上报给交易所等步骤组成。
实现关系——业务流程到业务功能的箭头。
业务数据——买入申报指令。
业务事件——图中“交易所回报”事件会触发券商“处理成交结果”，当收市时，“当日收市”事件也会触发相应业务处理。可见，用好业务事件，有利于把“条件触发的业务场景”表达清楚。
2. 应用架构
应用架构师应思考：
买入股票业务流程需要哪些应用服务支持呢？
1）
业务流程一级的买入挂单、规则检查、上报给交易所、处理成交结果，需要IT应用服务支持，分别为挂单录入、规则检查、委托上报、接收回报、结果显示。
2）
进一步地，这些IT应用服务要由具体的应用系统来实现，分别为券商App、券商集中交易系统。如下图所示。
3. 数据架构
数据架构师应思考：
买入股票业务流程需要哪些数据支持呢？
1）
券商的集中交易系统作为后台，首先要将委托记录排队，以备异步处理。
2）
券商App不保存“投资人账户”信息，但交易后台要保存，由证券经纪业务后台做交易规则检查。
3）
由证券经纪业务后台负责的交易规则检查，会用到投资人账户和投资人资产等数据信息，例如，账户余额不足时是不允许挂单成功的。
4）
后台存储“回报记录”数据，也是为了异步处理。如下图所示。
4. 技术架构
技术架构师应思考：
买入股票业务流程需要哪些技术组件支持呢？
1）
挂单录入、结果显示等技术，由客户端应用程序支持。
2）
规则检查、委托上报和接收回报是可重用的应用功能，可考虑实现成服务或微服务。
3）
基础设施的技术选型，由技术架构师决定。如下图1-8所示。
▊总结
本文重点 “理清BA、DA、AA、TA间的逻辑关系”，如下图所示。
正向逻辑：战略决定业务，业务决定技术。
反向逻辑：技术支撑业务，业务支撑战略。
▼
想要了解更多具体案例和实战方法，可阅读《业务架构 应用架构 数据架构 实战》一书。
▊《
业务架构 应用架构 数据架构 实战
》
温昱 著
-
每一页都是实践经验的总结，参考性超强
-
每一页都简洁明了重点突出，可读性超强
-
大局＋架构＋文档，三大篇，操作性超强
本书思路清晰，每一个概念、每一项方法都给出了简要透彻的阐述。同时又结合实践，给读者看得见、摸得着的项目实感，帮助读者迅速上手。本书还有一个作用，就是能提升读者对IT及其业务的认知层次，为长远职业发展提供助力。