什么是最有价值的IT体系结构技能,如何学习?

日期: 2008-12-02 作者:Ali ArsanjaniBobby WoolfChristina Lau 来源:TechTarget中国 英文

  IBM专家将提供各自的个人观点,以推动IT体系结构实践方面的发展,从而帮助您更好地担当架构师这一职责。

  引言:IT体系结构不像电视节目

  我希望能有电视节目展示IT架构师的生活。但您知道在电视上的样子。人们都很了不起,通常长得很好看,手边有所有需要的东西,他们都异常的聪明——而且所有部分都非常轻易地就整合到一起了。您可能看着这样的节目,而忘记了他们的实际工作有多困难。暂时逃避一下现实。而且,每周您都有机会假装这就是真实的生活。

  我们都知道,和生活一样,IT体系结构并不是这样的。(真是的,撰写这个专栏甚至也不那样简单,只是纯粹说说才很简单。)需要进行培训,需要努力工作,需要使用技能技巧,会犯很多错误,而且需要很多的耐心。当然,说需要一定天分也未尝不可。

  知道了成为一个成功的IT架构师需要投入多少工作后,我们就想知道哪些因素对成为一个不错的架构师起决定性作用。因此,我们向专家组提出了这样的问题:“什么技能对IT架构师最有价值,架构师如何学习这些技能?”

  可以在很多地方找到成为好的架构师所需的技能列表——书上、培训课程、大学、有关体系结构的其他网站上等等。例如,IBM的内部专业提高网站就提出以下几点IT架构师的理想特征:

  ·设计体系结构的技能和经验
  ·有序的以方法为驱动源的任务执行
  ·完整生命周期经验
  ·行业部门经验
  ·领导能力
  ·很强的沟通和专业技能

  和可能看到的很多其他列表类似,这个列表相当泛泛,可能并不如您所期望的那样有可操作性。而这正是我们询问前面的问题的原因所在:帮助您确定一个明确的方向。

  我们希望对此问题的讨论能为您提供帮助。我们鼓励您在IT体系结构讨论论坛发表您对这些观点的看法。如果您有任何问题希望我们的专家进行答复,请与我联系。充分利用专家资源——他们非常乐意为您提供帮助,非常愿意能推动IT体系结构方面的实践。

  另,为了避免对我们的排序方式的意见,我们已根据专家的名字按字母顺序对专栏进行了排序。不过,请一定阅读全文;您肯定不希望漏掉Walker Royce的连珠妙语。

  权衡各个相互冲突的需求

  架构师必须学习权衡各个相互冲突的需求的技能。在调和体系结构的各个组成部分时,我们必须对各个看起来截然相反的事项进行权衡,如下面这些事项:

  ·”“我需要一个全新的体系结构来支持一个新业务需求;所有项目必须在2年内完成,而我们希望您能在1年内完成下一个项目。””
  ·”资金有限,但我们希望能提供所有功能。”
  ·分析瘫痪与“直接编码”
  ·灵活方法与复杂方法
  ·用户期望与技术可实际提供的功能
  ·业务与IT
  ·您的工作负担和享受生活
  ·管理活动(时间计划、支出)与“真正的”项目工作

  无论从技术角度出发,还是就业务角度而言,我们都需要对经常冲突的各种考虑和各个侧面进行权衡。在看起来似乎无法解决的情况下进行正确的权衡是架构师成功的关键。

  这经常意味着要首先确定有哪些约束,理解这些约束为何存在冲突,并确定如何在问题空间对这些考虑进行权衡,从而解决所面临的问题。

  了解各个相关部分以及它们彼此如何结合

  我还记得我第一次感觉像个架构师时的情况。他们要求我开发一个新的应用程序,突然我发现这个应用程序并不是一个单体,而是由多个专门化的部分组成的,其中的每个部分都在专门的服务器上运行,所有部分一起协作,形成一个应用程序。数据由数据库服务器承载和提供,长时间运行的流程在工作流服务器中执行,遗留集成会通过消息传递服务器进行操作,而自定义代码在应用服务器上运行,负责将所有这些部分粘合到一起。

  这就是体系结构:专门化的彼此不同的部分一起协作,形成完整的应用程序。IT架构师知道如何将问题划分为专门化的各个部分,并使其作为整体一起协同工作。

  那么,什么是对IT架构师最具价值的技能呢?就是要了解这些不同类型的服务器以及其提供来帮助解决问题的不同功能,并要了解如何将它们一起使用来开发和部署应用程序。成为一个引擎方面的专家也非常诱人,如数据架构设计人员、规则专家、J2EE开发人员。团队也需要这样的人员,但他们不是架构师。IT架构师至少对所有这些方法都有所了解,了解哪个引擎适合用于执行应用程序中的何种任务,知道如何将应用程序分解成各个专门化的部分以及如何使这些部分一起工作。

  实际上,这是IT软件架构师。真正的IT架构师不仅需要了解软件,也要了解以下内容——甚至可能还要包括其他方面的东西:

  ·硬件:服务器计算机、网络路由器、延迟、防火墙、操作系统等等
  ·安全性:标识管理、访问控制、保密性、认可等等
  ·资源规划:内存使用、带宽、负载、负载平衡、故障转移、高可用性等等

  需要学习很多内容,但软件方面无疑可以作为一个很好的起点开始学习。

  如何学习这些技能呢?您需要逐个学习各个部分,并学习如何将其作为整体结合使用。首先要学习如何实现各个部分,如何使用每种类型的引擎。不知道工作流到底是什么?获取WebSphere Integration Developer并实现HelloWorld业务流程执行语言(Business Process Execution Language,BPEL)流程。不了解消息传递?阅读developerWorks上介绍如何使用服务集成总线的简单示例的文章。学习了每种服务器的细节知识后,请将这些细节放在一边,而将精力放在每种引擎所能完成的任务的全局状况上。消息传递、规则、工作流、数据和自定义代码——这些都彼此不同,但差异在哪里呢?了解了这一点后,您将能够把应用程序划分为多个部分,从而利用每种引擎的独特功能。

  此时您就成为了一名IT架构师。

  快速学习

  您所应具有的唯一最有价值的技能?

  快速学习新事物的能力。这一点适用于我们这个不断发展的行业的很多角色,而不仅是IT架构师。

  那么,如何学习这个技能呢?

  我是在读大学时学到这项技能的。从那以后,我们忘记了在那里学习过的很多东西,包括Lisp、微分方程等。但我保留了快速学习这一技能。

  沟通和推动力

  无论何时问我IT架构师的工作是怎样的——这个问题与他们的最重要技能直接相关——我都会将其与建筑设计师相比较。IT架构师处在客户(CEO、LOB执行人员)和构建人员(IT开发/交付),能够向客户说明技术可能性和向构建人员说明客户的需求。这意味着IT架构师必须能够在这两个领域进行清楚的表述、说明,并在这两方面都提出中肯的意见。

  显然,对这个职位而言,沟通和推动力是其关键的技能。IT架构师使用他们的经验和直观推断来将暂时的定义欠佳的问题空间简化为能够构建和交付的内容,并同时始终以客户的需求为工作的核心。

  沟通和倾听

  毫无疑问:沟通的能力。成功的架构师必须能够清楚、明了、简洁地对体系结构决策进行描述、演绎和申辩。高效的架构师还必须能够使用各种媒体(包括代码、模型、文档、PowerPoint演示文档以及谈话和讲座)与各方面的技术和非技术干系人进行沟通——包括代码编写人员和其他开发人员,甚至最终用户、会计师和行政官员。另外,真正高效的架构师不仅善于表述概念,同时也是相当出色的听众,能够按照预期计划完成讨论任务。

  如何学习这项技能?练习,练习,再练习。

  进行连接

  在我看来,IT架构师所具有的最有价值的技能是将各个部分连接起来的能力。为了将分散或看起来不相关的组件(问题)联系起来,以形成一个完整的系统。可以从完整的系统派生出在实效和策略方面都有意义且可行的解决办法。

  这就是将架构师与专业人员区分开的一项技能:通过全局性的视图,可以更全面地看待整个系统并了解其他一些注意事项,从而帮助您确定哪些是重要内容,哪些是干扰信息。此技能也能在不同角色身上和不同情况下发挥作用,不受技术、行业和职务级别的影响。具有这种能力的技术架构师可以帮助在业务和技术之间建立联系。

  如何获得此技能:体验学习。接触架构师工作的解决方案的子项目或子组件,不断询问自己这些问题:“为什么这个重要?”和“我的这一部分解决方案与什么相关?”尝试了解各个部分如何形成更大的完整程序。从外向内了解各个部分。

  一种称为思维导图的创造性思考技术异常有帮助。——Jenny Choy
 
  如何学习此技能:我发现,对于尝试学习和进行全局思维实践的人来说,一种称为思维导图的创造性思考技术异常有用。(思维导图是由Tony Buzan于20世纪60年代末提出的,用以帮助人们开发大脑潜能。)这项技术可帮助您捕获和组织各个想法(或组件),能在单页中体现各个组件的多层次分解和组件的相关关系。由于与某个主题相关的所有内容的全貌都呈现在单个页面上,这就训练大脑在相关上下文中看待所有事项,并允许对有兴趣的主体进行进一步分解,且同时保持对全局情况的了解。

  对可能遇到的问题进行预先估计

  我认为IT架构师必须具有的最重要技能是能够对在复杂环境中口可能出现的性能和吞吐问题进行事先估计,并进行恰当的决策来避免这些问题。这项技能与了解此类问题的分类、诊断根源和进行相应决策来解决这些问题的能力直接相关。只有一个真正的老师:实际处理具有代表性的各个实际(即“生产”)系统的各种问题。我不认为只具有应用程序开发经验而没有实际操作经验的人具有成为高效的架构师所需的经验。

  很多工程方面的造诣依赖于理解和分析故障以了解根源的实践。而这个技能正是我所要讨论的技能——系统地对故障和性能问题进行分析,然后对问题进行细化,以确定根源。IT架构师首先需要能够对潜在的吞吐问题进行预先估计,并设计恰当的解决方案来防止发生此类问题。

  基本学习:学习如何进行学习

  我希望能给出一个更为简单的问题,但为了成为成功的架构师,您需要具有出色的基本学习 技能。我对基本学习的定义是,学习如何高效地进行学习。目前,成功的架构师需要具有大量的技能,要不断地对旧技能进行更新并能快速地掌握新技能。如果不能获得和应用新技能,将可能缩短架构师的职业生涯。但出色的基本学习技能将为架构师提供不断扩展的灵活技能库——可根据需要进行灵活调整。这就让架构师能够完成其工作的复杂要求,非常专业地处理各个方面,如:

  理解和列出各个问题/解决方案的相关事项
  分析新场景和复杂场景

  ·分析和确定解决方案要求的范围
  ·对解决方案元素进行可视化和概念化工作
  ·对解决方案模型和模式进行合成
  ·应用(学习)各种新技术和最佳实践
  ·评估和区分解决方案概念/设计/提案
  ·研究备选选项
  ·与业务和技术干系人进行有效沟通

  除了通过固有的基本学习能力外,还可以通过一些其他方式来获得此技能:

  ·良好的学校教育,特别是大学阶段的教育,在此阶段的课程涉及范围非常广泛,课程的密集型较强,同学之间的竞争也较为激烈。我在Mumbai的IIT (Indian Institute of Technology) 进行大学本科的学习期间学习的很多精华课程的细节都已经遗忘了,但这段经历提升了我的出色的基本学习技能。那些考试前的十一个小时的填鸭式学习也对此有所贡献。

  ·通过多年担任各种角色和承担各种职责积累的专业经验和实践。在进行工作时,总是尝试进入对自己有所挑战的区域。这些区域将提升和加强您的基本学习技能。我最初是在一家《财富》10强金融机构(非常诱人!)担任分析师,随后从事了多年的技术咨询工作(从芯片设计、内核/OS编程到UI框架等多个领域)。然后,我加入了一家刚刚创立的公司,在其中帮助定义产品体系结构。(在这种新创建的公司里可以真正学到如何担当多面手!)现在我已在IBM担任过多个具有独特挑战的角色。
 
  深入研究,同时眼观全局

  我认为架构师所需的最重要技能是能够深入钻研可能会带来较大好处的特定技术问题,并同时能够考虑到更大的组织目标和体系结构。

  例如,在分析Web应用程序的性能时,如果所耗的大部分时间(如90%)都花在数据库服务器上的密集型数据库搜索、查询和数据聚合上了,则通过调整Web表示层的算法并不会带来太多改善。关键是能够处理查询性能问题(如果您是专家)或找到能够及时解决问题的专家。进行此类推理要求具有分析技能,能考虑更大范围内的情况和进行恰当的折衷,并同时对特定技术领域进行深入分析。

  那么如何学习这项技能呢?通过实际接触多个项目、向同事学习以及了解和利用体系结构模式和最佳实践。

  合成正确的解决方案

  一个好的架构师能够合成正确的解决方案(或判断候选解决方案或现有解决方案的宏观质量),却无需了解实现的所有精确细节。

  有能力的架构师是天生的,而不是培训出来的。有潜质的人可以进行培养,但如果您天生就不能领悟多维的“美丽”,您可以永远也学不会。因此,一个更好的问题是,如何能确定那些天生就具有架构师能力的人并培养他们的相关技能呢?

  这方面我也不确定。

  关于专家

  Ali Arsanjani

  Ali Arsanjani博士是IBM Global Services的SOA and Web Services Center of Excellence的首席架构师,主要负责收集和制定SOA和Web服务的建模、分析、设计和实现方面的最佳实践。他是内部的IBM全球SOA and Web Services Community of Practice(拥有4,000名成员)的负责人,是SOA的面向服务的建模和体系结构(Service-Oriented Modeling and Architecture,SOMA)方法的主要作者之一。他目前的工作重点是支持建模(SOMA)、评估、策略与计划、管理、体系结构和实现的SOA工具,以及其在IBM内部和外部的实际应用。

  Bobby Woolf

  Bobby Woolf是一名IBM Software Services for WebSphere咨询师,负责帮助客户使用WebSphere实现成功。他与人合著了Enterprise Integration Patterns和The Design Patterns Smalltalk Companion。

  Christina Lau

  Christina Lau是On Demand Development团队的一名架构师。她目前参与的项目包括创建Pattern Solutions using Rational Software Architect和试用业务创新和优化功能。Christina一位高级技术人员,同时也是IBM Academy of Technology的成员。她还是新书《Introduction to IBM Rational Application Developer》的合著者。

  David K. Jackson

  David K. Jackson是IBM Americas Software Sales的一位咨询IT架构师,是常驻New York Technical Exploration Center的IT架构师。同时,他还是Open Group Architecture Forum的副主席。The Open Group是一个IT行业标准组织,是X-open和Open Software Foundation合并而成的。The Open Group Architecture Forum已制定并发布了唯一的行业标准企业体系结构开发方法。The Open Group还于2005年建立了一个IT架构师认证计划,对IT行业中的IT架构师的含义进行了定义。

  Grady Booch

  Grady是IBM Fellow,曾参与过全球几乎能想象得到的所有领域的很多复杂的以软件为中心的系统,在其中担任架构师或体系结构顾问。Grady编写过六本畅销书,发表了数百篇关于软件工程的文章,其中包括在上个世纪80年代早期发布的数篇论文,后来从这些论文中发展出来了面向对象的设计的术语和实践。

  Jenny Choy

  IBM杰出工程师Jenny Choy是IBM Canada Ltd的Business Consulting Services内Application Services的Transformation Engineering负责人。她同时也是IBM Academy of Technology的成员和认证IT架构师。

  Kurt Bittner

  Kurt Bittner从事IBM Rational软件的产品策略工作。他23年来一直在从事帮助各个团队更好地开发软件方面的工作。他曾是早期Rational Unified Process(RUP)开发团队的一员,负责过很多行业的开发团队的工作。不进行软件开发工作时,他喜欢的休闲活动是攀爬冰瀑。Kurt和Ian Spence合作编写了Use Case Modeling(Addison-Wesley,2003年)和Managing Iterative Software Development(Addison-Wesley,2006年即将出版)。

  Sanjay Bose

  Sanjay Bose供职于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。

  Sridhar Iyengar

  杰出工程师Sridhar Iyengar负责IBM Rational Software开发团队的技术策略。他是OMG Architecture委员会和董事会的成员,对模型驱动的体系结构标准的发展进行指导。

  Walker Royce

  Walker Royce是Rational Software团队的老牌成员,目前担任IBM Software Services Rational的副总裁。他是《Software Project Management, A Unified Framework》(Addison Wesley Longman,1998年)的作者,同时也是Rational Unified Process中继承的管理理念的主要倡导者。在加入Rational前,Walker在TRW Electronics and Defense从事了16年软件开发工作,并获得了Chairman’s Award for Innovation。

我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。

我原创,你原创,我们的内容世界才会更加精彩!

【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】

微信公众号

TechTarget微信公众号二维码

TechTarget

官方微博

TechTarget中国官方微博二维码

TechTarget中国

相关推荐

  • 协作对敏捷方法的重要性

    协作的意思说是一起工作,而不是单独去完成某项任务。敏捷方法强调了与跨功能团队合作的好处,大大加强了业务负责人之间的沟通。

  • 业务软件制胜法宝:协作

    通过敏捷流程,许多团队都能非常好的交付运行中的软件。通常,交付周期非常紧迫的情况下,开发团队在没有周全地考虑业务需求和用户需求就会开始进行编码。

  • 检阅云计算工具

    虽然市场上有着数以百计的云计算解决方案供应商,但是作为用户的我们应当如何雾里看花找到真正满足我们需求的云计算产品与供应商?对云计算供应商进行分类对于更好地了解诸如应用程序迁移、自动化与监控等关键领域的领先厂商似乎并无裨益。

  • 云计算应用程序管理的任务清单

    把应用程序迁往云计算并不是最后的大功告成。有时候会发生一些迫使你不得不重新设计应用程序的突发事件,合规性需求可能会带来发展障碍,而如果你的云计算供应商不支持诸如组播的低层次网络服务,那么就可能带来带宽问题。