（五）小结：行路难
架构设计的思路到上个世纪70年代才逐渐开始发展出来，软件行业希望也能像工业、建筑业一样具有行业级的设计原则、标准，从而使高质量软件的产出得到保证。但是，到目前为止，架构之路殊为不易，还没有哪种方法升华为举世公认的原则或者榜样。
软件工程到今天才算年过半百，还是个比较年轻的领域。从“瀑布模型”进化到“螺旋模型”大约用了20年；敏捷开发快20岁了，DDD也有17岁；微服务虽然很年轻，才5岁，但是它的前身SOA是1996年诞生的。企业架构从Zachman模型诞生到现在是33岁，而TOGAF到现在也就25岁，只相当于软件工程的一半年纪。如此说来，这些方法以其要服务的目标领域而言，都还是只是刚刚进入“青年”这个水平。
然而上述方法我们至今仍在对其某一方面大加挞伐，没有一个是“银弹”，没有一个不曾被人骂做“坑”。但是贵在探索和坚持，这些方法经历时间的洗礼，仍未褪去“稚嫩”，仍需要“呵护”与反复实践才能健康成长。
现代社会的快节奏对架构的积累确实是一个挑战，“快”原本应该是目标，而今成了方法。我们对很多架构方法的理解尚不深入，对其应用也需要对方法创立者的初衷深加体会，比如，敏捷方法的创始人、“敏捷宣言”起草者之一的Jeff Sutherland在《敏捷革命》一书中提到其灵感来源的“OODA”方法，建议在每个冲刺中都要完整使用，但在各类敏捷书籍中却鲜有提及；Vernon也提到，无论是对敏捷方法还是对DDD而言，“知识获取”都至关重要，但是“知识获取”显然需要积累；即便是对口诛笔伐的“瀑布模型”，也一样存在众多误解。
抛去这些争议不谈，我们至少可以从软件工程与企业架构的发展历程中看到这样两个个趋势：一是关注点从软件架构向企业架构的进化，也就是对软件设计核心目标的认识，软件设计绝不是“先写了再说”，也不一定是越快越好；二是不同方法之间更明显的结合趋势，面向企业的软件设计是一个很复杂的事情，既然很难由某一个方法自己搞定，那就“抱团取暖”吧。
二、企业级业务架构（EBA）与“组合拳”
（一）关于EBA
上文谈到了架构演进的一个趋势，就是关注点从软件架构向企业架构的进化，这反映了技术在面对不断上升的业务复杂度时，对自身局限的认知。不深入了解业务和企业，就很难建立面向整个企业的系统规划，企业内部也就很难有效打通，事实上，比尔·盖茨先生1999年在《未来时速》中提出的为企业打造“数字神经”的想法，至今也还没能完全实现。
“数字神经”的打造跟理清企业架构是分不开的，如同给一个城市设计管道系统一样，它与城市的结构是要匹配和共同演进的。而企业架构中非常重要、技术人员又很难处理的，正是业务架构。业务架构在Zachman手中萌生，到TOGAF时明确，尽管那个定义还是挺难理解的。TOGAF将企业架构（EA）和业务架构（BA）都推向了一个新高度，并且给出了包含业务架构在内的著名的“4A”结构，但是其实施难度一直饱受争议，由于周期通常较长，分析业务架构能够投入的业务人员就是有限甚至很难保证的，当然，这与企业自身的实施决心也有关。
国外有些基于BA的成功案例，比如US Patent and Trademark Office（USPTO）于2013年启动了TMNG（Trademark Next 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所示：
如图8所示，EBA强调的是“知行合一”，强调企业自己对方法论的驾驭和对架构师的培养，未来的企业管理必然包含架构管理，企业管理追求的“韧性”很可能将来自于架构的“弹性”和演化能力。
EBA方法也是一个业务架构设计与IT实现之间不断迭代的过程，如图9所示：
