对于每一个软件开发人员,架构师都是一个令人向往的角色,它是能力与高薪的代名词。就连软件行业的传奇比尔盖茨在2000年卸任公司CEO时,也担任了微软公司的荣誉角色“首席软件架构师”,可见“架构师”这一称谓的吸引力。
而架构师也绝非简单写写代码就能当上的,它需要从业经验的积累和技术知识的融会。架构师成为目前很多软件企业急需的人才,特别是对一些大型软件产品和项目的开发,这一角色显得更为关键。
由于缺乏好的软件架构师导致项目失败的例子不胜枚举。如何才能成为一名合格的、进而成为一名优秀的软件架构师呢?借SOA标准研讨会之机采访了 Tibco资深架构师林伟炎先生,请他谈谈对于软件架构和软件架构师的认识,谈谈什么才是一个成功的架构,如何避免一个失败的架构,以及真正的软件架构师 是怎样炼成的。
: 首先请您介绍一下自己,您的经历、专长、目前的研究领域。
林伟炎:我在IT行业已经有十多年的经验。从程序员,系统分析,开发组长,到架构师,享受过软件开发的甜酸苦辣(哈!还是甜的比较多)。作为顾问的角色帮 助客户进行系统架构也已经有超过七年的时间。不能算是专长吧,只是近两年接触的项目都与SOA有关,对于SOA,尤其是治理的领域总算有些体会。
:因为架构师职业的特殊性,他需要与用户、业务人员、技术人员等多方交流,因此沟通能力是重要且必须的。但是对于大多数程序员来说,他们似乎更擅长与机器对话,而不是与人交流。您如何看待这个难题呢?
林伟炎:事实上,刚开始的时候,我是很怕作顾问的,因为常常都要接触新的客户,新的问题,新的挑战。但时间久了,就开始领略作顾问的好处。那就是可以多听,多看,多接触,不断丰富自己的经验。
:作为一名资深架构师,请谈谈您对架构的认识。
林伟炎:架构这个词这几年可能用得比较滥。好像什么都是架构。我们常听到的有电脑架构(硬件),应用架构,集成架构,企业信息架构等。因此,要为架构下一 个定义可能很难,但也许并没有必要。大部分的人说架构的时候,他们都是指向整体的设计方向,部件之间的关系,信息在部件间的流动等,都是考虑整体性,追求 一致性,方向与原则。然而,这一切的背后,最重要的还是你的架构到底要解决什么样的问题。
我亲眼看过很多架构师他们规划架构的时候,只是把业界最炫耀的东西放在一起。比如说现在流行Web Service,就干脆什么都用Web Service来连接吧。什么?Web Service不支持事务吗?那就不要事务吧。Web Service传送效率低吗?那就要用户多等一会吧!这样做就是本末倒置,所有架构背后的真义,就是要解决用户的问题。在企业的环境里面,这就是解决业务 的问题。要选择、设计一个架构的时候,这个是唯一要紧的问题。
:那么您认为一个成功的架构应该具有哪些特征呢?要如何避免一个失败的架构呢?
林伟炎:在过去几十年间,市场上出现了很多不同的架构,其中SOA是最炙手可热的。将IT基础设施应用到混乱的真实世界向来都是非常有挑战性的,讲求未来 概念的架构似乎更难以掌握。因此,我认为成功的架构,应该能够让企业快速回应现实世界,能够应付意料之外的事件,也可以帮助企业更进一步预测和对应有可能 出现的机遇及危机。
这个架构为现实世界的挑战提供了答案,从数据描述的方法与准确性,到影响IT状况(包括机构内外)的数据异质性,以至为决策者及与业务有关人士而设,最终希望能让IT支持人员工作更为轻松的信息展示方法。
成功的架构必须明白现实世界的问题,及拥有不一致主数据的成本,并提供确保机构内有数据一致性的方法。这个服务为本的方法,充许多类型IT资产可以更快速 重新配置,来对应场需、法规和更快的业务改变。架构的事件处理能力,让企业能够在机会和问题发生之前做出预测和对应。另外,这个架构可以将该事件处理能力 应用到自已上,按服务水平协议监控和主动管理架构的健康与绩效。在基于Ajax的前端,商业智能工具采用与业务相关人士能够轻松了解的形式提供信息。
这个架构的美好在于它真的存在。
所以,一个成功的架构,就是一个可以解决用户需求(包括功能和非功能)的架构。当然,还要考虑到可行性与扩展性。其中,扩展性又是最容易出问题及最困难的 地方。要做到容易扩展,你就要知道,或者预测到将来用户需求的变更方向。如果架构师只着重技术的话,要做到这点真的是非常困难。所以从企业架构师的角度来 看,他不但要对企业的业务非常了解,也必须要了解未来几年业务发展的方向。SOA的流行事实上就给了我们一个机会去想清楚IT跟业务部门的关系,IT到底 只是一个一味追赶业务需求的部门,还是一个业务上的拍档,彼此互相影响,这将影响到整个企业信息架构的成功。
:您多次谈到SOA,那么SOA对于系统架构的意义和影响何在?在您的理解中,SOA架构的本质是什么?
林伟炎:SOA对系统架构的意义极为深远,从解决单一问题,到解决整个企业的问题。从以部件为主,到以企业服务为主,牵涉到设计思路的改变。也许需求更多的投入在沟通,规划,设计,基建与组织治理方面。
很多人说服务的本质就是重用。这种看法不错,但拿捏不到重点。服务导向的本质应该是更紧密的IT-业务的关联,更高的服务抽象层次,更强的IT治理,最终达到业务的敏捷性。能达到最后这点,才是一个真正的面向服务架构(SOA)。
:目前,您或所在团队是如何开展软件架构设计工作的?在使用什么产品或者方法呢?
林伟炎:要进行软件架构设计并不特别需要什么工具,最重要倒是沟通。沟通是为了两个原因。第一个是对需求的理解,第二个是把你的设计作推广,缺一不可。
第一点比较容易理解,正如前面说过,不清楚需求是不可能设计出成功的架构。第二点则比较容易忽略。老实说,一个企业架构的成功与否就是要看到底这个架构能否落地,个别部门的项目组是否跟从。所以作为架构师,一定要多听,多沟通。
在架构的规划及设计阶段,我发现最有用的工具是工作坊,就是为了一个特定的目的而把不同部门的人聚集起来一同讨论,让每个受影响的部门都可以充分发表意 见。架构师作为facilitator,必需要有良好的沟通技巧,敏锐的触觉,以及包容和正面的态度。国内跟国外的架构设计不存在很大的技术差异,只是国 内搞技术的人都太注重技术,一般忽略了对业务的关注,对治理及沟通的重视。
:刚才您提到了Ajax。在今年的JaveOne会议上,Tibco公司也宣布Ajax消息服务(AMS)计划,能否详细介绍什么是AMS,AMS在SOA架构中将起到怎样的作用,以及AMS与ESB的异同?
林伟炎:我们认为SOA与Ajax会产生最完美的协同效应。两者独立演进,但也能同时善用各自的长处。典型的Ajax应用与HTTP服务联系,并只会传送 HTML标记或者只是数据的信息,然后在用户端转化为可供阅读的信息。至于企业服务管道 (ESB) 则是以JMS,或以Rendezvous,或者MQ为基础,按不同的供应商而定,来实时移动数据。Ajax Message Server的功用就是连接这两个世界。
另外一个ESB的问题就是,它只是消防喉,而不是自来水龙头。所以你需要把所有时刻改变且大量的即时数据过滤,令它们变成人能够接收了解的信息。这也正是 AMS所能够做到的。它其实是一个服务器,能够连接服务器及客户端,以建立一个即时的HTTP连接,然后作多路传输、过滤信息,还会根据用户应用情况来控 制流量。AMS能够优化由服务器端流向用户端的即时串流信息。
:最后,请对有志于软件架构发展的读者谈谈,您认为对于一个架构师,最大的挑战是什么?应该如何面对呢?
林伟炎:作为一个架构师,最大的挑战就是要放下自己,不能假设自己什么都懂,要多听,多看,多想,多包容。不能只顾技术,也要发展沟通、带领团队,以及处理人事关系的技巧。技术只能帮你成为一个技工,而架构师,就要看你的Soft Skill了。
感谢林伟炎先生的精彩回答,让我们在向架构师的征途上又迈进了一步。也请继续关注我们的架构师访谈系列。