胜兵先胜而后求战，败兵先站而后求胜。 -- 孙子，《孙子兵法 . 形篇》
人们常常使用战术，而忽略了战略。战略要求从大局上把握整个架构与设计......架构错误的代价非常高。 -- Stephane Faroult, 《SQL语言艺术》
架构新手和有经验的架构师的区别之一，在于是否懂得，并能有效的进行概念架构设计。作为架构新手，尤其害怕碰到自己没有做过的系统：系统较大时，一点祭出“架构 = 模块 + 接口”的发布却不太奏效，架构新手就往往乱了阵脚。想法，有经验的架构师不会一上来就关注与如何定义“接口”，他们在大型架构设计的早期比较注重识别重大需求、特色需求、高风险需求，据此来设计概念架构。
另外，概念架构设计还是投标及售后工作的有力武器。金牌售前和普通售前的一个重要区别是，能否清晰的讲解概念架构，并借此说明 “客户关系的价值如何实现、担心的问题如何解决”。
接下来，通过两个发生在身边的故事，来一窥上述不同工作（架构设计、投标、售前）背后的幕后英雄--概念架构。
6.1. 一筹莫展
日落西山，夜幕徐徐降临，遍布这个城市各个角落的写字楼陆续亮起了灯......
灯下，有我们这些软件从业者加班的身影。小张，还有老王，就是故事的主角。
6.1.1. 小张，以及他负责的产品
- 加班人： 小张
- 职业概况： 28岁，某医疗软件公司的程序高手，这不，公司刚刚提拔他作了架构师。
- 加班缘由： 他正负责一个名为“合理用药监测系统（
Prescription Automatic Screening System, PASS）”的软件的架构设计。由于以前没有做过类似的产品，小张压力很大。按说，压力大对软件行业的人来说早已是家常便饭了，但要命的是，小张有点不知所措了.....
晚上7点，小张坐在桌前。在心中，小张对架构的理解可以概况成一个公式：“架构 = 模块 + 接口”。
成为架构师伊始，他还专门用“接口”和“架构”作为关键词在网上搜了一把，看看别人的观点是否和他相同。结果让他非常满意，网上的一些观点和他的观点惊人的像是。例如网上有观点认为：
“当你发现可以越来越灵活的使用接口时，那么你就从程序员升级成架构师了。
在一些大型项目或大型公司里，都有架构师编写出系统接口，具体的实现类交给程序员编写。公司越大，这种情况月明显，所以在这些公司里做开发，我们可能都不知道编写出的系统是个什么样子，每天的工作可能就是做‘填空题’了”
但是，小张注定要在这个加班的夜晚，悄然开始重新认识“架构 = 模块 + 接口”这句话了。一方面，小张已在“模块 + 接口”一级做了些设计努力。另一方面，小张也感觉到问题所在了：这个PASS系统未来不可能仅仅包含一个可执行单元！相反，医生需要的功能要嵌入医院信息管理系统（HIS系统）的医生工作站中，管理员的功能需要其他方式，Server要独立出来......
小张当下的感觉，应了一句小品台词--“有点乱了”。是呀，连PASS系统到底将包含几个”可执行单元”都没有搞清楚，就考虑“模块 + 接口”一级的设计，的确有些武断了。晚9点，思路不畅的小张开始上网搜资料。在网上搜资料时，小张总是相当有耐心。他深知，虽然网上的资料非常多，但真正能启发思路的资料往往只在最后时刻出现。小张移动鼠标，右击任务栏上的“浏览器”按钮，点击了“关闭组”菜单，者表示小张任务查到的资料启发不大，准备重头来过--在今晚已经是第3次了。他若有所思，在搜索框中输入了3个关键词：”架构“、”大局“、”不拘小节“。一篇博文引起了他的注意：
概念性架构就是对系统设计的最初构想，就是把最关键的设计要素和交互的机制确定下来，然后考虑具体技术的运用，设计出实际架构。
概念性架构应该抓大局、不拘小节。
虽然概念性架构都跳不出”架构 = 组件 + 交互“的基本定义，但它们描述架构的具体方式还是有比较大的差异：有的重视逻辑层，有的重视物理层，有的通过隐喻表明机制，有的看起来似乎就是一些设计元素的组合。不同的概念性架构图中，“连接”代表的含义千差万别：有的是依赖方向，有的是控制方向，有的是数据流向，一次，必须根据具体情况而定。
小张仔细的揣摩每句话的意思。不知不觉，时钟指向了11点，小张坐不住了。他在办公室来来回回的踱步，表情时而郁闷，时而欣喜......最后，小张把文章打印了一份，塞在包里，离开了办公室。
6.1.2. 老王，后天见客户
- 加班人： 老王
- 职业概况： 35岁，某电信软件企业网管软件事业部的售前工程师。老王从事软件行业有10年了，一直做软件开发，一年前开始做售前相关工作。
- 加班缘由： 后天，他要到客户单位，做网管软件新产品的介绍。这个客户非常重要，二期公司对这一单志在必得，老王不敢懈怠。
老王看着公司草草拼凑出来的售前PPT有点发愁，架构方面的描述主要就是一个概念架构图，如图所示，这种架构描述根本没有体现产品特点，叫做售前的如何说服客户呢？
“我要不说明，谁看了这个概念架构能知道它是个网管系统，而不是电子商务或其他什么系统？”老王愤愤的想。
6.2. 制定方针
小张，还有老王，昨天都加班到很晚，但今天他们依然按时来到单位。每天的太阳都是新的。对开朗的人来说，昨天的烦恼不算什么，根本不会影响他们今天工作的热情和创造力。
6.2.1. 小张：我必须先进行概念架构的设计
小张在座位上坐定，破例没有查收邮件，更没有上网看新闻。他做的第一件事是，拿一张干净的A4纸铺在桌上，开始逐条例举PASS系统需求中对架构产生最关键影响的“5大因素”。
“我作为架构师应该做什么呢？”小张脑中快速的思考着，“是一层不变的继续‘模块 + 接口’一级的设计，还是先针对主要风险确定架构大局，而后在进一步考虑它呢？”
经过一系列的反思，小张认为对PASS系统直接进行“模块 + 接口“一级直接进行合计存在以下两个严重的问题：
- 针对”单独的可执行单元“形式的系统，或许可以直接按”模块 + 接口“方式展开架构设计，而现在的
PASS系统显然不是。 - 如何通过模块切分和接口定义来支持团队开发，还算不上当前的主要矛盾；上面分析的”5大因素“才是当前的主要矛盾。
主要矛盾决定事态发展。想清楚了架构设计的主要影响因素，小张微微有些高兴。他认真的把他的决定写在笔记本上（还特意加了一句注解说明），生怕忘了似的：
首先根据对架构产生最关键影响的”5大因素“进行概念设计。
注：概念架构不关心明确的接口定义。
此时的小张俨然像是在战场上做出了重大战略决策的将军。
6.2.2. 老王：清晰的概念架构，明确的价值体现
9点整，老王悠悠的走进办公室。他总是如此准时，在这个经常堵车的城市，可算是一个小小的迷了。他做的第一件事是，往茶杯里放入了几十粒上好的枸杞，倒上开水。上午枸杞，下午绿茶，老王习惯了。老王就是有这个本事，根本看不出来昨晚加班是多么的一筹莫展。老王或许不知道，这种弄闲庭信步的气质恰恰是他日后越来越成功的关键。
温伯格讲：“力量是一种关系”。老王很欣赏这句话。音乐有力量吗？不一定！它可以“催”人泪下，但也可以是对“牛”弹琴。你的产品很好吗？不一定！只有满足客户需求的产品才是好的产品，所以做售前的决不能自我感觉良好。胜利远远还没有”在望“，但端着茶杯楞一会儿神儿的老王已成竹在胸。
后天的重点不是在讲纯技术，而是抓住客户关系的价值和担心的问题，并在一个小时之内清晰的勾画出产品的相应策略 。
6.3. 柳暗花明
行必果，小张和老王忙开了。有人说，”行动果断是一种美德。 “，其实，他们都觉得”行动果断“算不上什么美德，毕竟，老板是要看结果的--不行动，就永远没有成功的可能。
6.3.1. 小张：重大需求塑造概念架构
小张将”分析需求特点“所归纳出来”5大因素“作为概念架构设计的目标。
考虑设计目标中的1、2和3这三点，小张得到了概念架构中间结果。
接下来，小张继续深入概念架构的设计。他想：上述设计目标中的第4点和第5点还没有相应的对策，这无疑意味着具体的风险，因为从现在的设计来看根本无法做到“较高的持续可用性”。而对于”降低HIS系统差异带来的影响“也没有任何针对性的设计决定。
经过一番考虑之后（具体思考过程请参考”目标-场景-决策表“方法的讲解），小张做出了下面的概念架构设计决定。为了提高持续可用性，在设计中引入了故障转移集群 。
针对”现行HIS系统差异很大、实现技术不统一“的约束性需求，重点考虑了如何提高重用性以降低开发及维护成本。采用的策略是：引入独立于具体HIS意思工作组的”PASS系统医生模块通用SDK“，它包括了”嵌入到医生工作站的软件模块“的所有特定HIS系统无关部分，使支持HIS的工作量降到最低。
6.3.2. 老王：概念架构体现重大需求
首先，老王通过一些途径了解了客户对网管软件采购的具体要求，例如可升级性、可方便支持新设备等。接下来，老王从公司的服务器上下载了新的网管产品的各种文档，开始快速浏览。他在找售前材料商遗漏的，却至关重要的产品特色。他敏感的发现，有如下几点比较重要：
- 强大的API支持，便于二次开发。
- 基于SPI（服务编程接口）的可扩展设计。
最终，老王利用FAB分析法，轻车熟路的绘制了更能体现新网管产品价值的概念架构。此架构对客户关系的”可升级性、可方便支持新设备“等要求有着较明确的支持。
6.4. 结局与经验
天气，风和日丽。小张和老王的心情都特别好。虽然统计数据显示，这个城市一年有上百天都是蓝天，但他两总觉得今天的天蓝的特别漂亮。
6.4.1. 小张：概念架构时设计大系统的关键
小张负责的PASS产品成功上市了，市场反映很不错。
回顾过往的辛苦，小张觉得很有收获，特别是切实体会到了概念架构设计对大系统成败的关键作用。他的工作笔记，也因此备受珍爱，其中一页写到：
万事开头难。
当要设计的软件系统非常复杂时，直接设计实际架构往往有困难。实际的软件架构设计过程是，一部应先进行概念架构的设计，把嘴关键的设计要素和交互机制确定下来，概念架构是对系统设计的最初构想，但绝不是无关紧要的；相反，它对大型系统的成功非常关键。架构师在设计概念架构时，必须牢牢抓住重大需求、特色需求、高风险需求，有针对性的确定设计策略 。
反过来讲，一个产品与类似产品在架构上的不同，其实在概念架构设计时就大局已定了。
概念架构一级的设计更重视”找对路子 “，它往往是战略而不是战术，它必将策略化而未必全面，它必将强调重点机制而不一定非常完整 。
在概念架构设计中，不关注明确的接口定义；之后才是”模块 + 接口“一级的设计。对大型系统而言，这一点恰恰是必需的。
6.4.2. 老王： 概念架构是售前必修课
老王成功了，最终这家客户采购了老王所在公司的新一代网管软件。回顾这看似平常的一单，老王不无收获：
- 第一，概念架构是售前的必修课 ，所谓金牌销售，必备的能力之一是：是否能清晰的讲解概念架构，并借此说明”客户关系的价值如何实现，担心的问题如何解决“ 。
- 第二，成功的售前必须关注客户 。力量是一种关系，通过FAB分析法找到产品之于客户的价值所在，是售前准备的重点之一 。
- 第三，售前PPT不能千篇一律。作为公司，制作标准的售前PPT是为了避免一般售前人员不得要领，或者讲错理念，真正的专家级售前不应受到”标准售前PPT“的限制 。
下一节：”Use Case驱动“的观点既有积极意义，也有不利影响。从积极的方面看，Use Case这种需求描述方式确实有助于分析模型，设计模型，实现模型和测试模型的建立.....但是从另一方面看，OOSE对Use Case的依赖程度超出了它的实际能力。 -- 邵伟忠， 《面向对象的系统设计》
顶级设计者在设计中并不是按部就班地采用自顶向下（或自底向上）的方法，而是着眼于权重更大的目标。这些目标通常是难点问题，设计者不能轻易地看出这些问题的解决方案。为了得到整个的设计方案，设计者必须先致力于难点的设计并消除其中的疑惑。 -- Robert L. Glass, 《软件工程的事实与谬误》
概念架构是大型系统架构设计成败的关键。