架构决定成败
软件架构是软件产品、软件系统设计当中的主体结构和主要矛盾。任何软件都有架构，哪怕一段短小的HelloWorld程序。软件架构设计的成败决定了软件产品和系统研发的成败。软件架构自身所具有的属性和特点，决定了软件架构设计的复杂性和难度。
这几年流行一个说法（管理谚语）：“细节决定成败”,这句话其实只说对了一半。细节确实很重要，很多项目、产品就输在细节的执行上。一方面，战术细节固然很重要，但另一方面，战略全局也同样重要，对应的我们可以说：“战略决定成败”.战略性失败，就好比下一盘围棋，局部下得再漂亮、再凌厉，如果罔顾大盘，己方连空都不够了，还有官子（细节）获胜的机会吗？必然是中盘告负。
类似地，正确的软件架构设计，应该既包括战略全局上的设计，也包括战术细节（关键路径）上的设计。有一种错误的观点认为，软件架构设计只要分分层和包，画一个大体的轮廓草图，就完事了。这种“纸上谈兵”型的架构师行为是非常有害的。事实上，既然软件架构是软件建筑的主体结构、隐蔽工程、承重墙和要害部位，那么软件架构也必然要落实到实际的算法和代码，不但要有实现代码，还要包括对这部分架构进行测试的代码，以保证获得高质量的、满足各种功能和非功能质量属性要求的架构。除了完成概念、模型设计外，软件架构师一定要参与实际的编码、测试和调试，做一位真正的hands-on practitioner,这已经成为了敏捷软件工程所倡导的主流文化。
两个架构
我们在日常的软件产品和系统开发中，实际上会遇到两种、两个部分的软件架构，即待开发的应用部分的软件架构（简称“应用架构”），以及既有的基础平台部分的软件架构（简称“基础架构”）。这两部分架构之间是互为依赖、相辅相成的关系，它们共同组成了整个软件产品和系统的架构。
基础架构的例子包括：.NET和J2EE等主流的基础平台和各种公共应用框架，由基础库API、对象模型、事件模型、各种开发和应用的扩展规则等内容组成。我们只有熟悉基础架构的构造细节、应用机理，才能有效地开发出高质量、高性能的上层应用。然而，开发一个面向最终用户的软件应用系统和产品，仅仅掌握一般的计算机高级编程语言知识和基础平台架构、API的使用知识显然是不够的，我们还需要根据客户应用的类型和特点，在基础架构之上，设计出符合用户要求的高质量应用软件。
熟悉OOA、OOD抽象建模技术、设计原则以及架构模式和设计模式等等方法技术，不但有助于我们更好地理解和利用基础平台架构，也有助于我们设计开发出更高质量的应用软件架构。
