架构设计系列文章，请参见连接。
背景
从事软件行业多年后总有一些疑问：软件架构是什么？业务模型是什么？业务蓝图怎么做？等等问题萦绕在心头。这些问题很多都是因为业界没有标准、没有标准实施方法，这样就会就需要有人去了解、理解、分析、权衡。
人的认知过程可以简单的说成：对于同一件事物不同的人的理解也是不同的，一个人在不同的时间对同一件事也有着不同的理解。所以在软件架构实施过程中不同的人有不同的方法去实施、不同的实施侧重非常常见，故对于架构的实施效果就不能很好的把控。
对于软件来说架构的实施效果是软件架构的最终价值。前人也对软件架构的价值思考与总结，这些总结对于真正的实施软件架构建设的人员来说总有那么一些借鉴意义。故在此对这些内容进行汇总。
架构的历史
在1968年时，软件架构还不叫软件架构那会叫：软件体系结构。
The Structure of the 'THE' Multiprogramming System
戴克斯加（Edsger Dijkstra）在THE操作系统设计时，定义了这个操作系统的结构。这个结构最初的就是软件体系结构。软件体系结构在1975年，软件体系结构思想被升华：
Architecture is the complete and detailed specification of the user interface
那时的布鲁克斯（Frederick Brooks）认为架构就是对用户接口的完整详细的规范。这个是对软件的对外属性的描述工作。从一个侧面定义软件架构。而另外一个高人帕纳斯在20世纪80年代左右对软件架构有一系列的认知提升：
information hiding and usage of interface（Parnas，1972)
structure separation (Parnas, 1974）
the relationships between software structure and its quality （Parnas，1976）
而在1991年由罗伊斯（Walker E. Royce）和 罗伊斯（Winston W. Royce）在正式文献中使用Software Architecture：
Software Architecture: Integrating Process and Technology authored
又过了两年，在1993年时Software Architecture被定义，此定义成为软件体系结构研究的公认基础，由加兰（David Garlan）和肖（Mary Shaw）对其进行了总结：
在这篇文章中还说明了软件架构模式。到此之后软件架构就被正式定义了。学术界的发展变成。而在此之后还是有很多实践中对软件架构有不断深入的理解。
大名鼎鼎的马丁·福勒（Martin Fowler）在《企业应用架构模式》中就说
很多人都试图给“架构”下定义，而这些定义本身却很难统一。
可以看到在实践中对架构进行单一的定义是不能满足实践指导意义的。而雅各布森（Ivar Jacobson）在《AOSD中文版-基于用例的面向方面软件开发》也有类似的阐述：
什么是架构？如果你问五个不同的人，可能会得到五种不同的答案。
鲍勃大叔（Robert C. Martin）在《架构简洁之道》也对很多人的错误理解做出了很好的解释。
架构并不是框架（也不应该是）。架构不应该由框架提供。框架是要使用的工具，而架构并不是。
上文中也说道：架构的实施效果是软件架构的最终价值。从这个角度看软件架构定义、解释、诠释都不能很好的为软件架构做实际的指导意义。
架构定义分类
在看《系统之美》时，作者在书中说到系统思维就是为大家提供一种认识世界的思维模式。那我们了解软件架构各种侧面的定义，让我们更加全面的理解软件架构。
组合派：软件架构=抽象+元素+交互
- 1997年，Bass，Ctements和Kazman在《使用软件体系结构》一书中给出如下的定义：一个程序或计算机系统的软件体系结构包括一个或一组软件构件、软件构件的外部的可见特性及其相互关系。
- IEEE610.12-1990，IEEE 1471-2000，ISO/IEC/IEEE 42010-2011
决策派：软件架构=重要决策的集合
- RUP定义的核心思想是：软件架构是在一些重要方面作出的决策的合集。
- woods观点：软件架构是一系列设计决策，如果做了不正确的决策，你的项目可 能最终会被取消
高层设计派：软件架构=受环境影响的高层设计
- Mary Shaw和David Garlan认为软件体系结构是软件设计过程中的一个层次，这一层次超越计算过程中的算法设计和数据结构设计。
- 软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式及这些模式的约束组成。
模型派：软件架构=不同模型的组合方式
这一派最主要的是关注模型间的关系。
思考
对于有一定经验的架构师来说，对软件架构的意义也有着不同的思考。从不同的角度思考的话会得出不同的结论。业界两位大神对软件架构的思考如下：
架构的目的是为了业务增长。
《聊聊架构》--王概凯架构的本质是管理复杂性。
《优秀架构师必须掌握的架构思维》--杨波
这基本上代表了两个方向的思考，一个是对企业来说软件架构能完成什么，另一个是对于软件架构应该怎样进行内部管理与实施。可以再看一下王概凯在《聊聊架构》中关于软件的另一段描述：
业务是核心，技术是解决业务问题的工具，而架构是让业务长大的组织方法。架构需要用技术来实现拆分，而技术需要架构来合理组织，以提升效率。
《聊聊架构》--王概凯
从作者的角度来看，要理解架构是什么架构可以从从业务价值和技术价值角度来去思考。但要做到最起码的一点：
跳出代码看代码才能真正的理解架构。
只有做到这一点才能真正的理解架构到底是什么，要做什么。
总结
架构是什么？我相信每个人都有自己的理解。使用更加通用的思维模式思考，就可以得到一个结论：软件架构就是为了使系统有序。
