《复杂系统应用架构》--概念到落地

引言

最近广州在举行车展，肯定很多朋友都在想，展厅这么多概念车，这么漂亮，为什么不量产？

为什么总有朋友会担心量产版本会被修改的“惨不忍睹”，江湖人称：“概念林志玲，量产罗玉凤”

 

类比我们的系统，往往架构设计很美好，现实很骨干~

 

《系统架构，复杂系统的产品设计与开发》中，给出比较“学院派”的指导。对于建立体系化架构思路很有帮助。

学习目标

如何定义出概念

怎么将概念落地

架构师在里面的职责是什么

名词解释

 

1：什么是系统架构？主要元素是什么？

简单说：

系统架构=功能+形式

形式=元素+结构，是系统的物流体系或者信息体现，

功能=实体+操作数（多为对象），

 

形式举例：汽车的零部件构成是形式，一个程序的代码也可以是形式；

功能举例：（房子）的功能=安置（过程）+居住者（操作数）

对象：某段时间内有可能稳定而无条件存在的事物。

2：什么是复杂的系统？

原子部分出现在Level 0层，为简单系统

原子部分出现在Level 1层，为适中系统

原子部分出现在Level 2层，为复杂系统

 

概念

什么是概念？

在《系统架构》中对其定义是：

概念是我们对产品或系统所形成的图景，理念，想法或者意象，它把功能映射到形式。它是对系统所做的规划，描述了系统的运作方式，能够使人们感到系统会如何展示其功能，也能够体现出对系统形式所做的抽象。它是对系统架构的一种简化，有助于我们对架构进行宏观的探索。

 

这个表述看上去很复杂，简单理解，就是初步描述我们构建的系统，大概是什么样的，能做什么。

 

通俗地讲，概念是一种构思和概括化表达。

 

概念也是用来链接形式和功能

为什么需要概念？

1：从具体功能到系统的架构，之间有这巨大的鸿沟，需要一个转换过程

2：一开始很难对新的产品有清晰的认识，可能只有大概的理解，比如概念车

3：人处理复杂的事情比较吃力，需要抽象和拆解，转换为简单容易理解的事务上。

 

 

L0：定义概念：

 

概念是我们对产品或系统所形成的图景，理念，想法或者意象

概念可以弥补从“和具体方案无关的功能” 到“系统架构”之间的鸿沟

构思框架：

 

左边虚线框外的部分，叫做“意图”，也就是我们构建的系统需要实现什么目的，右边虚线框内的，就是我们对实现意图的一个概念构思，它包括了对功能和功能两个方面的构思，左右两边的关系其实是从“一般”到“特殊”的关系，只不过在图中用“和特定……无关”和“特定”来描述

 

而它背后的逻辑是:

系统/产品的主要受益者是谁？

通过什么活动（过程），改变了什么（操作数，属性）让其受益？

实现这种活动的载体或工具是什么（形式）？

 

 

如何产生更加具体的概念呢？

向下拓展

上面只是个我们提供了一个构思的框架，如何产生更加具体的概念呢？《系统架构》提到了两个重要的概念：整体概念（integrated concept）和概念片段（concept fragment），而且通过形态矩阵（morphological matrix)这个工具，为我们展示了系统产生概念的方式。

 

 

上表展示的是针对“运输服务”（集成概念）的概念构想，任何运输的过程都包括三个部分：提升，推进和导向（概念片段），为了实现这些子功能，可以有不同的工具，对他们进行排列组合（形态矩阵），就可以形成大量不同的概念方案。

 

向上延伸

如果说“整体概念-概念片段”是一种向下拓展，你可能很容易想到，有没有可能向上延展呢？当然，向上拓展，就能发现当前这个概念也只是更大概念体系中的一个，而且这种拓展有时还能带来新的创意。

 

以"人"的“运输服务”——旅行为例，我们为什么要旅行？是因为要去客户的办公室见客户，为什么要去见客户？是为了更好了解客户的偏好；为什么要了解客户的偏好？是为了谈成一笔生意。

 

 

在这个过程中，有很多的环节，每个环节都有可能延伸出新的概念，比如，为了了解客户偏好，一定要去客户办公司吗？电话会议可以吗？间接了解可以吗？通过对旅行这个概念，向上延伸，可以让我们从另一个角度思考解决问题的概念方案。

怎么落地（架构过程）

L1：初步构想

逐步识别汽车这个概念所需要考虑的功能，功能确定后，选择实现它的形式，比如为了实现动力功能（功能），可以用内燃机或者电机（形式），它们共同就构成了第一级的结构

 

从1级架构到2级架构的分解过程，也是类似递归的过程。比如上面汽车一级架构分解到了动力系统，选择了电机，那么二级架构就可以通过相似的方式，先识别电机应该具备的功能，以及其对应的形式是什么。

 

于是《系统架构》引入了操作行为这个概念用来描述对系统的使用，它主要包括了三部分：操作者，行为，操作成本。

 

2.1 操作者

操作者和好理解，就是谁操作这个系统，比如正在使用手机的你，就是手机这个系统的操作者和使用者。因为目前很多系统都有人的操作，所以人的因素对系统的设计很重要，好的系统要考虑人机工程和人机交互。

 

2.2 行为

行为，通俗理解就是做了些什么，《系统架构》对其进行了精准的定义：

行为是由功能以及功能相关的状态变化所构成的序列，系统中的形式对象应该按照这个顺序来执行各个功能，以便使系统的价值得以体现。

并且书中把和行为相关的操作顺序（operations sequence）和系统时机（timing of the system）进行了 区分。前者指的是系统在动作或过程的整体进展情况，比如你要开车，首先要进入车辆-点火启动-加速……，它们主要描述的是动作的先后次序，对精确时间的关注较小。

而系统时机关心的是步骤的执行时机，起始时间，持续时间……，因为对于实时系统而言，这些特别重要，比如制动功能，需要在踩下刹车的若干毫秒内，把刹车装置部署好。

也非常像在做汽车的声音设计时，声音一定要在合适的时间出现，比如设计汽车加速声音时，如果踩下油门踏板后，过了一秒钟，相应的声音才出来，体验肯定非常差的。

所以，好的行为，是要按正确的顺序在正确的时间做正确的动作。

 

2.3 操作成本

第3项指的是操作成本，就操作系统需要的成本，比如你汽车行驶100公里，需要多升油和多少度电。

 

控制复杂度

我们介绍了两种描述系统的标准语言，但如果严格按照这样去做，对于一个稍微复杂点的系统，就会看上去较难理解，比如下图表示的是一个离心泵的工作过程，很容易常常让人感到难懂，所以有必要进行一定的简化。

 

 

书中给出了三种简化方式：隐藏细节，忽略细节以对系统进行投射，我们重点介绍第3种。

投射的思路就是：把系统中的过程投射到对象上。《系统架构》中给出了3步：

第一步：单独看某个对象；

第二步：沿着与该对象有关的链接找到相连接的过程，再沿着该过程，找到和它相连的另一个对象；

第三步：把“对象-过程-对象”的路径变成“对象-对象”，用标注说明对象间的过程关系。

 

 

 

为了便于理解，我们以书中的切片面包为例，左边这张图是标准的OPM结构图，右边是简化后的，可以看到它简化掉了用来表示过程的椭圆形状，这种简化可以一定程度降低“理解”的复杂度。

 

L2：系统拆解

从1级架构到2级架构的分解过程，也是类似递归的过程。比如上面汽车一级架构分解到了动力系统，选择了电机，那么二级架构就可以通过相似的方式，先识别电机应该具备的功能，以及其对应的形式是什么。

 

这里有个很重要的概念——递归。什么是递归？它在软件程序中用的比较多，指的是运行中调用自己。你估计听过一个典型故事：

从前有座山，山里有座庙，庙里有个和尚，和尚在讲故事，从前有座山，山里有座庙，庙里有个和尚，和尚在讲故事，从前有座山...”，

 

把这个故事加一个结束条件，就是典型的递归。这种现象在层级制的组织中也比较常见，总裁管着几个副总裁，几个副总裁管着几个总监，总监再管几个经理，经理再……，当然每一层级的管理方式可能有些差异。

 

这和系统机构的分解有什么关系？从1级架构到2级架构的分解过程，也是类似递归的过程。比如上面汽车一级架构分解到了动力系统，选择了电机，那么二级架构就可以通过相似的方式，先识别电机应该具备的功能，以及其对应的形式是什么。

 

架构中的模块化，简化复杂度

如果每个系统，我们都分解到原子部件，很容易超出人们的理解程度，所以需要降低其表面的复杂度，一个重要的方法就是模块化，将原子部件集成为各个模块。我们在使用的模块的时候，常常不需要关心模块内部的具体内容，只需要知道模块的功能和结构，典型的就是芯片的使用，对大多数使用芯片的人，关心的只是输入和输出。

 

模块不仅可以降低表面复杂度，而且对系统修理也比较容易，常常只需要更换换掉的模块就可以。那是不是模块化越多越好，其实也不然，因为如果模块太多，那么你就要定义很多的接口，而接口的数量的增加其实也会增加复杂度，另外，模块通常就意味着里面有一些模糊的东西你不知道，存在黑箱，你是不清楚里面究竟发生了什么？

 

对于分解而言，除了前面提到的方向和深度，还有一个重要方面是——分解面（也叫分解平面），通俗讲就是我们从哪个角度进行分解，比如对人群，我们可以按照年龄、性别，职业等进行分解，分解面的选择，不仅影响人们的理解程度，也会影响系统最后功能的涌现以及架构的美观程度。

 

以汽车为例，我们可以按照构成部分，将其分为车身，底盘，电驱动等，也可以按照性能/功能分为加速性能，制动性能，储物功能，舒适性能都等。

在《系统架构》中提到了13种常见的分解面，最典型的如形式、功能、设计自由度等。

 

架构师职责

 

什么是架构师：

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

 

《复杂系统架构》本书给了架构师职责的定义：消除歧义、发挥创造力，管理复杂度。

1：消除歧义

架构本身就要跨越上下游活动，上游指创建前已经确定的事情，架构师着手架构前，往往是接到一个上游的需求，上游的需求往往又是不确定性的，架构师需要消除上游过程中的歧义，创造系统的边界并明确系统的目标，

2：发挥创造力

前面提到的概念，就是架构师们需要发挥创造力的方法论。

3：管理复杂度

作为系统架构师，就是要选择合适的分解角度，在满足功能的情况下（必要复杂度），降低理解的难度（表面复杂度）。

 

架构师可以交付的成果有哪些？

1. 对系统所处大环境（法规、行业标准，公司内等）所做的描述；
2. 一套清晰、完整、连贯的目标（重点是功能方面），并且架构师要有80~90%的信心能达成目标；
3. 系统概念；
4. 系统操作概念，正常如何使用？出现异常后如何使用？
5. 系统的功能描述，并做到至少两层的分解；
6. 对形式做的两层细分，并完成功能和形式的匹配；
7. 所有外部接口，以及对接口控制所做的详细描述；
8. 一套涉及开发成本、工期、风险以及设计、实施计划的观念。

 

一个抓手，三个视图

抓手：PDP

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

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

 

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

 

 

 

视图1：5w2h

在产品开发中进行全局架构时所需考虑的产品/系统属性。请注意,图中的交互都是双向的，整个过程不一定要从左至右解读。架构主要是由形式和功能成的学思行图的中心部分所强调的那两个圆圈表示的就是架构

视图2：产品系统的整体框架

全局PDP的第二种视图,它展示了产品/系统开发的整体框架,并且把设计活动和实现活动明确地列为与构思活动平行的工作。请注意，图中的交互是双向，整过程不一定要按照从左至右的方向来解读

视图3：

在生产企业的大环境中审视 PDP。图中标出了企业内部的职能以及位业边果的交互对 PDP 的影响

 

总结

如何定义出概念？

概念是一种构思和概括化的东西，它建立了意向和架构之间的桥梁，创造了需求到方案的探索空间，拼接了想象到现实的路径。从系统架构的角度，生成概念方法：构思框架-向下拓展-向上延伸。

 

怎么将概念落地

逐步递归拆解概念，并将复杂的相同部分抽象成模块，控制好复杂度，然后使用PDP方法论进行实施

 

架构师在里面的职责是什么

消除歧义、发挥创造力，管理复杂度。