无数的著作中都论及了软件架构和建筑的关系。架构就如同一张蓝图，没有图纸很难建造房屋。如下图所示，一个令人神往的海边建筑涉及的方面非常多，具体实施过程包括各种测量和计算，没有一个架构设计的过程是不可能建造成功的。
架构是一种思维模式，可以理解为系统化地看待周遭事物并提出解决方案。从这个角度讲，小到一段代码，中到一个模块，大到一系列产品集，都有其架构层次。我们常常听到的抽象、扩展、复用、分层都是常见的架构设计手段。一位程序员经常做架构思维的训练和实践，然后成长为一位系统或者平台架构师，这是一种自然演化的成长路径。所以说，架构思维非架构师独有，架构师并非天降神人，而是通过实践、学习成长而来的。
架构兼具组成和决策的特点
Mary Shaw在《软件体系结构：一门初露端倪学科的展望》一书中论及软件系统的架构时，将系统描述为组件及组件之间的交互。软件架构包含了关于以下问题的重要决策：
如何对软件系统进行组织。
如何选择组成系统的结构元素和它们之间的接口，以及如何设计当这些元素相互协作时所体现的行为。
如何组合这些元素，使它们逐渐合成更大的子系统。
如何让用户知道这个系统组织的架构风格：这些元素及它们的接口、协作和组合。
软件架构并不仅仅注重软件本身的结构和行为，还注重其他特性：使用、功能性、性能、弹性、重用、可理解性、经济和技术的限制与权衡，以及美学。
架构是演进来的
架构是演进来的，是动态的。业界关于架构是预先设计出来的还是演进出来的颇有些争论，但笔者认为：
软件架构需要事先设计，而演进式架构号称是采用TDD、重构、持续集成等手段保障其演进的。但敏捷实践里面的TDD是从微观视角来看的，重构也可以以微观视角进行。宏观视角需要对整体架构进行设计，让参与者具有共同的愿景，并做出共同的决策。比如，技术框架如何选型、怎样评估用户并发、用户是谁，以及如何提供服务等。
不做BDUF，暂缓做不确定的事，不做大投入的方案。任何一个选择都需要考虑投资回报率（ROI）。
架构处于一个动态的过程中，是不断演进的。除了微观的重构及敏捷实践会演进，领域模型和架构方案亦可持续演进。
偿还技术债务、重构和不断抽象、分解问题域是演进的一些手段，保持架构演进要特别持续关注质量并保障其没有下降。
架构中无纯粹的非功能特性
什么叫非功能特性？有人也称之为质量特性。笔者觉得一切都是质量，所以在商业需求呈现过程中一定要区分下面两条需求的意义其实不大。
登录3次，锁定账号20分钟。
系统需要支持2000个用户同时并发。
另外一个区分功能特性与非功能特性的危害是容易把非功能特性当作增强性要素。增强性要素就是重要但紧急程度不高，可以让用户先用起来的要素。
笔者的观点很明确，应该把所有需求放到一起排序，而基于安全性、高可用性这些面向切面的分类，只是为了更好地管理架构的各个组成部分而已。同时，在团队分工上也可以做到术业有专攻。以下图为例，可以看到每个约束要求都对应具体可操作、可验证的功能，比如数据安全性、通信安全性。
软件架构工作看似简单，其实不然。系统化思考有助于理清软件架构流程及从客户价值出发，识别用户、设定SLA可以帮助软件架构设计人员和研发人员避免在技术纷繁复杂的跋涉中迷失而陷入“自嗨”。架构是演进而来的，架构包含了一系列的决策和若干组成，进行架构设计时应该从全局视角看问题。
