（转载非原创）IT架构师基本技能

架构师（Architecture）是目前很多软件企业最急需的人才，也是一个软件企业中薪水最高的技术人才。换句话说，架构师是企业的人力资本，与人力资源相比其能够通过架构、创新使企业获得新的产品、新的市场和新的技术体系。那么什么是架构师、架构师的作用、如何定位一个架构师和如何成为一个架构师呢？这是许多企业、许多程序员朋友希望知道的或希望参与讨论的话题内容。
所谓架构师通俗的说就是设计师、画图员、结构设计者，这些定义范畴主要用在建筑学上很容易理解。小时候到河中玩耍，经常干的事就是造桥，步骤如下：1、在沙滩上画图；2、选择形状好看、大小适合的石头；3、搭建拱桥。其中我们挑出来画图的那位光PP小孩就是传说中的“架构师”了。 在软件工程中，架构师的作用在于三方面：1、行业应用架构，行业架构师往往是行业专家，了解行业应用需求，其架构行为主要是将需求进行合理分析布局到应用模型中去，偏向于应用功能布局；2、应用系统技术体系架构，技术架构师往往是技术高手中的高手，掌握各类技术体系结构、掌握应用设计模式，其架构行为考虑软件系统的高效性、复用性、安全性、可维护性、灵活性、跨平台性等；3、规范架构师是通过多年磨砺或常年苦思顿悟后把某一类架构抽象成一套架构规范，当然也有专门研究规范而培养的规范架构师。他们的产物往往也分为应用规范和技术规范两类。

与建筑学类似，如果软件系统没有一个好的架构是不可能成为成功的软件系统的。没有图纸的建筑工地、没有设计的造桥工程都是不可以想象的混乱世界。建筑工程如是，软件工程中亦然！

由于国内合格、胜任的软件架构师极为少见，直接导致了我国民族软件产业水平的落后。在未来以信息产业为主导的社会，信息产业水平的低下将直接影响国家核心竞争力。究其原因，无企业非急功近利、个人缺乏引导。

企业的急功近利是有无法克服的原因的，那就是社会发展总体水平。“生存是第一位的，赚钱是第一位的”，多年来许多客户抱怨国内的软件公司无法信任、系统项目累做累败、公司越换越差，但因国外不可能给中国做应用系统项目还不得不找国内软件公司做。由于人月费用低、公司开发成本高，软件企业对于应用只能草草了事，拿钱走人（很多公司拿不到后期尾款）。这样的环境下，企业几乎无法投入更多资源培养自己的架构师，加上眼花缭乱的跳槽风气企业更是不愿投入…… 字串3

那么要成为架构师的途径似乎只有现在较为流行的软件学院和个人自我培养了。关于软件学院我接触过不少，其宗旨绝大部分都是造就（or打造）企业需要的软件架构师（or程序员or人才）。教师来源与企业、学员来源与企业、人才输送到企业是他们办学的手段。尽管各个如雨后春笋般出现的软件学院口号差不多，但恐怕大多只是为了圈钱卖学位了事... 字串4

架构师不是通过理论学习可以搞出来的，不过不学习相关知识那肯定是不行的。参考软件企业架构师需求、结合目前架构师所需知识，总结架构师自我培养过程大致如下仅供参考：

1、架构师胚胎（程序员）学习的知识是语言基础、设计基础、通信基础等，应该在大学完成，内容包括java、c、c++、uml、RUP、XML、socket通信（通信协议）――学习搭建应用系统所必须的原材料。
2、架构师萌芽（高级程序员）学习分布式系统、组建等内容，可以在大学或第一年工作时间接触，包括分布式系统原理、ejb、corba、com/com+、webservice（研究生可以研究网络计算机、高性能并发处理等内容）
3、架构师幼苗（设计师）应该在掌握上述基础之上，结合实际项目经验，透彻领会应用设计模式，内容包括设计模式（c++版本、java版本）、ejb设计模式、J2EE架构、UDDI、软件设计模式等。在此期间，最好能够了解软件工程在实际项目中的应用以及小组开发、团队管理。
4、软件架构师的正式成型在于机遇、个人努力和天赋，软件架构师其实是一种职位，但一个程序员在充分掌握软架构师所需的基本技能后，如何得到这样的机会、如何利用所掌握的技能进行应用的合理架构、如何不断的抽象和归纳自己的架构模式、如何深入行业成为能够胜任分析、架构为一体的精英人才这可不是每个人都能够遇上的馅饼……

然而学海无涯，精力有限，个人如何能够很快将这些所谓的架构师知识掌握？这是秘密，每个人都有自己的独门家传秘笈就不敢一一暴露了。不过有一点就是广泛学习的基础之上一定要根据个人兴趣、从事领域确定一条自己的主线来努力。

如果说架构师是在模型图纸上工作的，那么模型元素必须是实实在在的，正如我们不可能期望抽象派画家来设计高楼大厦，没有实际意义的模型元素，是不可能构筑出软件系统的。迄今为止，绝大部分软件架构师是依赖软件程序员来实现他们的架构意图的，这二者直接的鸿沟是显而易见的。设计模式的出现是为缩短二者之间的鸿沟所做的努力，目的是让架构师和程序员之间有更多的共同语言和规范。尽管设计模式让软件开发效率和质量有一定程度的提升，但是它始终面临一个很明显的局限，那就是人的因素。人虽然在创造性方面有绝对优势，但是在精确性、持久性、效率、质量上是无法比拟机器的。所以我们希望在软件系统构建过程中，人和机器发挥各自的长处，也就是说，让人来扮演架构师的角色，而让机器来扮演程序施工者的角色。事实上，目前已经有了成功的模式了，那就是KCOM 商业工程）企业应用平台所采用的基于设计的全自动化软件工厂模式，采用这种模式，架构师在工具平台所提供的模型图设计环境里做软件系统的设计，设计结果由工具平台自身所带的“软件工厂”自动加工成最终企业应用软件系统。这样的开发模式，能使企业应用软件系统的开发在效率、质量上有了质的提升，从根本上区别于传统的设计模式，因为这里的设计模式已经包含在软件工厂编译器之中了。
在截然不同的抽象层次上概念化解决方案是软件架构师的基本技能。通过将解决方案组织到离散的层次上，架构师可以将精力集中在解决方案的单个方面而忽略所有剩余的复杂性，一旦稳定了解决方案中的某个部分，就可以处理其他部分，从而不断的将层次发展并完善到最终可以被实现的粘合模型中。

而软件开发人员也应该理解解决方案的不同抽象层次，在实际项目中非常难于实践，第一个困难就是开发人员在急于编码时很容易放弃这些层次，架构师需要在整个项目的生命周期中严格保持这些层次。无论开发人员或架构师必须意识到通过不同抽象层次概念化解决方案可以简化系统，保证不会淹没在系统的复杂性中。

IT解决方案的抽象层次并没有固定的模式，在定义抽象层次的数量和范围时要注意抽象层次的完善性，在每个抽象层次上定义多个视图，每个视图展现系统的一个单独方面，其次在解决方案的实施过程中注意保持层次间的一致性，因为需求处在不断的变化当中，当需求发生变化时，对高抽象层次的更改需要同步低抽象层次。

这里展示了一个IT企业解决方案定义的抽象层次：

域。域层次捕获项目的业务环境。

项目洞察力。项目洞察力对系统将会有的对企业的业务影响进行通讯。它以投资回报分析量化了这个影响。项目洞察力表示该项目的最高抽象层次。

业务处理。系统层次为公司内的业务处理建模。对于极其复杂的单位来说，这个层次可以再细分到子层次：部门、部门间以及部门内。

UI 规范。UI 规范设计了实现业务处理的用户界面。它是由 UI 设计文档和功能 UI 原型组成的。

详细要求。详细要求指定了系统要求的最低层次抽象。它包括诸如数据类型格式和详细业务规则等详细信息。它还包括专业性要求，例如，性能、可用性、安全性、国际化、配置、可扩展性和灵活性要求等。

体系结构。系统的体系结构被组织到六个视图中：

逻辑。定义软件层和执行系统功能的主要抽象。

并发。捕获系统的并行方面，包括交易、服务器场和资源争用。

安全性。定义用于身份验证、授权、保护机密和日志记录的方法。

部署。定义网络拓扑和系统的部署配置。

组件。定义系统组件、其接口以及依赖项。

数据。定义持久性数据的设计结构。