“顶层设计”设计什么？

    最先接触“顶层设计”一词，是在软件的架构设计中，显然，它是软件架构设计的一部分工作。这个我原以为是一个技术性很强的词，现在越来越被国人，尤其是媒体转述政界话语时，每每讲到国家政策制定，都会说“要加强顶层设计”之类的话。因为，在听到这句话之后所听到的话，总感觉很空洞，所以，我的第一反应是这个词被滥用了，成了一个官僚词汇了，往后软件架构师可能不再敢用这个词了。

最近读到《穿越歧路的花园》讲到美国著名政治科学家司马贺的一生，早年从事政治科学和计量经济学研究，晚年极力倡导人工科学，提出建立人工系统的设计学问。加上司马贺对复杂系统的层级结构十分强调，让我感到我的那个第一反应，可能只是反映了我之前的视野比较狭窄，只局限在软件工程的范畴来考虑顶层设计的问题。

多年前，我参与过余彤鹰主持的企业工程网站的讨论，当时感觉，软件工程不得了了，软件工程的方法可从软件系统工程推广到企业系统工程，甚至社会系统工程和国家系统工程了。我当时当然也知道，这是受钱老系统工程思想的“弥漫影响”结果。

现在，这条影响我的思想的这条信息传导“外线”，似乎清晰了一些：维纳-司马贺-钱学森-武夷山-王飞跃-我。说是“外线”，是相对我早先相对熟悉的“软件工程”：-个体软件工程-团组软件工程-企业软件工程-RUP-CMMI这条“内线”而言的。早先我只是从“软件系统”这个“微观系统”内部实践，认为实践经验可向外推广到更大的以致国家系统层级上去。而今，我知道了，之所以有软件工程实践的来由，原本就是从整个社会系统工程导入的。而在国内，则主要是受钱学森系统科学理论熏陶的产物。有趣的是：CMMI，这个集成化的软件过程成熟度模型和司马贺这个人，同样来自美国的卡梅隆大学，应该有思想交集但我却没有在《穿越歧路的花园》中看到他俩的行为交集。

总算清楚了“顶层设计”原本就不是软件架构设计的专利了。

现在说回“顶层设计”的问题。也许不可否认的是：“顶层设计”的思想，在软件工程领域的实践也许是最充分的。由于软件的特殊的辐射和信息的渗透力，在软件工程架构设计上取得的经验和知识，或许，真值得反哺到更广泛的系统工程领域。更何况，“软件”一词，也就早就不是计算机系统的专利了，早就反哺到社会系统工程领域了。

然而，在我看来，这种反哺，看起来目前仍只是观念层的反哺，而没有达到技术层的反哺。否则，我们听过到的媒体津津乐道的“顶层设计”不会让人感觉“官架子”那么大。

在软件工程领域谈顶层设计，实际就是在谈用户的核心价值的需求。当然这只是观念，那么，在软件技术上又是如何谈的呢？在技术上，软件工程是通过需求工程对客户的可能涉及软件系统的业务系统进行分析和设计导出顶层设计的。

具体地说，就是通过深入用户组织内部做用户组织的业务调查，了解用户组织的业务流程存在的问题和改进的需求和机会，然后结合信息化手段的应用方法，设计在具有计算机信息系统的支撑下，用户组织的业务流程和业务方法存在哪些改进的机会？改进的长短期收益是否大于建造和运维计算机信息系统的综合成本？当然，软件的需求工程已经实践了很多的软件工具和方法，比如基于UML的业务建模方法。UML业务建模方法则是一整套系统成熟的方法，这套方法继承了面向对象的世界观方法，比传统的结构化方法有诸多的优势，尤其在组织的动态模型方面。然而，由于行业的隔阂，这套方法远没有得到其可实现的反哺价值。通过业务建模导出的信息系统的顶层设计，是一套“核心用例视图”所描述的“核心用例模型”。

软件界经常为用户的需求变化而烦恼，但也广泛流传着一句话是：“其实用户的需求很少变化，变化的是我们对用户需求的理解”。说的就是“核心用例模型”所能解决的问题。“核心用例模型”所描述的内容，就是软件的顶层设计的最顶层的工作，这些内容又包含些什么呢？

先说“用例模型”UseCase Model，什么是用例UseCase？用我早年的话说是：用例就是有用和可用的过程事例。就是用一组可能重复出现的过程事例，来反映用户组织活动的价值性和可操作性。这符合我所归纳的一个动态组织框架：目的-目标-行为-对象-实体的层次性框架。熟话说，听其言，观其行，一个人的心里想什么，不能光听他说出来的话，准确地说，不能光听他说出来的想法，而且要听他说出来的做法，比如说他说他爱你，怎么才能有可信的机会？他肯不肯说出他肯为此做出的行动？因为行动才能反映真实的目的，因为只有行动才能取得实际的效果，才需要支付相当的成本。所以，用例模型正是从“过程事实”的角度来表达过程价值和过程价值关系，以及支持过程价值关系实现的行为关系所建立的动态模型。因此“用例驱动”成为了软件架构设计的至理名言。用例驱动的实质是：目的驱动目标，目标驱动过程，过程驱动对象，对象驱动实体。所以，用我当今的话说，用例就是事实。你希望看到什么样的事实每天在你的周围发生着，这些事实如何才能发生？这，就是用例。

而用例模型，则是对这些事实建立模型，建立模型就是抽取核心信息，关键信息，用结构化和形式化的语言进行描述。用例模型的作用是双重的：一方面用例模型需要反映预造事实的目的和目标，另一方面，要反映目标实现的过程。极其重要的是：用例模型所确定的目的和目标不是孤立的，而是相互关联的——不仅是在心理需求的意义上关联，而且要在系统动力学的意义上关联。只有经验丰富的架构师才能在这二者之间取得贯通。通常的用例模型设计要么偏重目标体系设计的心理需求，使其过于理想化而不能整体落地，局部落地的效果往往偏离初衷；而另一个极端是用例模型过于偏重操作性，成为盲目的功能设计，造成“行为孤岛”，当然也不能取得架构设计的整体效果。

对比用例模型，核心用例模型又“核心”在哪呢？我们常听到过媒体也常常提到“核心价值”这个词。不过常常是在谈论外交关系时讲到的。通常理解是对象最看重的，影响对象自身厉害关系的要素，就是对象的核心价值。而不管对象是什么，一个国家，一个社群，一个组织，一个团队，一个人，一套软件均如此，当动了它，对象就会要命或要爽透，都是对象的核心价值。对象的核心目的，无非就是要维持其核心利益不受侵犯的前提下不断光大。一个对象的核心价值可能不多，但对象会围绕这些核心价值建立多个相关的目的，围绕这些目的会设立多套相互制约和影响的目标，围绕这些目标又会建立和设计互动的流程和计划，剩下的就是功能、行为和实体层面的问题了。能作为“核心”的，大多是稳定不变的驱动因素，作为有意识的主体对象，其核心，不过于是对象的价值、目的和目标，相对于功能需求，行为需求和实体需求来说，对象的价值、目的和目标的需求变化频度无疑的很低的，但正是它们决定着对象的一切。所以，如果说，顶层设计就是核心用例模型的设计的话，顶层设计要设计的，正是：横向的，要设计：对象的价值及价值关系，目的及目的关系，目标及目标关系，核心能力及核心能力的关系；纵向的，要设计价值与目的的关系，目的与目标的关系，目标与实现目标的核心能力的关系。

实际中的顶层设计，往往是重要素设计而轻关系设计，重横向设计而轻纵向设计，这是顶层设计最容易产生的缺陷。一个顶层的设计，只有完整的包含这些要素时，才能称为合格的顶层设计，但是否是有效或好的设计，还需要看其用户是否满意，其用户主要包括：其实现者和受用者。

如果说，一个国家的政治需要顶层设计，那么，对照这些要素不难找到“评审”这些顶层设计是否合格有效的要点。当然，这仅限于对设计的满意，而对设计的满意会给对现实的满意带来无尽的希望。从“中国梦”到“中国设计”有多远呢？在“设计中国”的事业中，你我又能做些什么呢？

邱嘉文

2015年1月20日

修改分类至“智慧城市”