在法求学时，一位教授告诉我，架构为什么是architecture？因为它有点像art。对于这个稍微有点“冷”的笑话，我第一个联想到的就是香港中银大厦，在我看来，中银大厦的外观设计与采光系统简直是平衡功能和艺术的杰作。这大概就是惊艳的architecture们的共通之处吧。
OK，言归正传。经历了业务分析与需求工程，今天终于来到了系统架构设计。这部分可以说是整个“V”模型中最重要的一个部分。可以说，当完成系统架构设计后，一个系统的performance已经定性了（这里我不想用“性能”这个词，原因我们下面再说）。
1. 何为系统架构设计？
This process encapsulates and defines areas of solution…with the system’s technical and commercial requirements and risks…
ISO/IEC 15288:2008
上文是ISO/IEC 15288:2008中关于系统架构设计目的的部分解释。从中有几个值得我们注意的关键词：areas和technical and commercial requirements。
第一关键词：Areas
“Areas” 的潜台词：架构设计的结果不是某种特点的solution，而是由多个solutuions组成的有共同性的“解”的集合。这个共性，也就是对系统需求的响应（当然，由于不同的架构设计会产生新的衍生需求，架构A不可能响应架构B的衍生需求，因此这类需求不在讨论之列）。
通过构造潜在架构的集合，一方面能够继续约束“V”模型下面的设计工作，另一方面，也为系统保留了“可能性”的基因，更可能在设计工作中产出革命性的产品。
虚线域内的任何一个点都可能是未来被采用的架构/solution
（结合上两期说到的需求工程，其实会发现在完整的工业体系流程中，伟大的工业产品，其初始定位往往是通过尊崇更基础的行为逻辑而产出的。这与我们传统认知中认为很多“灵光一现”而早就杰出产品的观念相矛盾。）
第二关键词：Technical & Commercial Requirements
这又是我们老调重弹了。既然架构是对系统需求的响应，系统需求是对STH Reqs的响应，那么架构就不可能不体现commerical需求。系统工程和机械工程、电气工程、自动化工程等等“工程”最大的区别就在于此。如果说其它各种“工程”是对“更高、更快、更强”的追求，系统工程则是一门平衡的艺术。而“优美”的系统架构就是这一艺术最好的体现。
既然是一门“艺术”，“优美”的系统架构也就没有优劣之分，好比谁也没办法比较莫奈和毕加索谁的作品更好？我没能力评价美术作品，但我知道，两者混合，肯定不是太好，因为风格不统一。同理，我们是不是可以推断“优秀”的系统架构都在遵循着各自内在唯一的设计哲学？
（图为莫奈的睡莲与毕加索的镜前女孩）
2. 架构设计的核心任务
解决了何为系统架构设计的问题，我们把系统架构设计从艺术的玄学领域拉回来，明确架构设计的核心任务，让它变得可操作起来。
实际上，系统架构设计可以理解为在一个高维空间中搜索最优解的过程。只不过这个空间也是需要自己建立的。
a）确立评价准则
评估评估准则是对判断系统架构的一个重要步骤。这跟之前说的系统架构设计无法评估优劣并不矛盾。在不同的设计哲学与理念下，我们很自然的不能比较毕加索与莫奈，但是当在统一的设计理念（或者说评价体系）下，评价他们却是可以的。
建立评价准则的过程可以理解为构建一个开放的高维特征空间（可以理解维度就是评价准则的数量）。因此，按照SE的理念，这一步的工作更多是关注如何响应更根本的功能需求（也就是建立空间），而不是纠结于具体技术细节本身（在空间中寻找符合要求的解），从而拓展系统架构设计的可能性。
同时，为了避免出现“萝卜招聘”的情况，先有评价准则再有待选的系统架构方案才能客观的对系统架构设计进行评价。当评估准则建立时，对应的“最优解"就会确定。
而如何根据需求准确建立每个系统的评价准则，如何平衡各种因素在评估时的权重，就是系统工程师的重要任务。
b）建立备选方案集
（高维空间中可能有无数个三点都满足需求，那么哪个才是最优解？）
在建立了评估空间之后的下一步工作是通过建立备选的解的子集合，降低搜索最优解的难度。
在这一步，体现系统工程师能力的时候又来了。如何平衡解的包络的大小？大的包络当然能包含更多系统设计的可能性，得到“惊艳”的系统设计，但是也会造成搜索最优解的过程冗长，浪费大量的资源。
c）选定系统架构
现在我们左手握着评价准则，右手拿着候选系统架构，已经可以做出选择了。下面的工作就不用多说了，就是系统工程师的“老把戏”——tradeoff。通过建模、仿真、分析等等手段，选择一个备选方案并证明其为最优就可以了。至此，我们就建立了系统的基线作为后续工作的输入。
之前聊过的，系统工程的两个核心思想：“需求”与“追溯”。完成了对需求的响应，这一步继续向下追溯就要到分系统了。因此，此处的基线应能提供后续需要的分系统需求、验证确认需求、系统组成描述等等后续开发所需要的全部信息。当然，后续还少不了持续迭代。
3. 总结
综上，可以看出在系统架构设计的整个过程中，各种权衡无处不在。从技术风险到成本效益，从备选部件到可能的架构。我想，架构设计可以比作一项“带着镣铐跳舞”的活动，甚至更难，因为还要考虑“美观性”和“完成度”。这大概也能解释在各种SE手册中，系统架构设计都是技术部分着墨最多的。然而，正如之前所说，系统架构设计就好像艺术一样。无论多么熟悉架构设计的流程，“惊艳”的架构永远还是需要一点灵感的。这大概也就是为什么革命性的工业系统也好像杰出的艺术品一样稀少吧。
（左图为通过风格迁移得到的“莫奈风格”的莲花，右上为原图，右下为莫奈“睡莲”原画。虽然大部分人无法像大师一样创造“惊艳”的系统，但是通过技术手段，“照猫画虎”足矣。）
欢迎关注我的微信公众号，一起交流系统工程技术