软件架构师类似于建筑的工程师，都是站在总体的角度考虑问题，楼房是建筑师的产品，建筑师在设计楼房的时候要考虑楼房的高度，地基的大小，建造的材料，楼房的用途等因素；同样的，软件架构师也要考虑各个方面的因素，例如：运行环境，软件功能，核心技术，适用人群等。

我们在课堂上观看了《梦想改造家》这个节目，这期节目主要讲述了王平仲设计师怎样设计并改造了一个上海的小房间。他的有些想法让人眼前一亮，他的改造使一个房子重新焕发生机，在解决用户问题的同时也想到了一些潜在的问题并进行预防，而且充分考虑到了用户的经济水平，节约了成本。我们应该从他身上学到这种统筹规划的能力，考虑到软件的各个方面，这样做出来的软件才有市场，才会受到用户的欢迎。

首先，软件架构是用来沟通的，软件架构必须满足软件项目所有步众代表都有自己立场与视角的模型、文档说明，且这些模型文档说明仅清晰包含自己立场与视角关注与有关的事物，不能有任何遗漏，也最好不要有多余。

其次，软件架构的每一步都是决策过程，而且关键需求决定架构，软件架构必须充分清楚地表达出这些决策与决策理由。众多的需求中为什么这些需求是关键需求？为满足这些关键需求，采用了什么样的关键机制、核心技术与第三方框架？什么选择这些关键机制、核心技术与第三方框架而不选用其它的？为什么说它们是可行的？

再则，软件架构必须为以后的开发提供足够的指导与限制，因此软件架构必须确定系统各元素间的关系、职责、交互接口与协作机制。仅仅划出几个层与层中包含的元素而不约束它们间的关系、职责、交互接口与协作机制，就如同一个公司，它的组织结构图就挂在墙上——再清晰不过了，但如果接口不清、机制不明，来了任务、出了事情不清楚找谁、如何汇报、怎样处理。

然后，软件架构必须突出强调通信机制、持久化机制和消息机制等公用模块的深入设计。通信机制、持久化机制和消息机制等公用模块较多的涉及软件的不同部分之间的交互，对系统的功能实现、非功能满足等成功因素起着举足轻重的作用。

最后，由于软件项目的不同、开发组织结构的不同、开发团队情况的不同，软件架构的设计粒度是不一定的。比如，航天航空领域中的软件系统对系统的可靠性等质量属性要求非常高甚至可以认为是荷刻，这种情况下对架构的设计详细程度的要求也会比较高；象IBM这样的大的团队中又有小的团队共同开发，架构的设计粒度到子系统级就足够了，各个小团队精通的技术各不相同，可以让其对子系统采用敏捷开发，对缩短工期、人尽其材有好处；有类似项目经验或项目团队所有成员整体技术水平较高的团队架构粒度可适当粗犷，而分布团队或涉及外包的情况则更强调架构的明确性。总之，架构设计对软件的不同部分的设计程度不应是整齐划一的，特别是具体的业务功能模块在架构设计中往往设计程度不深。