公司在谈一个项目，但还没有得到客户的认可。后来，除了老李这个项目经理之外，小张作为架构师、小王作为需求分析师也都参与了进来。他们几个在和客户沟通的基础上，通力合作，最后成功提交了《方案书》，并获得客户的认可。《方案书》是老李、小张、小王各负责一部分来写的，其中架构师小张负责总体设计部分。

小张认为：《方案书》被认可说明架构已经很明确，无须“再”架构设计了。

最后，苦了程序员，因为他们在实际开发过程中没有得到足够的指导和限制。

究其原因，这是因为概念架构难以支持并行开发。要支持开发组相对独立进行工作，需要提供指导和限制作用更明确的“规约”一级的设计。

具体而言，细化架构和概念架构之间存在如下典型差异：

当然，概念架构和细化架构都满足软件架构的定义--无论是“架构 = 组件 + 交互”，还是“架构 = 重要决策”。

方案的设定，为什么需要项目负责人、需求人员、架构师等功能参与呢？因为方案涉及的工作内容不仅仅是架构，还涉及项目管理和需求工作。“方案”和“架构”的联系与区别如下：

所以，架构师应记住：

办公室里，关于什么是软件架构，争论正酣。程序员说，软件架构就要决定要编写哪些类，使用哪些现成框架(Framework)。程序经理说，软件架构就是模块的划分和接口的定义。系统分析员说，软件架构就是为业务领域对象的关键建模。配置管理员说，软件架构就是开发出来的及编译后的软件到底是啥结构。数据库工程师说，软件架构规定了持久化数据的结构，其他一切不过是对数据的操作而已。部署工程师说，软件架构规定了软件部署到硬件的策略。用户说，软件架构就是决定一个个功能子系统如何划分。大家想了想说，这些架构视图好像我们都需要啊，软件架构师哭了。

上述争论可以总结为一句话：不同涉众看待软件架构的视角是不同的 。但是，实际工作中架构师的工作范围如此广泛，多视图方法能系统的涵盖吗？例如：

答案是：贴近实践的多视图方法，应将各项工作涵盖其中 。

总结一下。首先，架构设计仅进行到概念架构层面，对团队的并行开发而言是远远不够的；常见的错误就是把《方案书》中的概念架构设计部分直接作为《架构设计文档》提交。另外，业界早已存在一些有影响力的多视图方法（例如RUP4+1视图方法），但是作为一线架构师，要有意识的调整、扩充、改进经典方法以符合实践的真正需要。