一文说清楚企业级业务架构方法
作者：付晓岩
本文为付晓岩老师在“技术琐话”的直播整理，感谢付老师的付出。
今天分享主要分成三个部分，
第一部分是软件工程与企业架构方法论的发展。
不管是我个人写文章提到的企业级业务架构方法论，还是中台也好，都是从以往的方法发展到现在，也有几十年的历史了。所以大家研究方法论也好，或者是看一些现象也好，如果你希望对这个现象的了解更深刻的话，那最好的还是要从这个方法的历史开始了解。
第二部分，是关于企业级业务架构方法论的介绍。
最后一部分，实际上是从企业架构的角度谈中台，我认为中台就是企业架构范畴内的探索，所以第三部分：从企业架构角度谈谈中台。
先说说第一部分吧，大家可能都知道软件开发里面其实有两个核心问题，或者说两个关注点也行，一个是软件过程，就是这个软件是怎么造出来的，从头到尾的全生命周期是什么样。
另一个就是软件设计。软件设计其实是软件过程中的一个环节，但是这个环节比较重要，所以我们可以把它单独提出来看一下，也就是说，软件开发里面其实有这么两个关注点或者是两个重要的方向，一个方向是过程管理，一个方向就是关于设计。
软件开发中的两个关注点
那么过程管理，其实我们主要关注的就是软件工程了，我看这个老外那边比较受欢迎的软件工程图书，应该已经到了第九版、第十版吧，应该是常青树。
工程里边，其实我们主要关注的就是工序和标准，这个其实跟我们做一些工程管理或者其他其他行业的项目管理道理是一样的，都是关注做事情的顺序，以及每一个步骤应该达到一个什么样的交付条件，也就是工序和标准，其实有了这个才能算得上是工程上的管理，不管是我们做这种传统的传统方法还是做敏捷来讲，我觉得大家怎么都需要关注工序和标准。这么做的目标是为了什么？目标一个是为了提高这个软件的质量，再一个呢就是产量。其实产量换一个角度说了就是速度。
然后在设计这一侧，其实设计里边最难的部分应该就是架构设计，那么架构设计的核心点，我个人认为简单的来看就是结构和关系，也就是你把一个软件，切成多少个部分，把一个项目分成多少个部分，每个部分之间如何交互的，是一个什么样的关系，然后你怎样处理这个关系比较合适。
那么做架构的目的是什么呢？我个人认为第一点是为了复现，其实做架构的时候，我们相当于是把人家客户的要求或者是业务人员的要求，很清晰的结构化的理出来。
理出来之后，让这个清晰的结论确认它能跟业务的要求是一致的，所以我们做软件其实大部分情况下做的都是复现型的这种软件，不是突破型，其实没有很多突破型的。第二我觉得是就是技术人员对业务参与很多了之后，业务融合比较深的情况下，你才真正会产生一些是为了突破型的。但是大部分情况下，尤其是在很多传统企业里边，做的这个软件设计其实都是复现型的，把业务人员的这个需求听清楚了之后，跟业务人员沟通好了，然后把这个业务需求复现出来。
那么架构还有一个好处是什么呢？清晰的架构，还有一个优点就是有利于复用。
复现和复用，其实对质量和产量也是有影响的。那么今天看起来呢，这就是这个软件开发的关注点。这两点的话，大家已经听上去已经是很自然的一件事了，是吧？
但实际上在整个这个软件行业的发展过程里边，这么自然的一个事情，却是很长时间才认识起来的。
一九四六年第一个可编程的计算机诞生，软件行业也就开始了，对吧？那时候软件的生产过程其实是比较粗放的，就是今天也有人还在用这种方式来生产，这种方式就是“先写了再说”。先写完再说，一开始的时候，因为没有相应的管理理念，有这种思路、有这种思维是很正常的。然后就出现了我们所说的软件危机。
软件工程和企业架构模型的发展
做软件人们关注四个维度，时间，范围，成本，质量，所谓的危机就是这四样没有一样能控制住，所以大家又觉得该反思一下怎么做软件是对的。于是就产生了这个第一个模型就是瀑布模型，这个模型是70年提出来的。这个模型非常直观，大家能看出来软件开发到底有什么东西。
一开始我说的，咱们思考做软件就是两条线嘛。一个是过程的线，一个是架构的线。过程模型先出来了，但是架构的线更慢，过程那条线是软件行业发展二十多年才出了一个模型，那么架构这条线都快四十年了，才开始变化。
这方面一个相当大的变化，就是把企业视角加入模型，从软件自身的关注，上升到对企业的关注了。企业架构是花四十年才诞生的，也就是Zachman框架，但这个架构其实只是一个框架，它是六行六列的，这六行就是六个视图，然后那个六列其实相当于六种不同的视角，就是每六个视角构成一个视图，加在一起，这块儿就是说你在B端做软件，不是只看需求，不是只看一个功能，你应该看企业整体，就是我们做软件是为了企业整体的管理服务的，在这个基础上你才能真正做好B端软件，那么这个思路应该算是一个开创性的思路了。
那么这两条线，随着时间推移还是继续发展，就是大家有了瀑布模型，尽管算是有了一个工程模型了。但不是很合适，因为这瀑布模型太慢，不到交付，看不到东西，所以有人就给他改进了一下，变成了螺旋模型。
这螺旋模型就是对着原型去设计，每隔一定时间交付一次模型，但是好像这个螺旋模型每次交付都是全量，那这样的话就是解决了一下这个软件不到上线看不着这个问题。螺旋模型与TOGAF模型这两个模型很好，很全面，但是落地比较困难，维护成本高。
为了突破这些问题，软件工程之后的发展趋势就是组合拳。
敏捷过程其实也算是有头有尾的，也有产品定义过程，之后是经常说的头脑风暴，提出功能规划，提出来之后，然后就开始计划后开始快速迭代。
好多传统企业做敏捷做的不太到位，往往就记住这一个速度，就看中了这个两到四周的迭代速度，其实这对敏捷过程来讲是不完整的，也是有缺陷的，那么敏捷过程来讲，其实在这儿在功能规划上稍微有一点弱项，因为他没有给出一个好的划分能力点的方法，他主张的是头脑风暴，大家在一块儿快速讲，反正他第一版那个东西做得有缺陷也没事，我可以后边逐步把这缺陷补上。
就是说这块儿其实缺少一个扎实的方法。所以有人提出了DDD领域驱动开发，提的这种设计方式他认为跟敏捷很配。因为他这个方式其实对于做也算是敏捷的方法，如果做的熟练的话，操作起来速度确实可以很快，而且跟后面的设计直接对应，所以他确实能解决这业务和技术直接映射的问题。
但这个方式一开始出来的时候不是太好理解，所以技术人员并没有把它拿起来用，就是没有一开始就跟那个敏捷配上，到什么时候呢？到这个后边这个微服务架构出现之后，这个微服务架构出现之后，大家觉得微服务确实挺好，整个上线速度挺快，跟敏捷开发结合，代码那边写的快，这边部署也快。
嗯，但这就有一个问题，就是大家也都知道啊，这个微服务，问题就是多大的服务叫微服务，什么叫微服务，我们怎么切分企业的服务，就是这时候大家又想起来说，那是不是可以再走一走DDD。那么有人又专门去写怎么用DDD来设计为微服务，所以就出现几种方向之间是可以组合在一起去共同来提升这个软件开发速度。
算是一个组合拳吧，就是敏捷方法，就用于过程管理，然后DDD注重的是产品的架构设计，然后微服务是支撑实践。
那这块我们也看到了一个趋势，就是刚才我们说从软件架构到企业架构，这是一个架构发展的趋势。另外一个趋势就是出现这种架构方法之间的组合，大家越来越觉得说一个方法去把所有东西覆盖住，不一定合适，大一统的方法不一定合适，那么我们可以发挥各种方法的优势，各种方法结合起来，解决我们面对的种种复杂问题，那么最终组合拳，现在有这样的例子，其实我个人觉得这种这种方式本身也非常好。
而且做方法论呢其实你也需要有这种态度，方法论上的不是用来吵架了，做方法论其实最重要的是给你一条主线，去吸收别人的优秀经验和你自己的经验，方法论之间互相之间并不是排斥，它只是给你一种吸收经验的指导。
这个工程刚才咱们说敏捷那一块的工程发展呢，如火如荼的，但是咱们传统的笨重的架构领域啊，进展相对就慢了一些。
在这里讲一下DoDAF的，这个架构这种总结起来，其实主要就是他用换了一个视角去看架构这个问题，就是说他不太限制软件上设计。他关注的是什么呢？关注的是信息，就是数据。它强调说用体系结构数据取代体系结构产品就是做出一套类似于数据模型的东西。
那么上面我们就是简单回顾了一下这个软件工程和软件架构的一个发展过程。
企业级业务架构方法论的介绍
接下来我们来看一看企业级业务架构方法论的介绍。
关于数字化，砸烟囱，复用，双模开发，减低成本，企业转型等这些企业面对的困难，我们是否可以找到一个共同的发力点来解决这些问题呢？那咱们做计算机的一直有这种抽象思维，在不同的问题里面找到共性的东西，那咱们可以挑一个发力点，通过对这个点的解决，让咱们的其他问题都有一个好的解决，为其他问题的解决提供一些支撑，那么这个问题我们又回到了寻找发力点上，做企业就要关注企业管理，那么我们这个找到所有问题的共同点，那其实就是提高企业的整体性。
那我现在也觉得就是互联网企业的成功其实被一些宣传误读了，大家就会觉得是互联网企业就是快速的试错，然后赌中一个就发达了，那么跟传统企业的注重整体性没有关系，那我个人的观点其实不是这样的，虽然我个人不是这个互联网行业的，我是传统行业的，但是咱们群里有一些人是互联网行业的，那么我们企业肯定是要做整体管理的，这种企业管理逻辑我们是打破不了的，你到了数字化时代，我们这种逻辑也是打破不了的。所以我觉得这个所有问题的共同点还是如何用一种方法来提高企业的整体性，如果能提高企业的整体性的话，那左边的问题都能得到一定程度的解决。
那么这个方法是什么呢？那这个方法自然是企业级业务架构。
这张图的其实就是我给出企业级业务架构的一个定义。那么我给的定义是操作性的定义，那么你为了落地企业的战略，对企业的能力进行整体的规划，并把它传递到it端实现的一个结构化分析方法，那么一个关键词就是整体规划，对企业进行整体规划，然后传递的it实验，那么最终我们所需要的就是结构化，那么你落地企业战略的首先是要对战略进行把一个大的战略化整为0，化成一个小的需求，画成一个一个清晰的战略能力需求，这样我们才能一个一个往下落。否则的话，这个战略就是一堆漂亮的PPT，往墙上一贴就完事了。当然我们在执行的时候，我们还要去找能力的执行者，要找有能力的人来完成这一个战略的落地实现。
那我们先需要把现有的业务先解构了，然后跟这个战略能力去做一个对比，然后跟我们现有的业务战略进行z一个对比，哪一些业务是需要砍掉的，那些业务是保持不动的，哪些业务是需要新增的？
先把现有的业务解构了，然后从解构到结构，我们就有了一套新的结构。那么这一块其实已经融合了战略能力的需求进来，可能更具体的，那么这个时候我们在it那边实现的话，就会发现与任务已经匹配上了。
那我这一个业务架构最大改进之处就是强调业务架构的独立性。
那么刚刚那张图我们可以回忆一下，就是从战略到业务再到it，我们来看一下就是战略到业务，我们是不是可以发现业务架构可以独立的解决战略的问题，那本来这种融合了业务能力的需求，也不需要每个都会给it开发。所以理论上来讲，业务架构的范围给那个it开发的比it开发的范围其实是要大的。我们会形成一些线下的任务，比如说一些不需要it支撑的任务，但这些业务互相之间都有关联，业务架构分析的是一个完整的业务视角，他其实解决的是管理问题，所以业务架构我认为它是可以进入管理里面的，帮助业务一侧，把业务理清楚，最终生成这种业务能力。
包括很多人都想做中台，那很多人就会问的一个问题，就是中台里面会放什么，包括中台的那一套技术，你只要有钱，然后你的工作人员有技术，你就可以获得，就像你拿了一把枪一样，枪里面没子弹，你拿了技术之后，你没有业务内容的话，你会发现枪里面是没有子弹的，那光有it这个容器没有业务，那么这个软件资产其实没有价值的，所以说业务架构对于IT架构来说，它是架构的真正的灵魂，它梳理的是里面真正有价值的东西。
业务架构的一般设计过程
那接下来我们来看一下业务架构的一般设计过程，那么业务架构是一个有实操性的东西。真正做业务架构这种分析的话，它是需要有案例来支撑的。对今天这个分享到给我说的这一个分享，其实更多的还是让大家理解这个方法的作用和它的总体过程。
我们会看到战略设计变革组织设计，组织设计影响战略设计，业务分析推导组件设计，组件设计优化业务分析。战略与组织设计约束业务架构设计，业务架构设计实现战略与组织设计。
接下来我们看一下设计起点：战略分析。
那么我们其实能看出来底下这个就是商业画布，上面这个就是房顶是战略部分，这个家的房子，其实他的目的是为了做一个沙盘推演，通过这种沙盘的方式来定战略，这是可执行的。
接下来我们看一下加强协同，组织分析。我们看到企业级前与企业级后是有很大的区别的，加强协同需要各部门的配合，或者需要强有力的领导的支持，加强协同后其实我们很容易就意识到协同的好处与便利，随着时间的推移，这些便利会一步一步加强。
接下来我们来看一下流程设计：价值链分析。
价值链就是让企业各个领域意识到企业就是这么创造价值的，我这个企业总体而言就是这么创造价值的，然后你自己看看你这个领域是怎么按照这条路径走的。
这是一个思维对标过程，简单规划完之后，就是你各个领域就是按照这个价值链去把你的业务活动，我们分环节每个环节里边到底有多少个业务活动，而每个领域，用这种方法去把它展开，看下边有多少个任务要设计多少个，其实这块是一个传统的一种分析，如果单看这个的话，我们这方面就没什么特别。
这个方法的分析的特别之处就是流程和数据的结合，也就是说我们画一个任务的边界或者判断一个任务，到底是不是一个评定企业级唯一的任务，其实要看的是这个任务处理的数据是什么，把数据和任务结合在一起来看，那么这样的话我们就产生了这种业务组件，那么组件大家知道这个计算机设计上面我们其实关注的是什么，就是行为和数据，你设计功能的时候或者就设计这个子系统的时候，你会考虑什么把关系相近的数据聚合在一起，就类似于数据端的主题，那么这种数据聚集在一起之后，你再把相应的行为也就是说我们说这个任务对吧，这个工作梳理，到一起那么这样的话就形成了这个有业务组件。
接下来我们来看一下组件设计的：5W1H
通过When,Who,Where,Why,How,What来做分析，分析到底为什么要干这件事，这件事到底有没有价值？其实有时候我们判断价值的时候，用一个简单粗暴的方式去判断的话，就是你产生一个新活动，产生一个新任务了，有没有产生新数据，如果没有产生数据的话，那这个任务本身它的价值就没有那么高了。
单从一个领域去分析的话，其实你还看不出来它的优势，那么当你把两个领域，或者三个领域4个领域叠加起来，像这样把不同的领域在这个价值链环节上叠加起来的时候，这个时候那么这经过任务和数据的标准化，你就容易找到，我觉得公共的能力是什么，那有些任务可能只有一个活动在用，但有些任务就有可能被多个活动用，这就出现了这种公共，然后前面咱们提过的是希望软件资产复用也好啊，还是希望着提高开发速度也好，这就有综台性的帮助
中台是不是也在这么工作，就是以相当于整个业务的视角，从那个价值创造过程到你每个领域的具体活动任务，然后到了你这个任务产生的结果就是一个业务数据，对吧，反过来从下往上看呢，其实相当于是一个技术视角，一个业务组件要处理哪些功能，数据处理的过程是什么样的，那么我这个组合在一起的这个零件支撑了哪些业务活动，对吧？有没有哪些任务我们都要用，于是这一张图，从上往下的业务视角和从下往上的技术视角就是结合在一起的，而且最后结合成了一个企业的全貌。
接下来我们来看一下设计难点：标准化
标准化确实是一个难点。不仅仅是说说这个判断这个东西本身就复杂，再一个呢就是它这个范围带来的复杂度，当你的范围太大的时候，这个标准化就比较困难。
接下来我们来看看企业的特殊价值：企业能力地图。
这个企业级架构设计落地的过程里边，它可以成为一个更有效更容易吸引争端火力的这么一个沟通工具，就是你相当于有一个统一语言，大家在统一的一个蓝图上去互相去看问题。没有地图意味着什么呢？你就容易走丢对吧？你旅游还需要旅游地图，出来做这么大的项目，给一个大企业做的项目，你连个地图都没有，那是对企业自身不利的。
接下来我们来看看，长期管理：持续融合。
然后这个长期融合的话，其实业务架构师就是我们在做业务架构过程里边培养的这个业务架构师，不仅仅是让他们去做高阶设计、做业务架构PPT就完事了，其实他们要参与到项目实现里边，对整个实现要有一个深入的了解，那么在这个项目之外，其实我个人认为是要跑到业务部门去，尤其是对于我们传统企业的转型来讲，你需要一些在业务和技术两边都能懂一些的人来帮助业务人员去更好的理解企业级软件。
接下里我们来看看演进式架构。
企业级业务架构第1次做完了之后，要持续地应用这个架构，每次业务需求来的时候，通过一个业务架构设计分析，然后再到落地，那么逐渐的这么看到整个企业演进的过程，那么这种的话对于我们，就是新来的人员的迭代其实是有好处的，因为新来的人我也有机会看到架构迭代的过程，我们好多企业或者项目新人进去之后依然懵，因为你想熟悉这个企业的系统要好长时间，因为这个整体架构好多时候都是貌似有，实际上没有，那我们就会造成什么呢？就是一个是以往经验的流失和浪费，所以以前踩过的坑也没有人能记住，这样也会造成团队的低效益。
接下来我们看一下，打造自己的方法论：知行合一。
我们要注重业务架构的“知行合一”，知线是指架构方法论的持续改良，行线是指战略分析，架构设计，架构落地，长期管理。
接下来我们来看一下“知行合一”的延伸：方法间的融合。
架构发展的一个趋势，就是方法性的融合
接下来我们来看一下软件的“供求曲线”
如果需求能力和开发能力两条曲线同时上升的话，那它就意味着均衡价格的上升，对我们来讲就是软件开发的这个速度和质量的共同上升，所以这一块还是需要业务架构去提升业务侧的结构化思维，大家要多多思考一下，所以你也看看我在技术琐话里面写的另一篇文章，谈的这个问题就这一块呢，其实架构这个东西我个人认为，如果大家希望以后软件生产的这个质量、速度增长上来的话，那架构思维是必要的，当然我说的时候不是说高等级的那个架构师那种，但是大多数人来讲，其实都应该有一定的这种架构思维。
这个怎么培养呢？有一个这么方面需要关注一下，首先对于业务架构来讲，真正的这个核心能力不是业务能力也不是技术能力，而是架构能力，是结构化思维的能力，决定你能走多远的是你这个结构分析的能力。
在这有这么4个思维了，
比较重要的第1个是整体思维，你要看全面可以整体什么样的；然后是洞察能力，其实洞察能力最简单的来自于什么，就是来聊来自于交流，因为这块其实我们好多技术人员没有机会做到，没有机会到现场在业务现场看一看，看看客户交易怎么跑，客户经理怎么到客户那边去的，这些事就是你多聊一聊，其实就是很好的洞察能力，洞察本身不一定是那么深奥的东西。
演进思维，就是里边这个这个蓝色的小T逐渐长到外边，到灰色这个大T，它是需要一个过程的，所以说这个事谁也避免不了他都需要时间，需要时间去支撑这个发展，但是我们往往是企业不给时间是吧，这块是一个很大的矛盾。
然后最后一点就是开放是为我们将来的价格都是开放式架构的，就是每个企业都有它，自己的一个T，一家公司也都有它自己的一个T，那么如何把家公司的T相连起来，就是把这个4T串起来，相当于这就是T型的世界，这种开放的思维其实非常重要。
接下来我们要看到架构驱动的银行数字化转型，
从图中我们可以看出战略视野看出核心战略，再将核心战略进行分解，最后进行落实。
聊聊中台
2015年大动作要解决的“痛点”
缺少业务全链路视角的需求管理机制，协同效率低。
业务与平台没有很好分离，无法支撑业务自助式发展
平台准入门槛高，新小业务无法快速是错
缺少可复用业务资产
当时设定的目标
需求结构化，业务配置化，业务全链路可视，业务测试一体化，业务监控，故障排查
业务架构的作用：
舆论里的“中台”：
新的中台理念
多掌握点方法论，就都有助于了解这个中台现象吧，我提供这张图是不是为了大家去争论中台为什么叫中台而不叫平台，不要太关注里面的名词，而是关注里面所做的什么，我认为它还是做企业架构的这种设计，是一种挺好的探索，在企业架构落地实践上是一种挺好的探索，那么大家按照中台这个思路继续探索咱们自己的架构方法论和工程理论，这是值得需要我们鼓励的。
作者：付晓岩 著