关于ibm的研究论文

引言：杂家还是博学家？阅读“观点与展望”专栏所有文章第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 回页首放下清高，亲近现实任何方面都能推动架构师的工作：客户、他的团队、体系结构、小故障和各种问题。我认为体系结构更多的是一种态度、完美地建起软件“大厦”的热情，但现实却往往使得这不那么完美。不过，追求完美的想法与现实之间的平衡会让架构师保持一定的清醒态度，因为他必须向客户交付一个正常运行且性能良好的系统。回忆：我看到自己参加会议、在白板上画图、处理一个接一个的问题。在团队的帮助下，我尝试利用过去所积累的知识在问题领域中的各种力量和约束之间求得平衡。模式？或许吧。我喜欢体会团队活力在周围流动的那种感觉——每一分钟，我都能在同事仔细描述各种情况的细枝末叶时获得启发和学到新的东西：为什么这个情况略有不同，因而必须修改模式，以处理实际情况。编写代码的日子：编写代码是孤独的探寻过程。这个探寻过程同时也是永不停止的。有时候还没有回报。找到错误，会得到表扬。如果最终的交付内容/版本中没有错误，则不会提到这些代码中的重要性和您在其中投入的精力！我喜欢编程——不过现在很少进行此类工作了，仅在学术中需要时才会做这样的工作。处理项目时，我已不再进行代码编写工作了。香港，1980 年：我开始使用 BASIC 和 Fortran 进行编程。我非常喜欢编程。转眼到了 1995 年，我开始进行 Java�6�4 编程，享受接口实现和松散耦合所带来的纯粹乐趣。但应该如何设计系统结构呢？即使获得了最好的运行代码，仍然需要一个能够承受非功能需求冲击的结构。因此，您需要能够对各种相互冲突的约束进行权衡，在重复考虑当前情况的细微差异的前提下进行决策。 我比较认可“模式生成体系结构”这样的学术流派。从蓝图（一组基本模式）开始，然后根据自己的实际情况进行扩展和自定义。这就在最佳实践和现实具有特定的无名品质（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�0�3，参与了 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 开始我倒是希望自己对职业生涯以及整个人生都有所计划，但我必须承认并非如此。我女朋友和我曾就自由意志进行过讨论。她认为存在自由。而我认为我们是非常非常复杂的图灵机，完全由输入信息序列定义。因此，我可能不应该来回答这个问题。不过，每个人都知道我将如何回答。我的图灵机进入了一个状态，迫使我自然而无休止地钻研任意主题。我上大学前没有见过计算机（准确地说是大二才首次看到计算机）。是的，我有些落后。实际上，我都是在那之后很久才首次看见计算机的。我在大二时见到了计算机终端。我当时学习了 FORTRAN，才发现以下事实：我真的很喜欢编写程序。我真的很擅长编程。无论如何，我现在并不确定自己是否仍然对此很擅长。我仍然喜欢我工作的技术方面的东西：调整代码、编写小段 PHP、讨论一些设计选择、考虑重要的下一步工作。我定期到现场视察，花上一整天时间对项目进行检查，并与项目人员进行讨论。现场人员说，尽管会受时差的影响而且每天工作时间很长，我似乎从来不觉得累。他们想知道我是如何做到的。这样的日子是我工作中最有意思的日子，我非常喜欢。我对它们的喜爱程度超过了对咖啡的喜爱。 正是这个原因让我觉得 IT 是我的正确选择。那么，我走过的路是什么样的呢？我不断地探索新问题（现在也是如此）。我所走过的路似乎是最具挑战，也是最有趣的。回页首基于广泛 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

下面是一些相关的素材资料，您整合一下，理清论文的结构，再加上自己的观点，差不多就可以了。希望对您有所帮助！竞争对抗：企业创新的新原则许多公司都忽略了卓有成效的竞争对创新的刺激作用，这可能是一大损失——竞争对抗是创新的强力促成因素。如今，如果研发团队还没有引入竞争对抗机制，那么那些具有创新意识的高管应该去寻求更多机会组建团队、赞赏不同团队提出的不同工作方式间的差异区别，并进行市场测试。通常，竞争对抗可能意味着完全彻底的较量。在这种比赛中，两个人或两个团队针锋相对，其中一个人或一个团队会胜出，而代价是另一方的失败。但是在文艺复兴时期，竞争对抗则有第二种含义，我们称之为“帕拉贡”。它指的是将两位艺术家或其作品，并排放在一起，进行评价、比较和鉴赏，并不会褒奖一方而贬低另一方。实际上，有时也会委托多位艺术家，同时实施相类似的项目，每一方都利用自己独特的才华，来表现一个主题。“帕拉贡”哲学的一个有机组成部分是，相信这种直接比较将激发艺术家提高各自的技艺。不过目前，鲜有企业在自己的研发实验室中利用类似“帕拉贡”的方法。当然，也有些企业举行创新竞赛，比如塔塔集团最近的Innovista挑战，该活动在公司中产生了1700个新创意。但是，这些一次性的竞赛并不能真正复制文艺复兴时期那种充满创造力、极富成果的艺术竞争对抗。此外，有关创新的商业文献中一般也不鼓励竞争。管理专家们更愿意谈论研发中心内部的合作与协作，而不是竞争和对抗。但实施现代版“帕拉贡”的最佳方法则是让两个或多个团队同时开展相同的项目，这种竞争对抗未必一定就排除协作。我们相信，研发管理人员将能够使二者在更深层次相互结合，它应该成为更多企业日常研发流程的一部分。这似乎代价高昂，但安排多个团队处理相同的问题，如果能够产生更好的解决方案，广泛但有节制地利用竞争，并不一定就是低效果或低效率的。对于有兴趣利用“帕拉贡”威力的高管，应该遵循三条原则：组建团队。竞争的团队应该来自于不同的部门，包括多种专家，采用明显不同的方法处理相同的问题。毕竟，经常会有多种方法可以用来解决研发难题（有时还是出自不同的学科），如果不进行试验，我们常常无法知道哪种方法最佳。此外，各团队都有自己的偏好和在范围较窄领域内的专长，这使得明确地采用各种不同的方法变得更为重要。欣赏差异。在文艺复兴时期，绘画作品被并排摆放，使观赏者能够进行比较和欣赏，其他艺术家可以从中借鉴。采用同样的办法，我们可以将各个团队开发的各种不同的解决方案放在一起，比较它们之间的优缺点。在许多情况下，一方可以吸收来自于另一方的思想理念。或者可以将最终被淘汰的解决方案送回实验室，沿着新的方向再次进行开发。进行“市场测试”。复制“帕拉贡”实践的另一种方法是把产品设计提供给内部评判团或一组客户，让他们对不同的解决方案进行比较权衡。就像文艺复兴时期每个艺术家都有自己的追随者一样，在有些情况下，我们可能会发现，能赢得客户欢心的产品不只一种。无论采用何种评判机制，我们有理由相信，让两支或更多的团队同时攻关某一特定项目，能够产生更强的激励作用，从而提高创新水平。只要对这种竞争对抗精神进行有效的管理，让研发团队知道其方案最终会与其他的方案一较短长，他们将会更加努力地工作。同时，我们对于竞争对抗带来的挑战应持现实主义的态度。即使在文艺复兴时期，某些竞争对手也会失控，有时甚至会导致决斗、监禁和谋杀。管理不佳的竞争对抗可能会发展成研发管理人员千方百计避免的破坏性竞争，会抑制思想交流，并妨碍协作。只有强有力的管理应该能够确保竞争不会导致苦果，加剧不和。最为重要的是，企业在实施“帕拉贡”时，必须辅以广泛而深入的通过合作共同取得成就的企业文化，利用富有成效的竞争对抗所产生的创新活力，使企业产生更多更具价值的创新成果。宝洁和IBM的开放式创新企业的上下游客户、消费者、甚至是不相关的外部力量都可能成为智慧的支持，成为企业创新的源泉。从传统的“封闭式创新”转向互联网时代的“开放式创新”，越来越多的跨国企业在寻找新的发展模式。本期所关注的两个案例，无论是宝洁通过“C＋D”（联发）模式在网上公布创新需求清单，还是IBM通过“InnovationJam”（即兴创新大讨论）筛选新商业计划，都表明了他们是“开放式创新”的抢先获利者。两巨头的这一创新实践，无疑对国内企业界具有较大的借鉴价值。通过“C+D”（联发）模式在网上公布创新需求清单，宝洁从研发向“联发”演进宝洁，推倒实验室的围墙唇彩看似简单，但如何能让唇彩持久闪亮？却是个困扰了宝洁许久的问题。至今，宝洁依然没有能找到解决的办法。于是，宝洁向外界发出了求助信息：现今的唇彩一般一次只能持续1~2个小时的闪亮，若要实现4小时以上的闪亮，需要某种新的材料或工艺。而新型材料或技术应能够满足以下标准：长时间持久闪亮（光亮保持力）；不影响感觉（感觉、水分、涂抹能力）；便于涂抹。在宝洁“联系＋发展”（Connect + Develop，以下简称C＋D）的中文网站上，类似的求助信息已有上百条。“现在，宝洁50％以上的创新都来自于外部力量”，宝洁大中华区“联系与发展”部门经理金浩芳博士说，宝洁将这种方式称为“开放式创新”，而C＋D网站就是其中的一个实现路径，这一网站的中文版已于2009年3月26日正式开通。事实上，对于宝洁来说，从传统意义上的产品“研发”走向借助外部力量的“联发”，正是刚刚卸任的宝洁CEO雷富礼试图打破企业围墙的一大尝试，而宝洁也希望能借助互联网凝聚社会的智慧，通过“开放式创新”来打破大公司的创新困境。从“研发”转向“联发”1997年，金浩芳加入宝洁。之后的两年，她在亲身体验宝洁研发实力的同时，也隐隐感觉到：公司在创新方面还有很大的提升空间，因为内部有大量的研发成果还没有转化为上市产品，许多专利尚有待充分利用，研发潜力也没有被充分发掘出来。就在这一期间，哈佛商学院教授克莱曼克里斯坦森的著作《创新者的困境》出版。克里斯坦森认为，越是成熟的大企业，越容易被新进入市场的小企业逼上绝路，并最终陷入困境。这一观点令金浩芳产生了些许担忧，许多宝洁员工也与金浩芳有着同样感受，但是却找不到解决问题的办法。直到2000年，雷富礼被任命为宝洁公司新的CEO，而此时的宝洁正深陷困境。雷富礼上任后，第一件事就是大刀阔斧地整顿宝洁的研发部门。摆在雷富礼面前的是一道难题：要么重整研发部门，让宝洁拥有旺盛的创造力；要么削减研发成本。在公司的其他高管看来，这是一个二选一的问题。但雷富礼却认为，可以做到二者兼而有之。于是，他提出了“开放式创新”的概念，将宝洁的心脏——研发（Research＆Develop）改名为联发 （Connect Develop），即打开公司围墙，联合外部松散的非宝洁员工组成群体智慧，按照消费者的需求进行有目的的创新，然后再通过技术信息平台，让各项创新提案在全球范围内得到最优的配置。在雷富礼眼中，宝洁公司不只是拥有9000多名研发人员，他把散落在世界各地的大约180万名研发人员也看做自己的员工，如此一来，宝洁就拥有了万名研发人员。“企业外部也许恰好有人知道如何解决你的企业所面临的特殊问题，或者能够比你更好地把握现在你面临的机遇。你必须找到他们，找到一种和他们合作的机会。”雷富礼说。当时，他制定的目标是到2010年引入50%以上的外部创新，但是在2006年时，就已经实现了既定目标;并且，“由于从外部引入了更多的高端产品和技术思想，宝洁公司的研发成功率提高了85%。”金浩芳说。搭建创新资产集市在“C＋D”理念下，宝洁需要解决的第一个问题是：如何将自己的需求告知散布在世界各地的研发人员？起初，宝洁找到一家类似于创意集市的网站，在上面发布寻找解决办法的信息，之后就可以得到回应。虽然这已经令宝洁获得了许多外部的创新方案，但宝洁同时也发现：这种方法存在一些缺陷。由于只是宝洁单项的、订单式的沟通，外部潜在的合作伙伴如果想跟拥有庞大组织结构的宝洁沟通，通路并不顺畅。例如，外部的研发人员如果拥有一项美白面膜的专利配方，既想让这款面膜投入市场，但又苦于没有资金，并且不愿花太多精力在经营品牌或生意上，那他应该怎么办呢？他又如何跟宝洁沟通呢？为此，宝洁在2007年自己建立了“C+D”英文网站，这实际上相当于宝洁的创新资产集市。在这里，你可以浏览宝洁的需求及创新成果。若手上的创新成果刚好符合宝洁的需求，便可以根据提示提交方案，并在8周内获得回复。在未收到回复前，你可以随时登陆系统查询方案审核情况。这种模式推出后，得到了积极响应，网站在上线后一年半，就收到了来自全球各地的3700多个创新方案。然而，这些方案大多来自英语国家。这时，宝洁又发现，语言成为很多创新资产所有者参与“C＋D”的障碍。于是，在2009年3月26日，“C＋D”中文网站正式启动。“3个月后，注册访问量已经超过2万，有效的创新方案达到了129个，其中不乏有望与宝洁达成合作的创新方案。”金浩芳说，她觉得自己的部门就像一个“创新猎头”团队，每一天，都会对创新方案进行筛选，并在承诺的时间内回复。而对那些满足要求的创新方案，再安排专业人员进行审核，并在遴选通过后与提交者确定合作细节。中科院昆明动植物所的刘存宝，就是宝洁这一创新活动的参与者之一。如今，他已养成经常上“C＋D”网站的习惯，“看看宝洁又有什么最新需求，有了这个网站，庞大的宝洁变得不再遥不可及，随时随地都可以向宝洁展示自己的才华。”刘存宝表示，他的团队通过仿生学的创新，从两栖类动物中分离了100个以上生物多肽，并证实这些生物多肽是再好不过的具有抗微生物和抗氧化功能的天然材料，从而获得了宝洁2009年微生物技术创新大赛的金奖。金浩芳用了一组数字来描述“开放式创新”给宝洁带来的利益：从2004年到2008年，公司的研发投入不断增加，而这些投入占销售额比例反而从降低到。除了征求创新方案外，宝洁也会在这个网站上出售自己的专利，这同样也是雷富礼的创意。雷富礼在上世纪90年代末宝洁的一次内部调查中发现，公司投入了15亿美元研发资金，研制出了约万项专利，但其中只有10%用在了企业的产品上。于是，雷富礼决定把那些宝洁用不到的好点子放到“创意集市”，让它们在合适的地方实现价值，同时也能为宝洁带来可见的获利。“如果你正在寻找获得许可使用宝洁的商标、技术等其他创新资产的机会，登录这个网站，很可能就会找到和宝洁合作的商机，将共同的生意做到世界各地。”金浩芳说。“C＋D”模式下的全球协作金浩芳还通过一个故事更形象地讲述了宝洁的开放式创新。2005年，远在美国的宝洁研发人员正在为纺必适（宝洁旗下品牌）品牌下的一款新产品的设计开动脑筋。由于重视环保，研发人员不打算选用传统的塑料作为容器材料，而是倾向于使用竹木等自然材质。但是，竹制品的研发和生产制造并不是宝洁的强项。本着“C＋D”的理念，宝洁开始到处寻觅竹木加工的解决方案和制造商，但这一过程并不像想象的那么简单。很关键的原因有三，一是竹制产品含水率问题较难解决，易受原材料及加工存储环境的影响等；二是竹材料纯天然，纹理各异，外加手工制造，产品精度很难控制；三是宝洁对器具误差的要求是毫米，比普通一张纸的厚度还薄。并且，宝洁要求的量往往是几百万件，这种大规模生产对于往往是小作坊式手工制造的竹制品企业来说是很大的挑战。寻觅两年，宝洁始终没有找到能解决上述问题的合作伙伴。很快，这一问题上升到需要全球协作的高度。2007年4月，宝洁广州办公室的一位员工通过阿里巴巴找到了远在浙江仙居县的味老大。不过，在中国竹制工艺品行业，产品精度的误差平均是3毫米左右。味老大的几万件批量的出厂标准是误差1到2毫米，这已经非常难得。但是，宝洁的要求是毫米以下，显然还存在一定的差距。最终，在宝洁与味老大的多次磨合后，味老大的工艺达到了宝洁的要求。这显然是一个双赢的局面。现在，许多这样的故事正在宝洁上演。通过“InnovationJam”（即兴创新大讨论）筛选可执行的新商业计划IBM，开个创新Party当IBM公司宣布他们的知识产权为公司创造了10亿美元的许可证收入后，拥有万项专利的宝洁公司也不禁眼睛一亮。据说，宝洁前CEO雷富礼关于“联发”的构想，就是直接来自于IBM的启发。其实IBM不仅将自己的专利授权给合作伙伴和客户，也从外部获得了新的知识和智慧。据IBM全球企业咨询部运营战略首席顾问白立新介绍，IBM采用的方式是两年一次的InnovationJam（即兴创新大讨论）。在头三天的时间里，针对设定好的议题展开在线头脑风暴讨论会。这些创意点子，在网络上，如接龙般不断被讨论、延伸，完全不需要休息时间，因为当美国进入黑夜时，亚洲已经准备迎接白天。白立新说，在2008年10月份的InnovationJam上，有万名IBM员工参加，还有5000名特别邀请的客户和员工家属参加，以共同寻求新的创意和解决方案。白立新认为，这时的效率和产出是最高的，由于员工家属以及合作伙伴来自于不同的领域，更容易产生各种设想，从而在相互碰撞中激起脑海的创造性风暴。比如对于交通，IBM的业务合作伙伴北京富通提出的一个点子是：将全球物理定位系统安装在汽车和手机上，由此可以远程遥控引导对路线不熟悉的人轻松地达到目的地。而神州数码则认为，当交通发展到高级阶段的时候，应该开发自动驾驶技术，就像飞机一样，能在高空进行无人驾驶巡航……可以想象，5万人的在线讨论，这将是一个何等“混乱”的状态。白立新表示，创意风暴虽然是“无序”的，但同样也需要有纪律的程序。于是，IBM设置了比较严谨的管理机制。IBM大中华区首席技术总裁叶天正曾在“Jam坛子”的卷首中写道：有必要强调一下InnovationJam和普通博客、BBS之间的区别。“InnovationJam讨论和探究如何将IBM的新技术、工具和行业预见能力（许多是首次公开发布）与当今社会的前沿洞察和研究相结合，来创造新的市场机会和商业合作契机。因此，Jam内讨论的观点必须和设定的话题有关，而且是没有实现的，必须是具体的、非感性的。”同时，这三天中，每天IBM全球总部都会挑出几个最好的点子，放在醒目的位置，鼓励大家再继续延伸。而每项重大主题的讨论区，都会请副总裁以上级别的高管担当主持人，负责让讨论不发散，并随时抛出新话题，引导大家谈得更深。白立新说，对于英文不太流利的参与者，也没有任何障碍。因为专门有一组人，负责浏览英文之外的语言，当他们看到用当地语言发表的不错意见时，就会翻译成英文，附在原发言的下方。前三天,活动结束后，IBM的专家小组会接手讨论结果，从中挑选出那些讨论数最多的创新方案，把一些已经被商业化，或离现有技术太远的想法都剔除掉。然而进入InnovationJam的第二阶段，这次的讨论更聚焦于可行性分析。最后，从中选出10个最优想法，IBM则投资1亿美元支撑这10个想法的执行，而这10个想法也正是IBM未来要发展的10项新商业计划，比如智能医疗支付系统、智能基础设施网络、整合 大众交通(行情 股吧)信息系统、数字化的我、3D互联网等，其中有的计划已经融入到IBM目前大力提倡的战略理念——“智慧的地球”中了。我国企业管理创新案例及其评述摘要