企业架构培训感悟

一、前言

很多企业希望能够做数字化转型，但是一到具体启动做的时候又觉得两眼一抹黑，不知道如何下手。这次培训向我们阐述了如何可以通过 TOGAF 这种方法论把战略进行落地。 

二、为什么企业架构那么重要？

作为软件开发工程师，我们总是习惯于努力尽责的把分配给我们的开发任务按时按质完成，再有业务导向一点的开发会在受理需求前会先向业务了解清楚具体的需求背景及想解决的业务问题，这已经很不容易了。

因此，为什么需要去解决这个业务问题？背后跟企业的业务战略有什么关系？或者说企业的业务战略是如何一层层的对应上我们日常的开发工作呢？作为一个合格的架构师，无论是业务架构、技术架构或应用架构，这都是必须得知道的基本事实。我的理解是 TOGAF 就是那个把企业的战略有效略映射到 IT 系统层面的那个方法。它的内涵是强调 IT 与业务对齐，通过建立企业架构将战略规划落地，保证架构的规划是以业务为驱动和主导，架构落地后能够实现业务目标；这跟我们的目标管理是同一原理的，就是通过自顶而下的进行目标的分解，而只有从上到下的分解才能保证 IT 的动作能够跟业务目标紧紧对应上的。

TOGAF9.2 作为企业架构的标准，它包含了以下四种架构（具体如下图），其中我这里想要稍微讨论一下我对业务架构（BA）和应用架构（AA）的一些理解。

1、业务架构（Business Architect）

2、数据架构（Data Architect）

3、应用架构（Application Architect）

4、技术架构（Technology Architect）

三、业务架构（BA）

首先，业务架构在 TOGAF 方法论上是上承业务战略下接技术的一个中间关键环节，它明确定义了企业的治理结构、业务能力、业务流程及业务数据。其中，业务能力定义了企业做什么，业务流程定义了企业怎么做。

在明确业务能力的这个范畴内，业务架构师需要通过政策研究、高层访谈及同业调研等手段确定我们要做推行这个业务战略的驱动因素及业务目标，即是企业要做什么来达到这个业务战略。接着，业务流程则明确了针对流程中每个部门的定位及职责、具体业务规则、业务数据流向等维度的信息。既然企业架构是企业对市场信息认知的体现，那么业务架构（BA）就是实现或者实施这个体现的一个具体方法论。

为什么我会这么说？举个例子，在企业刚开始那几年，企业首要做的是生存下来，然后会出现什么状况？所有系统的建设都是基于急用先行而进行建设的，就妄论系统间的数据共享或功能复用之类的高阶需求了，因此导致烟囱林立，这也是我们目前的现状。但是随着新烟囱的增加和旧烟囱的进一步巩固，需求交付会随着功能复杂度增加和跨团队沟通成本提高而呈现下降趋势，这个时候会出现慢慢跟不上业务节奏的现象。这个时候，可能业务功能（或者叫业务战略）大体还是没变的，但是随着规模的扩大，可能原有的业务流程已经不适应了，这个时候就是业务架构（BA）要开始发挥能力的时候了。这个时候，它需要根据企业实际的情况（如组织架构的变动、流程变动）重新定义或调整新的业务流程以便更好的适应或者支持业务。

例如，本人所负责的几个业务条线在这几年陆陆续续在往导流方向发展，每个业务条线的业务流程都是基本差不多，更多不同点可能就是需要收集的信息不一致，或者渠道展示风格不一致。研发侧也会发现实际上大体流程是可以复用的，因此觉得可以共建，但是业务侧也会有自己的想法（例如资源专属、风格各异等），这本身没错的毕竟每个业务条线也背各自的 KPI，那肯定按自己业务构想去做是最安全的，就算指标达不到也认命了（自己挖的坑自己哭着也认了）。但是这个怎么解决资源复用和资源专属的冲突呢？就没有办法吗？按照业务架构（BA）的方法，应该是从业务流程层面定义清楚如何把这三个业务条线进行求同存异或者如何分段管理，并跟领导层沟通并得到充分理解与认同。一旦有了这个新调整的业务流程，研发侧在系统开发时候才能更加有迹（原则）可循，从而研发效率才能得到提升，基于复用最大化为目标的中台化才能更加顺利的落地。

四、应用架构（AA）

首先，正如温老师所说的，这里的应用架构指的不是应用系统的架构，而是一组应用系统及其相互关系的描述，它是用于定义为了支持某类业务所需要使用到的系统，相对来说比我们平时的系统架构要宏观一点，因为它不关注单个应用系统的内部实现。

还记得应用架构设计的流程吗？

首先，应用架构需要从业务架构蓝图中的业务功能及流程圈定具体的业务需求。我这里稍微展开一下。作为应用架构，我觉得从业务本质出发是很有必要的。首先什么是架构？架构的目的就是解决利益相关者的关注点，以下左图取自于《软件系统架构：使用视点和视角与利益相关者合作》，我尝试使用脑图（即右图）进行分解。每个系统实际上是为了满足利益相关方的一系列需求，具体方式是通过系统架构里面的一系列元素，诸如那些-ability、业务功能点及其相互关系所呈现的一堆架构视野（viewpoint）去分别对应的满足利益相关方的每一个关注点。再回到应用架构这个范畴，业务蓝图实际上就是企业的整体战略，也即整体需求，因此从业务蓝图中圈定范围也是必然的，因为从这里开始才能保证所有干系人的需求得到满足。

接着，应用架构需要根据业务功能及流程进行分析所需要提供什么系统；实际上，这里告诉我们的是需要什么系统承载什么功能，但是尺寸在系统级别而非服务级别。

然后，根据某种方法论把所有的功能进行归类并分配指定到相应系统中；这里要表达的是结合业务的领域驱动设计（DDD）的方法论，针对同一类型的业务要进行归并处理，做成服务层高内聚低耦合。

最后，针对每个系统制定系统间的交互方式，划分服务粒度等。这里的就是系统架构的范畴，因为它涉及到系统服务间的粒度划分及对应的技术实现细节。

从上面可以 ，这俨然就是指导业务中台建设的方法论。为什么我会这样说？可以拿所负责的某些系统作为例子，以前做系统的时候我们采取的是急用先行的策略先开发了一堆系统，但是在发展到一定规模的时候，业务觉得要精细化和规范化管理了，因此我们要准备上统一客户管理系统了；整个公司各个系统的功能有一定程度的重叠和交叉，内部协调成了大问题。整个过程我们就像在打局部信息化战争一样，头痛医头脚痛医脚，需要解决什么样的问题，就上什么样的系统，最终就形成了所谓烟囱式的系统架构，这又导致整个架构重复造轮子，跨系统管理也给运营人员造成了不必要的时间精力浪费。

我的理解是中台严格意义上就是一种业务战略，大家再细品一下是不是这样的道理。首先，企业架构是企业对市场信息认知的体现，那中台就是企业在不断发展的过程中，随着对市场信息的认知不断加深，为了保证其企业在不断变化的过程中具备这种快速响应的能力，唯有通过在其纷繁各异的业务流程中寻找共同点并作为最佳实践的方式固化在所谓的业务系统中，这便是中台的价值所在，也是中台存在的第一性原理。

五、后话

经过这一天的企业架构培训，确实掀开了我对企业架构的一个初步认识，但是如何进一步结合现在的业务和系统现状，然后通过 TOGAF 方法论进一步细化业务架构（BA）和应用架构（AA）确实一个比较高阶的工作，暂时确实只是略懂皮毛，后面可能更多的需要在日常工作中进行实践，同步看看行业的一些最佳实践。