[Chinese]架构师的思考
架构师不应该专注于技术本身，不是可以使用多么炫的技术，而是应该更加客观地、理性地分析业务的需求，合理地使用技术。给大家分享一个朋友寄来的故事：
联合利华引进了一条香皂包装生产线，结果发现这条生产线有个缺陷：常常会有盒子里没装入香皂。总不能把空盒子卖给顾客啊，他们只好请了一个学自动化的博士后设计一个方案来分拣空的香皂盒。博士后拉起了一个十几人的科研攻关小组，综合采用了机械、微电子、自动化、X射线探测等技术，花了几十万，成功解决了问题。每当生产线上有空香皂盒通过，两旁的探测器会检测到，并且驱动一只机械手把空皂盒推走。
中国南方有个乡镇企业也买了同样的生产线，老板发现这个问题后大为发火，找了个小工来说你他妈给我把这个搞定。小工果然想出了办法：他在生产线旁边放了台风扇猛吹，空皂盒自然会被吹走。
不知大家有何感受？也分享一下。前两天在微软Tech.Ed 2008大会上，腾讯展示了一下自己开发中的基于Web的QQ，界面真的很炫，鼠标在界面上滑动时，经过的一个一个的功能图标像水泡一样滚动，煞是好看。可是，却有点走火入魔的感觉，用户体验并不是美术大赛，用户到这里来的目的是什么？是沟通，方便、快速的沟通是第一位的。就如同Google的搜索框，无比的简单，却无比的快，非常“简捷”， 搜出来的内容非常适用得体。用户得到了很好的体验。Twitter也是一样。所以，新生QQ原型作为一种展示技术的原型不错，但却未必是一个用友很好的客户”体验“的产品。
有些跑题了。回来谈架构师的思考。架构师的职责是使用适当的架构和技术来满足并实现某种业务需求。这里的“适当”就非常重要。这就要求架构师能够将需求放到实际的业务背景下来考虑，能够主动结合方向和战略，具备丰富、广阔的知识面，以及灵活而不拘一格的考虑问题的方式，善于听取领域专家的建议并能为我所用。
在每年一度的OHRP中，我将Stragetic and Global Thinking当作一项重要的个人发展内容，也是团队的发展提高内容。举个例子来讲，说到Voice/Telecom系统的架构，其实，架构师第一个要回答的问题首先是需求，当前我们叫Business case分析, 例如员工分布和分类、通话需求和分类、可用性要求和分类、当前费用情况和分类。可用性的分类很重要，这样有助于控制成本，并且与业务保持一致。前面几种都好理解，为什么费用情况也要分类？这个分类可能是基于不同角度对费用的分解 – 例如不同的国家和地区、不同的业务需求的费用，例如普通固话费用、报销的移动电话费用、电话会议费用等。
大家或许还要问，为什么要那么多分类？这个分类在前面的“做一位出色的架构师”一文中，也已有描述。这些分类会大大有益于后面方案的设计，并不是所有的需求天然都会被、都应该被满足，不同的技术方案之间可能存在巨大的不同，就如同前面的那个故事所描述的。
架构师第二步要回答的问题是可能的Solution方向和关键点。还是上面的例子，如果当前的业务需求是在提供相似功能的基础上，降低费用。那么识别出最主要的费用类别，然后寻找适当的、可能的解决方案。例如，或许当前的移动电话费可能是最大的项目，或许电话会议费用是最大的费用。架构师通过分析，要能够给出解决方案的方向和重点，从而指导项目团队和特殊领域专家（SME）去做进一步的工作。
讲得好。架构师的权威是靠自己建立起来的，也需要有自己个人的信用。从组织流程上，如果架构师自己出现问题，例如偏执，钻牛角尖，小气，死板，甚至错误，的确会出现“扼杀”的现象。但一来二去，架构师自己也就失去了自己的信用，甚至工作。
[quote]灵活而不拘一格的考虑问题的方式[quote]
这一条我觉得深有体会！我们的系统，每隔几年会做一次大的重构和升级，这时，总是按原来的思路来做，当然是考虑了系统升级，平滑割接的问题，但很多问题已经暴露很多年，不能改善！导致每次都痛苦万分！
另外有open的态度很重要！尤其架构师着眼方向性的“战略问题”时，千万要沟通充分，把思路表达下去，架构师的一句话，尤其权威人士，会扼杀很多后起之秀的好想法。
今天看到robinhf博客中介绍IBM的IT架构师定义，有参考意义。虽然道理上差不多，前面我谈的主要体会和经验是基础设施架构师的部分。
下面是节录IBM对IT架构师的分类：
http://blog.csdn.net/robinhf/archive/2008/10/30/3185384.aspx
因此，存在不同类型的 IT 架构师。IBM 定义了以下六个体系结构类型：
1. 企业体系结构（Enterprise architecture）。企业架构师致力于将 IT 功能映射到业务需要。该架构师全面负责企业的软件密集系统，包括多个应用程序之间的关系、应用程序之间共享的数据、应用程序的集成以及运行应用程序的基础设施。
2. 应用程序体系结构（Application architecture）。应用程序架构师致力于应用程序的设计，以实现业务流程的自动化并提供帮助用户执行业务任务的功能。该架构师的职责包括设计应用程序来满足用户的功能和服务质量要求，包括性能、可用性、可伸缩性、安全性和完整性。他们的职责还包括评估并选择运行应用程序所必需的软件和硬件，以及用于开发应用程序的工具和方法。
3. 信息体系结构（Information architecture）。信息架构师致力于多个应用程序所使用的数据，包括该数据的结构、完整性、安全性和可访问性。该架构师的职责包括设计、构建、测试、安装、操作和维护用于管理该数据的系统。这些系统的设计必须考虑到数据要求，例如源、位置、完整性、可用性、性能和使用寿命。
4. 基础设施体系结构（Infrastructure architecture）。基础设施架构师致力于硬件和服务器软件的设计，包括服务器计算机、存储、工作站、中间件、非应用程序软件、网络以及支持企业所需应用程序和业务流程的物理设施。该架构师的职责包括这些组件的评估和选择、用于验证设计和所选产品的建模、模拟和测试工作，以及最终获得的基础设施的性能、可用性和可伸缩性。
5. 集成体系结构（Integration architecture）。集成架构师致力于支持现有应用程序、打包软件产品、网络和系统在企业中或企业之间协同工作的解决方案设计。这些解决方案可能使用不同的技术、供应商、平台和计算类型。
6. 操作体系结构（Operations architecture）。操作架构师致力于管理企业所使用的基础设施和应用程序的解决方案设计。该架构师的职责包括为复杂信息系统的安装、操作、迁移和管理定义计划、策略和体系结构。
同感。加入联想以来，再建立架构师队伍上投入了大量的精力，也包括本人大量的时间学习体会。做到上述这些，真的不容易，比想像起来的还要难，现在做的，自己感觉，也就是及格而已。丰富的经验（见多识广）、广泛的沟通讨论（知识及时升级）非常重要。
http://www.cnblogs.com/Carrie_Liang/archive/2008/09/21/1295484.html
我看到这篇文章有一个观点是很赞同的，
架构师是需要敏锐的Business Sense，这个大多是是经验决定的，是直觉。这与了解客户需求应该是不同的意识形态，了解客户需求靠分析的成分多些，应该还偏解决方案层面，如果架构师也分等级的话，靠分析的架构师要比靠敏锐直觉的架构师低一个级别。
看赵博士和大潘的网志总是有很多收获，
1、了解客户需求是解构的过程，是把握方向的前提
2、“合适”一词真的很难，要全面理解客户需求，又要紧跟公司整体战略和方向。
这里面还要看架构师在公司所处的位置和要做的工作，如果是解决方案相对会比较容易，难的是对以往产品的变革，心到力不逮往往是架构师最真实的写照。
3、有了方向之后，就要考虑如何实现和变通满足需求，这是一个建构的过程。
关键点的选择在第2步要完成的，在这一步主要是实现路线的问题，哪些关键点需要先做，哪些可以缓缓，为什么这么做是对的，多考虑和论证集中不同实现路线的优劣，这个也不容易。
4、其实，架构师还有一个最重要的能力就是需要沟通，与客户、与产品的项目团队讲解自己的思维和思路，还有你的上司，去说服他们你的方案是可行的。