Conceptual Architecture阶段通过小张还有老王加班的故事向我们介绍了概念架构的内容。小张对架构的理解可以概括为一个公式:架构=模块+接口。但是在小张的实际工作中却发现有点乱，“可执行单元”都没搞清楚，就考虑“模块+接口”一级的设计，的确有些武断了。
通过对一篇文章的了解，概念性架构就是对系统设计的最初构想，就是把最关键的设计要素和交互的机制确定下来，然后考虑具体技术的运用，设计出实际架构。概念性架构应该抓大局、不拘小节。小张归纳出五大元素1.系统涉及不同使用者。2.分工式的特点明显。3.集成的特点明显。4.较高的持续可用性要求。5.降低HIS系统差异带来的影响。
老王的问题在于当前的架构描述根本没有体现产品特点，无法说服客户，只有满足客户需求的产品才是好的产品，因此，抓住客户关心的价值和担心的问题成立老王重点关注的内容。
最终，小张和老王都如愿以偿，完成了自己的任务。总结一下，在概念架构设计中，不关注明确的接口定义;之后才是“模块+接口”一级的设计。对大型系统而言，这一点恰恰是必需的。概念架构是售前的必修课。所谓金牌售前，必备的能力之一是:能否清晰地讲解概念架构，并借此说明“客户关心的价值如何实现，担心的问题如何解决”。
概念架构满足“架构=组件+交互”的基本定义，只不过概念架构仅关注高层组件，概念架构对高层组件的“职责”进行了笼统的界定，概念架构不应涉及接口细节。
大而言之，概念架构设计分为3个步骤：
1. 初步设计。基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计。这-一步并不总是需要，但对于架构师而言，是“新系统"就必须重视这一-步。
2.高层分割。对系统这个黑盒子进行高层切分，例如切分复杂系统为多个二级系统，或者直接切分系统为具体子系统。
3.考虑非功能需求。概念架构≠理想化架构，所以不仅要考虑功能，也必须考虑非功能。具体方法是采用ADMEMS推荐目标-场景决策表。
“高层分割”的两种实践套路切系统为系统，切系统为子系统。
非功能需求往往非常笼统，而场景是一种明确性很强的技术。目标-场景-决策表可以让架构师理性地应对非功能需求。