付老师这篇一万四千字的长文，有不少独创性的真知灼见。比如中台实施组合拳，不拘泥一家。EBA vs DDD等。在十万加爽文式快餐阅读更容易被follow的时代，本文重发，谨以此献给能读懂或者打算读懂的读者们。毕竟专业领域是有阅读门槛的。 小编按：
应技术琐话之约，试图写一篇讨论架构方法论的文章，然而动笔之后，才发现，自己似乎陷入了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并没有给出一个详细的构建方法。
