有幸参加了IBM组织的IBM“IT架构师培育计划”第四期的培训，有点收获和大家分享一下。

课程主要是围绕如何成为优秀的IT架构师，IT架构师在项目中的角色，IBM的架构流程规范，IBM的架构师在检查自己设计架构的是否可行性，是否可用性，是否可实施性对以及对其扩展性手段和标准。IBM的架构在电子商务的模式的参考框架。上课的内容多是方法论的东西，这次的培训我认为是架构思路培训，
具体怎么样实施还应该根据实际情况而定。

（一）如何成为优秀的IT架构师，即需要哪些条件或特质。
1.对一两个技术方面具备非常深的专业知识和技术。
2.针对某个行业有着非常强的行业知识。
3.具备很好的“听”的能力和沟通能力。
4.具备很强的解决问题，处理问题的能力。
5.有对项目的一个生命周期的负责的能力。
6.领导能力。
7.个人魅力，个人特质。
8.项目管理能力（不需要项目经理那么强）。
9.与客户建立信任

（二）IT架构师在项目中的角色，以及如何和项目经理在项目整个周期中配合。
这点给我一个很大启发就是在IBM软件工程体系和所谓RUP过程中角色：项目经理（项目资源管理，项目进度管理，项目实施部署和维护等，把握中与客户和内部人员协调工作），架构师，产品专家（负责系统在行业产品化模式），技术专家（负责系统高新技术的技术方案包括细节化类级设计模式），编程员的角色。没有所谓SA（系统分析）--这是因为IBM认为它角色（责任）很不清晰和尴尬，即不是需求控制，也没有项目生命周期全程权责。IT架构师和产品专家侧重点不一样：IT架构师侧重系统设计（对客户建立信任度责任），而产品专家侧重产品的开发和项目的实施。IT架构师在整体项目周期中，从一开始的投标中的需求分析、出方案就要介入其中，和项目经理配合，项目中标之后，做具体设计以及监督它的实施，保证当初的设计被最大限度的实施了，在测试阶段，要配合测试经理进行单元测试和集成测试，以及最后的发布验收。
架构师不仅仅负责软件的架构，也负责硬件的架构，用他语言就是组件模型（组件可以软硬件主要针对功能性需求－－例如业务功能分类，硬件功能分类，抽象的功能节点）和运营模型（组件的运营环境主要体现非功能性需求－－组件的支撑环境，性能，安全，扩容，扩量，容错，扩展，未来需求），其中组件模型包括组件的定义，组件的对外接口，组件的使用；模型中体现非功能性需求，其中有一个叫未来需求（其实就是我们常常在架构是采用的高扩展服用架构动力，包括硬件设备未来－－加节点分布式，带宽扩展考虑，业务未来需求－－具有前瞻业务变更扩展或者更高一手，可定制业务变动适应力）。

（三）IBM的架构流程规范
总结如下：需求分析（use case 的分类和抽象）－＞用例建模（用例图，use case 的初步定制）－＞业务建模（业务概况图）－＞参考模型（已有资源利用）－＞组件模型（系统关系图，组件定义，组件的对外接口，组件的使用）－＞数据模型（包括数据库，系统内的信息格式）－＞运营模型（系统架构模型）－＞架构模型－＞可行性分析（用例逻辑验证）－＞实现（包括详细架构，编码，测试，递归过程）－＞部署－＞实施－＞总结。
在架构的过程中要注重在架构决策在可用性需求分析过程中要记录起来（这是为了评估/和出问题时候的回归决策）

（四）IBM的架构师在检查自己设计架构的是否可行性，是否可用性，是否可实施性对以及对其扩展性手段和标准。
总结如下：
1.可用性是指从客户的角度来对系统的要求--使用者感受（连续性，方便性，稳定性，持续性），性能和容量，可管理性，安全，可维护性，可靠性，利润，可扩展性；
2.性能，在设计架构时候就应该考虑到性能的需求，而不能等到实施编码的时候或测试的时候才注意。
3.评估的时候还要从用户角度看（交换角色的观点看架构）：主要看使用者的感受，可用性包括两个层面：a.组件出现问题的时候如何恢复，B.可用性，结合其他层面（中间件/OS/硬件层面）；同时要注意在对架构决策平衡的观看架构决策是否合理。
4.从项目管理角度和运营方面评估和审查架构是否可行性：包括时间，成本，服务的重要性—〉组件模型，运营模型，未来需求，架构决策—〉参照用户对服务的列表，服务对组件的矩阵，计划维护的矩阵（基本的）；组件失败影响分析，详细对用户服务矩阵，组件可行性分析—〉运营模型，组件模型，服务水平特征，非功能性需求，现有IT的环境，架构决策。
5.组件间松耦合(方便处理可用性)和紧耦合（提高性能）的决策，同时要检查容错性。
6.性能架构师的估算和建模：初步估算，不断增加细节，应用设计更改，从技术方案原形获取的信息，配置更改，容量信息，数据库设计进化，数据库使用模式（同步，备份，容量），应用使用场景建立，从系统测试获取信息，从系统运行过程获取信息。
7.同时要定义性能和容量的测试的标准，必须在架构时候初步获得系统架构的数量级极点（最高，最低，弱点，峰值）在测试的标准必须订立和找出系统的系统明显性能慢下来的点，系统崩溃临界点（这样可以找出系统的在不同状态的临界值，更能把握架构是否合符需求）。正常工作（或者在比例较多的时候—时间比例尽可能大）在极限值临界值订立标准有：CPU最大值75%左右，硬盘使用率40%，网络使用率30%作用。
8.从系统架构生命周期来考虑架构（非功能性需求，产品的生命周期）这个包括业务的（业务变更扩展处理张力）和非业务的（物理逻辑扩展处理张力）；可以通过以下步骤：a.需求和限制条件（系统关系图和描述来看）-〉架构功能方面考虑（组件模型和功能规范）-〉数据模型（数据库接口内容，信息载体内容）-〉系统运营架构方面考虑（非功能性，安全，网络，应用部署，数据管理，系统管理等等）-〉系统运营架构外部接口（组件整合规范）-〉系统性能方面-〉系统可用性（包括硬件，网络，系统功能，业务）-〉系统可靠性（备份和恢复，注意业务上应用场景德恢复）-〉项目的团队的实施能力（项目管理和运营管理的资源环境）

（五）架构的模式
1.概括所谓模式种类有：架构模式，分析模式，设计模式。电子商务层次的模式分为：复合模式—〉商业模式（商业交互，业务集成），集成模式（前台，后台集成）—〉应用模式（应用结构）—〉运作模式（中间件）—〉产品影射（不同平台的影射）。
2.商业模式分为：自助服务（用户对商业服务，例如：Web）；协同工作（用户对用户的数据与信息，例如：QQ，MSN,视频，Outlook，Exchange Server，OA），信息集成（用户对数据，例如：搜索引擎，知识管理系统），扩展企业（商业队商业，对数据和过程业务服务，例如：电子数据交换）
3.最后培训老师在介绍模式的时候，重点向我们介绍了SOA的架构模式，也是IBM所推荐的，虽然现在SOA项目案例还比较少。