企业级业务架构（EBA）方法源自Zachman框架和TOGAF理论。企业架构总是给人一种庞大而笨重的印象，实践往往也需要一定的时间周期，相信很多人都会怀疑这种连它自己都快不起来的实施模式会对提升B端软件开发效能有什么帮助，本文笔者就试着讨论下这个问题，同时，也跟各位读者分析分析软件工程发展至今仍有很大不足的一处“盲区”。
一、B端软件开发效能存在的一些瓶颈
（一）令人头疼的源头管理
软件行业一直在致力于工程效率方面的持续改进，从瀑布模型、螺旋模型到敏捷过程。对于效率而言，其实各种工程模式并没有绝对的好坏，虽然对“古老”的瀑布模型的批评之声始终不绝于耳，但是新冠抗疫期间，武汉二神山医院的建设奇迹正是用瀑布模型完成的，从基建到设备到软件仅用了28天，这都是在瀑布模型的规划下完成的，所以，目标和需求清晰的情况下，瀑布模型能创造敏捷过程也无法完成的奇迹。
此外，瀑布模型的一个好处是对软件工程的主要环节说的一清二楚，自瀑布模型之后，无论工程模式如何改变，都没能将瀑布模型中的这些环节真正省略掉，无非是实施顺序、方式的变化。所以，本文还是借用瀑布模型的“清晰”来说说B端软件开发中存在的最大瓶颈——源头管理。
从上面这张图中，我们可以发现，软件过程中越靠后，也就是越进入纯粹技术实现部分，比如编码、测试、运营，工程效率改进非常明显，持续集成、持续发布、测试驱动开发，以及各种软件开发平台，头部企业已经搞出了很多神兵利器。
但是，从这个部分再往前推的话，在需求分析、概设、详设的效率方面，平台和工具的支持能力就大大减弱了，因为这方面我们更需要的是一套清晰的架构，要能更好的识别企业的业务资产和IT资产，设计能在架构中找到有哪些东西，能复用哪些东西，才有可能把效率大幅度提升上来，不然的话就经常会重复造轮子。
那么再往前到源头，到需求提出这部分，其实已经走出了软件工程真正可控的范围，因为这部分来自于业务，受技术实现能力的制约，但是不归技术管制。在这4个环节上，我们通常采用评审机制进行管理，可能互联网公司的评审工作会略微优化下，但总体而言，评审机制的工作效率并不是很高。
越靠前的环节对总体工程效率的影响实际上越大，如果是在源头环节发生错误的话，那整个开发过程就变成“试错”了，尽管目前工程方面有鼓励试错的观点和实践，但是“纵容”试错也是有很多问题的，尤其是在传统行业里边，能避免要尽量避免，轻易地去“试错”会对软件开发造成很大的资源浪费，尤其是非常宝贵的时间资源。此外，对于一些“家业”没那么大的企业来讲，频繁“试错”可能会把企业都搭进去。
需求管理还是挺头疼的一个事，经常有产品经理和技术人员互怼的这种段子。开发上常说需求来的太模糊，给你两个圈就想要你画出一匹马。其实按照科学方法按部就班地慢慢来，确实也能画出一匹马，但是如果我们真的这么细致地搞需求，可能两三个月就耗掉了，老板们就会抱怨，说是人家两三个月系统系统都上线了，我们才搞出个需求，所以这种方法尽管很科学，但是现在大家普遍都不接受了。比较接受的是什么呢？这两个圈有了之后，一顿头脑风暴，非驴非马的形象先出一个，开始开发，再多轮迭代，直到搞出马来。
即便开发端如此“折磨自己”，业务端可能还不满意，要么不满意速度，要么不满意结果，总之，跟需求还是有“差距” 。领导可能会想，为啥别人家的娃干活又快又好，咱家的娃就不行？是不是咱家娃的姿势不对？很自然的就把锅背给了工程方法和工程团队。
其实工程这个问题IT行业已经研究了很久了，瀑布模型诞生于上个世纪70年代，软件工程已经有50年历史，研究也很系统，出版了很多经典教材，像《软件工程》这种教科书级别的著作。而且内容并不深奥，业务人员稍花心思也能看懂，但是几乎很少有业务人员对这本书有兴趣，也就是说没有哪个人员对我们的开发过程真感兴趣，没有真正融入到开发过程中，所以他们也不太清楚在对于一个软件开发来讲，我们到底需要什么样的需求，到底需求应该怎么做合适。而有的时候技术人员也也愿意把工程这个东西封闭在自己的圈子里，“上帝的归上帝，凯撒的归凯撒”。
但是，如果把工程封闭在技术人员自己这个圈子里，对互联网企业来讲还好一点，开发人员通常在企业总人数中占比过半，技术氛围浓厚。但是很多传统行业的企业中，开发人员占比几乎都是个位数，甚至是很低的个位数，这种情况下，如果业务人员对工程缺少足够了解的话，那很自然的就会认为提什么样的需求都对，技术团队开发效能低的话，是你技术的问题，因为你那块我又不懂。
所以，在软件工程的改进中一直缺少一件事情，就是笔者在文章开头说的那个“盲区”，没把业务人员真正纳入工程中，我们的工程理论过于封闭了，没有在企业内部更好地向业务宣传。现在都讲IT与业务之间的融合，融合应该是双向的，不仅是IT人员要去多了解业务，也要让业务人员多了解软件的开发过程，这对提升企业未来竞争力而言将会是一件非常重要的基础性工作。
（二）对企业战略和管理的忽视
首先，很多人都对战略有个“假大空”的坏印象，技术人员也不例外。企业搞卫星、发宏愿跟我有什么关系？我只看需求，战略说的再好，如果不能转换成需求，那对技术而言有什么意义？因为我也不知道你要做什么。这种想法尽管可以理解，但并不正确，因为战略跟企业中的每一个人都相关，所以这作为企业的一员来讲，IT人员也应该关心企业要走到哪个方向，要去做什么。
其次，就是企业管理。企业管理确实是一个非常琐碎的事，有太多的杂务，开发人员还是更原意待在一个跟业务有一定隔离的后端里边，更愿意让业务提出需求，自己来写代码。
但是，如果忽略了战略和管理这两个问题的话，那么就像Zachman框架提出的思想那样，想在B端把开发这件事情做好，你必须对企业整体有深入的了解。而忽视战略和管理，则会影响到我们在架构设计上的一些决策。业务需求要跟企业发展方向吻合的，但是我们把这个责任只留给了业务，自己却没有关注。企业管理也是在处理各个业务模块之间的关系，如果都是都交代给了业务人员去承担，需求书上怎么写我们就怎么做，那么这种情况下有些需求即便有问题，可能我们也看不出来，这些问题到后续的时候都会影响开发效能，包括一些返工，一边赶工一边还要返工。所以，现在主流思想已经是提升IT与业务的融合深度了，就不要再把业务和技术这两侧截然的分开去看待。
二、EBA方法的价值
（一）EBA的核心价值
上面这张图是笔者在自己的《企业级业务架构设计：方法论与实践》一书中给出的业务架构定义，是一个操作型定义，同时也阐明了EBA的价值。EBA就是为了落地企业战略，对企业业务能力进行整体规划，再把这种规划结果传导给IT实现端的一种结构化分析方法。从这个定义上大家能看出来EBA到底要做什么：把战略落实到业务上，再通过业务的需求传导给IT。
EBA也帮助业务进行了战略在业务侧的落地。最近笔者看了一篇研究报告，提到了一个数字，虽然无从考证，但报告中说85%的国有企业没能找到有效将战略分解执行的方法。EBA其实很适合做这件事情。另一方面，EBA也可以解决IT人员不关心战略的问题，因为战略到IT中间需要业务进行传导，否则IT人员很难理解战略。
在EBA方法下，战略不能仅停留在纲领性要求这个层面，而是要分解成更细的战略能力能力。然后把现有的业务梳理成结构化的现状业务模型，把战略能力需求跟模型之间进行匹配后，会发现有哪些业务要调整或新增，进而形成目标模型。通过这个过程，实现战略与业务的结合，结合在一起的战略能力需求再传导给IT人员的时候，我们就不会说这个东西是不明确的了。战略、业务和IT之间一直缺少一个有效的衔接，只有通过业务架构这个桥梁进行连接，我们才能真正让企业变成一个整体，这也是EBA的核心价值。
（二）与TOGAF相比的改进之处
与TOGAF相比，笔者介绍的EBA方法更强调独立使用时对业务人员的价值。TOGAF中，业务架构仍是IT架构的一个延伸，也就是说，做业务架构目的是为了更好的去做IT设计，这对业务人员而言，贡献就比较小了，本质上还是IT的事，是业务在帮IT做事，业务人员应用业务架构的意愿和动力相对就会差很多。但实际上，独立应用业务架构方法去管理、理解业务过程对业务人员而言也很有意义。现在大家都在谈数字化转型，未来企业中的很多产品都是数字化形式的，尤其像金融行业，本身业务都是服务化、虚拟的，非常适合在去虚拟空间中开展。这种情况下，所有的金融产品几乎都是软件，业务想要创新产品、想要改善客户体验，哪怕想提一些内部管理建议，最终都要转化成软件的。
所以，在这个新的时代里，对从业人员的素质要求逐渐会改变，因为软件成为了最基础的生产工具，从业者必须能够驾驭软件。这不仅仅是我们开发人员，业务人员也需要很好的理解软件，这样提出来的建议才能够以最快的速度被开发理解。
EBA本身可以用来独立的去解决企业的转型问题，同时也可以帮业务人员去提升结构化思维能力，所以业务架构应该从我们原有的TOGAF理论框架中独立出来，逐渐由业务架构师交给业务人员去使用，这样就不再只是为了帮IT更好的做系统才去搞这些事情。如果业务人员能够用这种思路去分析他自己的业务，那对我们IT开发效能的提升也会很明显，会帮助我们的软件工程走出技术端。
（三）EBA的落地应用
建设银行的“新一代核心业务系统”是采用企业架构方式推动的。业务架构设计采用自顶向下逐层分解的方式，将建设银行的战略浓缩成26个业务方向，并进一步细化为72个转型举措，形成了108个能力主题，这108个能力主题最终分解为2000多个战略能力需求，这是对战略的解析，多数企业在研究自身战略时，都缺少这种详细的分解，以致于战略总是保持在高阶层面，难以向下融合。
为了落地战略，还需要梳理现状模型和目标模型，基于现状模型导入战略能力需求，进而产生目标模型。业务模型其实是业务架构的表述方式，建行的实践中，业务模型分成四种：在流程模型这部分，共计梳理900多个三级活动，任务层面做到4500多个，步骤大约是2万多个；数据模型约有3000多个数据实体，2万多个属性，把原来分散在各个系统中的数据，在企业级层面重新定义，所有数据的标准都统一，然后把旧的数据统一转换成新的数据；产品模型则提升了配置化能力，做了15条产品线、150多个基础产品，在新一代期间是支持了1万多个可售产品配置；体验模型在当时主要是以界面体验为主。
基于业务架构推导应用结构，再结合技术架构进行实施，最后变成了建行的新一代信息系统。由于建行的实践涉及100多个主要业务系统的SOA改造，所以，这么大的一个工程如果不从上到下把结构处理好，后边的实施会很难处理，是架构设计提供了对总体效能的基本保障。
大的企业转型工程，尤其是传统企业转型，的确需要先把业务架构梳理清楚，才能保障实施的顺利。建行的实践证明了这种“庞大”的方法是可以落地实践的。
三、EBA方法对开发效能的改善
（一）EBA一般设计过程
EBA一般设计过程如下图所示：
EBA设计起点是战略设计，企业对环境的变化做出的最高级别的响应就是战略调整，设计新的战略一般也会要求组织结构发生相应变化，因为组织结构是要承担战略实现的，组织结构的设计好坏会影响战略实施效果。但是战略和组织设计对业务架构设计的技术层面而言，是约束，因为这是决策层的职责而不是业务架构师的。
战略和组织确定后，就进入技术层面的业务架构设计。通过业务分析来推导业务能力，并将业务能力聚类成业务组件。业务组件可以被理解成一个“筐”，里面放的就是各种能力零件，把这些能力串接起来就成为业务过程。串接的顺还是不顺，也会检验我们原来的流程设计是不是合理，两者之间可以有一个互相验证，所以业务分析可以推导组件设计，组件设计也可以反过来可以优化业务分析。
业务架构设计完之后，它的目标是什么？当然是实现企业战略目标，这就是EBA的一般设计过程。
虽然业务架构师无法真正影响企业的战略和组织设计，但是面向数字化转型，在管理层、管理思想中引入架构思维却是非常必要的，如今有各类CXO，其实可以考虑在企业设置CAO（首席架构官），顺理成章地将架构思想引入到管理层中来。
（二）推动技术和业务思维的接近
EBA核心逻辑如下图所示：
这个整体视图大家可以看到，从上往下其实是业务逻辑。顶层是企业最高阶的价值链，浓缩了企业的价值创造过程。要做这种企业级架构设计目标上是要把不同领域的业务进行整合，去找它的公共部分，公共部分提炼出来了之后，才能更好地复用，从而提升以后的开发效能，这也是中台方法的目标。那么不同的领域最好能够按照同一个“尺子”去梳理自己的业务活动，才有可能比较各个领域的工作。如果没有上面这个统一价值链，每个领域自说自话地整理流程，就很难找到公共部分了。
在统一价值链下，我们可以看到每一个领域是如何按照企业统一的价值创造过程去展开业务活动的，进而把业务活动再细分到任务层级。任务需要创造数据，现在大家经常提“一切业务数据化”，但如何做呢？通过这种方式，我们可以看到任务创造了哪些关键数据，反过来也可以检验一下，这个数据是不是完整？是不是所有关键的活动都会记录下来？
这个整体视图从下往上解读则是技术视角。计算机设计主要关注的是行为和数据，一般在设计模块或者设计组件时，可以先从数据的聚类开始，通过主题域的方式把关系相近的数据先聚在一起，因为这些数据的变化通常会互相影响。通过数据再把行为聚类，也就是功能聚在一起，这样的话，有数据有功能，就形成了业务组件。从图上，IT人员可以在总体上看到，组件包含了哪些数据和行为，组件的能力又是如何支持业务活动，支持企业价值创造的。
这张图可以把业务和技术的思维结合到一起，如果让业务人员具备结构化思维，那就必须给他们提供工具，否则结构化思维就是空话，无法聚焦。而这个工具又必须跟我们IT的思维有一定程度的接近，这样两者的思维才能够走到一起。有了共同的思维模式，才会有共同语言，业务跟技术的交流才会真正好起来。如同本文第一部分分析的那样，通过推广业务架构方法才能更好解决软件工程走出IT封闭圈子的问题，推动需求侧的变化。
（三）提升实施阶段的沟通效率
对于企业转型这类复杂的企业工程，大家经常说它是一种“巴别塔”项目，“巴别塔”项目失败在哪里，就是沟通，项目之间各自有各自的利益述求，通常需要站在自己的角度去看问题，作为需求方的各个部门其实也会如此。有企业级业务架构模型的好处就是能够把所有的项目横向拉通，均衡地分析问题。
实施中，如果对一个组件的边界有争议，那么从开发团队的角度来讲，他会先质疑应用架构有没有问题，应用架构自然会反推业务架构有没有问题，这样就把大家的争吵溯源到同一个源头上来，企业级业务架构相当于吸引了所有人的“火力”，最后大家吵架能够吵到同一个点上，吵到如何去判断业务架构是不是合适？如何去调整？所有的矛盾期都集中到这里之后，反倒会有处理这个问题的解决。作为复杂项目的横向沟通工具来讲，企业级业务架构给了大家一个统一的蓝图，现在经常讲的一张蓝图绘到底，一个蓝图有助于统一大家的概念，不要公说公有理婆说婆有理地讨论问题。模型也有助于结论的结构化记录，比单纯的会议结果更容易保存和查阅。
（四）通过能力地图提升设计效率
EBA并不指定特殊的实现方式，EBA实际上是在澄清业务能力结构，业务侧理清楚之后，IT侧，只要是团队驾驭得了的设计风格都可以用来进行企业级实现，无论是SOA还是微服务。实现后的企业能力地图如下图所示：
落地之后我们就回到了EBA概念强调的内容，我们能够把战略分解成需求，把需求映射到业务，业务最终映射到IT设计，可以把这三者之间串联起来，串联起来就构成了能力地图。无论是互联网企业还是传统企业，其实在总体架构上来讲，都在找这种关系，在这方面的诉求是一样的，能力地图代表了对业务资产和IT资产的清晰描述，无论是在复用方面还是在新增设计方面，都有助于效率的提升。
大家经常说TOGAF不利于推广的原因之一就是它的维护比较麻烦，但其实维护麻烦的一个原因是在于使用日常是不是能够坚持使用这个方法去项目管理。模型是常用常新的，如果在使用中持续的去改进的话，那么它的维护量其实是可以分散的，如同跑步一样，坚持跑一千公里并不是要你一次就跑一千公里。
（五）对需求源头管理的改进
这个改进的责任可以落给业务架构师。对于企业级业务架构实施来讲，较长的实施周期也必然会培养大量的业务架构师，对业务架构师的日常使用，笔者认为其主要使命就是促进IT与业务的融合。从这个角度来讲，把他们分散到业务部门去，让他们在业务部门里边，在业务需求萌芽期就形成体系化的引导，即减小了企业级实施的阻力，也能够真正让业务人员多接触业务架构模型，多理解结构化的思维，多了解业务需求应该按照一个什么样的套路形成，从而逐步从源头上去解决需求管理的问题。
软件工程一直没能处理好这个盲区，这是我们在效能提升过程中必须要关注的一个点，因为我们在IT侧的改进上取得了很大的成果，但是如果业务这一层不加强，我们的天花板高度就是有限的。
就工程方法而言，国内相当于有两种做复杂企业工程的思路，一个是以建行为代表的自上而下通过企业架构规划进行的实施；另一种就是差不多在同一时间开展的阿里巴巴的“中台”，“中台”被认为是从下而上的演进式发展。但这两种工程方式有一个非常有趣的共同点——都很强调业务架构的作用，虽然双方业务架构师的工作方式方法相差很多。
阿里巴巴做“中台”之前，总结了自己存在的问题，包括缺乏业务全链路视角的需求管理机制、缺少可复用的业务资产等，从企业架构的角度来讲，就是业务资产、IT资产都不清楚。这种述求与建行开展“新一代”建设的述求在本质上是相同的，都是要去找这个企业里可以复用的东西，把资产定位清楚，才能够提升开发效能。
架构资产的描述方式并非只有一种，建行的、阿里巴巴的，此外还有TOGAF的模型、DDD模型也都是资产描述方法，孰优孰劣的区分未必很有意义，长枪短炮的差别最终还是体现在使用者的运用能力上，很多对工程方法的非议并非来自深入实践之后的结论，很多时候，成功是看坚持到什么程度，“行百里者半九十”。
四、对从行业层面提升开发效能的一点展望
说过了眼前的苟且，再看看诗和远方。
从行业级层面提升开发效能首先一点要考虑的是如何跨企业复用，上文讲的还是企业内部基于自身架构的复用设计，但是从行业的角度来讲，比如金融行业这种监管比较严的行业，很多业务规则大家都一样，但是做出的系统就是不一样，经常要把别人做过的功能换一个企业再重做，这对谁而言都是浪费。
如果想在这方面有所改进的话，就得发挥业务架构的引导作用，在业务架构设计过程中是很强调标准化的，通过标准化过程梳理出来业务结构，能不能做一些横向的比较、横向的复用？这就是行业级标准化的问题，目前欧美银行中有一种架构理论，银行业架构网络（BIAN）模型，就是从标准化构件的角度思考的。
标准化构件也就是大家常说的“乐高积木”，不知道大家是不是刻意观察过，乐高积木的第一个特点是简单易懂，这些积木块放那没有说明书你也能用，我们现在很多软件远远达不到这个程度，其服务层级的结构划分业务人员完全是一头雾水，是照着技术自己的理解搞的，业务的思想没有充分体现在技术侧的切分上。乐高积木的第二个特点是不同系列大约有70%是采用通用组件，有30%左右是有差异的。我们所说的差异化，同一行业的各个企业，业务上能达到30%的差异化就已经相当高了。那也就意味着，其实我们70~80%的开发是换了个环境在重复做，有20-30%是真正有可能产生差异化的，但是并没有分配到足够的资源，按照二八定律来讲，我们其实应该倒过来给这20%或者30%的业务分配80%或者70%的资源，但实际上并非如此，大量的时间和资源还是被用来做跟别人一样的东西，还经常是加班做。
改进这一点并不容易，希望做出这种在行业可以推广的构件，那设计上必须要做到对业务友好，一定是一个业务人员可理解的设计，他才能参与进来。很多时候服务的切分都太过于技术化了，甚至非常碎，以实现技术理解的“解耦”。阿里巴巴做“中台”之前也出现了这个问题，微服务快速膨胀到1万多个，最后大家都很难说清楚服务的关系了，这也应该算是开发上效率上的一种损失吧。只有能被业务人员理解并可以用来组装产品的构件，才是合格的构件，这是我们在设计上要努力去追求的。
自Linux诞生后，开源的集市和闭源的大教堂就成为人们心目中的两大开发流派，现在大家也经常使用开源软件进行B端开发工作。开源有利于更广泛的进行高效的软件创新，主动添加的各种功能可能会让开源系统支持更多的应用目标，但是目前开源多为技术组件，需要再加入一些业务组件，否则，我们难以应对今后更大规模的对软件的需求。
源代码不是可口可乐的配方法，技术人员真正的核心能力是利用各类构件进行要素组合去解决问题的能力。通过“集市”上找到的构件，更快地完成大教堂的建设才是目标，这样才能集中精力去搞20~30%的差异部分，对企业而言也才有价值。对70-80%的重复部分进行保护，实际上是整个行业的损失。
本文从B端软件开发的瓶颈讲起，对软件工程中还需要通过EBA方法进行改进之处做了自己的阐述，一家之言，供大家探讨。最后，笔者想引用一句古诗做个总结：“问渠那得清如许，为有源头活水来”，开发的河想要清澈，不能仅仅在开发侧发力，除了持续的供给侧改革，我们更需要需求侧革命，这是数字化时代的要求，而非我们对业务人员的过度期许。未来企业都会逐渐转变为科技公司，一旦起跑线差不多，我们比拼的就不再是技术实力，而是谁家的业务人员更能帮助技术人员快速理解业务，因此，没有业务这一侧结构化思维的改进，开发效能的提升最终还是有限的。
