IT架构师在项目中的角色，IBM的架构流程规范，IBM的架构师在检查自己设计架构的是否可行性，是否可用性，是否可实施性对以及对其扩展性手段和标准。IBM的架构在电子商务的模式的参考框架。方法论的东西，我认为是架构思路培训，具体怎么样实施还应该根据实际情况而定。对不同的业务模式有所不同，需要形成具体业务模型的方法学。
下面内容从几个方面谈谈我的感受：
1.1 如何成为优秀的IT架构师，即需要哪些条件或特质。
1.对一两个技术方面具备非常深的专业知识和技术。
2.针对某个行业有着非常强的行业知识。
3.具备很好的“听”的能力和沟通能力。
4.具备很强的解决问题，处理问题的能力。
5.有对项目的一个生命周期的负责的能力。
6.领导能力。
7.个人魅力，个人特质。
8.项目管理能力(不需要项目经理那么强)。
9.与客户建立信任
总结：上面的9个方面能力的确对要想成为架构师的我们提出很高的要求，架构师不仅仅是业务方面的专家，更是沟通、领导能力方面的专家，是一个全方位的能人，因此，我们下一步对自己的努力方向应该要有明确目标，一个方面一个方面的去加强。
1.2 IT架构师在项目中的角色，以及如何和项目经理在项目整个周期中配合。
这点给我一个很大启发就是在IBM软件工程体系和所谓RUP过程中角色：项目经理(项目资源管理，项目进度管理，项目实施部署和维护等，把握中与客户和内部人员协调工作)，架构师，产品专家(负责系统在行业产品化模式)，技术专家(负责系统高新技术的技术方案包括细节化类级设计模式)，编程员的角色。没有所谓SA(系统分析)--这是因为IBM认为它角色(责任)很不清晰和尴尬，即不是需求控制，也没有项目生命周期全程权责。IT架构师和产品专家侧重点不一样：IT架构师侧重系统设计(对客户建立信任度责任)，而产品专家侧重产品的开发和项目的实施。IT架构师在整体项目周期中，从一开始的投标中的需求分析、出方案就要介入其中，和项目经理配合，项目中标之后，做具体设计以及监督它的实施，保证当初的设计被最大限度的实施了，在测试阶段，要配合测试经理进行单元测试和集成测试，以及最后的发布验收。
架构师不仅仅负责软件的架构，也负责硬件的架构，用他语言就是组件模型(组件可以软硬件主要针对功能性需求--例如业务功能分类，硬件功能分类，抽象的功能节点)和运营模型(组件的运营环境主要体现非功能性需求--组件的支撑环境，性能，安全，扩容，扩量，容错，扩展，未来需求)，其中组件模型包括组件的定义，组件的对外接口，组件的使用;模型中体现非功能性需求，其中有一个叫未来需求(其实就是我们常常在架构是采用的高扩展服用架构动力，包括硬件设备未来--加节点分布式，带宽扩展考虑，业务未来需求--具有前瞻业务变更扩展或者更高一手，可定制业务变动适应力)。
总结：好的架构师是既懂软件又懂硬件的，这对我们这些以做产品技术为主的工程师来说有很大的挑战。对我来说，虽然以前也做过开发，但是新的开发技术不断出来，尤其基于j2ee架构的技术还需要进一步提高，以便能够满足做架构师的要求。
1.3 架构流程规范
个人的理解如下：
需求分析(use case 的分类和抽象)->用例建模(用例图，use case 的初步定制)->业务建模(业务概况图)->参考模型(已有资源利用)->组件模型(系统关系图，组件定义，组件的对外接口，组件的使用)->数据模型(包括数据库，系统内的信息格式)->运营模型(系统架构模型)->架构模型->可行性分析(用例逻辑验证)->实现(包括详细架构，编码，测试，递归过程)->部署->实施->总结。
在架构的过程中要注重在架构决策在可用性需求分析过程中要记录起来(这是为了评估/和出问题时候的回归决策)
总结：其实我们的大部分项目都是安照这个思路来做的，只是希望能做到更认真些。
1.4 架构师在检查自己设计架构的是否可行性，是否可用性，是否可实施性对
以及对其扩展性手段和标准。
个人的理解是：
1.可用性是指从客户的角度来对系统的要求--使用者感受(连续性，方便性，稳定性，持续性)，性能和容量，可管理性，安全，可维护性，可靠性，利润，可扩展性;
2.性能，在设计架构时候就应该考虑到性能的需求，而不能等到实施编码的时候或测试的时候才注意。
3.评估的时候还要从用户角度看(交换角色的观点看架构)：主要看使用者的感受，可用性包括两个层面：a.组件出现问题的时候如何恢复，B.可用性，结合其他层面(中间件/OS/硬件层面);同时要注意在对架构决策平衡的观看架构决策是否合理。
4.从项目管理角度和运营方面评估和审查架构是否可行性：包括时间，成本，服务的重要性—〉组件模型，运营模型，未来需求，架构决策—〉参照用户对服务的列表，服务对组件的矩阵，计划维护的矩阵(基本的);组件失败影响分析，详细对用户服务矩阵，组件可行性分析—〉运营模型，组件模型，服务水平特征，非功能性需求，现有IT的环境，架构决策。
5.组件间松耦合(方便处理可用性)和紧耦合(提高性能)的决策，同时要检查容错性。
6.性能架构师的估算和建模：初步估算，不断增加细节，应用设计更改，从技术方案原形获取的信息，配置更改，容量信息，数据库设计进化，数据库使用模式(同步，备份，容量)，应用使用场景建立，从系统测试获取信息，从系统运行过程获取信息。
7.同时要定义性能和容量的测试的标准，必须在架构时候初步获得系统架构的数量级极点(最高，最低，弱点，峰值)在测试的标准必须订立和找出系统的系统明显性能慢下来的点，系统崩溃临界点(这样可以找出系统的在不同状态的临界值，更能把握架构是否合符需求)。正常工作(或者在比例较多的时候—时间比例尽可能大)在极限值临界值订立标准有：CPU最大值75%左右，硬盘使用率40%，网络使用率30%作用。
8.从系统架构生命周期来考虑架构(非功能性需求，产品的生命周期)这个包括业务的(业务变更扩展处理张力)和非业务的(物理逻辑扩展处理张力);可以通过以下步骤：a.需求和限制条件(系统关系图和描述来看)-〉架构功能方面考虑(组件模型和功能规范)-〉数据模型(数据库接口内容，信息载体内容)-〉系统运营架构方面考虑(非功能性，安全，网络，应用部署，数据管理，系统管理等等)-〉系统运营架构外部接口(组件整合规范)-〉系统性能方面 -〉系统可用性(包括硬件，网络，系统功能，业务)-〉系统可靠性(备份和恢复，注意业务上应用场景德恢复)-〉项目的团队的实施能力(项目管理和运营管理的资源环境)
总之，如果可能，希望在我们的项目评估中引进这些方法，以更能准确评估一个系统的可行性以及能力。
1.5 架构的模式
这部分个人感觉对架构的描述和标示架构方法这部分有些体会：
对于架构设计的描述和方法，目前采用四个视图、一个场景方式，其中大家对进程视图比较关注，因为我们一般开发人员更多关注逻辑视图和开发视图，而物理视图一般是系统工程师比较关注的，我们感机密觉对于大多数项目来说，都没有做到，如果做到对进程模型的把握几乎就能够对整体系统架构软、硬件的把握，可以很清楚系统的瓶颈之所在。因此，在以后的工作中希望能够加强这一部分工作。