架构师的能力既要有广度也要有深度,技术方面: 软件开发生命周期,从需求,设计到实现和测试都有一定的了解. 过程,重量级(RUP/CMM)和轻量级(XP/Scrum) 框架,JEE/.Net 工具,用来建模,设计,沟通...(UML, ER) 操作系统,Windows系列及Linux/Unix系列 服务器,App Server, Web Server. IBM WebSphere, Oracle WebLogic, JBoss, Tomcat, Apache... 硬件知识,各大厂商提供的机器型号及配置,在不同应用环境下的性能. 网络知识,网卡,路由,网络布局. 非技术方面: 平衡和决策能力; 培训和讲解能力; 划分层次; 制定规则和标准; 沟通能力; 领导能力/问题解决型领导; 在截然不同的抽象层次上概念化解决方案;(这一点尤其关键) 看到了吧,架构师不是个容易活,而且多数公司都不需要这么强的人.在多数情况下,每个公司在自己特定的业务领域已经有比较可靠的架构原型,项目对架构的要求并没有那么高,或者范围相对小一些.不过,这并不妨碍我以此为目标.以前我的目标没有这么明确,还好一直在朝这个方向走.看来我的运气不错. 系统架构的概念可大可小,基本的层次如下(取自知识大金矿--MSDN): 领域--公司做为一个黑盒,以业务的外部用户的视角为业务建模,为与业务外部用户的交互建模 业务处理--系统为黑盒, 为以实现领域级业务交互为目的的业务过程建模,以系统的外部用户的视角为业务过程建模 逻辑--系统设计,系统用户的视角为业务建模 物理--为实现的物理结构建模,协议,页面,数据表等 如果企业的业务相对复杂,可以在此基础上进行扩展.通俗一点讲,就是首先关注企业的客户如何看待企业提供的服务的,然后理清企业内部的业务流程,明确企业对系统的期望,再就是从系统的各个参与者出发明确系统功能.再就是具体的物理架构.看起来非常像需求建模,实际上也确实是需求决定了系统架构.所以,架构包含了两方面的内容,架构的定义和架构的物理实现.