架构三问【2】：业务架构 将引我们走向何方
本文内容来自资深架构师曹洪伟老师的分享！
曹洪伟老师介绍：
（向下滑动查看）
一个全栈工匠
二本图书的合作译者
三次世界 500 强企业的从业经历
四家创业公司的实战
五篇铅字短文发表（增长中）
六次会议分享
七年时间在一个生态系统中打磨
八种编程语言的掌握
九项国内外专利（不包括21项还在审核中的专利）
十位作者之一（《深入分布式缓存》）
目前从事人工智能尤其是对话式AI系统的研发，任百度DuerOS 首席布道师，闲来维护CSDN博客和公众号：wireless_com
▼
“架构”一词，仿佛是“熟悉的陌生人”，系统架构、硬件架构、企业架构、缓存架构...... 林林总总， 某种技术只要加上“架构”一词，就好像变得“高大上”起来。
然而，讨论问题的基础应该是，澄清概念和明确问题的领域边界。随着所谓“中台”的兴起，业务架构被再次推到了前台，那么：
什么是业务架构？与软件架构有什么区别和联系？
业务架构在整个IT体系中处于怎样的位置？
业务架构发展的动向如何？将引我们走向何方？
▊ 什么是业务架构？
先让我们澄清一下概念的内涵与外延。OMG 的业务架构工作组（BAWG）给了如下定义：
A Business Architecture is a formal blueprint of governance structures,business semantics and value streams across the extended enterprise.
业务架构是企业治理结构、商业能力与价值流的正式蓝图。
It articulates the structure of an enterprise in terms of its capabilities, governance structure, business processes, and information. The business capability is what the organisation does, the business processes are how the organisation executes its capabilities.
业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义企业做什么，业务流程定义企业怎么做。
一般地，我们谈及的架构大都是面向软件系统自身的，指的是软件系统自身的体系结构以及实现的流程与方法。业务架构虽然与软件系统自身有着紧密的联系，但更多指的是企业架构的一部分，是面向企业或组织的。
也就是说，软件架构和业务架构的核心关注点不同，业务架构是为企业的整体目标服务的，由企业战略所驱动。
▊ 业务架构与TOGAF
在明确了领域边界之后，会发现“业务架构”这个词并不新，它隐藏在企业架构中。企业架构是上世纪 80 年代的产物，其标志就是 1987 年 Zachman 提出的企业架构模型，该模型按照“5W1H”，即 What（数据）、How（功能）、Where（网络）、Who（角色）、When（时间）、Why（动机）六个维度进行了设计，结合了目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统等六个层次。
进而在笔者大学毕业的那一年，TOGAF，这个在企业架构市场中据说占了半壁江山的架构模型明确提出了业务架构的概念。
TOGAF 将企业定义为有着共同目标集合的组织的聚集，强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键是基于架构体系的集成，而不是基于组件的集成。
完整的TOGAF，是以ADM 为核心的一系列方法和工具的集合。
我们也常把“方法和工具的集合”叫做架构框架，即Architecture Framework，AF。这里的ADM 就是架构开发方法Architecture Development Method 的缩写，是创造TOGAF的专家们网罗了业界大量最佳实践构建的一个闭环的、迭代化的架构设计/实现/维护过程。
TOGAF 9.2 原版的ADM 过程模型如下：
▊ 业务架构是从战略向实施过渡的桥梁
企业架构（Enterprise Architecture）包含如下四种架构，这是被广泛认同的：
业务架构：Business Architecture，BA
数据架构：Data Architecture，DA
应用架构：Applications Architecture，AA
技术架构：Technology Architecture，TA
目前，TOGAF 9.2 是企业架构实际上的标准，在全球有着广泛的实践。TOGAF 9.2 中的BA/DA/AA/TA 内容模型，如下图所示：
BA 属于现实世界，DA/AA/TA 都属于IT 世界。前者是后者的缘起，后者是前者的支撑, 模型可以简化为：
为什么干——战略目标、业务动机
干什么——业务功能、业务能力
谁来干——组织结构、业务角色
怎么干——业务流程、业务规则
用到的数据——业务数据
用到的应用——应用系统
用到的技术——技术设施
业务架构是由企业战略驱动的。业务架构发挥了从战略向实施过渡的作用，上接公司战略，下接IT与非IT实施。
战略是公司高层的设计，却是业务架构师的需求。业务架构师的工作是“战略进，业务架构出”，业务架构是BA 架构师的设计，却是DA/AA/TA 架构师的需求，环环相扣，上层驱动下层，下层支撑上层。
▊ 业务架构的发展趋势
早在2015 年Gartner 预测说：在2020-2025 年，大数据/DevOps/业务架构等技术都会进入成熟期。五年后的今天，我们看到了什么，又做到了什么呢？
如今，各行业赛道迭代加速、竞争加剧。蓝海是暂态，红海是常态，每一步领先都有时效期限。
运维侧，全球业界已普遍接受和频繁实施DevOps改革，打造开发-测试-部署-运维一体化的实践体系。
规划侧，以TOGAF等EA框架的全球流行、业务架构师岗位的日益普及、BizDevOps体系的提出等为标志，正经历着一场战略规划-IT规划-架构设计一体化（Integration）的大变革。
每个行业的参赛选手，拼IT、拼业务、更拼IT与业务的快速结合与创新。我们看到，各行业赛道竞争的核心是业务快速落地能力的比拼。
IT与业务快速结合与创新的最大障碍不是IT技术，而是：1）业务理解的速度与质量、2）业务诉求向IT方案转化的速度与质量。
因此，本文认为业务架构的发展方向将是：业务架构日益成为规划侧各个环节的基础技能，使能“战略快速落实到架构”、“业务快速落实到IT”。
业界正在发生的运维侧变革，带来了架构师懂运维、程序员懂运维、测试懂运维、运维懂运维的要求。规划侧变革也将带来业务战略规划者、IT战略规划者、IT方案规划者都要懂业务架构的要求。
规划侧变革，未来还有很长的路要走。毕竟，相对而言，技术变革易、思维变革难。让我们拭目以待。
▊ 后记
笔者和温昱相识十数年，他的《软件架构设计》、《一线架构师实践指南》以及译作《SQL语言的艺术》《应用框架的设计与实现》等书帮助了大量的程序员。更为难得的是，他一直专注于系统架构这一领域，《业务架构·应用架构·数据架构实战》更是多年实践水到渠成之作，这本书为业务架构及企业架构的具体实践，带来了诸多真知灼见和实践探索。
▊《业务架构·应用架构·数据架构实战》
温昱 著
每一页都是实践经验的总结，参考性超强
每一页都简洁明了重点突出，可读性超强
大局＋架构＋文档，三大篇，操作性超强
本书思路清晰，每一个概念、每一项方法都给出了简要透彻的阐述。同时又结合实践，给读者看得见、摸得着的项目实感，帮助读者迅速上手。本书还有一个作用，就是能提升读者对IT及其业务的认知层次，为长远职业发展提供助力。
（扫码了解本书详情）
如果喜欢本文 欢迎 在看丨留言丨分享至朋友圈 三连 热文推荐
▼点击阅读原文，获取本书详情~