系统架构10|系统架构师如何扮演好角色？

精进学思行 精进学思行 今天

工作中，你是否会碰到一些新的任务，相对比较复杂，已经有了一些的信息，但是没有形成一个结构清晰的框架来安置它们？

还有一种情况，就是对于一个产品开发，有不同来源的需求，在开发中需求不断变化，而且关于需求的表述还常常是模糊和有歧义的。在这种情况下，如何保证产品正常开发？

这个时候，就需要一个人或者少数的人，把基本的框架搭建起来，并让共同协作的人准确理解这个结构，在关键时刻，还需要做出果断的决策，否则很难推进一个较为复杂的事情。正如亚伯拉罕.林肯所说：

“必须有人做主，否则什么都定不下来”。

在系统架构中，这个人就是系统架构师，而他们扮演的角色对我们回答前面提到的两种情形也很有启发。

什么是系统架构师？

系统架构师的英文是“Architect”

韦伯词典中：

"a person who designs buildings and advises in their construction"(设计建筑并在其建造中提供建议的人)；

维基百科：

An architect is a person who plans, designs and oversees the construction of buildings（计划、设计和监控建筑的建造的人）；

百度：

系统架构师（同架构师）是一个最终确认和评估系统需求，给出开发规范，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技术人员。

从上面三个不同来源的定义中，我们会发现，架构师最初的定义和建筑物的建造有关，而在系统架构中，架构师是最终明确需求、搭建核心构架扫除主要难点的人。

在《系统架构》中我没看到明确的定义，但是它对架构师在系统架构中需要扮演的角色，主要成功及可用的抓手给出了清晰的论述。这也是本文分享的核心：

架构师在系统架构中的主要任务是什么？

架构师如何体现其贡献，他的关键成果是什么？

有什么好的抓手，可以帮助架构师完成任务，达成成果？

1 三个任务

在前面的定义中，我们已经初步了解了系统架构师的主要角色，《系统架构》中对其进行了更加明确的说明，系统架构师的重要的三个任务是：消除歧义、发挥创造力，管理复杂度。

1.1 减少歧义

为什么减少歧义是架构师的主要任务？因为系统架构师最核心的成果是设计一套满足需求，且可以实现的系统架构。而在开发一个系统（比如一个产品）的前期，需求常常是模糊的，开发目标是不明确的，有些时候，具体实现技术也是不清晰的，这就会导致系统的需求方和实现方产生很多认识的偏差，很可能系统实现的功能和效果不是需求方设想的，这个我在工作中也常常见到，比如工程部门的人抱怨市场的需求输入不明确，而且总是在变化需求，或则市场抱怨工程部门实现的东西不是它们想要的。

所以，为了减少这些常见问题，就需要在系统架构阶段，减少歧义，而这是架构师的重要职责之一。而为了减少歧义，就需要了解歧义产生的常见情况，并尽可能降低。

在《系统架构》中将歧义分为两类：模糊和不确定。

什么是模糊？如果某个事件或者某种状态可以解读为多种不同的含义，就会出现模糊（fuzziness）。比如我在做汽车声音设计时就会碰到一个常见的需求描述——“声音要好听，有品质，有高级感”，这个怎么理解？这就是一种模糊。因为不同的人对其解读很可能不一样，比如有人会觉得低沉的大提琴有品质和高级感，而有人觉得明亮的钢琴声有高级感，这就是一种模糊。

如果某个事件的结果不明确或是值得怀疑，就会出现不确定（uncertainty）。比如扔一个硬币，我们知道它有两种可能的结果，要么正面，要么反面，但我们事先很难知道一枚硬币扔出去是哪种结果。

《系统架构》中按照公司的职能安排，列出了常常容易出现歧义的情况：

策略方面：公司执委会/董事会愿意承担多大的风险？

客户方面：客户想要的是什么？他们的需求会不会随着时间变换？

法规方面：产品应该遵循的法规有哪些？是否有可能发生变化？

研发方面：那项技术是不是很难融合进来？

制造方面：生产产品的制造设备是否就位了？

……

上诉这些信息都可能存在模糊、不确定，甚至是矛盾的，而架构师的作用就是要尽量给团队提供更加确定而不是那么模糊的信息，有的时候可以通过分析来减低（比如明确定义），有的时候可以通过施加限制（比如明确技术能实现的内容），而有的时候，只能先做出假定，先走几步看看。

具体如何降低歧义，第三部分我们会介绍一个抓手来进一步说明。

1.2 发挥创造力

什么是发挥创造力？我们之前在系统架构8 概念|需求和具体方案的探索空间中介绍过，概念是连接功能和形式的桥梁，在系统架构中，发挥创造力，关键就是提出并制定各种备选概念，找出衡量的标准，进行权衡和优化，我们在系统架构8 概念|需求和具体方案的探索空间中也有专门的介绍。

1.3 管理复杂度

在系统架构2：分解-管理复杂的利器，我们分享了管理复杂的一个利器——分解，作为系统架构师，就是要选择合适的分解角度，在满足功能的情况下（必要复杂度），降低理解的难度（表面复杂度）。

2  可以交付的成果有哪些？

上面虽然清晰定义了架构师的任务和责任，但是总体感觉有点“虚”，如何具体衡量他的工作成效，或者他的可以交付的具体成果是什么呢？《系统架构》中给列出了8条架构师可以交付的成果：

①对系统所处大环境（法规、行业标准，公司内等）所做的描述；

②一套清晰、完整、连贯的目标（重点是功能方面），并且架构师要有80~90%的信心能达成目标；

③系统概念；

④系统操作概念，正常如何使用？出现异常后如何使用？

⑤系统的功能描述，并做到至少两层的分解；

⑥对形式做的两层细分，并完成功能和形式的匹配；

⑦所有外部接口，以及对接口控制所做的详细描述；

⑧一套涉及开发成本、工期、风险以及设计、实施计划的观念。

八个不容易记住，我们可以将其分为4个部分：环境识别（①）-目标设定（②）-系统架构（③④⑤⑥⑦）-实现了解（⑧）。

3 一个抓手

前面两部分介绍了架构师的主要职责及成果体现，而系统架构的工作的价值，最终还是要通过产品来实现，而刚好有这样的一个工具，帮助架构师更好完成任务，产生成果，这就是PDP(Product development process), 也叫产品开发流程。

为什么它可以帮助架构师？因为PDP通常会对任务及职责进行定义，而这可以帮助架构师消除歧义。

稍微大一点的公司，都会有自己的内部产品开发流程，《系统架构》作者提到，他翻看了很多企业的PDP，发现不同的PDP有很多的共通点，从我个人的经历来看，我供职的两家汽车企业，分别有自己的开发流程，而我也发现他们的相似性也是远高于差异的， 只是有些名称不同而已。

《系统架构》总结出了一套通用的产品开发流程，并为了更好理解它，衍生了三种不同的表现形式。

3.1 常规套路

如下图所示，展示了PDP中普遍存在的活动，主要包括了构思-设计-实现-运作四个步骤，它为我们提供了理解绝大多数产品开发的一个框架，但是作者特别强调，这不是一个线性的过程，所以用灰色箭头（下游影响）表示了这是个互动和迭代的过程，而且图中虚线特别强调了架构师的主要工作领域。

3.2  三种视图

为了更好呈现系统架构的全局性和迭代性，书中也给出了三种演化的视图，这三张图重点突出了系统PDP和周围环境的关系，这也是我们在下一次要分享的。

总结

1 系统架构主要是由系统架构师完成的，系统架构师的主要职责包括：消除歧义、发挥创造力和管理复杂度；

2 完成这些职责的主要成果体现包括：描述了系统所处环境、为系统设定了明确的目标、并对系统的功能和形式进行了定义和分解（至少到第二级）；

3 在这个过程中，产品开发流程（PDP）是帮助架构师消除歧义的好抓手。