高性能
　　在进行性能设计时，首先要与客户充分地沟通，了解客户的性能需求，不管它是清晰的还是暗含的。不要等到项目后期才发现其实数据量是60万而不是10万。所以预先了解项目的性能指标，获取与性能相关的数据，从而预先评估架构的性能指标非常重要。
　　其他具体的性能设计方法可以参考我另外一篇文章：《架构设计之性能设计经验》
　　可用性，用户友好性
　　设计以人为本，到头来还是给人用的。产品经理、客户和终用户很注重界面，他们不知道你的系统有多么先进，只看界面是不是美观，界面友好，标准，操作流畅，有良好的用户体验(User experience)。界面做好了，客户满意，你成功了一半；否则内部系统再先进，客户都会认为这个系统非常糟糕，用户体验非常不好。因此，可用性设计在这个Web2.0的时代尤其重要。
　　针对可用性的设计应该由架构师、用户体验设计师共同完成。可用性设计不等于界面设计。界面设计是静态的，而可用性设计是以用户为中心的交互设计(Interaction Design)，更关注用户的行为和体验。交互设计需要研究角色模型，用户行为和上下文，数据整合和呈现方式等(Persona，goal，scenario)。一个成功的可用性设计/用户体验设计需要一个或多个跨学科的设计师，倾听和收集用户对系统使用的需求、体验或不满，并进行艺术化的设计。
　　例如一个失败的网站，内容繁杂，让客户无所适从；搜索了一个内容，出来一堆东西，用户想在这里面进一步搜索，却找不到这个功能。而良好的网站设计，用户操作非常流畅，流程很容易让用户理解。简洁明了，没有乱七八糟的东西干扰用户。因为后者仔细研究过用户交互模型，知道大多数用户的操作习惯和困难，而网站内容是根据清晰的流程设计的。数据的呈现方式也是经过整合的，不是所有数据都呈现给用户，而是呈现对用户有用的数据。
　　可维护性，可管理性
　　可维护性包括代码的可理解性，可测试性，可修改性和系统的可移植性。如果一个系统的可维护性从初没有得到很好的重视，当系统面临重大的设计改动时，会发现几乎无法入手，简单的方法是彻底推翻重写，于是造成大量的资源浪费。
　　具体来说，软件系统可维护性差的原因有：
　　1.过于僵硬: 加入一个新性能，不仅仅意味着建造一个独立的模块，而且因为这个新性能会波及很多其他的模块，好变成跨越几个模块的改动。
　　2.过于脆弱: 对一个地方的修改，往往会导致看上去没什么关系的另外一个地方发生故障。尽管在修改之前，设计师会尽力预测可能的故障点，当是修改完成之前，系统的原始设计师们甚至都无法预测到可能会波及的地方。
　　3.复用率低: 每当程序员发现一段代码、函数、模块所做的事情是可以在新的模块、或者新系统中使用的是，他们总是发现，这些已有的代码依赖于一堆其他的东西，以至于很难将它们分开。好他们发现好的办法是不去“碰”这些已有的东西，而是重新写自己的代码。他们可能会使用源代码拷贝的办法，以原始的复用方式，节省一些时间。
　　4.黏度过高: 有的时候，一个改动可以以保存原始设计意图和原始设计框架的方式进行，也可以以破坏原始意图和框架的方式进行。一个系统设计，如果总是使得第二种办法比第一种办法容易，叫黏度过高。
　　5.系统过于复杂：系统过于复杂和庞大，结构不尽合理，设计文档缺乏或没有更新，系统年龄大时间久远。
　　可维护性设计应该采用灵活架构，采用复用的设计方法，尽量减少相互之间的依赖项，尽量采用成熟的工业应用级的产品和框架，采用代码审查机制等。传统软件工程用可理解性、可测试性和可修改性来衡量软件的可维护性，CASE软件工程则以考察可重用性来衡量可维护性。可维护性直接的体现是良好的软件结构和完整正确的文档体系。维护应在文档级以上展开，应从软件结构出发，即以重构为核心。可重用性是可维护性的基本属性，大限度地重用现存软件是软件维护方法学的重要思想原则。
　　运行可管理性，包括运维对系统软硬件各个部分的监控，以便于控制系统运行、监视系统状态、错误处理。为了实现上述目标，系统应该尽量采用参数化的可配置的设计，模块间通信应当尽可能简单，同时建立合理详尽的系统运行日志，系统通过自动审计运行日志和动态跟踪（dynamic tracing facility），了解系统运行状态、监控资源的使用和配置、进行有效的错误处理。