只有这样，才能适应用户的市场扩展得可能性 。·可定制化（CuSTomizable） 。
同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整 。·可扩展性（Extensible） 。
在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展 ·可维护性（MAIntainable） 。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去 。
一个易于维护的系统可以有效地降低技术支持的花费 ·客户体验（Customer Experience） 。软件系统必须易于使用 。
·市场时机（Time to Market） 。软件用户要面临同业竞争，软件提供商也要面临同业竞争 。
以最快的速度争夺市场先机非常重要 。架构的种类 根据我们关注的角度不同，可以将架构分成三种： ·逻辑架构、软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等 。
比如下面就是笔者亲身经历过的一个软件系统的逻辑架构图 图2、一个逻辑架构的例子 从上面这张图中可以看出，此系统被划分成三个逻辑层次，即表象层次，商业层次和数据持久层次 。每一个层次都含有多个逻辑元件 。
比如WEB服务器层次中有HTML服务元件、Session服务元件、安全服务元件、系统管理元件等 。·物理架构、软件元件是怎样放到硬件上的 。
比如下面这张物理架构图描述了一个分布于北京和上海的分布式系统的物理架构，图中所有的元件都是物理设备，包括网络分流器、代理服务器、WEB服务器、应用服务器、报表服务器、整合服务器、存储服务器、主机等等 。图3、一个物理架构的例子 ·系统架构、系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、性能等 。
系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，这一工作无疑是架构设计工作中最为困难的工作 。此外，从每一个角度上看，都可以看到架构的两要素：元件划分和设计决定 。
首先，一个软件系统中的元件首先是逻辑元件 。这些逻辑元件如何放到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等做出贡献，是非常重要的信息 。
其次，进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它们如何影响到系统的所有非功能性特征 。这些决定中会有很多是一旦作出，就很难更改的 。
根据作者的经验，一个基于数据库的系统架构，有多少个数据表，就会有多少页的架构设计文档 。比如一个中等的数据库应用系统通常含有一百个左右的数据表，这样的一个系统设计通常需要有一百页左右的架构设计文档 。
构架描述 为了讨论和分析软件构架，必须首先定义构架表示方式，即描述构架重要方面的方式 。在 Rational Unified Process 中，软件构架文档记录有这种描述 。
构架视图 我们决定以多种构架视图来表示软件构架 。每种构架视图针对于开发流程中的涉众（例如最终用户、设计人员、管理人员、系统工程师 。
3. 什么是软件架构 当你去了解一个东东的时候，第一步要做的，就应该去知道这个东东的定义，对于软件架构也是如此，经过网上查询和书籍的帮助，我大概理清了一个轮廓 。
软件行业是一个热衷于制造‘名词’的行业，如果退回15年，估计没几个人知道‘软件架构’是什么，在上个世纪80年代，随着软件开发的规模不断扩大，软件开发成为一个行业，初期，随之而来的是越来越多的软件项目的失败，造成项目失败的原因很多，但主要集中在开发过程，所以软件工程应运而生，CMMI等流程标准也是一茬接着一茬的冒个不停 。