注：本文为 “软件架构演变” 相关文章合辑。

英文引文机翻，未校。

---

Evolution of Software Architecture: From Mainframes and Monoliths to Distributed Computing

Liv Wong
Technical Writer
August 06, 2024

Software architecture—the blueprint of our digital world—has evolved tremendously since the dawn of the computer age in the mid-20th century. The early 1960s and 70s were dominated by mainframes and monolithic software. Today, the digital landscape looks entirely different, running on a distributed web of cloud computing, API connectivity, AI algorithms, microservices, and orchestration platforming.

自 20 世纪中叶计算机时代到来以来，软件架构 — 我们数字世界的蓝图 — 已经发生了巨大的变化。1960 年代初和 70 年代由大型机和单体软件主导。如今，数字环境看起来完全不同，它们在云计算、API 连接、AI 算法、微服务和编排平台的分布式 Web 上运行。

How has software architecture evolved over the years? As we revisit the technological progress through the decades, we will see how changes in business needs, market trends, and engineering practices have impacted software architecture.
这些年来，软件架构是如何演变的？当我们重新审视几十年来的技术进步时，我们将看到业务需求、市场趋势和工程实践的变化如何影响软件架构。

Mainframes and monoliths: ~1940s

大型机和巨型机：~1940 年代

The first computers were mainframe computers—large, powerful hardware machines that took up an entire room. Mainframes originated as standalone machines that could run complex computing tasks. Prior to the 1970s, instructions to mainframe computers were sent via punchcards or magnetic tape, and the output received via printers.
第一台计算机是大型计算机 — 占用整个房间的大型功能强大的硬件计算机。大型机起源于可以运行复杂计算任务的独立机器。在 1970 年代之前，向主机发送的指令通过穿孔卡或磁带发送，输出通过打印机接收。

Prior to the 1970s, data centers held mainframes that accepted instructions through punchcards or magnetic tape. Credit: unknown.

The first mainframes, Harvard Mark I and ENIAC, were developed for military and research purposes in the 1930s-1940s. In 1948, the first commercial mainframe was introduced to the world: UNIVAC. The following decades saw widespread adoption by banking, financial, and airline sectors for the mainframe’s outstanding ability in batch processing transactional data. Many of these systems still remain in operation today.
第一台主机 Harvard Mark I 和 ENIAC 是在 1930 年代至 1940 年代为军事和研究目的而开发的。1948 年，第一台商用主机问世：UNIVAC。在接下来的几十年里，银行、金融和航空部门广泛采用大型机在批处理事务数据方面的出色能力。其中许多系统至今仍在运行。

Mainframe applications were programmed in COBOL (Common Business-Oriented Language), which remains popular amongst mainframers even today. The software architecture for these applications was monolithic, which meant a single, unified codebase that contained the data schema, application methods, database connections, presentation logic, and so on without modularization. To update any of these components, developers would have to access the entire codebase and redeploy it in a single package.
大型机应用程序使用 COBOL（通用面向业务的语言）进行编程，即使在今天，这种语言在大型机中仍然很受欢迎。这些应用程序的软件架构是整体式的，这意味着一个单一的统一代码库，其中包含数据架构、应用程序方法、数据库连接、表示逻辑等，而无需模块化。要更新这些组件中的任何一个，开发人员必须访问整个代码库并将其重新部署到单个包中。

Monolithic architecture.

Networks and client-server: ~1950s

网络和客户端-服务器：~1950 年代

Networks connect and facilitate communication between computers—mainframe to terminal, mainframe to mainframe, and later client to server. The development of network technology from 1958 onwards enabled mainframes to be connected electronically, transforming them into multi-user computers that were connected to multiple terminals. Instead of punchcards and printers, people could use a monitor, keyboard, and a command-line interface (CLI) to send and receive data.
网络连接并促进计算机之间的通信 — 大型机到终端、大型机到大型机，以及后来的客户端到服务器。从 1958 年开始，网络技术的发展使主机能够以电子方式连接，将它们转变为连接到多个终端的多用户计算机。人们可以使用显示器、键盘和命令行界面 （CLI） 来发送和接收数据，而不是穿孔卡和打印机。

Technological limitations restricted the first few connected computer systems. Multiplex mainframes, for example, could only be used locally as the cable length meant that the terminals had to be positioned very close to the mainframe. These early data centers contained not just computers, but dozens of humans sending jobs to the mainframe.
技术限制限制了最初几个连接的计算机系统。例如，多路复用主机只能在本地使用，因为电缆长度意味着端子必须非常靠近主机。这些早期的数据中心不仅包含计算机，还包含数十个将作业发送到大型机的人。

ARPANET was the first public, wide-area computer network, going live in 1969. It communicated data using packet switching, which went on to serve as the foundation for modern-day Internet as we know it.
ARPANET 是第一个公共广域计算机网络，于 1969 年上线。它使用分组交换来传输数据，这后来成为我们所知道的现代互联网的基础。

Network technology popularized the client-server structure in the 1980s, where an application is divided into a server software and a client software that communicates over a computer network. This structure is familiar to us today: a client, typically a desktop computer, remotely makes a request to a server, which returns a response. With the distribution of computing resources, the server handled data processing and retrieval while the client dealt with the presentation of the data.
网络技术在 1980 年代普及了客户端-服务器结构，其中应用程序分为服务器软件和通过计算机网络进行通信的客户端软件。这种结构今天对我们来说很熟悉：客户端（通常是台式计算机）远程向服务器发出请求，服务器返回响应。通过分配计算资源，服务器处理数据处理和检索，而客户端处理数据的呈现。

Client-server architecture.

The first client-server applications were mail services, web servers, and other desktop applications with online capabilities. Today, client-server has become the standard paradigm for most applications, and more broadly encompasses a general model of a service requester and a service provider.
第一个客户端-服务器应用程序是邮件服务、Web 服务器和其他具有联机功能的桌面应用程序。今天，客户端-服务器已经成为大多数应用程序的标准范例，并且更广泛地包括服务请求者和服务提供商的一般模型。

Despite the two-tier separation, many such applications were still built in a monolithic fashion. All application features resided in a single codebase, tightly coupled, and shared access to a single database.
尽管有两层分离，但许多此类应用程序仍然是以整体方式构建的。所有应用程序功能都驻留在单个代码库中，紧密耦合，并共享对单个数据库的访问。

WWW, websites, and webapps: ~1980s

WWW、网站和 Web 应用程序：~1980 年代

1983 marked the year of the Internet. The Internet was a global system of computer networks that used the TCP/IP protocol to facilitate communication between devices and applications. This was the backbone for FTP programs, SSH systems, and of course, the World Wide Web (WWW).
1983 年是互联网之年。Internet 是一个全球性的计算机系统，它使用 TCP/IP 协议来促进设备和应用程序之间的通信。这是 FTP 程序、SSH 系统，当然还有万维网 （WWW） 的支柱。

Although the Internet and WWW are used interchangeably today, the WWW was invented almost a decade later, in 1990. The WWW is an information system—a web of HTML content connected by links—shared and organized over the Internet using the HTTP protocol. It was a revolutionary way of storing information such that it could be accessed globally, paving the road for the era of websites and web programming.
尽管 Internet 和 WWW 今天可以互换使用，但 WWW 是在近十年后的 1990 年发明的。WWW 是一个信息系统，即通过链接连接的 HTML 内容 Web，使用 HTTP 协议在 Internet 上共享和组织。这是一种革命性的信息存储方式，因此可以在全球范围内访问，为网站和网络编程时代铺平了道路。

In the early days, websites were static pages that displayed data from the web server. The introduction of the Common Gateway Interface (CGI) in 1993 brought web interactivity to the fore, kickstarting the prospects of web applications.
在早期，网站是显示来自 Web 服务器的数据的静态页面。1993 年引入的通用网关接口 （CGI） 使 Web 交互性脱颖而出，开启了 Web 应用程序的前景。

Fledging web interactivity took off with the invention of JavaScript in 1995, which brought scripting logic onto the client side. JavaScript quickly became the new standard for web programming, and web servers could more easily deliver dynamic, interactive content. These were the early forums, bulletin boards, and web forms.
随着 1995 年 JavaScript 的发明，新兴的 Web 交互性开始腾飞，它将脚本逻辑带到了客户端。JavaScript 很快成为 Web 编程的新标准，Web 服务器可以更轻松地提供动态的交互式内容。这些是早期的论坛、公告板和 Web 表单。

The invention of the web and its latent possibilities soon kicked off the next wave of application development. Instead of building a dedicated client for your application, you could simply build a website to be hosted on the web.
Web 的发明及其潜在可能性很快拉开了下一波应用程序开发的序幕。您无需为您的应用程序构建专用客户端，只需构建一个托管在 Web 上的网站即可。

Service-oriented architecture and web services: ~1990s

面向服务的架构和 Web 服务：~1990 年代

As application development grew, a monolithic codebase became more unwieldy to manage, and it became clear that capabilities or data housed in one system could be reused in another.
随着应用程序开发的发展，整体式代码库变得越来越难以管理，很明显，一个系统中的功能或数据可以在另一个系统中重复使用。

To address these challenges, modularization became a topic of discussion. In the 1990s, the server side was further split into two tiers: the application server and the database. The application server stored all the application and business logic, while the database server stored the data records, which reduced latency at high processing volumes.
为了应对这些挑战，模块化成为讨论的话题。在 1990 年代，服务器端进一步分为两层：应用程序服务器和数据库。应用程序服务器存储所有应用程序和业务逻辑，而数据库服务器存储数据记录，从而减少了高处理量时的延迟。

Around the same time, service-oriented architecture (SOA) emerged as an architectural pattern where software capabilities are designed as individual services that can be used with any system as long as the system followed its usage specification. SOA encouraged a move towards developing enterprise applications as loosely coupled services that interact through a communication protocol over a network, a pattern that has remained dominant today.
大约在同一时间，面向服务的架构 （SOA） 作为一种架构模式出现，其中软件功能被设计为单独的服务，只要系统遵循其使用规范，就可以与任何系统一起使用。SOA 鼓励将企业应用程序开发为松散耦合的服务，这些服务通过网络上的通信协议进行交互，这种模式今天仍然占主导地位。

Under SOA, a shopping app would contain multiple services: one for inventory tracking, another for order processing, and yet another for user authentication. Unlike a microservice-based application, services in an SOA pattern still share the same database, through the application layer.
在 SOA 下，购物应用程序将包含多个服务：一个用于库存跟踪，另一个用于订单处理，还有一个用于用户身份验证。与基于微服务的应用程序不同，SOA 模式中的服务仍然通过应用程序层共享同一个数据库。

Service-oriented architecture (SOA).

With SOA, came the need to define set standards and protocols for how these services interacted with all sorts of clients. DCOM and CORBA were some non-web-based standards soon overshadowed by web-based ones like SOAP and REST APIs. SOA offered a way for services from different providers to be integrated into one application or for the same services to be utilized on different clients, like a web portal or a dedicated desktop interface.
随着 SOA 的出现，需要为这些服务如何与各种客户端交互定义固定的标准和协议。DCOM 和 CORBA 是一些非基于 Web 的标准，很快就被 SOAP 和 REST API 等基于 Web 的标准所掩盖。SOA 提供了一种方法，可以将来自不同提供商的服务集成到一个应用程序中，或者将相同的服务用于不同的客户端，如 Web 门户或专用桌面界面。

Virtual machines and cloud computing: ~2000s

虚拟机和云计算：~2000 年代

SOA set the stage for the move from traditional desktop applications to a new mode of software applications—SaaS—but it was the invention of virtual machines and cloud computing that further spurred the explosion of SaaS products in the coming decades.
SOA 为从传统桌面应用程序转向新的软件应用程序模式 SaaS 奠定了基础，但虚拟机和云计算的发明进一步刺激了未来几十年 SaaS 产品的爆炸式增长。

Virtual machines, enabled by the hypervisor, are computer systems that exist on the software layer instead of as a physical machine. Using virtual machines, it became much easier to create, update, and destroy multiple machines that run different operating systems on a single computer, maximizing resource allocation and utilization for application development.
由虚拟机管理程序启用的虚拟机是存在于软件层而不是物理机上的计算机系统。使用虚拟机，可以更轻松地创建、更新和销毁在单台计算机上运行不同操作系统的多台计算机，从而最大限度地提高应用程序开发的资源分配和利用率。

Virtual machine infrastructure.

Although machine virtualization has existed since the 1960s, it only came into mainstream use in the 2ooos with the rapid succession of releases by Linux, Microsoft, and VMware. This was the period when companies like Amazon identified the lucrative opportunity that virtualization offered: managed cloud computing services. Physical bare metal machines are expensive and difficult to manage, a limiting factor when companies want to scale. With cloud computing services like Amazon EC2, companies could rent virtual machines for processing power and scale as required.
尽管机器虚拟化自 1960 年代就已经存在，但随着 Linux、Microsoft 和 VMware 的快速接连发布，它才在 2ooos 中成为主流使用。正是在这个时期，像 Amazon 这样的公司发现了虚拟化提供的有利可图的机会：托管云计算服务。物理裸机成本高昂且难以管理，这是公司想要扩展时的限制因素。借助 Amazon EC2 等云计算服务，公司可以根据需要租用虚拟机来提高处理能力和扩展能力。

Growing companies like Facebook and Netflix could truly focus on building out their software capabilities without needing to maintain the underlying hardware of bare metal machines and data centers. The technical overhead to get started became much lower, accelerating the next wave of startups and digital-native businesses in the coming decades. In turn, this unlocked the next step in distributed computing and software architecture: microservices.
像 Facebook 和 Netflix 这样的成长型公司可以真正专注于构建他们的软件功能，而无需维护裸机机器和数据中心的底层硬件。起步的技术开销大大降低，从而加速了未来几十年的下一波初创公司和数字原生企业浪潮。反过来，这开启了分布式计算和软件架构的下一步：微服务。

APIs, containers, and the rise of microservices: ~2010s

API、容器和微服务的兴起：~2010 年代

The 2010s were the culmination of multiple trends towards distributed computing. Fueled by the need for third-party access to their services, the first few commercial APIs were launched in 2000 by Salesforce and eBay, enabling their partners or customers to integrate features onto their own sites or applications. From Twitter and Google Maps to Stripe, Twilio, and now OpenAI, the API economy has ballooned since, powering integrated features across the web.
2010 年代是分布式计算的多种趋势的高潮。在第三方访问其服务的需求的推动下，Salesforce 和 eBay 于 2000 年推出了最初的几个商业 API，使他们的合作伙伴或客户能够将功能集成到他们自己的网站或应用程序中。从 Twitter 和 Google 地图到 Stripe、Twilio，再到现在的 OpenAI，API 经济从那时起迅速发展，为整个 Web 的集成功能提供支持。

In the same vein, microservices took off when scaling companies like Amazon and Netflix needed to speed up and streamline the development cycle, which was slowed down by a monolithic codebase. By splitting up an application into individual microservices, each with its own database, teams could independently update and deploy them, leading to faster releases and improvements.
同样，当 Amazon 和 Netflix 等扩展公司需要加快和简化开发周期时，微服务开始起飞，而单体代码库会减慢开发周期。通过将应用程序拆分为单独的微服务，每个微服务都有自己的数据库，团队可以独立更新和部署它们，从而加快发布和改进速度。

Microservice-based infrastructure.

While there are many ways to package and deploy microservices—on a physical or virtual machine—the growth in microservice-based architecture was supported by the emergence of containers. Like virtual machines, containers were an abstraction layer conceptualized in the 1970s, but only launched into enterprise recognition after 2013 when Docker was made open-source.
虽然在物理机或虚拟机上打包和部署微服务的方法有很多种，但容器的出现支持了基于微服务的架构的增长。与虚拟机一样，容器是 1970 年代概念化的抽象层，但直到 2013 年 Docker 开源后才推出企业认可。

Compared to virtual machines, containers provide a greater level of compartmentalization, so multiple instances and versions of the same application can run on the same operating system. All the components needed to run an application—code, run time, libraries, dependencies, and system tools—are stored within the container, offering greater portability and scalability for deploying applications or microservices.
与虚拟机相比，容器提供了更高级别的划分，因此同一应用程序的多个实例和版本可以在同一操作系统上运行。运行应用程序所需的所有组件（代码、运行时、库、依赖项和系统工具）都存储在容器中，为部署应用程序或微服务提供了更高的可移植性和可扩展性。

Containers.

With a patchwork of native or third-party services, databases, and so on, modern application development now requires a robust way to architect and integrate these different components. This brings us to the software architecture of today: orchestration and event systems.
由于本机或第三方服务、数据库等拼凑在一起，现代应用程序开发现在需要一种强大的方法来构建和集成这些不同的组件。这就引出了当今的软件架构：编排和事件系统。

Orchestration, eventing systems, and solving for distributed interdependency: today

编排、事件系统和解决分布式相互依赖性：今天

With a distributed model of computing—microservices, APIs, and SOA to a degree—comes a pertinent problem in software architecture: how will these separate services, databases, and components communicate and interact with each other to flow cohesively?
分布式计算模型（在一定程度上是微服务、API 和 SOA）在软件架构中带来了一个相关问题：这些独立的服务、数据库和组件将如何相互通信和交互以紧密流动？

There are two main approaches to resolving the issue of interdependency between distributed services: event-driven architecture and orchestration.
解决分布式服务之间的相互依赖关系问题有两种主要方法：事件驱动架构和编排。

Event-driven architecture

事件驱动型架构

In an event-driven architecture, services push data into a service bus or event pipeline for any other connected service to read and execute if necessary. The overall system responds to events or state changes without keeping track of the impact of individual events on other events, thus reducing interdependency between each service.
在事件驱动型架构中，服务将数据推送到服务总线或事件管道中，供任何其他连接的服务在必要时读取和执行。整个系统响应事件或状态更改，而不跟踪单个事件对其他事件的影响，从而减少每个服务之间的相互依赖关系。

While the concept of a service bus has been around since the emergence of SOA, the trend towards microservices has brought it even further to the fore, with the likes of Kafka and Amazon SQS. An event-driven system enables real-time updates and improved system responsiveness while unlocking increased throughput in parallel processing. This has powered systems with fast-changing updates, such as ride-hailing or airline transactions.
虽然服务总线的概念自 SOA 出现以来就已经存在，但微服务的趋势使其进一步突出，例如 Kafka 和 Amazon SQS。事件驱动型系统可实现实时更新并提高系统响应能力，同时在并行处理中释放更高的吞吐量。这为系统提供了快速变化的更新，例如叫车或航空公司交易。

Event-driven architecture.

However, event streams do not provide insight into the overall state of the system and the progress of a process across distributed services. The lack of state tracking and visibility poses significant challenges when it comes to debugging and troubleshooting, as well as implementing error handling and resilience mechanisms. Designing an event stream that can properly handle sequential processes when there is no in-built chronology may end up overly complicated, requiring careful consideration of the event flow, routing, and handling.
但是，事件流无法深入了解系统的整体状态和跨分布式服务的流程进度。缺乏状态跟踪和可见性，在调试和故障排除以及实施错误处理和弹性机制方面带来了重大挑战。在没有内置年表的情况下，设计一个可以正确处理顺序流程的事件流最终可能会过于复杂，需要仔细考虑事件流、路由和处理。

Orchestration

编排

Orchestration offers another viable solution to resolving the problem of microservice interdependency and even the issues encountered in event-driven architecture. In orchestration, a central orchestrator schedules each task or microservice based on a predefined flow, only proceeding to the next task in sequence when the previous one has been completed successfully. Unlike event streams, the orchestrator tracks the overall progress across each service, empowering developers to easily trace and debug errors and implement failure compensation.
编排为解决微服务相互依赖问题，甚至事件驱动架构中遇到的问题提供了另一种可行的解决方案。在编排中，中央编排器根据预定义的流程安排每个任务或微服务，只有在前一个任务成功完成后，才会按顺序继续执行下一个任务。与事件流不同，编排器可以跟踪每个服务的整体进度，使开发人员能够轻松跟踪和调试错误并实施故障补偿。

Orchestration.

The orchestration layer forms an integral level of abstraction that coordinates separate services, databases, event streams, LLMs, and other components into a concerted process. From ease of integration to ease of tracking and troubleshooting, orchestration empowers developers to architect applications across the entire development lifecycle, seizing the world of software development with the likes of Orkes Conductor and Airflow. The durability of orchestration has streamlined many complex workflows, such as automating infrastructure upgrades or processing shipment orders over long periods of time.
编排层形成一个完整的抽象级别，将单独的服务、数据库、事件流、LLM 和其他组件协调到一个协同流程中。从易于集成到易于跟踪和故障排除，编排使开发人员能够在整个开发生命周期中构建应用程序，从而通过 Orkes Conductor 和 Airflow 等产品抢占软件开发的世界。编排的持久性简化了许多复杂的工作流程，例如自动化基础设施升级或长时间处理货运订单。

We leave the history of software architecture at this juncture: orchestration as an architectural layer that unlocks the next step in distributed computing.
在这个关头，我们离开软件架构的历史：编排作为一个架构层，解锁分布式计算的下一步。

Summary 总结

Throughout the past century, technology has advanced in leaps and bounds from mainframes and networks to virtual machines, containers, and genAI capabilities today.
在过去的一个世纪里，技术突飞猛进，从大型机和网络到今天的虚拟机、容器和 genAI 功能。

The tech stack over the years.

Looking ahead, software architecture will continue to evolve, shaped by advances in technology and the changing needs of businesses. For software architects and developers, it is more important than ever to adopt and adapt to better paradigms without losing sight of the core principles of good design. Ultimately, the best software architecture is one that best suits your business and product requirements.
展望未来，软件架构将继续发展，受到技术进步和不断变化的业务需求的影响。对于软件架构师和开发人员来说，在不忽视优秀设计的核心原则的情况下采用和适应更好的范式比以往任何时候都更加重要。归根结底，最好的软件架构是最适合您的业务和产品要求的架构。

---

软件架构 50 年：大模型是否开启新的抽象层次？ACM 院士、UML 创始人谈软件架构演变

InfoQ 2024年12月28日 10:16 湖北
作者 | Gergely Orosz、Grady Booch
译者 | 核子可乐
策划 | Tina

整个软件工程的发展史，就是一段抽象层次不断提升的历史。我们如今正在见证又一个抽象层次的出现，它为我们带来了极其强大的框架，帮助我们以此为基础构建新的系统。之前我也曾反复提到，以往我们最关注的架构决策同样在新的框架中有所体现，进而引发新的决策需求：我应该使用什么样的云服务？应该使用什么样的消息系统？又应该使用什么样的平台？

这些决策涉及一系列经济因素，而不仅仅是与软件相关。我认为架构师的角色已经发生了变化，因为我们现在已经开始解决系统层面的问题，而不再局限于软件问题。Grady Booch 是软件工程领域的先驱，早在 57 年前，年仅 12 岁的他就制造了自己的第一台电脑，并凭借随后数十年来在软件工程和软件架构领域的卓越贡献而广受爱戴。作为 UML 的联合缔造者，他还开创了面向对象设计的术语和实践。

身为 IBM 院士、ACM 和 IEEE 院士，他凭借自己在软件架构方面的工作获得了一系列知名奖项。他出版过六本著作并发表了 100 多篇软件工程技术论文。在本次访谈中，我们将探讨软件工程的最初两个黄金时代、UML 的建立过程，以及 Grady 为何不认同 UML 自 1.0 版以来的发展方式。此外，访谈还将涉及软件架构实践随时间推移的变化，Grady 对于大语言模型的看法，更多趣闻（例如比尔 - 盖茨曾邀请 Grady 出任微软公司首席架构师，但被其婉拒）等等。总之，本期访谈节目是一次对话传奇软件技术领袖的宝贵机会，让我们共同开启这段旅程吧。

软件开发领域的演变

问：您最为人所知的身份自然就是 IBM 公司的首席科学家。这是个非常耀眼的光环，那担任 IBM 公司首席科学家到底是种怎样的体验？之所以说非常耀眼，是因为我们很难想象你日常工作具体要做什么。

Grady Booch： 嗐，只是个职务罢了，不用太过较真。我还打算在名片上还写我是个自由激进分子呢，但高层管理者显然不希望我这么搞。

所以我只能选择更为温和的表述。实际上，我自己最重要的头衔 / 职务就是研究员，或者叫院士。当前在世的 IBM 院士大概有 68 个人，哦不，是 89 个。而 IBM 在整个发展史上一共出现过大约 350 名院士。

所以说我们这帮人还有点稀缺。2003 年，我们公司 Rational Software 被收购之后，我就被 IBM 任命为院士。成为院士的一大好处，在于它很像某种终身职位——代表企业对于我们个人的信任，类似于“你之前做得很好，我们希望你能继续保持下去，而且愿意为你给予一定的自由发挥空间。”身为一名院士，我专注于软件工程方向，后来又把注意力转向了人工智能，因此我有很大的自由来追求自己认为有意义的东西。正如 Alan Kay 所说，要去“创造未来”。在我的职业生涯中，从 2003 年开始，我先是留在 Rational 部门一段时间，但很快就转到了研究部门，因为 IBM 的高管团队意识到我是那种关注未来五到十年趋势、而不仅仅是下个季度问题的人。

事实上，我早期研究工作的重点就是努力想要以自动化方式发现遗留软件系统中的模式。那时候神经网络还没有出现，所以这虽然是个相当有趣的探索方向，但很遗憾始终没能取得任何进展。这毕竟是个颇具挑战性的问题。因此，我们开始更多从架构角度开展工作。我曾与许多客户展开合作，在几十年的职业生涯中四处空降，响应客户们提出的“请帮我解决这个特殊的架构问题，魔法师先生。”

对我来说，最令人兴奋的一点，就是几十年来我几乎参与到自己所能想象的一切领域的项目当中。好像是在 2010 年左右，我开始被 AI 领域重新吸引。

问：您刚刚提到自己在遗留系统上工作，那对你来说何谓遗留系统？

Grady Booch： 这确实需要明确定义，毕竟当我们写下一行代码的瞬间，它其实就成了遗留系统，直到我们最终将其废弃。

所以在某种程度上讲，所有代码都可以被称为遗留系统。Facebook 是个遗留系统，谷歌也是，就连 OpenAI 也面临遗留系统问题。而现实情况也确实如此，陈旧代码永远无法被彻底消灭。哪怕再怎么努力，只要我们构建出某些有用的东西，它就会持续存在并最终成为遗留的包袱。而在另一方面，除非代码的设计之初就充分考虑到可废弃性，否则必然会有一部分代码难以甚至根本不可变动——这对应的就是成本，是一定程度上的技术债。看看那些大型金融机构就明白了，这些组织从 20 世纪 60 年代开始就在使用代码库。我还跟美国国税局有过一次接触，他们希望对自己上世纪 60 年代开发的技术系统进行现代化改造。

那现在我们就回顾一下，上世纪 60 年代究竟发生了什么。为什么大家技术现代化的改造目标总是集中在这个时代的系统上？60 年代，人口不断增加，社会保障持续提升，许多组织中都诞生了大量文职工作。

因此到 20 世纪 60 年代中后期，银行和政府意识到工作实在太多、根本无法手动管理。为什么过去银行下午 3 点就要关门？因为他们得留出时间让人类雇员核对账目。美国国税局的情况也很相似。20 世纪 60 年代，有那么一段时期也掀起过人力流程自动化的浪潮，而其中大部分系统是由 IBM 360 汇编语言所编写的。

时间快进到当下：美国国税局系统中仍有大量使用 IBM 360 汇编语言编写的代码，它们运行在模拟器之上。而这就带来了极其艰难的挑战，因为其中某些代码体现的是嵌入在汇编语言本体中的业务规则。那么，我们要如何扭转这种状况？答案是，恐怕只能领先堆人力的方式慢慢解决，也就是将旧有代码转换为 COBOL 汇编语言，以使其能够在现代技术上运行。单纯模拟能够达成的效果已经非常有限。

但大家也知道，下令每年都会制定出新的商业规则。那金融机构又该如何跟上时代变化的脚步？这是个真实存在的遗留问题。Facebook 的代码虽然没有那么久远，但面临的问题是相同的。谷歌这边也是一样。甚至还很年轻的 OpenAI 也将很快被这个问题所困扰。

问：在说起空降到不同类型的企业帮助他们解决问题时，能不能具体介绍一下多年来您曾经跟哪些公司合作过，具体帮助他们处理了哪些架构、遗留代码和技术债难题？

Grady Booch： 你能想到的几乎每个领域我都接触过。毕竟我从来也那么多年了，经常会跟包括金融服务和国防部门在内的各行各业打交道。实际上，追溯到很久之前，复杂系统并非起源于商业领域，而是率先部署在国防产业当中。其实整个现代计算体系都诞生于此，也就是在第二次世界大战和冷战环境下孕育出的 SAGE 系统——即半自动地面防空系统。其出现在 20 世纪 50 年代，一直运行到 20 世纪 80 年代。这套系统的建立目标非常明确，就是为了应对苏联轰炸机飞越北极、直插美国本土的威胁。当时我们还没有卫星，雷达也不够普及，而这套系统也引发了后来大家常说的第一次软件危机。

这样的战略迫切性促成了北约会议的召开，来自世界各地的一群计算机科学家聚集起来讨论如何解决这一重大威胁。在我看来，这就是软件工程第一个黄金时代的巅峰，而一切就源自国防系统。后面我也接触过很多其他实时系统，比如心脏起搏器、地铁系统乃至 CT 扫描系统等等。总之但凡是大家能想象到的领域，我可能或多或少都有接触并参与其中。詹姆斯·韦伯太空望远镜目前在其设计中就用到时了 UML，这真是太酷了。

问：回顾过去几十年的发展，你明显参与到一系列关键技术的发明当中，而相关成果如今也得到了广泛普及。这又是一种什么样的体验？

Grady Booch： 前面我提到了所谓“软件工程黄金时代”的概念。这个时期包括函数式语言，或者更准确地讲，应该叫算法语言，比如 Fortran、COBOl、APL 以及 Lisp 等等。尽管 Lisp 在某种程度上应该算是一种多模语言，而我们拆分系统的主要方式则是依靠算法。因此，我们见证了结构化分析与设计技术的兴起，这在当时都有着非常重要的进步意义。

但这又带来了新的问题，因为当时的软件系统最大的短板在于其并非分布式，而采取的是单体式架构。那么，我们要如何才能构建起越来越大、可持续且经济可行的系统？随着我们看到分布式系统的兴起，软件工程的第一个黄金时代也开始发生变化。有趣的是，这种崛起并非发生在商业世界，反而率先出现在国防领域。ARPANET 阿帕网就是由政府部门提供资助，特别是 DARPA。

我之前曾介绍过，我在 1979 年注册了自己的第一个电子邮件地址，那时候使用电子邮件的用户还不多。实际上，这里也有个小故事。当 ARPANET 刚刚出现时，我正在空军学院任教。当时组织会印发一份小小的手册，里面列出了世界上所有的电子邮件地址。没错，全部电子邮件用户就只有几千人。

所以我能随时查阅他们到底是谁。这真是段神奇的经历。第一个分布式系统就是在这个领域开发完成的。事实上，在范登堡，我还开发过一套名叫遥测综合处理系统的项目，这是一个由大约 32 台微型计算机构成的封闭网络。微型计算机那会才刚刚流行起来。因此，如何将一个更大的系统拆分成多个分布式部分，成为困扰许多人的又一个重大问题。

当时这一切还没有进入商业领域，因此软件行业的人们开始意识到，单凭算法拆分所能做到的事情终究是有限的。结果就是，开发下一代软件的压力开始迅速涌现：分布式、实时、多语言、能够在各种计算机上运行的软件。我们必须解决分布式系统中方方面面的难题，包括它们可能会在不同时间出现故障，以及通信问题及其他相关挑战。

这让我们意识到，必须要以与以往截然不同的方式重新审视软件。研究期间发生的另一件大事，就是 Simula 和 Smalltalk 等语言的兴起，它们开始从根本上不同于以往的角度看待世界。时间来到 20 世纪 70 年代末，当时我 20 多岁，空军学院的一位前任教官问我，“Grady，你能帮助国防部学会使用 Ada 这种新型编程语言，以便将其应用于现代软件工程技术吗？”政府为什么会关心这个问题？因为当时软件对于国防部来说非常重要，甚至可以说对整个联邦政府来说都构成了重大难题，因为同时有几千种语言被付诸使用，而且数量还在快速增长。Fortran 和 COBOL 在某些场景下表现不错，但仍然无法适应全部应用需求。

所以就有了开发一种新语言来统领所有语言的决定，这就是 Ada 编程语言。Ada 远远领先于它出现的那个时代，这是一种受 Simula、Smalltalk 以及其他语言启发而来的新语种，在吸收了 Liskov 和 Guttag 等提出的抽象数据类型概念的同时，也引入了 David Parnas 的信息隐藏思想。所有这些概念在当时都还很新，但如今已经成为我们运营体系中的基础组成部分。

总而言之，当时整个软件行业并不了解要如何实现这样一个前所未有的目标。于是 Booch 方法，也就是面向对象的软件开发方法诞生了。从 1979 年到 1981 年左右，我在美国各地奔波，帮助联邦政府和承包商尝试以新的方式运用 Ada 这种新语言，这也标志着软件工程第二个黄金时代的开启。在当时，算法的复杂性已经不那么重要，人们更多开始关注系统工程问题，强调处理当时还刚刚出现的分布式系统。

而这也是 Booch 方法的精髓，其中蕴藏的正是我在帮助各类组织为新领域、新语言构建系统时积累下来的知识。

问：那您能不能解释一下什么是 Booch 方法？我只知道它跟面向对象编程有关，但作为这种方法的发明者，请您具体介绍一下这个概念及其重要意义。

Grady Booch： 要说清这个问题，咱们就得从柏拉图讲起。我不是那个时代的人，但我读过不少柏拉图的文章，他的《对话录》讨论了如何更好地认识这个世界。我们到底该把世界看作是一个个原子、还是一个个过程？软件工程的第一个黄金时代，明显更关注过程和算法。

但同时还有另外一种与之平行的认识世界的方式，那就是通过原子来观察现实。我们可以将原子理解成软件工程中的类和对象。所以说，我其实是受到了抽象数据类型理论、柏拉图以及当时出现的许多其他有趣哲学概念的影响，这些概念促使我们以完全不同的方式看待这个世界。Booch 方法实际上就是在将这一切进行规范化，比如我们以基于类和对象、而非基于算法的方式拆分系统？同样的，我也受到了 Liskov、Parnas、Dijkstra 和 Hoare 等人的影响。这些名字现在的年轻人们可能不太熟悉，但他们代表的就是软件工程领域的第一代和第二代理论基础。

Booch 方法的本质就是提供一种认识世界的新方式，强调我们不应该只关注算法，而应该考虑数据和流程与算法组合而成的具有凝聚力的实体，也就是如今大家熟知的类。我们做对了一些事情，也做错了一些事情。我认为我们做得最好的是，类在抽象方面表现出色，而做错的部分则是过分强调了继承的概念。

继承的意义在于节省代码，因为这样我们就可以构建泛化机制。然而事实证明这并没有多大意义，因为我们最终创造出许多不同类型的抽象。但没关系，时间快进到当下，人们会不屑地表示“这有什么区别吗？”确实，生活在水中的鱼感受不到水的存在，业已存在的规范也压根不需要开发者额外去费神思考。

以 Redis 为例，大家可能都习惯了以它为基础再构建自己的项目。但如果认真分析，就会发现 Redis 提供的其实是一组抽象。这些抽象是基于类的，再被集成至相应的系统当中。简而言之，Booch 方法不再通过算法来认识世界，而是通过对象和类来认识世界。

我要强调的最后一点是，Booch 方法还暗含着从多个角度看待系统的概念，而这个概念在 UML 中并没有得到完全实现。

问：之所以需要专门澄清，是因为包括我在内，我们的大多数听众都是在 Booch 方法出现了很多年之后才开始自己的职业生涯，那时候类、变量和继承之类的概念已经相当常见，成为日常开发体验中的固有部分。但据我所知，最早的情况并非如此，那您能不能讲讲当时的应用环境和技术水平？到底是什么让 Booch 方法如此独特？是新颖、有趣还是创新？

Grady Booch： 要回答这个问题，咱们还是得回到 20 世纪 50 年代，用一个类似的故事来说清楚。在算法编程语言的发展过程中，曾有那么一段时间，子程序这个概念引发了不小的争议？

为什么呢？因为执行函数调用至少会增加两到三条指令，所以计算成本很高。甚至函数调用和将某些东西拆分成子程序也会被视为架构异常。人们对这种效率低下的产物表达了强烈的抵触。很明显，现在看来这是一种相当短视的观点，毕竟我们需要承担一些技术成本来管理复杂性。同样的，最初面向对象的观点也受到了类似的抨击，因为人们在 COBOL 之类的算法语言中使用面向对象原则时，需要使用到所谓“common”的数据构造。

人们需要统筹这些 common 数据。也就是说，不同于以往立足语言的设计方式，现在大家需要从实践上考虑这些数据会以怎样的方式被哪些算法所使用。说回当初我任职过的范登堡空军基地，那里有个 32 台计算机的项目，每天我们都能在这些计算设备的侧面看到来自公共数据池的打印输出。由于频繁变化，它们相当于是把抽象概念直接呈现在开发者面前。

所以，人们希望依靠算法或者面向对象的方式进行拆分，但语言本身无法支持。也就是说，在开发出合适的语言之前，根本就没有行之有效的方式能把这些新观念结合起来。Booch 方法在很大程度上反映出了行业对于构建软件密集型系统的需求。它将注意力集中在类身上，将类的概念推广到众多现代语言，并围绕类建立开发方法。在如今的我们看来，这一切当然是理所当然的，毕竟各种主流编程语言都能让我们轻松做到这些。

这种回溯性的变革过程真的很让人着迷，特别是亲眼见证其从当初的探索性项目一路发展成为现在的普遍性方案。同样有趣的是，我们如今发明的革命性产物可能在 20 年后也会无处不在，对吧？

为什么 UML 不再用于工业界

问：确实是这样。您是因 UML 而闻名，也经常谈论自己与 UML 的关系。那能不能聊聊它是如何诞生的、最初的目标是什么、有谁参与进来、当时解决了哪些需求？

Grady Booch：1982 年，我在空军学院的两位同学 Paul Levy 和 Mike Devlin 也有参与，Paul 还曾是我在空军学院的室友。

他主修的是经济学，而 Mike Devlin 则主修计算机科学。Mike 跟我一起上过几节课。顺带一提，我第一次见 Mike 其实是在一门徒手搏击课上。虽然这种情况在一般的大学里不太常见，但我们军校出来的学生其实都要接受作战训练。

第一次遇见 Mike 的时候，如果我没记错，他在搏击对抗里打败了我。但在开发 UML 的时候，我自己在范登堡空军基地，而 Mike 和 Paul 则生活在湾区，主要负责卫星控制设施方面的工作。之所以主动选择他们，是因为当时他们参与的正是当时最大的 Ada 项目之一。所以我前往那边，帮助为该项目提供咨询。

他们二人后来也都去了斯坦福大学，所以我断定斯坦福大学一定很有潜力。之后他们又与顶尖风险投资家、苹果主要创始人 Arthur Rock 等取得了联系，并且为 Rational Software 的融资做出了贡献。1982 年，Mike 和 Paul 跟我聚在一起，说“要不咱们创办家公司吧。”说干就干，这家公司最终定名为 Rational Machines Inforporated，旨在为新兴的 Ada 编程语言构建一套软件开发环境。

我们都觉得这是个能赚大钱的机会。我们最初之所以选择制造硬件，是因为当时很多计算机都越来越价廉物美。Sun Microsystems 也开始大放异彩，但它们都没有足够的能力来完成我们既定的目标。因此 Mike 设计了一套系统，而我帮助建立了以此为基础的应用方法。

这套系统叫做 R1000，也是当时得到全球认可的主流 Ada 系统。我也不太确定，但业务大概顺风顺水经营了十年。时间来到 90 年代中期，我对一成不变的业务有点厌倦了，于是开始涉足其他领域。我发现 Booch 方法在商业领域很有吸引力。

当时我正在做一系列演讲。有一回，听众里的一位先生问了个很有见地的问题。后来我跟他单独见面，这位正是 Bjarne Stroustrup——即 C++ 语言之父。原本 Bjarne 当时正在做一个 C with Classes 的项目，后来 C++ 语言的前身。我们俩一拍即合。

我们发现双方在做的事情非常相似。实际上，我们就此决定一起在美国各地举办一系列讲座，在此过程中我也对他有了相当深入的了解。当时他写了一本关于 C++ 的书，从第一版的内容来看，他引用了我提出的很多想法。也就是在那个时候，我面向对象程序设计的书也出版了。

其实我也会经常引用他的著作。总之，Booch 方法可以说是跟 C++ 一同成长起来的。我觉得这相当有趣，还记得我当时曾经跟 Mike 和 Paul 举行过一次特别重要的会议，那是在丹佛联合航空公司的红地毯俱乐部。

他们见到我说，“嘿 Grady，我们正在考虑要不要让公司转向嵌入式系统。” 我回答说，“可能你觉得好，但我觉得这主意不怎么样，因为这会错过一些重要的商业机会。总之你们自己决定，我要去做点不同的事情。” 我的态度也让他们马上改变了想法。

我猜他们马上就意识到，我这么说是因为商业领域有一些更有前景的事情可做。当时大家都感觉到，单纯在国防领域发展业务已经不太走得通了，所以他们才想要进军嵌入式开发。在沟通之后，大家共同决定“那我们就试试怎么让 Booch 方法实践落地。” 于是我们开始开发一套名叫 ROSE 的系统，即 Rational 面向对象软件工程，也是我们的第一款工具。顺带一提，初版原型是我用 Smalltalk 编写而成的。

这是个很棒的系统，要是当初能保留下源代码就好了。我记得我们在初次演示的几分钟之前，还匆忙又做了修改。从 ROSE 开始，我们正式从国防领域转向了商业领域。项目获得了巨大成功，因为当时许多人都意识到面向对象是种很强大的认识世界的方式，而 C++ 实际上也支持这一点。于是乎，这又带来了两个结果。

不只是我们取得了商业成功，虽然我们确实赚了很多钱；我们还开始收购其他公司，并着手补全完整的软件工程生命周期。

问：那能不能跟我们聊聊 Ratioanl Software 是怎么让这项商业冒险取得成功的吗？

Grady Booch： 没问题。Rational Software 的 ROSE（即 Rational 面向对象软件工程）是一款个人生产力工具，能够在 IBM PC 上运行。但我猜其最终也被移植到了许多其他设备之上。

它的首个版本运行在 Windows 之下，基本上就是允许用户绘制 UML 图——抱歉，不是 UML 图，而是 Booch 图——旨在推理并批判性地考量整个软件设计思路。我们虽然也提供一些代码生成功能，但它主要还是一款设计工具，能够帮助组织概念化自己的设计思路。人们可以用它来有效记录、指定并构建自己预期中的系统。这样一款产品，也为我们带来了可观的商业收益。

手头有了钱之后，我们就开始收购其他公司。我们收购了一家来自剑桥的小公司 Pure Atria，而后者由一位名叫 Reed Hastings 的人主导建立。

Reed 主动找到了我们，我们最终也收购了他的公司。对了，大家知道 Reed Hastings 是谁吧？他后来建立了 Netflix。

Reed 清楚地知道他自己不太擅长处理 CEO 的工作，所以他拿到钱后闲了几年，考虑自己到底要做什么。实际上，收购 Pure Astria 的资金也成了后来支撑 Netflix 的第一桶金。从这个角度看，我们生活的世界还真是很小。

总之，到 20 世纪 90 年代末我们事业的巅峰时期，IBM Rational 在某种程度上已经主导着软件工程领域，因为我们拥有涵盖开发生命周期中各个环节的工具。其背后的基本思路，就是增量与不可简化软件开发理念。早在我们现在经常讨论的持续集成和持续部署出现之前，我们就已经使用 Rational Machine 和其他自主工具实现了这些概念。我们率先提出了这些想法，而且构建出了相应的增量编译工具和类似技术。总之，我们在 90 年代就拥有一整套围绕这种方法建立的综合性工具集。

但随着新思路在市场上获得关注，越来越多的厂商加入进来，我们看到成百上千家企业也开始做面向对象的业务。这标志着软件工程第二个黄金时代的开始，在这个活跃的周期之内，各个组织都在努力运用新兴的伟大生产力工具。

当时我们已经有了 ARPANET、也有了个人计算机，那要如何为它们构建软件？更具体地讲，为其构建的软件应该具有哪些表现形式？使用我们这套极其强大且功能完备的工具，应当遵循怎样的系统设计最佳实践？在这样一个合理且有趣的空间之内，我们意识到自己在某种程度上已经开始主导市场。

在经营期间，我们又聘请了 Jim Rumbaugh。Jim 和我的任务是把他的 OMT（对象管理技术）方法跟我的方法结合起来。我们当时就是两位项目带头人。之后我们又收购了 Ivar Jacobson 博士创立的公司，原因是 Jim 和我都开始拥抱“用例”的概念。时至今日，用例同样是个大家耳熟能详的定义，可在 90 年代却是新鲜事物。

用例是 Ivar 在爱立信工作时的奇思妙想。当时我们与 Ivar 合作为蓬勃发展的蜂窝电话网络基站开发软件——这些项目在那时候非常重要。我们三个人因 Rational 而齐聚一堂，工作内容就是想办法把三个人的方法论结合起来，可回顾整个人生，我觉得再难找出三个如此水火不容的家伙了。

我甚至觉得很惊讶，就是我们三个凑在一起居然没有发生恶性暴力事件。我们的性子差别太大了，这里就不细讲了，我只想说，我们为自己创造的一切感到无比自豪。

最终，UML 由此诞生。所以我们决定这不应该只是我们自己的成果，我们应该让它成为全世界都能使用的成果。因此我们决定将它交付给对象管理组织，而 UML 1.0 也由此正式诞生。

在合作期间，我负责推动了大部分工作。我为项目编写了主体文档。当然，一切都是我们三个人配合完成，我并不想贬低其他人的贡献，但当时我承担的工作确实最多。不过在 UML 1.0 之后，我可谓身心俱疲，于是想要离开去做点新的东西。

所以我当时真的考虑过放弃，这时候出现了两个非常重要的人。其中一位就是 Philippe Kruchten。我们意识到自己的工作极其广泛，没办法同时关注方法论和符号系统。

因此，Jima、Ivar 和我继续共同研究符号系统，即 UML。而 Philippe 则主要与 Ivar 团队的部分成员合作研究方法论，由此诞生的就是 Rational Unified Process。请注意这里 Unified 统一的概念。Philippe 引入了我们在 Bouch 方法中提出的一个关键概念：通过多个角度认识世界。

Philippe 据此提出了 4+1 视图模型，这是他从构建加拿大空中交通管制系统的经验中发展而来——那是一套极其复杂的分布式系统。这些想法最终体现在了 IEEE、IEC、IOC 标准 420020 当中。作为一种架构描述，其基本含义就是在观察架构时，应当从多个视角进行考量：用例、逻辑视图、流程视图、实现视图与部署视图等。这是一个非常重要且深刻的概念。另一位参与其中的则是 Walker Royce，下面咱们就来聊聊有趣的 Walker 其人。

还是那句话，这世界真小。Walker 的父亲 Wynn Royce 曾写过一篇关于瀑布式开发生命周期的文章，而当时我有幸与他共事。Walker 主要研究螺旋模型与 Booch 方法。其实很多人对 Wynn 有误解，他本人并不支持瀑布式方法。

他当时直言，“这是个愚蠢的想法。实际上，看看 Parnas 的论文〈理性设计过程：为何以及如何进行伪造〉就知道了。顺带一提，Rational Software 这个名字就是从「理性设计」而来。文章里提到，从某种角度来讲，这其实就是我们今天所说的敏捷。所以早在 90 年代末和 2000 年初我们就已经发展到了这一步，当时 UML 1.0 已经得到广泛接纳，也是 Grady 用一生为之奋斗的目标。”

问：那从我的理解来讲，UML 的目标就是要描述一套系统？记得在大学里学习 UML 的时候，我们会用不同的方框来表示不同的类，而且各个类之间用箭头串连起不同类型的关系。只要认真看完整个图表，就能对正在构建的软件架构有所了解。

Grady Booch： 没错，就是这么回事。其实只要看看 UML 1.0 标准的第一行，就会发现 UML 是一种可视化语言，旨在推理、可视化、指定并记录软件密集型系统中的工件。但标准中没有提到这是一种编程语言。实际上，我也一直强烈反对这种观点。UML 只是一种用于引导思考的语言——帮助我们思考并推理一套系统，并以面向对象的方式思考世界，特别是允许大家从多个角度建立起全面的理解。

顺带一提，如今的 DevOps 就只是将部署和实现视图融合了起来，只是那时候我们不会使用这个字眼。我们也同样有这样的审视角度，这正是 UML 1.0 最大的意义所在。其重点就是我们如何思考这些问题，以及如何通过推理找到答案。

我一直认为，画 UML 图的意义就在于废弃掉其中的大部分内容。可遗憾的是，现在很多人并没有这么做。在从 UML 1.0 到 2.0 的转变过程中，有一部分个人和企业总觉得，“我们应该让 UML 非常精确，我们想把它变成一种编程语言。”但在我看来，这实际反而彻底扭曲了 UML 诞生的意义。

我从来没想过要把 UMl 变成一种编程语言，这样做的后果只会让 UMl 变得更加复杂也更加臃肿。当时很多人的关注点不在于推理，而是用它来生成代码和做逆向工程。时至今日，我对逆向工程这类用途已经比较理解，道理完全讲得通。但把它变成一种编程语言肯定是个错误。我相信这个决定标志着 UML 衰落的开始，因为人们开始以错误的方式加以使用。

在巅峰时期，UML 在市场上的渗透率可能达到了 20% 甚至 30%。现在想来，能有这样的普及度真的很酷。UML 影响到了使用它的系统，而且更重要的是，我为它能帮助人们以不同的方式思考软件设计而感到自豪。

问：你所说的巅峰时期有 20% 到 30% 的使用率，是说当时约有两成甚至三成的商业开发商都在用 UML？那具体是什么时候？

Grady Booch： 没错，那大概是在 2000 年前后。但必须强调，微软在这段时期也发挥了重要作用，他们实际上与 Rational 开展合作并把 ROSE 产品集成到了 Visual Studio 当中。我们在西雅图专门派遣了团队负责这块工作。

这也是微软产品当时的一个主要卖点，能够帮助客户构建起复杂度更高的软件。所以没错，应该就是在 2000 年左右。但大家还记不记得当时还发生了什么？答案是，互联网正在迅速发展。ARPANET 已经转型升级成了互联网，众多企业在上世纪 90 年代后期开始接入网络。但新的挑战也随之而来，即我们要如何在网络之上构建分布式工作系统并从中盈利？这些系统应该是什么样子？微软的参与也正源于此，他们正帮助客户从独立 PC 转向分布式系统。另一方面，也出现了大量炒作之声，宣称互联网能够改善这、优化那，总之乱七八糟的。于是那段时间互联网领域出现了严重的投资泡沫。

千禧之后不久，预期中的反弹果然到来，市场出现了显著衰退。许多人意识到，他们斥巨资构建的成果在经济上并不一定具有可持续性。现在时间来到 2003 年，IBM 和微软仍在大量使用我们的工具，因为这些工具对于他们的客户非常重要。于是两大巨头都想出价进行收购，而最后 IBM 以 27 亿美元拿下了 Rational 的所有权。

于是我们就加入了 IBM，成为蓝色巨人的一部分。这个价格其实不难理解，毕竟当时我们在全球 14 个国家拥有 3500 名员工，年收入接近 10 亿美元，这对于当时的企业来说是个相当了不起的成绩。但现在让我们进入新的节点，聊聊 IBM 收购我们之后的故事。

加入之后，IBM 立即将我评选为院士，这是之前从未发生过的情况。毕竟 IBM 往往需要几年时间才会真正接纳一位新成员。几个月后，我接到一通电话，那头说“嗨，Grady，我是比尔，咱们当面聊聊吧。”

所以我就赶过去见他，那可是比尔 - 盖茨。我之前其实跟比尔也一起做过项目，当时比尔还担任微软的 CEO。他跟我打过招呼后，就把我带进了他的办公室。

我们原本只打算开个 30 分钟的小会，但最终会面持续了两个小时，这让他的员工们大为光火。他坐下来说，“Grady，这事还没有公开，但我打算辞去微软 CEO 职务，转而去做点其他事情。Grady，你知道我身兼两份职务，既是微软的 CEO，也是微软的首席架构师。”

他想让我担任企业首席架构师，而我的回答是，“比尔，这个提议很有趣，但请给我点时间让我考虑一下。之后我到处拜访，接洽了比尔的各位主要下属。但重要的是，我跟鲍尔默从未会过面。”

这是个危险的信号。大约就是在那段时间，我意识到微软其实是家运营状况极差的公司。他们的 Office 部门和 Windows 部门简直势同水火。最后，我通过招聘团队再次来到比尔面前，说“比尔，我很荣幸收到你的邀请，但实话实说，你的公司功能严重失调，而我肯定不是能够解决问题的理想人选。所以谢谢你的建议，但我恐怕无法接受。”

我记得自己好像还说过，“如果我接受职务，我们俩最终都会以悲剧收场。所以不如让我们各自安好吧。”于是我留在了 IBM，事实证明这是个正确的决定。接受邀约绝不会有什么好结果。

软件工程师兼漫画家 Manu Kornet 曾经创作过一幅关于微软的漫画，描绘的正是微软内部两个部门之间相互对峙的场景。没错，情况就是这样，他们亟需有人来打破僵局。

我是那种老好人，不擅长做出艰难的决断。我也不是那种会破坏气氛的人。总之，这事我真的干不了。

问：其实很多大学已经把 UML 列入教学课程了。但有趣的是，在行业当中，我并没看到有人真正把它用于实际开发——至少在我自己工作过的企业、合作过的初创公司、扩张中的组织以及行业巨头中都没有。我甚至发现很多人在提到 UML 的时候有种抵触情绪，而且经常认为它太正式了。毕竟我们都需要使用架构，但真的没人用方框和箭头把架构勾勒成图表。所以我很婍，之前你谈到 UML 曾经被 20% 到 30% 的行业采用，那这为什么跟我的感受不同呢？

Grady Booch： 这事要从当代架构的演变说起。

我有本书是专门讨论架构的，其中既涉及旧架构、也涵盖了新架构。今天很多开发者在说起软件架构时，都默认认为这些方案既合理且完备，有很多现成的素材可以使用。然而，在这些架构师讨论的各类系统当中，很多架构决策实际上已经替开发者做好了。比如说，假设我要构建一套涉及消息传递的系统，那可能会直接去用 RabbitMQ 或者 Redis 之类的成熟方案。

这些选项都已经替大家做出了架构决策。因此当代架构师的大部分工作，实际就是从大型框架和组件中做选择并将它们编排在一起。 当然，这是一项非常崇高而且美妙的事业，框架本身也代表着 Meta 等大型系统的精髓。他们已经拥有数十年的架构和系统开发经验，他们在这些架构上构建的项目，很大程度上就是从这些 API 发展而来，而这些 API 并不需要更深层次的架构思维。关于这个问题，我想用一套三轴系统形象地解释一下。

沿着其中一条轴，体现的是不同的责任度等级。比如说对于一家初创公司，那我们只需要关注自己能不能赚钱，至于投资者的钱有没有回报根本不重要。所以说我可以编写一次性的软件，如果项目失败了，再去找其他风险投资家就行。所以我根本不需要考虑什么架不架构，花钱雇优秀的技术人员把它实现出来就行。

但如果我负责的是开发下一代洲际弹道导弹系统，整个项目投资数亿甚至上千亿美元，那就肯定得拿出更负责任的态度。毕竟此事非同小可，每一项决策都得深思熟虑。这就是所谓责任度轴。

接下来咱们再说说风险轴。假设我构建了一套系统，哪怕项目失败，那最差的结果也不过是找不到与之匹配的机床，那这肯定没什么大不了的。但如果我的项目发生故障就会导致人身安全面临威胁，那问题可就大了。在这种情况下，我们肯定会使用更规范的架构。

第三条轴则是复杂性。假设我构建的是一套市面上已经被用烂了的系统，那我啥都不用考虑。这就是提示词工程最擅长的领域了，AI 大模型就能快速搞定、根据提示词构建起应用程序。毕竟这些都有成熟的解决方案，我根本不需要什么 UML 这那的。但如果我要构建的是更复杂的东西，那在工程层面需要考虑的问题就多了。

我可以通过编写提示词来构建应用程序，毕竟所有工具都是现成且完善的，不需要繁琐的 UML 流程。但如果我开发的是一些之前并不存在的东西——假设我不是在构建某个语言模型，而是想要打造一组能够相互协同的语言模型，而且希望把它们跟非神经系统集成起来，那就必须考虑架构方面的问题了。这也正是 UML 的意义所在。在软件开发中其实也有舒适区，就是指那些无需依赖 UML 或者类似工具就能完成的工作。

但在另一方面，如果在这三条轴构成的三维空间中走得再远一点，就会发现其实到处都有人在用 UML。我之前提到了詹姆斯韦伯太空望远镜。除此之外，我还在跟很多肩负着重大风险、复杂性与责任度的金融服务机构，他们就需要在架构方面多下心思。

软件开发中的颠覆性变化和重大飞跃

问：那我可不可以这样理解，您是说软件架构自 90 年代和 2000 年初诞生以来已经发生了变化？

Grady Booch： 肯定是的，当时的软件架构仍是新生事物。而且如果我们看看今天由风险投资资助的初创公司和大型科技企业，就会发现首先它们承担的风险并不大，毕竟出了故障也不会特别致命。

另外，我们也可以使用更多已经存在多年并融入了架构设计的软件。比如说，我们可以使用 Redis 作为缓存机制，它功能完备而且可用度极高，根本不需要我们过多操心。

第三点是，很多初创公司根本不需要考虑责任这码事。实际上，他们甚至连审计流程都不怎么在意。毕竟体量不大、承担的责任也不重，所以他们基本想怎么做就可以怎么做，可以轻装上阵。

问：那我是否可以理解为，正是这些软件架构层面的变化，导致 UML 主张的形式化方法在初创公司和扩张阶段的企业中不太受欢迎？

Grady Booch： 没错，实际上我认为一切的根源还是在于软件开发的经济学形态。让我们说回软件的第一个黄金时代。

那个时候，机器可要比人金贵得多。在使用机器之前必须深思熟虑，因为机器时间对使用者来说非常非常昂贵。因此算法分解和结构化分析设计之类的技术才会极具意义，因为我们离不开这样的优化。然而在当代，计算资源就如同身边的空气一样普遍，任何人都可以随时获取、随时使用。

我身后的桌子上就有四台安装着英伟达显卡的计算机，它们构成的私有云在算力上甚至超过了 20 世纪 70 年代整个世界的处理容量之和，简直太神奇了！而且只需要几千美元就能买到。计算经济学已经发生了巨大变化，以至于我们根本不需要考虑得太多，因为很多细节已经不再重要。我认为 AI 的崛起也在塑造新的经济形态，因为它让我能够随手构建一些成果、完全不必考虑任何设计层面的问题。

就连软件似乎都不再必需。我只需要用提示词构建出一次性的方案就行。在用完之后，随手丢掉即可。所以从这个意义上来讲，现实世界仍然是由经济学规律支配的。然而，仍会出现一些新的、独特且颠覆性的软件，其中还是少不了架构思维的引导。这很有趣，比如最近我就读到了亚马逊如何用形式化方法设计 Amazon Web Services S3 存储服务。

他们发布的博文详细介绍了整个项目实现过程。之所以采取形式化设计，是为了应对那些特别极端的情况。这类情况虽然只会以十亿甚至万亿分之一的概率发生，但就他们的设施规模来讲，这总会成为频繁出现的事件。总之我发现技术的发展反而让一些老办法有了新用途，这很有趣。

好吧，我得先控制一下自己，少聊点形式化方法的问题，毕竟这是另一个完全不同的方向了。回到亚马逊这边，如果访问他们的网站，就会发现他们是有自己一套围绕架构设计的语言存在。微软在 Azure 方面也有类似的东西。在我看来，这其实就是亚马逊的架构思维。

整个体系看起来类似于块状图，他们会说“我要构建这种东西，所以用这种特定符号进行标记。”类似的例子还有很多。总之，尽管人们已经做过足够多的探索、有了足够多现成的方案，但亚马逊和微软仍然非常重视架构的作用。

他们的网站会说，“如果想要构建这样的系统，请使用这些服务，另外请参阅我们网站上的相关参考示例。”所以虽然他们没有把架构随时挂在嘴边，但亚马逊和微软就是在强调架构的重要意义。只不过因为其中的模式已经相当成熟，所以人们不必经历重新发明轮子的过程，仅须选择方案、上手构建就行。

我认为这是业务发展趋于成熟的表现。我们已经从算法时代转向了每个人都能掌握的设计模式时代，如今又转向了亚马逊和微软自行编纂的全新架构模式时代。 下面咱们再来聊聊形式化方法。其实形式化方法一直存在。

但根据我的经验，形式化方法是软件密集型系统中各个部分的必要元素。形式化方法只能涵盖特定领域。例如，微软开始在其驱动程序中使用形式化方法来验证其与硬件交互的正确性。这是个非常重要的进步。我自己就曾参与过一些项目，比如说“我有一套系统，关乎使用者的生命安全，现在需要对它做形式化分析。”可问题在于，这些形式化方法并没有考虑到现实世界中的因素，因为它不涉及时间和空间。

形式化方法处理的仅仅是功能。我一直认为形式化方法很有用，但也仅仅适用于系统中的某些部分，而不能作为架构本体的核心驱动因素。说到软件架构，如今软件架构师这类岗位已经不像过去那么受欢迎了，至少在初创公司和大型科技企业是这样。 相反，我们有统一的架构师，但他们也越来越多被称为高级工程师、首席工程师或者杰出工程师之类。架构仍然存在，很多人也仍然参与架构设计，只是侧重点已经发生了转移。

问：说起软件架构设计，在这个概念刚刚诞生之时您就是首批软件架构师中的一员。那您能不能告诉我们，您是如何看待这个角色在过去几十年中的发展和演变的？

Grady Booch： 我对软件架构师的理解主要受到两件大事的影响：首先我并不会称自己为架构师，但我确实在帮助客户设计他们所构建的系统。在这方面，我深受自己的一位好友，卡耐基梅隆大学教授 Mary Shaw 的影响。

如果我没记错的话，她好像在奥巴马执政期间获得了国家荣誉勋章。她还写过一本非常深刻的书，书名就叫《软件架构》，并在书中首次阐述了架构模式。Mary 是个特别有亲和力的人，也正是在那个时候，我开始理解架构的形式化机制。对我影响最大的反而是其他领域中的架构模式，特别是土木工程之类。

在国防领域，还有船舶结构设计、飞机结构设计以及类似的领域。“架构”这个词在工程界特别受尊重。所以在深入探讨之前，我们可能先要明确一个定义，那就是架构究竟是什么？

我之前曾经说过，一切架构都属于设计，但并不是所有设计都属于架构。架构代表的是塑造系统形式和功能的一系列重要设计决策，其中的“核心”则是以变更成本来衡量。软件架构和架构师的角色往往有着很重的心理负担，因为他们的决定往往会造成重大影响甚至是沉重的后果。

也就是说，架构师所负责的，就是在塑造系统的过程中做出一个个决策。当然，项目经理之类的角色也会参与决策。但其间最微妙的区别在于，架构师关注的不只是软件形态的决策，而更多体现在系统本身的形态上——即软件系统与其他系统乃至人类本身在自然世界中呈现出的样貌。就是这么一回事。

问：所以说架构师关注的是决策过程。那您觉得这个角色发生了变化吗？您有没有见到过企业聘用软件架构师，并授权他们灵活开展设计的黄金时代？我注意到这种放权的趋势正在减弱，很好奇您对此会怎么看。您有没有观察到类似的趋势，还是说这只是种误解？毕竟您接触过各行各业不同的客户。

Grady Booch： 关于这个问题，我想分享另一个心得：软件工程的整个发展史，就是抽象水平不断提升的历程。我们也刚刚亲自见证了又一个抽象层次的出现，它为我们的系统构建提供了极其强大的框架。正如之前所提到，过去对我们来说属于最顶尖级别的架构决策，如今却已成为常规框架的固有组成部分。

所以现在架构师的决策变成了：我该使用哪种云服务、该选择哪种消息传递系统？这个决定涉及很多经济考量，而不仅仅是与软件相关的选择。我认为架构师的角色已经发生了重大变化，因为大家现在处理的是系统问题，而不再仅仅局限于软件本身。

问：不知道您有没有听说过解决方案架构这个职位。这个概念大约是十年前兴起的，相关职位非常有趣，而且专门针对云，这批专业人士就只关注云架构。如您之前所述，他们会做出经济决策，决定使用哪些服务——比如是选择亚马逊云科技还是 Google Cloud Platform。如果他们选择了亚马逊云科技，那还需要进一步判断到底使用 EC2 还是其他服务。这关注的明显就是系统性的问题。一般来说，作为一家初创公司，肯定会希望聘请在这方面有经验的专家——也就是那些知道哪里有陷阱，而且熟悉服务相关成本的人。聘请这类专业人士能够加快业务开发进度，因为他们已经做出了最关键的决定，可以指引企业确定哪些选项对当前正在构建的基础设施更有现实意义。

而之所以称其为系统性决策，是因为它们在经济上有着深远的长期影响。软件架构的另一个重要方面就是迁移，我发现大多数企业都把长期迁移视为一种沉重包袱。

这种迁移往往源自软件架构的变化，例如从单体式架构过渡到微服务架构，或者技术方案的转换（例如从 Node.js 转向 Go），又或是升级框架的主要版本（比如将 Angular 从一个版本迁移至另一个版本）。您觉得软件架构跟迁移有直接关联吗？您觉得软件迁移为什么这么困难，但又总之如影随行？甚至可以说除非到了宇宙消亡的那一天，否则这个问题永远得不到根治。

Grady Booch： 这是因为我们一直在构建具备经济可行性的软件，而不断变化的技术趋势逼迫人们选择迁移。例如从 20 世纪 60 年代、70 年代和 80 年代的单体式设计，转向经济实惠的微型机普及时代下的分布式系统。虽然哪怕到了今天，我们也不可能一边用 iPhone，一边把所有高强度负载都交给大型机，但这种变化会促使大家考虑一种能够更好平衡处理位置的架构。如果边缘推理突然流行起来，那么软件架构也必然要随之改变。硬件因素和社会因素就是这样持续影响着系统结构，而这一切正是敦促我们进行迁移的核心驱力。

至于问题解决起来为什么很难，我再谈谈自己的另一个观点。代码确实是事实，但不是全部事实。除了代码之外，还有很多东西会影响到设计决策、设计准则以及我们对于具体开发方法的选择——包括影响命名约定及其他经常被忽视的微妙因素。有时候原有代码是完全准确的，但迁移之后却会导致其中重要信息的丢失。换言之，我们很难单凭代码就体会到当初开发者做出的那些设计决策。这些遗留代码的初代开发者可能已经离职、退休甚至去世，而接手的人根本无法理解他们当初做出选择时的具体背景。

所以面对各种奇怪的状况，大家开始怀疑为什么当初的开发者要做出这些决定，陷入迷茫与混乱。

问：您提到有些初始开发者可能已经去世了，这确实是后来者很少会考虑的问题。但回顾 40 或者 50 年前开发出来的系统，这就是冷冰冰的现实。比如当 Linux 最终退休之后，Linux 内核会是什么样子、又该如何发展？

Grady Booch： 他其实一直在为 Linux 项目的概念完整性提供坚定且有力的支持，这就是一位优秀首席决策者应该做到的。始终把握概念完整性，这一点非常重要。当然，在核心决策者离开之后，项目肯定会出现漂移，这也很难避免。

这就是熵的概念。所有软件都会表现出一定程度的熵，这属于无法消除的内部应力。

问：在技术和架构方面，当下最典型的例子就是 AI。这是一项极具革命性和颠覆性的技术成果。作为一位已经在行业内工作了近 50 年的老兵，您觉得大语言模型和 AI 跟行业过去出现过的创新和大事件相比，在意义上有何差别？

对于我们这种在行业里也待过不短时间的从业者来说，大语言模型似乎可算是软件领域出现过的最大变革。但是回顾过去，您是否看到过在影响力或者变革速度方面能够与之相比肩的趋势？

Grady Booch： 这是个好问题。我首先能够想到的应该是构建分布式系统，即不再将所有处理都放在单一系统之上。这是一场彻底颠覆我们系统构建方式的革命。在那个时候，我突然意识到我们可以打造一套微型计算机网络。最终，这种网络延伸并覆盖了微型计算机和边缘设备，包括当下人们寸步不能离的智能手机。

但在微型计算机时代，这种转变背后的巨大潜力和意义超出了大家的想象，我觉得人们直到很久之后才真正理解了其全貌。因为这要求我们重新审视自己构建系统的方式。我们发现不确定性显著增加，因为我们不知道该如何构建符合新时代特征的系统。我其实不清楚该如何处理消息传递：要使用 RPC 吗，还是有什么别的选择？

我该使用什么进行通信？要使用共享内存吗？这是一段前景不明的探索期，最后我们才想明白，这才是新时代下的常态。

问：发生这一切的具体时间点在哪里？是 90 年代左右还是 70 年代末、80 年代初？

Grady Booch： 大概是在 80 年代末。为了便于理解，让我们先回顾一下历史。在 60 年代末和 70 年代初，整个计算世界都由大型机所统治。

但即使是在那时，人们就意识到这些机器并没有得到充分利用。因此第一套分时系统诞生了。大约就在同一时间，林肯实验室研究出的 Whirlwind 等系统开始将机器与现实世界连接起来。于是突然之间，实时计算成为了现实，最终使得两股非常有趣的发展趋势得以融合。

我们开始在大型机器中开发分时操作系统，设计与现实世界交互的机器。这些元素随着小型计算机的兴起而出现，尤其是在数字设备厂商和类似的公司里，小型化技术的普及（主要由国防部在半导体领域的投资所驱动）使得在办公桌上部署一台供一、两个人使用的计算机首次具备了经济可行性。这波趋势又进一步吸纳了 Whirlwind 等系统中体现的理念，并将其与当时正在构建的分布式系统结合起来。突然之间，我们有了将这些组件构建在一处的能力。

这就是 70 年代中后期的现实：我们亲眼见证了分布式系统的兴起。最后还有一点：客户端 - 服务器系统的普及。我们看到了哑终端（当时 IBM 也在做这件事）与大型机通信。然而，这些新机器的出现意味着我们可以将部分处理负载转移到边缘，而不必全部留给大型机。这股变革的力量促使我们重新思考系统设计。

问：那我这样理解对不对，当时的程序员已经习惯于在大型计算机上工作，而分布式计算的出现彻底改变了这种思维方式？就是说，年轻人开始接受分布式计算范式，但老一批程序员仍在坚持使用他们在大型机上跑通的方法，是这样吗？

Grady Booch： 没错，之后随着 TCP/IP 和 HTML 等事物的出现，我们突然之间有了一份新的术语表，有了能够将这些元素绑定在一起的机制。

所以，我不敢说大语言模型跟当初分布式系统的普遍兴起是否同等重要，但二者确实有一定的相似之处。 我想谈的第二件事是 GPU 的兴起，这波趋势最初来自游戏行业，当时他们需要解决的是个前所未有的问题：如何处理更多图像，并在游戏中创建出更加逼真的视觉元素。我们意识到这一切都被归结为矩阵简洁，而英伟达正在强势进军这部分市场。

GPU 由此崛起，并在领域中占据了证实地位。直到吴恩达站出来，说“等等，用于游戏画面运算的 GPU 使用的数学，跟我们深度学习的技术是一样的。”瞬息之间，我们迎来了一场完美风暴，大量数据、强大硬件以及各类有趣的算法、反向传播机制成为可能。没错，这是一场完美风暴，是技术发展史上又一个激动人心的时刻。

对大模型的看法

问：大语言模型虽然有趣，但我们也必须小心谨慎。我们稍后再讨论这个问题。我想听听你对大语言模型的坦诚评价，包括它们的适用性、创新意义以及由此带来的权衡需求等。

Grady Booch： 首先，为了避免大家以为我只是在随意点评自己完全不了解的东西，这里先介绍一下我跟 AI 的缘分。当我 12 岁还是 14 岁时，我对当时蓬勃发展的 AI 就很感兴趣。我一直对此念念不忘，也一直在追求并保持着对这一领域的关注。直到加入 IBM，我又真正参与到了其中。

在 Watson 项目上，我是以全职工作的态度参与的。当时领导 Watson 开发的 David Ferrucci 打电话给我说，“嘿 Grady，我打算做个讲座，但实在没空。你能替我顶上吗？”我回答说，“David，我很乐意，但前提是得让我自由选择主题。”

我选择的主题就是：Watson Jeopardy 的架构是什么？事实证明，这事之前确实没人认真讨论过。作为架构领域的专家，我与 David 的团队当面聊了好几个月，记录了 Watson Jeopardy 的现有架构。它并不是神经网络系统，而是一种管线架构，通过管线将许多统计系统整合在一起。

当时的 AI 完全基于预测统计方法，而不是现在大家熟悉的神经网络或者知识工程方法。因此我对架构的关注引起了 IBM 管理层的注意，这也是我第一次正式讨论 AI 架构。

问：如果我没记错的话，Watson 在“Jeopardy！”答题综艺中大获全胜，击败了所有人类选手。当时主流媒体、新闻媒体都在长篇累牍地报道此事。作为 AI 系统最典型的案例，Watson 能够在人类最擅长的一项任务中超越人类，所以很多人都会把 Watson 跟 Joepardy 联系在一起。

Grady Booch： 没错，这也是 IBM 在 AI 领域发展轨迹中的一部分。在此之前 IBM 还有深蓝，它击败了当时最强的国际象棋选手卡斯帕罗夫。但那时候靠的还是算力的粗暴堆叠。

随后 Watson Jeopardy 出现了，并且在当时的自然语言处理领域击败了人类。IBM 在这一领域中开发出一套基于统计方法的系统，我们最终将这套系统出售给了其他公司。但无论如何，我们在特定阶段确实占据了自然语言处理的主导地位，而 IBm Watson Jeopardy 代表的就是那个时候 AI 成就的巅峰。因此公司问我，“Grady，这东西很酷，我们想把它转化成商业化产品。你能帮我们研究一下具体该怎么做吗？”

我之前曾经领导过一个为期约一年的认知系统研究项目。所以对于 IBM 具体该怎么做的问题，马上激发了我的好奇心。我认真研究了 Watson 能做什么，又观察了市场上的变化动态。那时候大约是在 2010 年左右。

面对新的十年，我向 IBM 管理层明确表示，虽然这项技术很酷，但也必须保持谨慎，因为我们很清楚有些事情它做不到。我反复强调，一定别过度炒作 Watson 的能力。记得跟罗睿兰会面时，我正好在做关于 Watson 项目的简报。

时任 CEO 的罗睿兰问了我个问题，突然有位副总裁介入并说起了自己的想法。我礼貌地回应说，“谢谢，但我觉得你说的不对”，之后继续解释起我的观点。

老实讲，如果我不是 IBM 院士，肯定会被当场解雇。但院士这个身份让我有底气这样表达。最终他们没有邀请我加入 Watson 项目组，我反倒挺高兴的，可以继续做其他工作。后来事情的发展果然不太顺利，而且哪怕我去了也改变不了太多。

所以我之于 IBM 有点像个局外人——虽然是内部员工，但一直做自己的事情。后来我们奥斯汀那边的一支团队接到了希尔顿酒店的邀请，他们想为酒店打造一台礼宾服务机器人。于是我们选择了来自法国南部的 Aldebaran 公司，他们专门制造三英尺高的机器人、名叫 Pepper。还有一款尺寸更小的型号，名叫 NAO。

他们还开发了一套机器人系统。这套系统很酷，能够基于 Watson 技术实现自动问答，但功能上仍有缺失。团队来找我说，“Grady，能不能帮帮我们？”我帮助他们完善了架构，并在几家希尔顿酒店进行了实验性部署。

当时那支团队的驻扎地离约翰逊航天中心不远，所以我又开始跟航天中心合作。我感觉很棒，因为我自己就是从空军那边出来的嘛。他们有一套名叫 Robonaut 2 的系统，这是一款人形机器人，部署在当时的国际空间站上。NASA 希望借此探索如何在火星环境中实现人机交互。

因此我们一群人坐下来讨论：“有哪些设计问题值得讨论，而且有助于推动我们解决难题？”我们都希望做点有难度的事情，而且都认为火星任务值得探索，因为其中涉及两个有趣的用例。其一，由于光速传播有其极限，所以不可能靠地面站进行遥控，设备必须能够自主运作。

这有点像《2001 太空漫游》中的 HAL，我们要构建自己的 HAL 来控制任务，但又得保证它不会“杀死所有人类”。但出于种种考虑，NASA 不太认同这个用例。我不清楚，反正他们决定。第个问题是，当时 NASA 想把机器人部署在火星表面，帮助宇航员建立自己的科学实验和栖息地。

我记得有一天下午，我突发奇想，似乎找到了设计思路。当时大概是在 2014 年左右，我建立了一套神经符号架构，将其命名为“Self”自我。它融合了 Marvin Minsky 提出的心智社会、Rodney Brooks 的包容架构概念以及 Hofstadter 的奇异循环概念。将这三个概念结合起来，就形成了我们后来开发的 Self 架构。我们跟 NASA 又合作了一段时间，为 Robonaut 2 开发软件，比如说“嘿机器人，这有个科学过程，帮我整理过滤一下。”总之我们本质上就是在开发能够与人类直接交互的软件，同时也可以充当问答工具。为此，我们当时接触了新西兰一家名叫 Soul Machines 的公司。他们还曾参与詹姆斯 - 卡梅隆电影中的部分制作环节。

其实就是《阿凡达》三部曲啦，其中运用了一系列堪称伟大的技术，包括将摄像头放在演员身上来测量他们的肌肉运动。他们开发了一套模拟人体肌肉的神经模型，也拥有出色的硬件，但缺乏配套软件的支持。所以我们就在这方面为他们提供帮助。我们还跟一家名叫 Woodside 的澳大利亚石油与天然气企业合作，他们面临着与 NASA 类似的问题。他们主要为石油钻井平台构建系统，而这类平台的工作环境显然相当危险。

所以他们希望合作开发机器人，跟 NASA 的火星探索项目真的很相似。我们开发了一套名叫 CELF 的系统——简单来讲，这是一套神经符号系统。其中既有神经组件，也有符号部分，整个架构体系特别酷。在巅峰期，我们这边有 35 个人都在做这个项目。

但后来我们意识到 IBM 在全球设有六处实验室，于是我选择前往夏威夷毛伊岛生活和工作，而且直到今天仍然住在那边。至于 IBM 那边，则很快意识到 Watson 正在亏损，于是他们解雇所有团队成员。幸运的是作为一名院士，我仍然保住了自己的岗位。我继续在这个领域工作，这也成为我接触的第一波新型架构。

最近这六年左右，我一直在跟一组神经科学家合作，希望破解有机大脑的架构。我不再专注于跟软件相关的概念，而是开始研究皮质柱和下丘脑中的回路。我一直希望通过软件架构师的视角来评估这些有机系统究竟遵循怎样的架构。而这最终又回归到你提出的问题：我对大语言模型怎么看？我觉得它们非常非常酷炫。

但从其架构的本质来看，大语言模型其实是种相当不可靠的方案。这还是我收着说的，如果不客气一点讲，大模型实际就是毫无意义的生成工具、纯纯没脑子的随机鹦鹉。它们没有推理能力，也没有理解能力。

不过我也承认，大语言模型确实能生成一些相当连续的结果，也凭借基于互联网语料库的训练帮助人类探索极其复杂的潜在空间。所以我觉得大语言模型也是一场完美风暴——依托于数据、算法和硬件的大语言模型，让我们得以生成如此连续的输出。但我们也必须多加小心，Gary Marcus 和我一直在猛烈批评山姆 - 奥特曼等从业者，驳斥他们关于通用人工智能 AGI 即将来临的言论。

在我看来，这对 AGI 本身其实是种亵渎、也破坏了人类智慧的美感。坦率地讲，我绝不相信什么规模效应就足以支撑起真正的智能，反倒觉得这条路子正在走向死胡同。

我曾多次在线上跟马斯克交流过他对 AGI 的看法，毕竟多年来一直在承诺能够实现完全自动驾驶 FSD 功能。我觉得不行，因为那些模型从架构设计开始就有问题。 在我看来，如果需要专门建造一座核电站才能承载起系统的运行能耗，那肯定是架构方面出了大错。所以我相信大语言模型有其行之有效的用例，但我们必须保持谨慎，因为它们也真的很危险。

我还曾经在 Galactica 立项之初就在 Twitter 上提出了批评，结果被对方屏蔽了。我说“这项目很棒，但也请你们想清楚它到底意味着什么。”对方不予理会，而我则不断批评，并最终被拉黑。但 Galactica 后来闹出的很多问题再次印证了我的看法。总之，我一直对大语言模型背后的风险抱有警惕。

问：我想明确一下，您似乎在说大语言模型不可能引领人类实现 AGI？但如果把大模型跟其他工具——比如神经网络或者神经共生系统——结合起来，会不会更接近实现此类智能系统？还是以您刚刚提到的项目为例，一台能够整理过滤条件并遵循指令的火星机器人，您觉得我们需要哪些前置条件才能实现这类智能？

Grady Booch： 在回答之前，我还想补充一点。以日本为例，那里的人口老龄化和劳动力萎缩问题非常严重，美国也面临类似的情况，对于老年人的护理压力持续增长。因此，机器人技术的应用（不仅仅是纯人形机器人）变得越来越重要。这类解决方案已经在现实中具有明确而且迫切的需求。

所以没错，市场并不缺乏理想的应用场景。我一直觉得这是个系统工程问题。所以我才一直想用 Self 架构来解释神经符号系统的重要意义。现在我想聊点哲学，不知道你是否感兴趣。首先，人是有感知能力的，至少从表现上来看，人跟大语言模型有着本质的区别。

我为什么能下如此判断？因为这个猜测非常合理，与我交流的人拥有一套心智体系，通过多模态方式彼此交互。通过现实体验，我认定对方拥有感知能力，包括专属于自己的能动性、感受、行为和需求等等。

这很酷，把人和机器彻底区分开来。人类思维经过成千上万年的演进，发展出了一种以神经为基础的基本架构。然而，人工神经元根本不是人脑神经元的映射，而只能算是人脑神经元的“回声”。

如果认真看看大语言模型的架构，就会发现它们相对简单——分层简单粗暴，忽略了人类思维的精妙性与复杂性。 在我们的大脑皮层中，有着数千万个皮质柱，但却只有大概七层深度。

爬行动物也有皮质柱，只是数量上要少很多。皮质柱似乎就是人脑当中的一个个“小矮人”，它们不辞辛劳地工作，帮助我们建立起世界预测模型。而通过与丘脑和其他类似结构的紧密缠绕，人类最终拥有了决定情绪和其他决策过程的发生区。

此外，我们的激素系统似乎也对这套架构有所影响，比如影响我们神经网络当中的其他信息传递方式。从同样的角度来看，大语言模型虽然非常有趣，但也只能算是我认为的真实神经元架构的一小部分。Gray 和我观察到，我们在规模效应下所能实现的收益正在迅速递减。OpenAI 团队和马斯克都认为规模效应将持续很长时间，但 Gray 和我则持相反意见：不，我们已经趋近于极限。

也就是说，接下来的发展必须调整思考方式。让我们说回架构议题。我想强调的最后一点是，节目开头咱们聊过我参与了具身认知项目。那么，具身是什么？

这是一种构建于现实世界内的系统，对现实做出反应并在现实中行动。大语言模型最缺乏的正是这一点。它们通过文本、音频乃至视频等纺织而成的静态信息进行运作，但在感官方面却太过稀疏。相比之下，人类的思维和智能则更加先进且成熟，因为它们始终与现实世界紧密关联。

从这个角度看，我觉得智能可以分成很多类别。而人类的智慧是跟身体一同发展而来。要实现这一点，就离不开一些极其复杂的架构。也正因为如此，我才拿出六年时间研究人脑中的神经元架构，因为我们对此的了解还不够深。我希望知晓这一切将如何影响我们设计软件架构的方式。

问：对了，您之前曾在 Twitter 上发表过一些有趣的内容。引用其中的原话，“我们需要一种标准方式对架构和大模型活动进行可视化，并且将一切人工神经网络都囊括进入——类似于 AI 版本的 UML。”如今一年时间过去，您观察到这个领域是否出现了发展态势？您为什么觉得大语言模型的架构问题如此重要？

Grady Booch： 没错，我确实抱有这样的观点，也看到了相应的变化。所以在工作当中，我们一直尝试对大语言模型的运作施以监督，想要把最佳实践路径以可视化形式呈现出来。事实证明，这确实跟 UML 类似，毕竟现在的大模型就是黑箱、是一种自我封闭的消息传递系统。 所以我想为其确定最佳表示方式。

大家应该也知道，不久之前 AlphaFold 刚刚公布了项目的源代码和权重参数。我把握住这一点，并打算以此为基础使用 UML 的交付成果来描述 AlphaFold 3 的架构，敬请期待。我觉得这方面还有很多工作可做。对于刚刚进入软件行业的软件工程师们，很多新人都觉得自己面临着充满挑战的就业市场。我个人给出的建议是：1）积累作品集：开发有助于展示你技能和兴趣的项目，什么都可以，无论是个人项目还是开源软件贡献；2）拓展人脉网络：积极参加行业聚会、会议，并在 LinkedIn 等平台上跟专业人士多交流，人脉网络往往就是开启工作机会的大门；3）终生学习：科技行业一直在不断发展，请务必通过在线课程、教材和阅读相关材料，保证自己随时了解最新趋势和技术；4）广撒网：洒把自己局限在跟专业技能完全匹配的职位上，可以申请多种职位以增加被雇主注意到的几率；5）认真准备面试：演练常见的编程问题和系统设计面试，LeetCode 和 HackerRank 等平台都是很好的选择；6）坚持不懈：第一份工作的得来可能需要不短的时间，请一定坚持下来并在期间持续提升自身技能；7）寻找实习机会：寻求实习或者合约岗位以积累经验，这有助于大家成功过渡到后续的全职岗位。请记住，职业生涯的初期总是充满挑战，但只要坚持不懈并采取正确方法，相信各位一定能在软件行业找到属于自己的一席之地。

问：我有种感觉，AI 工具正在改变我们开展软件工程的方式。您经历了软件工程领域的一系列创新周期。对于刚刚起步的新人，您能不能就如何实现成功的软件工程职业生涯方面提供一点建议？

Grady Booch： 没问题。当初 Copilot 和 ChatGPT 刚刚问世时，我收到过很多网友发来的消息。他们感叹，“天哪，难道我选错职业了？未来根本就不需要人类开发者。”其实并不是这样，无论使用哪种语言，市场永远需要能够做出明智决策的人。

软件工程是个抽象程度不断提升的领域，只不过与之配套的工具发生了变化。 我当初学的是用汇编语言编程，但如今人们会使用抽象程度更高的语言来编程。所以关于这个问题，我想给大家提两点建议。

首先，不必焦虑、也不必恐惧。总会有一些很酷的工作在等着你去完成。实际上，我倒觉得现在是个好时代。在这样一个激动人心的历史时期，我们面对着如此多的机遇、酷炫的工具和超量供应的计算资源。所以总的来讲，真正限制我们的就只有自己的想象力。

因此，我鼓励大家先尽可能多去学习。另外，不要把自己限制在单一领域之内。虽然我们确实需要成为某个领域的专家，但计算世界是如此广阔，所以不妨考虑在一个还没人涉足的领域为自己打响名声，毕竟那里有很多很多机会在等待着我们。

第三点就是，希望大家能尽量享受从业的过程。我的意思是，如今的技术工具太新奇、太有趣、也太实惠了。一个人居然可以用如此低的成本做出那么多可能改变世界的尝试，这还不够神奇吗？最后我想跟大家说一句，就连我都不会觉得自己太老，我仍然在享受软件工程的乐趣。

除了之前提到关于研究人脑和使用大语言模型的事情之外，我目前还在兼顾两个项目，而且已经为此工作了很长时间。首先，我一直在尝试写一本关于软件架构的书。很高兴自己之前没有急着动笔，因为我现在比以前知道得更多。这是一本不同于以往的架构书，其中的内容不只是是指导，而更多是要记录我曾参与合作的几家企业的现有架构。

所以我想把 AlphaFold 也囊括在内，还有 Photoshop。比如讨论 Photoshop 采用了怎样的架构、气候监测系统采用了怎样的架构、维基百科采用了怎样的架构等等。

总之，我想要记录人们当前所熟悉并且正在使用的系统架构，这些已经被忽视太久了。世界上存在这么多不同的架构形式，我要向大家介绍它们，毕竟哪怕是从业者大多也只接触过其中特定一种。现实世界其实更加广阔。

第二件事就是《软件架构指南》，出版社的编辑已经忍受了我十年，非常感谢有这么好的耐性。我希望自己能在去世之前把这本书写完。我在计算机历史博物馆董事会任职大约十年，期间一位新上任的 CEO 突然找来，问“Grady，你为什么不拍一部类似 Carl Sagan 的〈宇宙〉那样的纪录片呢？”

我回答说，“我不是 Sagan，但这个想法倒是有趣。”所以我在考虑创作纪录片的同时，决定写一本关于计算与人类社会发展历程的书，探讨计算的历史和人类的意义。其中希望探讨这样的问题：计算思维是什么样的？计算又如何改变个人、社群乃至整个国家？计算如何改变科学、艺术还有宗教？这又引出一个终极问题：在计算的背景之下，人类的意义应该是什么？这就是我目前正在进行的重大项目，希望能在去世之前把它写完。

好的，那咱们进入收尾的快速问答部分。我直接提问，您直接回答、不用考虑太多。

您使用过的第一种编程语言是什么？

Fortran。

您最近为哪个项目提交过代码，在项目中使用的是什么语言？

最近一次提交是 Self 项目，用的是 Python。

开发这事其实很累人，那您是怎么在劳心劳力的软件开发之余恢复精力的？

我生活在毛伊岛。每天从床上醒来的舒爽体验就足够了。

确实，那可是个度假胜地。对于想要更多了解软件架构的朋友，能不能为他们推荐两本书？

我个人最推荐的就是 Mary Shaw 的《软件架构》，其他任何选项在它面前都黯然失色，所以就先推荐这一本吧。

好的，非常感谢 Grady 能参加我们的节目。跟您聊得很开心，也很有启发。

我也很荣幸，感谢你的邀请。

参考链接

https://www.youtube.com/watch?v=u7WaC429YcU

---

via:

• Evolution of Software Architecture: From Mainframes and Monoliths to Distributed Computing | Orkes Platform - Microservices and Workflow Orchestration at Scale
  https://orkes.io/blog/software-architecture-evolution/

• 软件架构 50 年：大模型是否开启新的抽象层次？ACM 院士、UML 创始人谈软件架构演变
  https://mp.weixin.qq.com/s/14ehvBvdiq8syWzWrCPhkg