Conceptual Architecture，直接翻译为【概念架构】，这是本书的第三个部分，上个阶段按为pre-Architecture阶段【前架构】，我自己对这阶段的理解就是，一栋建筑物的形成过程，在正式架构之前，要了解这栋建筑的用途，居民楼？学生公寓？购物广场？政府大楼……，将情况了解清楚之后，进行概念架构，也就是要求不是特别多的一种大体概括，画出建筑物的草图。将建筑替换成我们的软件，就是首先了解这个软件，这个系统各方各面的需求，然后进行系统的概念设计，具有哪些功能等等，对软件整体有一个理解。
首先本部分开头的两句名言，就引发了我很深的思考，“胜兵先胜而后求战，败兵先战而后求胜。”和“人们常常使用战术，而忽略了战略，战略要求从大局上把握整个架构与设计……架构错误的代价非常高。”。这两句话其实都之处了制定战略，大局看事情的重要性，也就是本阶段【概念架构】中指出的十分重要的一点，在稍稍后面一点，第一个关于小张的故事中，这一点大局观念就体现的十分明显，起初，小张将架构简单理解为一个公式“架构=模块+接口”，显然，这个片面的观点让他吃了大亏，在他后续的搜索过程中，一篇博客上写的“概念性架构就是对系统设计的最初构想，就是把最关键的设计要素和交互的机制确定下来,然后考虑具体技术的运用，设计出实际架构。概念性架构应该抓大局、不拘小节。虽然概念性架构都跳不出“架构=组件+交互”的基本定义，但它们描述架构的具体方式还是有比较大的差异:有的重视逻辑层，有的重视物理层，有的通过隐喻表明机制，有的看上去似乎就是一些设计元素的组合。不同的概念性架构图中，“连接”代表的含义千差万别:有的是依赖方向，有的是控制方向，有的是数据流向，因此，必须根据具体情况而定。”给了他大局观的意识，之后他站在一个比较高的层次看待整个系统，很好的解决了困扰他的问题。
概念架构是大型系统架构设计成败的关键，概念性架构界定系统的高层组件，以及它们之间的关系。概念性架构意在对系统进行适当分解，而不陷入细节。借此，可以与管理人员、市场人员、用户等非技术人员交流架构。概念性架构规定了每个组件的非正式规约及架构图，但不涉及接口细节。根据定义，我们注意到如下几点:
■概念架构满足“架构=组件+. 交互"的基本定义，只不过概念架构仅关注高层组件(high-level components) .
■概念架构对高层组件的“职责”进行了笼统的界定(informal specification) ,并给出了高层组件之间的相互关系(Architecture Diagram)。
■概念架构不应涉 及接口细节( without interface detail)。
概念架构分为以下三个阶段：1.初步设计。基于关键功能，借助鲁棒图进行以发现职责为目的的初步设计。这一步并不;总是需要，但对于架构师而言，是“新系统”就必须重视这-一步。2.高层分割。 对系统这个黑盒子进行高层切分，例如切分复杂系统为多个二级系统，或者直接切分系统为具体子系统。3.考虑非功能需求。概念架构≠理想化架构，所以不仅要考虑功能，也必须考虑非功能。具体方法是采用ADMEMS推荐目标-场最-决策表。
在这个阶段，还要注意的是对系统进行分割，将系统切分为若干子系统，如下图所示：