架构师这个名称听起来高大上，其实在一个开发团队中，架构师也的确起到了“定海神针”的作用。为什么这么讲呢？架构师就像建筑设计师一样，从大的方向来给软件定一个基调。软件开发中碰到的很多问题，归咎起来都可能和当初的架构设计有关，所以架构师要想不成为众矢之的，也不是容易的事情。
各个行业甚至同一行业不同主攻方向的team都需要不同的架构师，比如做SOA的很多架构师实际上的职责是向用户推销自己的产品，即使有时采用其他方案更适合企业的情况，出于宣传本公司产品的需要，也要贬低一番。当然利益对架构的影响不可避免，其他行业也存在类似的情况。但是SOA的架构师更多做的是把自己公司的产品套用在客户身上。当架构师是在设计自己公司的产品时，相对来说会客观一些，从功能，性能，稳定性，扩展性，市场接受程度和成本等几方面来权衡。
因为我是在做手机软件方面的工作，对系统架构师的想当然的要求也只能局限在这个领域。由于平台非常庞大，系统架构师的职责显得尤为重要，可能也是因为这个原因，公司里在不同层面上都设立了系统架构师，连某个Component team都有自己的架构师。当然小team的架构师的职责与整个平台的架构师的职责不可同日而语。
如果一个架构师负责的仅仅是一个小的模块，或者是一个小的应用程序，那么他所能施展的空间不太多，包括操作系统，硬件，驱动，其他模块的接口等都是已经确定的了，甚至自己的模块需要哪些接口暴露给别人也都是定义好的了，那么这个架构师该做些什么呢？从别的程序或者系统来看，这个应用程序至少要具备以下几个条件才能算是合格的：
1、完成此应用程序的基本功能，如果这是一个通信程序客户端，那么它至少应该完成客户端所具有的功能，通过所有的测试用例。不同的功能是需要不同的组成架构的，从降低复杂度和提高可维护性的角度来考虑对系统进行解构，往往是最直观的做法。
2、健壮性，这个程序不应该轻易的crash，如果是界面程序，在面对异常情况的时候采取柔和的方式来通知用户。如果是被别的程序所使用的库，保持健壮性更是非常重要。作为架构师，应该采取一定的措施来保证模块的正确工作，至少应该保证在出错的情况下能够比较容易的区分是否是本模块造成的。也许有人说这是design和program的事情，但是架构师如果不在纲领上制定策略和要求，实现上也是很难操作的。
3、低的资源消耗。我碰到很多软件架构，在架构文档里看时非常华丽，用了很多模式，一个普通的应用要拆分成多个进程，再用MVC分离各个模块，加上一大堆监听器适配器过滤器等，可以说模式是能带来一些好处的，但是往往代价是更多的资源消耗，内存占的多了，性能下降了，逻辑变得更复杂了。作为架构师一定要权衡，而不是为了表达自己的知识能力。最好的情况是，能够给出在各种usecase下模块或应用对资源的消耗程度，比如会占用多少内存，某个接口需要多长时间等。因为现在的接口定义一般都只是定义使用方式，包括函数名和参数列表，至于使用时的代价由于没有说明，往往成为模块使用者和提供者之间争论的焦点。
从程序员的角度来讲，可维护性往往更为重要，因为维护的阶段比开发的阶段更长，面对的压力也更大，而且由于各种各样的原因，经常要一个新手来维护这个程序，如何让新手很容易的理解它并且马上具备解决问题的能力，对架构师来说也不是一件可以推卸的责任，采用常见的设计模式，制定或采用通用的代码风格，完善相关的文档等等，都是好的practice。
对于那些高层次的架构师来说，因为面对的是由很多模块应用组成的系统，他所要处理的实际上如何协调各模块关系，保证整个系统的功能性能和稳定性，至少他应该了解各个应用所具备的功能，基于此来制定各个模块之间的接口。在必要的时候，要去掉那些作用不大但影响整个系统性能和稳定性的模块，对各个模块的可选功能也要做一定的限制，不能允许其无限制的膨胀。架构师也往往面临着选择既有实现的困境，采用第三方或者开源实现时，一定要和已有的实现进行全方位的比较，在很难做出决定时宁可保持不变，或者采用小的实验步骤来获取真实的数据。
