荐书丨企业业务架构的发展及与IT架构的关系

架构君：本文来自《企业级业务架构设计：方法论与实践》一书，作者为付晓岩，本书专注于企业级的业务架构，公众号「架构文摘」获得机械工业出版社华章分社的授权，刊载其中的部分章节——企业业务架构的发展及与IT架构的关系，内容仅发布在本公众号，社区网站等平台不得在未经授权的情况下，以任何形式转载此文。

由于本书还未正式上市，如果你想了解本书目录和尝鲜读电子版，可以扫描文末二维码。

业务架构并非软件工程中新诞生的领域，但是提及的人却很少。这个偶尔走进读者视线的词汇，经常带着一种“花非花、雾非雾”的“朦胧感”，很多人对业务架构究竟在软件设计中发挥了什么作用、有什么好处，以及业务架构和应用架构的关系、业务架构师和产品经理的区别等基本问题说不清、道不明。《软件工程》、《软件系统架构》、《系统分析与设计》等大家耳熟能详的经典教材也很少提及业务架构这个概念，更不用说企业级业务架构了，目前市面上也几乎没有专门论述业务架构及其设计方法的书籍。本书作为一本企业级业务架构专述，将从业务架构的发展历程、基本理念讲起，让读者对业务架构有一个基本的了解。

第1章 业务架构的发展历程

与软件的发展历史相比，业务架构的发展历程其实并不算短，而且也是有几个颇具影响力的架构设计理论。

1.1　Zachman模型

业务架构这个词最初是隐藏在企业架构（ Enterprise Architecture， EA）中的。 企业架构是 20世纪 80年代的产物，其标志就是 1987年 Zachman提出的企业架构模型，该模型按照“5W1H”，即 What（数据）、 Where（网络）、Who（角色）、When（时间）、Why（动机）、How（功能） 6个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统这 6个层次，将企业架构分成 36个组成部分，描述了一个完整的企业架构需要考虑的内容，如表 1-1所示。

表1-1　Zachman模型简介

Zachman模型虽然没有明确提出业务架构这个概念，但是已经包含了业务架构关注的一些主要内容：如流程模型、数据、角色组织等，既然没有提出业务架构的概念，自然也就没有包含构建方法，所以， Zachman模型应该算是业务架构的启蒙，同时，它也表明了这一工具或技术的最佳使用场景—面向复杂系统构建企业架构。
1.2　TOGAF 

1995年，大名鼎鼎的 TOGAF登场了，这个在企业架构市场中占据了半壁江山的架构模型明确提出了业务架构的概念。 TOGAF将企业定义为有着共同目标集合的组织的聚集。
例如，企业可能是政府部门、一个完整的公司、公司部门、单个处 /科室，或者是通过共同拥有权连接在一起的地理上疏远的组织链。 TOGAF进一步定义企业架构分为两大部分： 业务架构和 IT架构，大部分企业架构方法都是从 IT架构发展而来的。 业务架构是将企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，其包括业务的运营模式、流程体系、组织结构、地域分布等内容。  
TOGAF强调基于业务导向和驱动的架构来理解、分析、设计、构建、集成、扩展、运行和管理信息系统，复杂系统集成的关键，是基于架构（或体系）的集成，而不是基于部件（或组件）的集成。 TOGAF还提供了一个详细的架构工件模型，如表 1-2所示。
从表 1-2中可以明确看到业务架构阶段的交付物，这些内容也清楚地说明了业务架构在软件工程中的位置。 相信很多对架构有兴趣的读者都认真学习过 TOGAF模型，此处不再赘述。
表 1-2　TOGAF9交付物：目录、矩阵、图

1.3　FEA和 DODAF

在 TOGAF之后，又先后诞生了 FEA（联邦企业架构）和 DODAF （美国国防部体系架构框架）。 前者的体系由 5个参考模型组成： 绩效参考模型（PRM）、业务参考模型（BRM）、服务构件参考模型（FRM）、数据参考模型（ DRM）和技术参考模型（ TRM），该方法应用于美国电子政务领域，着眼于跨部门、跨机构提升业务效率，解决重复建设、信息孤岛等问题，相当具有“企业级”理念； 虽然没有明确的业务架构定义，但是很好地应用了业务架构的思维。 后者体系比较复杂，共有 8个视点 52个模型，但是实用性不错，据说美国国防部和一些相关企业都在使用，详细内容如表 1-3所示。
表1- 3　DODAF的核心—8个视点与 52个模型
表 1-3中能力视点和作战视点就是我们做企业架构时通常关注的业务部分。 这两个模型在网上都有相关资料，感兴趣的读者可以自行查阅。
1.4　沉吟至今
通过寻根溯源我们可以发现，即便是从 TOGAF算起，业务架构这个词也有 20多年的历史了，但是在开发人员中，业务架构显然没有需求分析的概念明确，业务架构师也远不如产品经理常见。 笔者曾就职的单位曾经实施了一个长达数年的、以企业级业务架构驱动的转型项目，但是很多企业并没有这样的经历，因此，每当与技术人员讨论至此，他们就会觉得业务架构有点儿虚，细究可能有如下几点原因。

• 用得少

原有的单体式或竖井式开发依然是企业更常采用的项目构建方法，而这种开发基本上没有横向视角，所以无需强调业务架构，通常的产品分析或者需求分析即足以满足其开发需要。

• 难设计

业务架构，特别是大型企业这种错综复杂的业务架构，说起来容易做起来难。 业务架构对战略的分解、业务架构自身的整合与标准化，到 IT设计的过渡都存在不少陷阱，业务越复杂宽泛就越难驾驭。 因此，即便是尝试过业务架构设计的企业，也有不少是将业务架构设计保持在高阶状态，让做过的人自己都觉得有点儿没底气。

• 易偏离

施工期间由于客观因素可能会导致实施对业务架构的偏离，这种偏离如果没有得到及时纠正或架构调整，那么累积久了就会造成业务架构的失真。

• 难维护

少数度过了业务架构落地困难期的企业，也会由于感受到维护架构的难度而心生放弃，从而降低了对业务架构的评价。
1.5　业务架构的定义
业务架构从诞生之初就很清楚地定义了自己的使命： 面向复杂系统构建。 也就是说，业务架构与其他架构一样，其目的也是要降低复杂度，从更好地规划和实现系统，因此 TOGAF将业务架构归属于 IT战略部分。 但是从笔者的实践经验来看，业务架构更突出的特点是影响了参加过企业级业务架构设计工作的业务人员，他们的逻辑思维能力、结构化能力、企业级观念和意识都发生了明显的改变，所以，应当将业务架构从 IT战略中独立出来，更多地面向业务人员，以充当业务与技术之间的桥梁。 当然，业务架构要想真正承担起这一职责，还需要改进、简化业务架构设计的方法，对业务人员更友好，并且坚持使用业务架构方法做企业级需求管控，否则，“熵增”一定会将已经建好的架构秩序回归到混沌状态。
说到这里，本书也尝试为业务架构提供一个简单的定义： 以实现企业战略为目标，构建企业整体业务能力规划并将其传导给技术实现端的结构化企业能力分析方法。 业务架构就其方法本身而言，既可以用于单个产品线或业务种类的领域级分析，也可以用于跨越产品线、业务领域的企业级分析； 就价值而言，后一种显然对企业具有更高的价值，更值得企业去尝试、推广。 因此，本书如无特殊说明，使用“业务架构”一词时多是指“企业级业务架构”。 不同于一般基于业务诉求的需求分析或产品设计，业务架构的首要责任在于实现业务与技术的深度融合，在于打造能够让企业整体、尤其是业务与技术之间有效沟通的“通用语言”。
如今大热的“中台”概念，说到底也是一种业务架构设计结果，是对企业能力的一种规划，只不过阿里的实践代表的是自下而上的积累方式，而业务架构设计通常是自上而下的规划与演变。 如果认真回顾软件设计的发展历程，那么你一定可以发现，所谓的“中台”绝非是一种超越了“企业架构”这个概念的存在。 因此，若想要深入理解“中台”，那么多学习业务架构、软件架构的历史还是很有必要的。
第2章 业务架构的作用及与 IT架构的关系
2.1　业务架构的作用
业务架构的作用通常被认为是连接业务与 IT的纽带，用于实现业务需求到 IT的顺利传导，对于 TOGAF等企业架构理论来说，业务架构也承担着将企业战略落地的职责。 任何方法其实都有一定的时代性，除了上述一般意义上的作用之外，在通向“数字化”时代的进程中，业务架构的独特性在于帮助企业完成了深刻的“数字化”转型，使企业通过信息技术将内部、业务与 IT深刻地连接起来，成为高效的“数字化”企业。

• 传统行业中的先行者已经实现了“数字化”

有人说，未来的企业都是科技公司，虽然就目前来讲还为时尚 早，但是，科技已经极大地改变了很多传统行业。 读者都知道 BATJ（百度、阿里巴巴、腾讯、京东）是科技公司，其实星巴克也可以算是科技公司了。 美国的星巴克门店，将近 16%的收入是来自于其手机客户端； 星巴克自己的 App有近 1300万的活跃用户，星巴克内部已 经将网页、手机、社交媒体、网络营销、 StarbucksCard、电子商务、  Wi-Fi、星巴克数字网络和新兴的店内消费技术等，统一作为数字业务 战略。
近年颇受大众观注的滴滴，在 2016年就已经实现日产生数据超过 50TB（相当于 5万部电影），每天规划 90亿次路径； 据称 2017年全年累计提供出行服务 74.3亿次。
美团也是人工智能的“玩家”，其开发了服务快递骑手的语音助手，支持骑手全程通过语音与系统进行沟通、确认，免除了手动操作，提高了效率和安全性。 以派单操作为例，语音系统会提示： “派单，从哪里到哪里，收到回复”，骑手只需回复： “收到”，系统即可确认派单。 到了目的地附近时，骑手亦可以通过语音关键词回复，直接拨打电话，从而省去了掏出手机这个动作。 在电量过低的时候，系统会提醒骑手注意电量，骑行速度过快的时候也会提醒骑手放慢速度，到达顾客附近时还会自动提示顾客的地址。 美团的语音助手不仅方便了快递骑手，也使得快递过程更加安全，减少了事故发生的几率。
倒回十几年前，恐怕没有多少人真的相信零售、餐饮、出租车、外卖这些行业会与科技如此紧密相关，甚至会直接成为科技企业，而他们所用的技术也已经是大多数普通业务人员无法理解的了。 这不仅仅是指技术原理无法理解，就连应用方式也都无法理解了，这是一个真实的“数字鸿沟”，其赋予了先行者“降维打击”的能力。

• 后觉者如何启动自身的“数字化”

很多人都清楚地认识到了科技的力量，心里也明白要应对技术推动的跨界竞争，那么后觉者应该怎么做呢？ 是简单重复先行者的“套路”吗？ 或者是高薪聘请一些技术人员？ 还是购买大厂的科技产品？ 这些虽然都是很有必要的，但正如交给你一把狙击枪，不代表你已经成为了一名合格的狙击手一样，你还需要内因的转变，这种转变才是最终促成自身数字化转型的关键。
转变当然不是让所有人都去跨领域学习 IT技术，全去当“技术 能手”，而是转变思维方式，架起一道跨越“数字鸿沟”的桥梁，这就 是业务架构的核心作用。 业务架构可以帮助业务人员整体化、结构化 地思考问题，从业务和系统的整体视角，附带一些对技术的基础了解， 如分层理念、服务化、微服务化等，去理解业务和技术； 同时还能够帮 助技术人员理解、归纳业务人员的想法和目标，从而让业务和技术能 够处于同一个语境之下，使用同一种“语言”工作。 业务架构能够让“后觉者”从认知自身开始完成一场深刻的“数字化”转型。

• 业务架构带动深度融合

曾经的业务不用管技术怎么实现、技术能听懂需求就足够的时代已经过去了，现在是深度融合的时代。 深度融合代表互相深入理解，而这种理解首先需要从思维方式的转变开始，通过建立业务架构，业务和技术都能向对方的领域多迈出一步。 当然，这一步对业务人员的挑战更大，但信息技术是这个时代的特征，在一个信息化的时代，就得具备这个时代的思维方式和基本技能，这是任何人都无法回避的问题，就如同从农业时代的战车到工业时代的坦克的变化一样，无论是其战术还是对操作者的技能要求，都发生了翻天覆地的变化。
在构建业务架构的过程中，业务人员需要技术人员的大力协助来共同掌握这个方法，这不仅是一个通向理解的过程，更是一个达成信任的过程。 此外，我们无法忽视的一点是，如果业务本身不能被很好地结构化、模块化，那么技术人员也很难做出一个具有良好架构的系统，就算你是中台的“铁粉”，也无法解决这个问题。 所以，培养业务人员的逻辑思维、架构意识，对于系统开发而言，只有好处，没有坏处，要努力让业务“懂”技术。
有些技术人员会觉得应该让业务人员只专注业务，但是不妨想一想，业务人员和技术人员在现实中的比例，你会发现，要是业务人员也能对技术的思维方式有所了解，那将会对技术的合理应用乃至创新产生多么大的推动力。 打个不恰当的比方，技术人员就好比是茶商，你可能想象不到，有多少现代人的喝茶习惯、茶叶知识都是拜茶商所赐，客户对茶叶了解的越多兴趣就会越浓，就更愿意尝试不同的茶叶、茶具以及泡茶技法。 很多消费者最终在知识、兴趣上都远超一般的茶商，这就是人们常说的培养客户，与客户共同成长的案例吧。

• 来自银行的声音

大型商业银行业务种类繁多、组织结构庞杂，每年的 IT投入也是不菲的，他们更需要进行合理的“企业级”规划以实现 IT对业务发展的支持，应对来自互联网企业的跨界竞争。  
2017年 6月 25日，中国建设银行宣布，该行完成历时 6年的“新一代”核心系统建设，明确称其采用了企业级建模方法，形成了以“四个一（一套模型、一套 IT架构、一套实施工艺和一套管理流程）”为特征的企业级工程实施方法，全面建立集团层面的流程模型、数据模型、 产品模型和用户体验模型； 2019年 4月，中国工商银行金融科技部总经理在《中国金融电脑》杂志上撰文称，“中国工商银行整合构建企业级业务架构”，“重构了适应新时期发展需要的业务架构视图，重新规划整合了 28个领域的业务架构，形成了 2300余个任务组件”，“通过强化业务架构的顶层设计和跨条线的协同联动，为后续进一步打造更具新时代基因的智慧金融体系奠定基础”。
这些银行的应用能够为企业级业务架构方法提供了更多的有效性佐证和实现上的借鉴。 关于业务架构作用的讨论，读者可以进一步阅读本书的附录 A，该篇附录是笔者在进行企业级业务架构设计工作期间，阅读马汉的名著—《海军战略》的读后感，也是对业务架构作用的一种思考。
2.2　业务架构与 IT架构的关系 
1.5节中提到过， TOGAF框架将业务架构视为 IT战略的一部分，但事实上，业务架构应当是企业战略而非 IT战略的一部分，它不同于通常意义上的业务需求，而是企业业务战略的实现方法。 因此，业务架构范围是可以大于 IT架构范围的，可以包含企业战略的非系统化部分，是企业业务的全景描述。 IT架构则是用于企业信息化建设的，是企业战略的系统实现部分。 二者之间的关系，用灵魂与容器来形容也许更为恰当。 业务架构是灵魂， IT架构是容器，即灵魂的载体，没有灵魂，只有容器是没有生机的，所以，技术人员需要关注业务和业务架构。
业务架构与 IT架构的关系可以用图 2-1加以说明。   图2-1 业务架构与 IT架构的关系

业务架构可从企业战略出发，按照企业战略设计业务及业务过程，业务过程是需要业务能力支撑的，从战略到业务再到对业务能力的需要，就形成了支持企业战略实现的能力布局，可以将这个布局理解为业务架构，它是企业为客户创造价值的设计过程。 业务架构设计会尽可能地追求以更为集约的能力实现更为多变的业务或服务，这其实也是中台战略追求的目标，因而，中台战略实际上也可以归结为一种业务架构设计。
业务架构设计完成后，“灵魂”就诞生了，IT架构则是根据“灵魂”的需要来设计“容器”。 IT架构的分类方式并没有统一的说法，通常会分为应用架构和技术架构，而近些年随着大数据的发展，数据架构的地位直线上升。 此外，随着数据安全问题日益受到重视，许多企业的 IT架构也将安全架构置于重要的位置上。  
IT架构的 4种架构的特点以及关系具体如下。

1 ）应用架构重点关注的是功能布局，与业务架构的关系非常紧密，可以称其为业务架构设计的“紧后工序”。 

2 ）技术架构主要关注分层结构，对于大型业务系统来说，一个逻辑分层很可能要通过多种平台才能实现，因此还会在分层中加入平台规划。技术架构与业务架构的关系不像应用架构那么直接，主要是通过对业务特征、业务量等多种因素综合考虑分层的合理性和平台选型，通常业务架构设计不会涉及这部分工作，但业务架构人员应当了解本企业的技术架构及特点。 

3 ）数据架构中有一个重要的组成部分是数据模型，数据模型与业务架构关系密切，甚至可以归类为业务架构的组成部分。 

4 ）安全架构与业务架构的关系一般不是十分紧密，但是目前安全架构设计的一个发展趋势便是在向业务架构靠拢，或者说是向企业战略靠近，以使得安全架构设计更贴近实际业务需要，符合企业发展方向，而不再局限于传统的网络安全、信息安全等防护型工作，需要体现出更多的“规划”特征。

从上面的介绍可以看出，作为“灵魂”的“容器”，IT架构中的应用架构和数据架构与业务架构的关系是最为紧密的。 从实践的角度来说，如果企业没有那么多的架构设计人员，那么应用架构与业务架构可以合并，毕竟业务能力规划清楚之后，向部署延伸一点就是应用架构。 如果将业务架构与应用架构合并，那么让经验丰富的技术人员担任此项工作会更为合理，但要求相关人员必须具有或者培养良好的业务思维。 数据架构中的数据建模工作更是可以合并在业务架构设计过程中。
将“灵魂”注入“容器”是技术人员的重要工作，而能否顺利注入，让“灵魂”有个适宜的居所，则有赖于对“灵魂”的充分认知； 而引导这一认知过程，让原本朦胧神秘、纷繁复杂的“灵魂”清晰可见的，正是业务架构。

架构文摘

ID：ArchDigest

更多精彩文章，请点击下方：阅读原文