▼
一直以来，在软件行业，对于什么是架构，都有很多的争论，每个人都有自己的理解。甚至于很多架构师一说架构，就开始谈论什么应用架构、硬件架构、数据架构等等。我曾经也到处寻找过架构的定义，请教过很多人，结果发现，没有大家都认可的定义。套用一句关于big data流行的笑话，放在架构上也适用：
Architecture is like teenage sex，everybody talks about it，nobody really knows what is it。
事实上，架构在软件发明时的N多年以前，就已经存在了，这个词最早是跟随着建筑出现的。所以，我觉得有必要从源头开始，把架构这个概念先讨论清楚，只有这样，软件行业架构的讨论才有意义。
▊什么是业务架构？
先让我们试图澄清一下概念的内涵与外延。OMG 的业务架构工作组（BAWG）给了如下定义：
业务架构是企业治理结构、商业能力与价值流的正式蓝图。
业务架构明确定义企业的治理结构、业务能力、业务流程、业务数据。其中，业务能力定义企业做什么，业务流程定义企业怎么做。
一般地，我们谈及的架构大都是面向软件系统自身的，指的是软件系统自身的体系结构以及实现的流程与方法。业务架构虽然与软件系统自身有着紧密的联系，但更多指的是企业架构的一部分，是面向企业或组织的。
也就是说，软件架构和业务架构的核心关注点不同，业务架构是为企业的整体目标服务的，由企业战略所驱动。
▊业务架构&TOGAF
1995年，TOGAF这个在企业架构市场中据说占了半壁江山的架构模型明确提出了业务架构的概念。
TOGAF将企业定义为有着共同目标集合的组织的聚集，强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键是基于架构体系的集成，而不是基于组件的集成。
完整的TOGAF，是以ADM 为核心的一系列方法和工具的集合。
我们也常把“方法和工具的集合”叫做架构框架——即Architecture Framework，AF。
这里的ADM 就是架构开发方法，是Architecture Development Method 的缩写，是创造TOGAF的专家们网罗了业界大量最佳实践构建的一个闭环的、迭代化的架构设计/实现/维护过程。
▊业务架构是从战略到实施过渡的桥梁
企业架构（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方案规划者都要懂业务架构的要求。
规划侧变革，未来还有很长的路要走。毕竟，相对而言，技术变革易、思维变革难。让我们拭目以待。
👇👇👇
