观点与展望，第 8 部分: IBM 架构师为何以及如何成为了架构师(转与 developerWorks)

developerWorks 编辑团队, IBM
2007 年 4 月 24 日
和 IBM 体系结构专家亲密接触。了解他们为何要做目前所做的事以及如何达到目前的职位。探索他们职业生涯中遇到的种种曲折，了解他们如何通过这些经历最终进入 IT 体系结构领域中。

第 1 部分: 选择 SOA 的原因和时机第 2 部分: 如何将业务需求转转换为 IT 要求？第 3 部分: 什么是最有价值的 IT 体系结构技能，如何学习？第 4 部分: 如果刚刚开始采用 SOA，最好将哪些软件作为服务实现？第 5 部分: 什么是 IT 管理，为什么应该对其加以注意？第 6 部分: 定义最重要的 IT 体系结构问题第 7 部分: 当今开发人员面临的最有影响力的趋势有哪些？更多...
 
长大后，您想干什么？虽然我已经工作了很长时间了（已经到了不愿意公开自己的工作年限的地步了），我仍然在考虑这个问题。或许您也是这样。事实上，如果您和我一样是生育高峰期出生的，您可能将不断问自己这个问题，给出各种不同的答案，直到有一天极不情愿地被推入退休队伍中为止。
本月我们将询问专家组一个类似的问题（不过我们将问的是他们的过去，而不是他们对将来的看法）：
为什么您觉得 IT 体系结构方面的工作适合您，为了成为架构师，您走过了什么样的路？
正如您将看到的，IBM 技术带头人也经历了同样的心路历程。事实上，他们似乎都有一个共同的特点，就是始终都在积极地尝试获得新的经验和知识。或许这使得他们有些像杂家， Grady Booch 就使用这个词来描述自己，而这又被Merriam Webster 定义为“闲人”或“不安分的人”。（此处并不是说“不诚实或没用的人”。）更可能的是，这使他们成为博学家（即 Merriam Webster 所说的“具有各方面知识”的人）。他们日子过得似乎都不错!
对于希望成为 IT 架构师的普通人，这可能会使他们望而却步。那么，究竟在 IT 领域中工作的哪些人如此有创造力而同时又过得这样快乐呢？但他们每个人都是很久以前从普通人开始一步步做起的。他们并不是一下子就获得了成为 IT 架构师的所有技能，他们经历了漫长而艰难的过程，并深入各种不同领域才得到了所需的技能。设计方面也是如此。其他人则是在尝试了其他角色后才选择这个职业。
考虑到我们的专家组成员对新鲜事务的好奇心，我忍不住认为这可能并不是他们中的任何人的最终归宿。如果我们要讨论的是他们以后的职业生涯，我想会发现他们在将来承担起新的任务、对新的挑战发起攻击。我们都经历了很长的成长过程，但我认为他们有可能还会继续这个过程。因此，如果下次问他们这个问题也会非常有意义：“长大后，您想干什么？”让我们拭目以待吧。
developerWorks Architecture 团队——
Paul Dreyfus，编辑
developerWorks
pdreyfus@us.ibm.com




回页首
任何方面都能推动架构师的工作：客户、他的团队、体系结构、小故障和各种问题。我认为体系结构更多的是一种态度、完美地建起软件“大厦”的热情，但现实却往往使得这不那么完美。不过，追求完美的想法与现实之间的平衡会让架构师保持一定的清醒态度，因为他必须向客户交付一个正常运行且性能良好的系统。
回忆：我看到自己参加会议、在白板上画图、处理一个接一个的问题。在团队的帮助下，我尝试利用过去所积累的知识在问题领域中的各种力量和约束之间求得平衡。模式？或许吧。我喜欢体会团队活力在周围流动的那种感觉——每一分钟，我都能在同事仔细描述各种情况的细枝末叶时获得启发和学到新的东西：为什么这个情况略有不同，因而必须修改模式，以处理实际情况。
编写代码的日子：编写代码是孤独的探寻过程。这个探寻过程同时也是永不停止的。有时候还没有回报。找到错误，会得到表扬。如果最终的交付内容/版本中没有错误，则不会提到这些代码中的重要性和您在其中投入的精力！
我喜欢编程——不过现在很少进行此类工作了，仅在学术中需要时才会做这样的工作。处理项目时，我已不再进行代码编写工作了。
香港，1980 年：我开始使用 BASIC 和 Fortran 进行编程。我非常喜欢编程。转眼到了 1995 年，我开始进行 Java™ 编程，享受接口实现和松散耦合所带来的纯粹乐趣。但应该如何设计系统结构呢？
即使获得了最好的运行代码，仍然需要一个能够承受非功能需求冲击的结构。因此，您需要能够对各种相互冲突的约束进行权衡，在重复考虑当前情况的细微差异的前提下进行决策。
我比较认可“模式生成体系结构”这样的学术流派。从蓝图（一组基本模式）开始，然后根据自己的实际情况进行扩展和自定义。这就在最佳实践和现实具有特定的无名品质（QWAN，Quality Without a Name）之间获得了最佳的平衡点，这一点我非常喜欢。
我喜欢自己的架构师工作。 :)




回页首
并不是我决定要做一名架构师，而是我从事的工作所涉及的内容正是我们目前所称的体系结构方面的东西。
开始的时候（大部分时间，甚至到现在也是如此），我们并不进行“体系结构设计”。我们只编写程序，其中的任何体系结构都是意外出现的。
我在 14 岁时编写了第一个程序（使用的是 Fortran，当然我对于良好的设计所知并不多，体系结构方面懂的就更少了）。上大学时（最初在 Air Force Academy，后来在 Santa Barbara 的 University of California），我遇到了当时形成了深度设计的早期理念的很多人：David Parnas、Mary Shaw、Tony Hoare、Edsger Dijkstra 等。刚刚二十岁出头的时候，我担任过一些相当大（甚至按照今天的标准也可以这么说）的实时分布式系统的项目工程师和项目经理的角色，为美国军事航天项目提供支持。
1982 年退役后，我加入刚刚创建的 Rational®，参与了 Ada 项目的大量工作。我的大部分时间都奔走于美国各地，与合同客户和军队协作，以帮助他们应用软件工程的最佳实践以及这个新兴的语言。
我一直是个杂家，出现在科学所指引的地方。我逐渐发现商业领域的很多组织开始邀请我帮助他们进行类似的工作，因此我开始偏离 Rational 的核心业务，将我的精力投入到这个更大的领域中。也大约在这段时间，我撰写了第一篇有关面向对象的设计的论文，并开始编写我自己的第三本书（与此主题相关）——其中所有内容不过是对我通过这些项目得到的经验的总结。我还与 Bjarne Stroustrup 进行了合作（他是 C++ 的发明者，我们甚至还一起去参加了全国性的巡回演讲），因为我们发现他的语言设计方法和我的系统设计方法非常相似。
在那段时间里，我仍然进行编程工作：我使用 ObjectPascal（在 Mac 平台上）编写了 Rational Rose 的原型，并采用 Smalltalk（PC 平台上）编写了第二个更为完整的版本。Dave Stevenson 和我是第一个 Rational 建模产品的架构师（采用 C++ 编写；这对 Rational 是一项突破，因为之前的所有产品都是使用 Ada 完成的）。
这些产品进入市场后，我再次承担起作为架构师和体系结构指导人的角色，为我们的一系列最大的客户服务。在此期间，我受到Philippe Kruchten 的工作的很大影响；他领导进行了早期的流程设计等方面的工作，同时他还是 Canadian Air Traffic Control System 的首席架构师之一。他也参与了有关体系结构描述的 IEEE 标准方面的工作。
我在尝试让人们记住，“SOA”中的“A”表示“体系结构”。
——Grady Booch
最近这些年，Kent Beck 和我组织了名为Hillside Group 的模式研讨会；这个研讨会今天仍然是模式文化的重心。我是 World Wide Institute of Software Architects (WWISA) 的最早成员之一，同时也是后来成立的 American Institute of Software Architects (AISA) 的第一批成员之一，这两个组织都致力于发展软件体系结构实践。
这段时间里，随着 Rational 的业务全面纳入 IBM 中，我也回到了我原来进行的体系结构方面的工作。我不仅对 IT 体系结构感兴趣，而且也对软件密集型系统的每个领域的体系结构原则感兴趣。体系结构方面仍然有很多东西我们不知道——它所代表的东西、它所不能代表的东西、如何最好地表示它、体系结构级别存在何种模式等等。因此，我花费了大量的时间通过实践和研究来进行学习。在实践方面，我仍然继续担任我们客户（甚至也包括尚不是我们客户的组织）的架构师兼体系结构指导人的角色。在研究领域，我正在编写Handbook of Software Architecture，该书的目标是确定各种有意义的软件密集型系统的体系结构。我与 Software Engineering Institute (SEI) 的体系结构人员进行了大量的合作。同时，我也非常密切地关注着Murray Cantor 在系统工程方面的进展。我在尝试帮助人们记住，“SOA” 中的“A”表示“体系结构”，另外还参与了一些新兴商业和行业体系结构标准方面的工作。
我仍然在进行编程工作（大部分时间都是用 Java），但我想自己现在终于知道了如何设计我所编程的系统的体系结构。




回页首
当时是我学生生涯的倒数第二个学期。我在堆满研究论文、翻开的书籍和无数的潦草笔记的书桌上埋头苦读，并考虑我的毕业论文的命题。我被这个抽象的几何模型困扰着，试图说明其对计算图形的潜在影响。我成天看不同维度形状的视图、准平面和 N 维空间的抽象数学变化，都有些头大了。在此过程中，我清楚地发现自己处于这样一个十字路口：理论计算机科学（学术方向）或应用计算机科学（计算机行业从业）。我非常果断地选择了后者，毕业后加入了一家在《财富》杂志排行 10 强的银行。
我在此银行中担任助理咨询师，我所属的团队负责设计广泛分布于全球范围内的信用证解决方案。我全面接触了正式软件开发生命周期方法、经过业界检验的工程原则、软件产品堆栈和大量商业银行领域的概念。有了这些经验，我大胆地来到瑞士，为多家银行提供咨询服务，指导他们解决多个领域的技术问题（如进行电子文档存档，以实现异类数据集成）。瑞士人对精工和质量方面的关注是非常有远见的，而他们对采用新兴技术的渴望让我有机会接触各种创新产品。
……他们允许我对应用程序层进行分析，并能够直接研究 OS 内核和基础硬件的基本细节。
——Sanjay Bose
到此时，我已非常深入地了解了银行业务，并加入了一个全球性 SI 的研发部门，重新回到我最擅长的领域。在这里，他们允许我对应用程序层进行分析，并能够直接研究 OS 内核和基础硬件的基本细节。我对 UNIX SVR4 进行了修改——调整引导和调度算法、优化设备驱动程序、调整事件和中断处理、对机器代码进行反向工程、研究前辈（Ritchie、Thompson、Joy）编写的组件、使其识别 x86 和 RISC 处理器内部指令、处理后来出现的新兴微内核和实时操作系统。从中获得的经验巩固了我对解决方案和应用程序实际 如何运行的认识。
随后进入 .COM 时代，全世界都开始更多地接触面向对象的概念，而我也不希望被这个潮流抛在脑后。因此，我开始担任一家新成立的公司的首席工程师，该公司当时正在研发用于解决异类企业数据源的实时集成的产品。我负责设计和构建核心运行时基础设施、元数据管理和数据访问框架。这个公司真的是一个 OO 新兵训练营。我的同事（大部分都刚刚毕业）都具有完全的 OO 意识——我甚至怀疑他们将Gang-of-Four 的书作为早餐！我很快便成了 OO 的信徒，对 OO 设计、模式和技术以及如何将其应用于 Java 以及早期 J2EE 了如指掌。除了核心产品体系结构外，我还承担其他一些任务：客户销售、提供 UI 工具和人为因素方面的培训、生成安装二进制文件、排除客户部署的故障等等。
很快我开始渴望感受大公司的那种节奏，随后加入 IBM。最初我有些担心自己会迷失在蓝色巨人怀抱中，但很快发现 IBM 的运作方式就像带保护伞的 VC，充满了主人翁意识和创新。我最初是 WebSphere Application Server 产品的一名开发人员，进行的是系统管理和 EJB 容器组件方面的工作。之后，我加入了 IBM Research 的一个孵化项目 NextWeb，为 Web 服务建议和创建综合框架，包括“on-the-glass”服务。由此引出了各种临时标准，并最后定型为 OASIS WSRP TC。同时，我还负责设计 WebSphere Portal Server 中的一些组件的体系结构，以将这些孵化技术投入实际应用。
到此时，我掌握了 Web 服务和初期 SOA 的要点。我开始为 IBM 战略业务合作伙伴提供技术指导，引导他们充分利用我们的中间件投资组合，从而更好地完成他们的重要产品功能。随着 SOA 技术不断成熟，我的这些服务范围开始扩展到大型 IBM 客户和相关的适配器方面——共享技术策略、指导他们进行体系结构试点项目以及将他们的问题转给我们的软件产品团队。目前，我的工作重点已经发生了进一步的变化，负责将全球客户活动中发现的关键差距和问题反映到 IBM 软件投资组合和解决方案资产中，从而帮助推动 IBM 软件部的 SOA 需求策略的发展。
我非常幸运，能够亲身经历 IT 的诸多方面，正如前面提到的，还通过这些经历磨练了我的基本学习技能。就今天而言，如果在处理技术理念僵局或应付要命的竞选活动（是的，在 IBM 也有这样的活动）让我感觉到自己的精力不足，为了重新打起精神，我只需要从书架上取下我的毕业论文看看就能办到。




回页首
我之所以认为 IT 体系结构是我的正确选择，是因为这个技术领域是让我最为痴迷的领域（现在仍然如此）。这种专业性驱使我在没有任何时间期限时开展研究工作，也正是这个因素让我错过吃饭时间，因为我舍不得暂时停止阅读有关新技术的资料。我非常喜欢将很多不同的观点组合为一个具有内聚力的交付内容，尝试将似乎不相关的东西形成一个更为相关的解决方案。体系结构强调确定很多不同技术细节的挑战，这包括对项目的成败非常关键的细节，也包括对满足涉众的需求有直接影响的细节。
在我职业生涯之初，担任的是开发人员的工作，工作重点在较大的软件工程中非常具体的元素；这通常意味着主要在实现阶段参与相关工作，而在体系结构设计期间却涉及的不多。我当时所进行的设计工作主要是“小型”设计，通常属于一个应用程序中的工作。随着我职业生涯的发展，我越来越认识到，即使通过非常娴熟的技能创建了软件构建块，但如果基本理解和体系结构不正确，项目成功的几率也将大打折扣。因此我开始主动寻找能让我更多参与此类活动的项目。这让我倾向于喜欢发现解决方案的总体概貌。一段时间后，我开始在项目进行期间担任架构师的角色。以后的故事您都知道啦 :)




回页首
我倒是希望自己对职业生涯以及整个人生都有所计划，但我必须承认并非如此。我女朋友和我曾就自由意志进行过讨论。她认为存在自由。而我认为我们是非常非常复杂的图灵机，完全由输入信息序列定义。因此，我可能不应该来回答这个问题。不过，每个人都知道我将如何回答。我的图灵机进入了一个状态，迫使我自然而无休止地钻研任意主题。
我上大学前没有见过计算机（准确地说是大二才首次看到计算机）。是的，我有些落后。实际上，我都是在那之后很久才首次看见计算机的。我在大二时见到了计算机终端。我当时学习了 FORTRAN，才发现以下事实：
我真的很喜欢编写程序。 我真的很擅长编程。
无论如何，我现在并不确定自己是否仍然对此很擅长。我仍然喜欢我工作的技术方面的东西：调整代码、编写小段 PHP、讨论一些设计选择、考虑重要的下一步工作。我定期到现场视察，花上一整天时间对项目进行检查，并与项目人员进行讨论。现场人员说，尽管会受时差的影响而且每天工作时间很长，我似乎从来不觉得累。他们想知道我是如何做到的。这样的日子是我工作中最有意思的日子，我非常喜欢。我对它们的喜爱程度超过了对咖啡的喜爱。
正是这个原因让我觉得 IT 是我的正确选择。那么，我走过的路是什么样的呢？我不断地探索新问题（现在也是如此）。我所走过的路似乎是最具挑战，也是最有趣的。




回页首
我之所以选择 IT 体系结构，有很多与 Bobby 相同的原因。我最开始负责维护其他人编写的代码。我经常遇到这样的情况，我要维护的代码，除了编写者本人外，几乎没有任何人能够理解。（至少那些希望理解这些代码的人无法理解。）为了更好地了解代码所进行的各方面工作，我要重写代码，以便能够更好地了解系统如何工作。我发现（我的经理和其他更为资深的软件工程师也发现了这一点）自己能够很好地重写软件，从而更便于其他人在我之后进行维护。
随着时间的推移，我的技能不断提升，所接触的项目范围也越来越广泛，我经常发现所处理的软件存在功能重复（或功能非常相近）。我会重新设计此类冗余功能，以使其包含在应用程序内的可重用模块中，从而减少要维护的代码量，降低出现错误的潜在可能性。
此时我发现自己希望在更广泛的范围内应用这些技能。我想知道我所处理的所有这些应用程序如何一起工作。我想正是在此时我决定要成为一个 IT 架构师。为了最终达到我的目标，我接触了诸多 IT 领域的东西，包括 QA 测试和操作。我还在一个替换 ERP 系统的部署中扮演过主要角色：这项工作要求对旧 ERP 系统与对其依赖的外围应用程序（或反过来）间的所有接口进行全面的检查。
所有这些经验促成了我的 IT 体系结构技能的形成。我当然很同意 Bobby 的观点，为了成为高效率的 IT 架构师，务必通过操作、维护、测试和部署软件获得足够的经验，从而形成坚实的基础。




回页首
我成为架构师所走的路可能与大多数人都不一样，因为我大学学的是数学专业，在高中和大学都编写过很多简单的计算机程序。大学毕业后，我加入了一家大型零售企业，学习使用各种技术构建商业应用程序。我掌握了很多编程语言和技术，并在后来担任过团队负责人、设计师和教师的职位。之后，我厌倦了这样的生活，决定转行，因此去上了一所法律学校。从法律学校毕业后，我惊讶地发现很多大公司（不是律师事务所）在招聘应届法律专业毕业生。在接受招聘面试的过程中，我发现，在法律学校中学习的各种技能（例如，问题确定和冲突管理）对领导能力的各个方面都非常重要（前提是必须掌握这些技能）。此外，我记得在法律学校学习的第一年，一位教授曾指出，该校的目标实际上是仅仅教会我们三件事情：如何读、如何写以及如何思考。这些是我们的主要课程。
在决定不从事法律方面的工作后，我在一家咨询公司谋得了一个职位。我后来离职，并首次加入了一家小型计算机公司（当时规模小）Tandem Computers。我在 Tandem 获得了大量的经验，让我对各个公司如何购买各种先进技术以及如何使用技术有了更全面的了解。更为重要的是，由于在 Tandem 担任过不同的角色，我担任过指导咨询师、程序员、软件工程师和架构师的职责。我发现自己不仅需要进行设计和编码，还需要帮助为解决方案确定恰当的技术，还必须考虑使用模式、服务质量，而且必须同时考虑以后的需求和目前的需求。
我发现好的架构师都是善良的独裁者，具有很强的技术、良好的写作能力、良好的口头表达能力，能够在各个层次进行沟通。我很喜欢这个新角色。我之所以加入 IBM，是因为我遇到了很多非常聪明的人，他们都在非常大的公司工作，与 CEO、CIO 交流，影响着技术方向，并负责设计主要解决方案（其成功对高级执行人员非常重要）的体系结构。我也希望成为这样的人——现在我是了。




回页首
我从事 IT 工作的头五年，主要是在零售行业像打杂的一样（不过仍然被称为 DBA）设计和优化数据库。当时是 20 世纪 80 年代初（是的，从我的年龄就能够猜出来），但我仍然感到惊讶的是，重构包含几百万记录的数据库之类的简单任务经常要花上 2 到 3 天时间。联机重组和关系数据库之类的东西当时还不流行！进入公司几个月后，我询问当时的上级，为什么 CPU 大部分时间都是空闲的，还运行这么慢，他给的答案是“原本就是这样的。我们只需要按照手册中的过程进行操作就行了。这就是为什么劳动节的这个周末加班的原因（译者注：美国劳动节在 9 月的第一个星期一），方便您对问题进行修复。我们每年只有一次机会对数据库进行重组（对于不熟悉数据库的读者，我解释一下重组：重组通常用于对已经填充了信息的数据库进行重新设计或重建），以便为应付圣诞节的购物高峰期做好准备。”
我升了职，我的老板告诉我，他认为我以后会成为一名好的架构师（如此之类的说法）！
——Sridhar Iyengar
当时我刚刚走出学校的大门。我非常失望，发现自己所学的所有关于并行计算机科学理论并没有在那个年代的计算机系统上得到利用——至少在我所知的数据库系统上是如此。我的目标是设计一个并行版本的重组命令，从而不必在所有周末都在绿色屏幕（指绿色的单色显示器）前度过。而正是这个使我开始进行数据库设计、并行编程和多任务操作系统设计。当我将原来约两天半的重组执行时间降低为约 7 个小时后，我升了职，我的老板告诉我，他认为我以后会成为一名好的架构师（如此之类的说法）！很快，我成为了一家小咨询公司（后来被一家更大的计算机供应商收购）的数据库咨询师，开始为很多客户设计和调整数据库。
接下的五年左右，我在教客户如何设计数据库和应用程序，以最有效地使用 CPU 资源。这意味着要讨论应用程序和数据库体系结构——而这使我开始接触 IT 体系结构。我最初以数据库设计为核心的工作重点让我开始探索实体关系模型（一项大部分数据库设计人员仍然在使用的技术）。后来，在 80 年代末期，我开始研究语义建模（我当时认为这种技术非常不错），后来又开始研究对象建模和对象数据库。大约在这段时间，我首次接触了“元数据”和“元数据库存储库”——当时正是应用开发周期 (AD/Cycle) 的年代。数年后（也就是 90 年代中期），同时发生了一系列有意义的事件，建模语言（如 UML）、元数据语言（如 Meta-Object Facility、XML DTD 以及后来的 XML 模式）和中间件（如最初的 CORBA 和后来的 J2EE 、.NET 及 ESB）开始采用面向对象的方式，并最终发展为基于组件和面向服务的系统。
从这期间的某个时段起，我的名片上开始出现“数据库架构师”、“对象架构师”、“软件架构师”、“首席架构师”之类的字样。也正是这段时间，我被推举到 Object Management Group (OMG) 的“体系结构委员会”；这是一个行业标准组织，致力于推广各种行业标准，如 Common Object Request Broker Architecture (CORBA)、统一建模语言（Unified Modeling Language，UML）以及后来的模型驱动的体系结构（Model-Driven Architecture，MDA）。我想人们最终认为我是个“架构师”，是因为我几年前开始不再编写代码，而开始将更多的精力放在如何使系统一起工作——工具、应用程序和数据集成的世界。
现在我需要考虑的是各个“体系结构”如何一起工作，如“如何将模型驱动的体系结构和面向服务的体系结构概念一起使用”。使用开放源代码（主要是 Eclipse 和 Apache 项目）和开放标准（主要来自 W3C、PMG 和 OASIS）基于真实客户场景设计一起工作的软件工具是这段时间我在 IBM 作为架构师所进行的工作。我还要花时间为重要客户提供协助，帮助他们定义体系结构和使用工具与中间件时的策略方向。我想我仍然是个架构师，因为我现在是 IBM 软件部体系结构委员会指导委员会 (IBM Software Group Architecture Board Steering Committee)、IBM Eclipse 审查委员会 (IBM Eclipse Review Board) 和 OMG 体系结构委员会 (OMG Architecture Board) 的成员。
毫无疑问，我现在意气风发，准备继续在体系结构的赛场上驰骋几年。也可以说，我现在对体系结构如醉如痴——特别与 IBM 内外这么多业内出色的架构师在一起时。




回页首
尽管我的职位中有架构师 三个字，但却不从不敢对架构师这个称呼感到理所当然。相反，我对 Kent Beck 所写的关于极限编程 (Extreme Programming) 一段话更为赞同：不要强制性地要求团队成员专业化，成为分析人员、架构师、程序员、测试人员和集成人员——每个 XP 程序员每天都会参与所有这些关键活动。
能够做各个方面的事情，这才是 IT 的乐趣所在。可以构思一个新想法、对其进行展开、向其他人展示、获得反馈，然后对其进行改进。而且可以任何时间在任何地点做这样的事情。其他哪种职业能让您有这样自由进行创新的机会呢？
因此要寻找任何能够培养所有这些技能的机会。不要不敢接触任何新技术和编写“Hello World”一类的简单应用程序。始终有新东西值得学习和尝试。




回页首
我年轻的时候，经常对看起来似乎简单的东西如何工作感到疑惑。为什么我的自行车有这么多转动的部件？为什么自行车上有一个链子连到踏板上？如果将割草机的小电动机连接到自行车后面将发生什么样的情况？自行车会自己动吗？骑自行车不捏把手下坡时，最好的做法是怎样的？我并没有意识到，这正是充满吸引力的体系结构世界之旅的开始。
和很多同事一样，我并没有成为架构师的想法。但和他们一样，在我的 IT 领域的成长过程中，成为架构师的路似乎是一个自然的发展过程。我的职业生涯始于 80 年代末期，最开始在 IBM AIX 开发实验室工作。我当时的体系结构概念全是关于 AIX 的速度/数据提供和功能。我并不理解自己作为 C 和 C++ UNIX 编码人员和测试人员能如何帮助客户实现和部署任务关键型应用程序。其中的很多应用程序都作为所谓的“资本主义社会”的催化剂或为其提供主要支持。
离开 AIX 开发实验室后，我开始担任与客户协作的 IT 专家，尝试实现客户机-服务器系统。我从事此工作后不久，.COM 热潮开始了，而很多人称为“Java 进化”的趋势也在这个时候出现了。换了公司后，我于 90 年代中期开始在 Sun Microsystems JavaSoft 组织担任第一份名片上有“架构师”字样的工作。从这之后到现在这段时间内，我在不同的 IT 专家角色（执行师和 IT 架构师）之间不断来回转换着。
体系结构更多地与理解问题是什么相关，而不是考虑应该使用何种工具和技术来解决此问题。
——Calvin Lawrence
尽管与架构师相比，我更喜欢“执行师”这个词，但“架构师”接受度似乎更广泛，也似乎更受尊敬。我们架构师对技术非常感兴趣，因为我们知道技术如何支持体系结构以及体系结构如何支持 IT。作为 IT 专家，我通常在知道问题前就已知道了解决方案。例如，我口袋里有 Java 这样的锤子，无论手里的钉子或螺丝钉（问题）的大小如何，我都能够使用 Java 将其解决。这种理念在很长一段时间内都非常适合我的情况。在上世纪 90 年代末期和本世纪之初，我最终认识到，无论我的编程技能多么先进，对结果的影响始终微乎其微。我随后认识到：“体系结构更多地与理解问题是什么相关，而不是考虑应该使用何种工具和技术来解决此问题。”
我从这些经历所总结得来的首要原则是：全面理解问题将帮助您确定使用何种技术来解决此问题。




回页首
我上大学时，并不认为自己将要成为一名架构师。我认为自己之所以成为架构师，是缘于我倾向于对我（以及我的团队的一些成员）使用的大部分组件进行定形或设计工作。在我担任每个职位（程序员、系统管理员、咨询师、中间件产品专家）的过程中，我都倾向于问自己这类问题：为什么在做目前正在做的事情以及按照我做事的方式进行是否合理？
我与一些非常聪明的人合作过，学到了大量知识，知道如何将大的复杂问题分解为较小的可行单元并同时兼顾全局。我认为这是架构师帮助解决难题和进行大型项目时的关键方面之一。我喜欢尽可能从多个角度看待问题，以找到最佳解决方案。我很希望亲自动手解决问题，非常喜欢接触新软件、新体系结构、新领域和新技术——并将其应用到我的项目中。这是一个持续的学习过程，我很喜欢这样的生活。
现在可以方便地通过多种渠道进行学习（网络课程、自学、网站、演示程序等等），学习新技术已不再是难事。关键是如何将其应用到实际生活中——而这正是好的体系结构决策与其他决策的区别所在。这非常具有挑战性，我所知的做到这一点的唯一有效方法就是不断参加新项目，了解自己不熟悉的新领域。




回页首
我一直对设计和制作各种东西充满着浓厚的兴趣。随着渐渐长大，我真的很喜欢为科学展览和其他爱好（如电子学）设计（体系结构设计）试验的过程。我通过这些开始注重动手为项目和爱好绘制设计图。我的父亲是一位非常著名的免疫学专家和极端的完美主义者，他向我灌输了在尝试动手工作前首先进行设计（设计体系结构）的价值。
我真正的第一份工作是在 80 年代中期参与政府的一份合同履行工作；计算机在当时还是一种奢侈品。
——Andras Szakal
不过，我成长为架构师的道路有些曲折。我本科时学习的是生物学和计算机科学。我努力利用多学科方法进行微生物学或免疫学（继承我父亲的衣钵）领域的基础研究。我真正的第一份工作是在 80 年代中期参与政府的一份合同履行工作；计算机在当时还是一种奢侈品。幸运的是，我的客户财力雄厚，购买了多台 PC。征得了实验室主管的同意，我使用计算机开发了一些程序，用于进行费时且手工计算时容易出错的必要计算工作，以便得到化验结果。
在实验室进行了几年脑生物化学研究后，我觉得自己对计算机和设计系统方面的东西有很高的热情。我重返学校，并完成了计算机科学硕士学位课程。幸运的是，我从研究生院毕业后，就马上获得了参与设计一个首创性电信服务提供系统的体系结构的机会——同样也是为政府工作。（这项工作让我不得不从头学习很多东西。）我们开发的系统将最终为政府的每个部门提供服务。这五年在一体化电话公司服务方面的工作经历让我获得了指导其他工程师所必要的经验，最终成为了所有员工中出色的一员。
我在电信并购狂潮开始前离开了电信方面项目的工作，并随后加入 IBM，担任组件代理团队的架构师。以后的事情大家都知道了。最终，我发现 IT 体系结构为我提供了跨组织边界工作的机会，使我能够设计对客户业务带来切实影响的系统体系结构。




回页首
我在为本专栏第三期提供的“了解各个相关部分以及它们彼此如何结合”中给出了此问题的部分答案。体系结构意味着了解所涉及的所有部分以及它们彼此如何结合。那么，如何学着进行此类工作呢？我是怎么做的呢？（假设我经历过这样的阶段！）
我首先从事的是软件测试工作，我接受这个工作完全是因为可以通过其在编写软件的团队中获得一个职位（尽管当时我并未编写过软件）。测试让我思考这样一些类型的问题：如何知道何时软件正确工作？如果某个功能不正确工作，如何判断？什么最容易出问题，怎样会引起问题？后来发现，这些问题对测试人员非常有意义。另外，我还发现这些问题可以帮助您了解如何创建好的软件。
我的第一项编程工作是对现有代码进行维护。这项工作实际上教会了我如何编写可维护（或不可维护）的代码，以及如何恰当设计来促进重用。代码应该可供两类读者阅读和理解：
执行代码的计算机 维护代码的开发人员
我遇到了很多代码都是仅满足了第一类读者的需求，而忽略了第二类读者。一直到今天，我都尽力不犯这样的错误。
因此了解如何测试和维护代码帮助我成为了一个更好的代码编写人员。能够进行代码编写工作，帮助我学会了如何设计组件和框架以及如何将实现隐藏在接口后。必须测试自己的代码，让我学会编写能够作为可重用组件分离且能够作为单元进行测试的代码。然后，我开始为不同的部分进行编程：数据库、消息传递、工作流等，甚至还包括本身具有多个部分的应用程序，如 EJB 和 Servlet。有了这些经验，我开始将应用程序视为各大部分一起工作的整体，封装了每个部分如何实现的细节。随着我开始将应用程序视为由各大部分、分布层次以及运行所需的专用引擎组成，我开始像架构师一样思考问题了。
因此，我的建议是，从底层做起，循序渐进。掌握每个层次的能力；您将需要以此为基础来进入下一个未知的层次。缺少这个基础的架构师工作起来会比较费劲。
体系结构是特定的参与层次，使我能够最高效地给项目带来最积极的影响。
——Bobby Woolf
体系结构是我的正确选择，因为它是特定的参与层次，使我能够最高效地给项目带来最积极的影响。这在以前指的就是（目前有时候还是如此）测试、代码维护、开发、设计。可能某一天这将会涉及其他什么内容。（管理？可能不会。）但就目前来说，体系结构是我帮助完成项目的最佳方式。
在以前的专栏文章中，David Jackson、Grady Booch 和 Jenny Choy 分别建议架构师要注重“沟通与推动”、“沟通与倾听”及“建立联系”。这些也都是很好的建议，但并不一定是作为工程师时学到的东西。您可能会想到如何构建应用程序的最好方法，但如果无法通过沟通将这些想法传递给团队，说服他们按照您的计划行事，您唯一的出路就是自己一个人完成所有工作。




回页首
Ali Arsanjani 博士是 IBM Global Services 的 SOA and Web Services Center of Excellence 的首席架构师，主要负责收集和制定 SOA 和 Web 服务的建模、分析、设计和实现方面的最佳实践。他是内部的 IBM 全球 SOA and Web Services Community of Practice（拥有 4000 名成员）的负责人，是 SOA 的面向服务的建模和体系结构（Service-Oriented Modeling and Architecture，SOMA）方法的主要作者之一。他目前的工作重点是支持建模 (SOMA)、评估、策略与计划、管理、体系结构和实现的 SOA 工具，以及其在 IBM 内部和外部的实际应用。请访问他的博客：Best Practices in Service-Oriented Architecture。
Grady 是 IBM Fellow，曾参与过全球几乎能想象得到的所有领域的很多复杂的以软件为中心的系统，在其中担任架构师或体系结构顾问。Grady 编写过六本畅销书，发表了数百篇关于软件工程的文章，其中包括在上个世纪 80 年代早期发布的数篇论文，后来从这些论文中发展出来了面向对象的设计的术语和实践。请访问他的博客：Software architecture, software engineering, and Renaissance Jazz。
Sanjay Bose 是 SOA Requirements Hub 的程序总监，供职于 IBM Software Strategy 部门，负责 Enterprise Integration Design Center，该中心对 IBM Software 投资组合需求进行标识，并通过参与企业客户和 IBM Software 产品开发实验室的工作来开发解决方案组件和资产。他有超过 12 年的 IT 行业从业经验，主要涉及创建产品体系结构、设计和细化技术策略以及使用分布式技术设计企业应用程序系统。他擅长的领域包括 SOA、Enterprise Service Bus (ESB)、Web 服务、Java™ 2 Platform, Enterprise Edition (J2EE) 和电子商务技术。他与人合著了 SOA Compass 一书，并在 IBM developerWorks and Systems Journal 上发表了一些文章。他目前在宾夕法尼亚州匹兹堡居住和工作，业余时间他喜欢参加哲学讲座、读书、看电影和玩 Sony PlayStation。请访问他的博客：SOA, ESB, and beyond。
Jorge Diaz 是 IBM Software Services for WebSphere 的一位解决方案架构师。他的工作重点是提供中间件和分布式系统集成领域的策略体系结构，负责欧美地区的相关工作。Diaz 先生与各个大客户密切合作，帮助他们使用各种技术（包括 Web 访问）来引入面向服务的体系结构。
Donald Ferguson 是 IBM 的 200,000 技术雇员中的 53 个 IBM Fellow（IBM 最高的技术职位）之一。Don 还是 IBM Software Group 的首席架构师。Don 是 SWG Architecture Board 的主席，该委员会监督 WebSphere、DB2®、Lotus®、Tivoli® 和 Rational® 产品的体系结构和集成。Don 原来曾担任过 WebSphere 系列产品的首席架构师。他于 1985 年加入 IBM Research。他的兴趣爱好包括带他的孩子们、与他们玩耍、分布式系统、简化应用程序开发、系统管理、Web 服务、事务处理、性能以及空手道。请访问他的博客：Middleware and tools。
Chris Ferris 是 IBM 的 Software Standards Strategy Group 的一位资深技术成员。他有超过 25 年的 IT 行业从业经验，其中大部分时间都在参与分布式系统的体系结构、设计和工程方面的工作，并从 1999 年后就开始积极参与 XML 和 Web 服务的开放标准制订工作。Chris 目前是 WS-I Basic Profile Working Group 的主席；该组织负责开发 WS-I Basic Profile。他是 IBM 在 W3C XML Protocols WG 的代表，并在其中担任编辑。他还是 IBM 在 OASIS WS-RX TC 的代表。他曾被推选为 OASIS Technical Advisory Board (TAB) 的成员。此外，他还是 WS-Reliable Messaging 规范和 IBM RAMP 概要的作者和编辑。请访问他的博客Web services, distributed computing, and interoperability。
Kerrie Holley 是 IBM 的 Services Oriented Architecture and Web Services Center of Excellence 的首席技术官。他擅长的领域包括软件工程、体系结构以及将业务要求转换为以网络为中心的分布式解决方案的设计。
杰出工程师 Sridhar Iyengar 负责 IBM Rational Software 开发团队的技术策略。他是 OMG Architecture 委员会和董事会的成员，对模型驱动的体系结构标准的发展进行指导。
Christina Lau 是 On Demand Development 团队的一名架构师。她目前参与的项目包括创建使用 Rational Software Architect 的模式解决方案 和试用业务创新和优化功能。Christina 一位高级技术人员，同时也是IBM Academy of Technology 的成员。她还是Introduction to IBM Rational Application Developer 一书的合著者。
Calvin Lawrence 是 IBM Software Group Emerging Technology 团队的一位执行架构师。他的职责范围包括通过关键策略活动的支持来推广战略 IBM 体系结构、技术和产品，以及使用 IBM 技术确保客户实现成功。他是 IBM Software Group Worldwide Technical Leadership Council 的前主席。
Sridhar Sudarsan 是 IBM Software Services for WebSphere 的一位高级 IT 架构师。他曾负责过全球很多客户的企业体系结构解决方案的工作，包括金融、政府机构、汽车和 SRM 等垂直行业的大公司。他是 J2EE 中的批处理编程模型（该模型现在是 WebSphere XD 中的一个组件）的创建者之一，目前正在向客户推广这个模型，并致力于构建此技术相关的最佳实践。他目前正在负责一家大型保险公司的大型 SOA Center of Excellence 的工作。
Andras Robert Szakal 是 IBM Federal Software Group 的首席架构师，同时也是杰出工程师和高级认证 IT 架构师。他还是The Open Group 理事会成员。
Bobby Woolf 是一名IBM Software Services for WebSphere 咨询师，负责帮助客户使用 WebSphere 实现成功。他与人合著了Enterprise Integration Patterns 和The Design Patterns Smalltalk Companion 。请参阅 developerWorks 上Bobby 的博客，以了解更多信息。
学习
您可以参阅本文在 developerWorks 全球站点上的英文原文 。
了解关于developerWorks 技术事件和网络广播的最新消息。
获得产品和技术
使用IBM 试用软件开发您的下一个项目，可直接从 developerWorks 下载这些试用软件。
从IBM IT 架构工具包系列获得大量体系结构资源，可直接从 developerWorks 下载这些套件。
讨论
参与论坛讨论。
参与developerWorks blogs，从而加入到 developerWorks 社区中来。

 

此内容是由developerWorks 编辑团队为您提供。如有建议或问题，请通过以下邮件地址与编辑团队联系：dwinfo@us.ibm.com。