二、企业级业务架构（EBA）与“组合拳”
（一）关于EBA
上文谈到了架构演进的一个趋势，就是关注点从软件架构向企业架构的进化，这反映了技术在面对不断上升的业务复杂度时，对自身局限的认知。不深入了解业务和企业，就很难建立面向整个企业的系统规划，企业内部也就很难有效打通，事实上，比尔·盖茨先生1999年在《未来时速》中提出的为企业打造“数字神经”的想法，至今也还没能完全实现。“数字神经”的打造跟理清企业架构是分不开的，如同给一个城市设计管道系统一样，它与城市的结构是要匹配和共同演进的。而企业架构中非常重要、技术人员又很难处理的，正是业务架构。业务架构在Zachman手中萌生，到TOGAF时明确，尽管那个定义还是挺难理解的。
TOGAF将企业架构（EA）和业务架构（BA）都推向了一个新高度，并且给出了包含业务架构在内的著名的“4A”结构，但是其实施难度一直饱受争议，由于周期通常较长，分析业务架构能够投入的业务人员就是有限甚至很难保证的，当然，这与企业自身的实施决心也有关。国外有些基于BA的成功案例，比如US Patent and Trademark Office（USPTO）于2013年启动了TMNG（TrademarkNext Generation）项目，按照BA方法梳理了企业层面的20多条价值链、19个1级能力、100余个2级能力，并按照能力复用等条件确定实施优先级，能力复用越多的，计划排期越靠前。TMNG项目持续5年，从第一年只能释放1组价值链环节，到第四年可以6组价值链环节同时实施，这一方面显示了对方法应用的熟练，另一方面也是来自于可复用能力的增加。
国内，建设银行是贯彻业务架构方法的典范。由于长期受到“竖井式”开发的影响，该行于2011年痛下决心启动了“新一代核心业务系统”转型工程，以企业级业务架构方法驱动IT开发转型，进而推动企业转型。工程实施时间长达6年，通过业务模型方法构建了全行统一的业务架构，梳理了20余个业务领域、80余个业务应用、100余个业务组件、900余个活动、4500余个任务、20000余个数据实体，规划了全行100余个新老系统的SOA风格改造，将整个企业连接起来。此后，工行、中行也都在近两年构建了自己的企业级业务架构模型。
综上，EBA其实对开发最大的指导作用在于它对业务的深刻理解、对企业整体性的解读与规划、对业务能力的聚类与组件的划分，从而使IT对业务的支持上升到合作、融合的高度而非原有的实现，它的作用其实更多还是在过程中，而非文字里。笔者基于原有的工作经验，将EBA设计方法进一步改造为通用方法论，以期能够为更多领域的设计人员提供借鉴。
EBA方法这两年有复兴之势，一方面是有建行这样的大型实施案例，另一方面也有来自阿里巴巴这样的互联网头部企业对业务架构的重视。如果再说更深层次的原因，也许是现在又到了一个“转型”的时期，互联网企业这类跨界竞争者对原有行业的巨大冲击，使大家认识到，未来企业都将会带有较强的科技属性，信息化将进入它自身的高级阶段，并逐渐走向数字化阶段。这样的“转型”时期需要已经不仅是“一招鲜吃遍天”的爆款产品，更重要是大多数传统企业需要首先完成自身的“科技化”改造，需要首先实现企业内部技术基因的增强，实现业务与技术的深度融合，这种转型非常需要EBA的支撑。
提高企业的整体性正是EBA方法的强项，正如笔者在《企业级业务架构设计：方法论与实践》一书中对EBA的定义：“以实现企业战略为目标，对企业能力进行整体规划并将其传导到IT实现端的结构化分析方法”。企业无分大小都有战略，都有架构，就算没有显性地表现出来，所以，各种规模的企业都可以尝试用EBA方法为自己诊脉，就算你没有最终将它应用于IT实现。笔者介绍的方法没有那么复杂，充分地认识自己不是坏事，正所谓“知己知彼，百战不殆”，毕竟，无论做不做系统开发，企业每发展到一定时间，总会积累些“管理债务”要去偿还，EBA本身也可以应用于“管理”上的重构。EBA的一般设计过程如图6所示：
图7EBA的整体逻辑如图8所示，EBA强调的是“知行合一”，强调企业自己对方法论的驾驭和对架构师的培养，未来的企业管理必然包含架构管理，企业管理追求的“韧性”很可能将来自于架构的“弹性”和演化能力。
（二）EBA与DDD
方法之间的结合也是一个趋势，当然，结合是一件难度很高的事情，它的基本要求之一就是尝试结合者自己要对各个方法都有充分的了解和实践经验，并且能够让学习者可以掌握，因为对学习者而言，这意味着“1+1>2”的学习量。EBA方法在形成业务架构解决方案之后，本身对IT实现端采用的方法没有特殊的限制性要求，这也意味着进入IT实现端的需求分析阶段后，可以尝试采用DDD方法进行细化设计，因为二者都注重数据与行为的结合，EBA方法是通过流程模型与数据模型的结合进行表达的，DDD的实体表达方式则更为直接；二者都强调通用语言，只是范围上，
EBA是跨领域的通用语言，而DDD是限界上下文内部的通用语言；二者也都希望实现业务和技术两端都能理解的解决方案，也都非常关注业务含义对模型设计的影响。
但是二者也有区别，结合也有一些的困难要克服。一个比较直接的问题来自于数据模型，EBA方法注重对企业级数据模型的设计，企业级数据模型对数据治理有非常重要的作用，对大数据应用也有很直接的影响。数据模型通常的设计方式与DDD中对数据的处理有一些区别，二者在数据建模方面，对实体的定义有共同之处，比如应关注实体的业务含义，但是具体定义、实体大小的考量上，都会在实操层面有区别，而且，EBA方法比较提倡在企业层面的数据概念的抽象和统一，但是DDD是从领域出发考虑问题的，而且这个领域也不同于EBA中范围较大的领域概念，其限界上下文涵盖的范围可能很小，从而产生多个领域都有同名不同义的实体。
比如，Vaughn Vernon在《领域驱动设计精粹》一书第二章介绍的“保单”的例子，就是在承保、审核、理赔三个限界上下文中分别定义了“保单”实体，每个实体都有重复的部分和差异的部分，这样做的原因则是认为整合会造成一个过于臃肿的“超负荷”的“保单”实体。这样的实体也许大家在设计过程中也曾经遇到过，就是一个数据实体包含了过多的属性，导致数据层面没有很好地分离“关注点”。Chris Richardson在《微服务架构设计模式》一书的第二章中也给出了一个通过DDD处理类似问题的例子，就是对“上帝类”的拆分，“上帝类”作为全局类，可以为多个不同领域的应用调用，因而也就设计了包含不同领域的状态和行为的复杂结构，比如书中提到的“Order（订单）”，下单、送餐、付款等多个领域都会触发订单状态的转换，如果将丰富的行为打包成一个中央Order数据库，会导致微服务设计方面出现“紧耦合”，微服务之间不够独立；如果只保留一个纯数据服务的Order Service，又会成为“贫血模型”。其解决之道同样也是在不同领域定义同名不同义的Order。
这两个例子其实体现了与EBA很不同的处理方式，EBA希望实现企业级的数据模型定义，也即，在企业级范围内尽可能消除同名不同义的数据实体，所以，“保单”、“订单”在EBA中通常会处理为一个而非多个实体，那么解决实体过于庞大的问题，还是要依靠对数据实体的业务含义、业务能力的识别，因为按照领域的拆分本身也会存在弊端，就是企业级数据查询与应用的困难。
