架构师要回的东东

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