春节前应“技术琐话”之约，试图写一篇讨论架构方法论的文章，然而动笔之后，才发现，自己似乎陷入了Frederick P. Brooks先生在《设计原本》一书中指出的问题：“设计中最困难的部分在于决定要设计什么”。
2020年1月18日，有人戏称是“中台”历史上最“困难”的一天，一篇炸圈的文章将对“中台”的讨论又一次推向高点，虽然“泼冷水”的意味十足。其实笔者之前也谈到过，“中台”自诞生伊始就非一个严谨的定义，而是一种比喻，比喻当然也就容易导致争论不休，“中台”现在面临的问题其实也和笔者动手写这篇文章面对的问题差不多。但是，将“中台”理论不断明晰化的尝试仍是个好事情，毕竟，这是国内企业掀起的一次对架构设计方法的有益探索。笔者在2019年11月南京中台大会上也曾讲到，如今很多领域都在谈国产化、自主可控，架构领域难道不需要吗？架构领域方法论的持续完善、国产理论的持续创新，是驾驭技术组合的关键，底层技术的不断自主化并不会必然带来顶层设计能力的自主化，而数字化转型，除了需要底层技术的支撑外，卓越的上层设计更是重中之重。走出有中国特色的数字化道路，底层技术能力与上层设计能力缺一不可。对企业级软件架构设计方法的研究需要所有人共同关注，它是在持续进化的，也是未来企业走向数字化过程中，实现业务与技术深度融合的必经之路。Brooks先生在同一本书还提到：“好的设计者应该投入大量精力来学习判例……但现代设计匆忙的节奏却对这种实现非常不利”，他写下此语是在10年前，今天，这种情况只能说是有过之而无不及吧。讨论架构问题永远是困难的，虽然笔者能力有限，但是出于对架构理论的爱好，还是尝试通过本文与各位读者共同探讨架构方法的演进与改良。
一、软件工程与企业架构
（一）懵懂的早期：没有工程、没有架构
架构设计是随着软件复杂度的上升而真正受到人们重视的。1946年，巨大的电子管计算机ENIAC诞生，软件行业的帷幕拉开，但是此后十几年的时间里，软件设计都只是少数人的事情，这个行业大部分时间都在实验室中发展。虽然高级语言出现，但是大多数程序设计人员的主要武器是汇编语言。模块化的思路逐渐出现，但是软件过程管理是很原始的，也没有所谓的架构设计方法，流行的就是“先写了再说”。
（二）方法的开始：瀑布模型和Zachman模型
混乱的管理方式引发了60-70年代的软件危机，于是，1968年NATO会议上，“软件工程”的概念首次被提出，其核心思想就是建立并使用完善的工程化原则，通过一系列方法，以较经济的手段获得能在实际机器上有效运行的可靠软件。这个“朴素”的目标，反映了软件行业早期存在的时间不可控、质量不可控、预算不可控等诸多问题造成的困扰。1970年，Winston Royce在《大型软件系统开发的管理》一文中，提出了“瀑布模型”，将开发分成如图1所示的7个明确的阶段：
Royce其实认为这是一个有风险的开发过程，并提出了5个修改建议，包括在分析阶段之前增加一个在信息不足条件下的预设计、开发过程中增加客户参与等，但是大家却把这个被他列为批评对象的“瀑布模型”作为开发的标准过程，包括美国国防部，他的建议却鲜为人知了。其中的分析阶段也就包括了架构设计工作，逐渐又被细分为概要设计和详细设计。但是这个时期的架构设计主要还是针对软件设计，还没有发展出成形的企业架构理论。随着人们对软件设计工作认识的不断深入，大型软件设计与企业管理的关系越来越紧密，这也体现了人们对软件设计的本质性目标——为企业服务的认知。基于此，1987年Zachman提出了首个较为完整的企业架构模型，该模型按照“5W1H”，即What（数据）、How（功能）、Where（网络）、Who（角色）、When（时间）、Why（动机）6个维度，结合目标范围、业务模型、信息系统模型、技术模型、详细展现、功能系统6个层次，将企业架构分成36个组成部分，描述了一个完整的企业架构要考虑的内容，如表1-1所示。
这个架构设计方法论已经将系统设计应支持企业经营管理目标的要求表达出来，但是该模型的一个不足是Zachman并没有给出一个详细的构建方法。
（三）成熟的进步：螺旋模型和TOGAF
1988年，软件工程上又一个里程碑式的方法诞生了，Barry Boehm提出了“螺旋模型”，该模型如图2所示：
螺旋模型通过持续对原型进行验证式、增量交付的方式，弥补“瀑布模型”在需求管理方面不足，是一种对需求的渐进式探索，也加强了对项目风险的管理。Brooks在2010年著书时仍对该模型赞赏有加。随着信息化程度的加深，企业越发认识到将IT融入企业管理的重要性，IT人员也意识到与业务结合的重要性，于是，1995年TOGAF（The Open Group Architecture Framework ，开放组体系结构框架）应运而生，业务架构的概念也被明确提出来。TOGAF认为企业架构分为业务架构和IT架构两大部分，业务架构是把企业的业务战略转化为日常运作的渠道，业务战略决定业务架构，它包括业务的运营模式、流程体系、组织结构、地域分布等内容，业务架构再作用于IT实现。TOGAF的设计交付物如表2所示：
可以看出，到TOGAF时代，在内容上，企业架构和业务架构发展的已经较为完善了；在工艺上，TOGAF也有明确的操作要求，也正是因为有详细的要求，TOGAF被公认的缺点之一就是太“重”，有点像是架构领域的“瀑布模型”。
从Zachman到TOGAF，尽管理论日臻成熟，但是企业架构设计与实际开发过程之间的结合一直不是很好，更像是在两条线上发展，表面看起来，Zachman模型似乎还能跟“瀑布模型”走得到一起，毕竟二者都被认为是“漫长”的，但大部分开发实际上在这个时期都是沿着“竖井式”的道路在走，仍旧缺乏对企业级设计的关心。至于TOGAF，它跟螺旋模型、迭代模型之间在实操上有不易结合之嫌，恐怕不少企业接受了应用TOGAF思路的咨询方案，却在实施过程中将其束之高阁了。尽管如此，TOGAF对推动企业架构发展的作用仍是非常大的。
