内容


观点与展望,第 6 部分

定义最重要的 IT 体系结构问题

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

Comments

系列内容:

此内容是该系列 # 部分中的第 # 部分: 观点与展望,第 6 部分

敬请期待该系列的后续内容。

此内容是该系列的一部分:观点与展望,第 6 部分

敬请期待该系列的后续内容。

高瞻远瞩,平衡业务和 IT 需求

我最近亲历了一组 IT 架构师的专家组讨论,感到颇有压力。他们召集会议的目的是为了讨论自己的需求和希望,以帮助 developerWorks 团队确定哪些类型的信息对他们最有用。

会议室里聚积了十多位来自各个方面的架构师——一些来自小型咨询公司,一些来自独立软件提供商,还有一些来自具有海量 IT 系统的大型企业。他们似乎都有一个特点:所有人都视自己为技术人员,而且都发现自己被不断卷入业务策略决策过程中。(他们都表达出对过去只需要进行应用程序设计和编码的生活的怀念,但这已经一去不返了。)

显然,IT 架构师现在必须“逆流而上”,除了作为 IT 系统的设计者之外,还要充当业务人员的角色。如果您要成为一名成功的 IT 架构师,则需要兼顾两方面,将业务决策与技术决策联系起来。这个领域的工作并不容易,为了帮助您处理这种微妙的平衡,我们在 developerWorks 站点上提供了大量的 IT 体系结构内容供参考。(我们承诺此后将尽量少用含义不是十分清楚的比喻。)

为了进一步改进我们向您提供所需资源的方法,developerWorks 编辑团队感到务必了解 IT 架构师所面临的最重要问题。我们采用了多种方法来实现此目标:第一个方法是研究其他网站并以非正式的方式向我们的体系结构作者进行咨询,这反映在 IT architecture resource roundup 页面中给出的各个问题上。第二个方法是密切关注 IT 体系结构讨论论坛的动向,您可以随时访问此论坛,以询问问题或加入讨论。

第三个方法:本月,我们邀请 IBM IT 体系结构专家组回答以下问题:

您认为目前 IT 架构师面临的最重要问题是什么,为什么?

专家组的成员与我们的客户或内部团队合作,他们也必须在业务和 IT 之间保持平衡。他们的视角可能比普通的 IT 架构师更宽一些;不过,由于他们有丰富的经验,因此我们认为他们的答案将对您有启发意义,会十分有用。他们的回答当然对我们有参考价值,您可以再次访问 developerWorks IT 体系结构专区来了解将来的文章所讨论的其中很多问题。

developerWorks IT 体系结构团队——

Paul Dreyfus
developerWorks 成员
pdreyfus@us.ibm.com

另外,我们很遗憾本月少了一位固定投稿人的观点。IBM Fellow 兼 Rational 软件权威 Grady Booch 最近进行了切除动脉瘤的胸外科手术。我们向他和他的家人表达了我们最真诚的问候,祝愿他早日全面康复,早日回到他享有盛誉的工作领域中来。

将 IT 与业务结合

Bobby Woolf我认为 IT 架构师目前面临的首要问题是将 IT 与业务结合。这个问题长久以来就是一个大问题,至少从业务领域的面向对象的建模出现以来就是如此(甚至可以追溯到最早期的自动化数据处理)。从这方面来看,这个问题没有发生变化,但我们处理问题的技术在不断变化(我希望是提高)。

目前用于将业务和 IT 结合的两项主要技术是面向服务的体系结构(Service-Oriented Architecture,SOA)和企业服务总线(Enterprise Service Bus,ESB)。SOA 将业务功能组织为可重用业务任务,其将业务应用程序的结构设计为作为经过协调的服务实现的组合应用程序。我们使用服务实现应用程序的功能以及使用其他应用程序的服务集成应用程序时,服务调用就会变得更为重要。ESB 简化了服务调用,减少了服务使用者和服务提供者的很多调用负担。从业务的角度而言,SOA 应用程序充当使用者;它告知 ESB 自己希望调用哪个服务,ESB 会将这些请求与最佳的可用提供者进行匹配,而提供者则负责执行业务任务。

在此 SOA 过程中,应用程序建模就成为了业务建模。对应用程序进行再工程就成了对业务进行再工程。业务必须具有公共的可重用任务,以便 IT 将这些任务捕获为服务。因此,SOA 可能较为简单;将业务建模为可重用服务可能成为一个更大的挑战。

复杂性、上市时间压力、垂直行业标准

Andras SzakalIT 面临着前所未有的压力,需要迅速而有效地生成相关 IT 体系结构来满足复杂性不断提高的业务需求。随着组织继续通过合作伙伴来进行其部分业务功能,业务流程的复杂性将持续提高。此趋势要求我们将 IT 层扩展到边缘位置、提高体系结构的灵活性并设计出可联合业务供应商、合作伙伴和客户间的传统企业服务的体系结构。

我考虑的这些因素中最主要的是对 IT 开发和部署的设计阶段的上市时间压力。随着与业务部门人员更紧密地合作,压力将从设计阶段转移到开发甚至部署阶段。这就增加了业务的风险。IT 架构师需要让其他人员认识到恰当分解业务问题和生成将业务需求与实现正确结合的相关而有意义的体系结构的必要性。

IT 架构师始终要承担应对一项特定挑战的责任,即理解不断发展的 IT 行业标准。现在这个趋势也在垂直行业(金融、国防、政府部门、电信)体现出来了,IT 架构师需要理解技术标准和相应的 IT 相关垂直行业标准。对于 IT 架构师,了解这些趋势是降低这些不断变化的趋势对成功生成有意义的体系结构带来的风险的第一步。

同时进行创新和维护,开放源代码

Sridhar Sudarsan目前 IT 架构师面临的主要问题之一就是,在新功能的业务需求(因而需要采用新技术和体系结构样式)和保持当前应用程序正常运行方面找到一个平衡点。这个平衡点始终比较麻烦,因为并没有唯一的正确规定性答案,必须具体情况具体处理。所涉及的各方始终存在争议,更为糟糕的是,各方都有完全合理的理由,而这些理由之间经常又存在冲突。现在整个行业已经认识到了这个挑战,正在努力提供辅助手段来帮助完成此决策过程,但这是一个费时的过程,并不能遵循某一组准确的指导原则或标准来解决此问题。

IT 架构师面临着严峻考验的另一个关键领域是对关键应用程序使用开放源代码产品的一系列决策。同样,这个方面也存在很大困难,因为并没有唯一的答案解决这个问题,只有人们支持和反对的声音。这同样也是能对 IT 架构师造成巨大影响的业务决策。

注意差异和采用开放源代码时的细节

Richard Schwerdtfeger编者注:IBM 杰出工程师 Richard Schwerdtfeger 是计算机系统可访问性方面的专家。他在此处的观点源自系统开发领域,将 IT 体系结构的问题扩展到了更大的范围内。

问题 1:如果我以现有体系结构为基础进行构建,体系结构和部署之间存在何种差异?

IBM 正逐渐支持越来越多的 Linux™ 应用程序。如果 IBM 的客户是政府部门,为了部署应用程序,需要能在所确定的目标桌面上访问这些应用程序。这些桌面均遵循给定的体系结构,而此类体系结构在可访问性方面存在巨大的体系结构差异。我们需要处理此差异,因为它们会导致 IBM 无法在该平台上支持我们的产品。现在我们正在处理这些差异,但我们必须刻意延迟投资。

在设计解决方案时面临的问题的一些示例:

  • Gnome 桌面的单线程体系结构要求对辅助技术服务提供者接口(Assistive Technology Service Provider Interface,ATSPI)体系结构(辅助结构进行连接的层)内的更改进行分离。
  • 对进程外应用程序访问的依赖要求添加新 API,以减少访问应用程序时的上下文切换。(这还涉及到到标准工作。)
  • X Windows 中的体系结构并不支持高速屏幕放大。
  • 辅助技术的体系结构不能与 Windows 相提并论。

问题 2:体系结构应遵循哪些行业标准?其中是否存在差异?这个问题在今天的业务环境中非常重要。

我并不认为在设计新系统和软件的体系结构时,我们对各个行业标准进行了足够的评估。以 DHTML 和 Ajax 方面的进展为例。以下是我的个人经验。IBM(事实上,整个行业)因为一些很明显的原因对编程模型进行了更改。不过,我们并未处理使用 HTML 来完成此任务时的重大差异,从而给我们的产品带来了风险。例如,这些 HTML 差异对构造可访问的解决方案造成了阻碍,同时妨碍了政府接受度。我们现在通过采取以下的一些措施处理其中的一些差异:

  • 仔细分析 CSS 标准和浏览器支持将影响我们如何设计 UI 组件的体系结构和下载内容的大小。
  • IBM JSF Widget Library (JWL) 组件现在已经过重新设计,以处理在其 Ajax 实现中使用 XML 的问题。
  • 浏览器可访问性不足的问题正逐渐被发现和解决。

处理 HTML 中可访问性差异已经花费了两年时间,其中涉及到大量的标准工作、浏览器方面的资金投入等等。我们将重新设计 Dojo 组件的体系结构,以适应可访问性支持。更重要的是,更改影响了 UI 与 Web 组件的整个交互,从而使得此界面更像 GUI。此处的要点是,我们后来为了处理标准而给公司带来了大量的成本支出。

总之,架构师应询问以下与标准相关的问题:

  • 我将作为构建基础的标准是什么?
  • 标准差异和风险如何,它们将对我造成什么样的影响?
  • 从长期和短期的角度而言,我如何处理这些差异?

问题 3:是否需要作为开放源代码使用或生成的组件?适用什么样的许可证?

与开放源代码软件的交互正变得越来越多。当将此类软件包含到体系结构中时,您必须处理一系列问题:

  • 我是否熟悉存在的各种不同类型的许可证?
  • 我是否熟悉开放源代码中的工作流程?
  • 谁对代码进行维护?
  • 管理工作是否需要隔离开发人员,以防止造成代码混杂?
  • 我是否必须将代码提交回相应的组织?
  • 我必须提供什么 IP?
  • 适用什么样的许可证?
  • 我们如何隔离我们的专用代码?
  • 最后,我是否应在定义自己的体系结构时使用此软件?

利用灵活性激活业务和 IT 系统

Kerrie Holley目前 IT 架构师面临着有或多或少的期望的业务环境。业务涉众将 IT 视为流程创新的催化剂,但同时将旧思想和遗留系统视为更改的阻碍因素。IT 架构师现在必须与业务涉众共同协作来设计业务解决方案的体系结构,而业务涉众可能并不能充分理解构建和部署业务应用程序所面临的 IT 挑战。技术正在改变使用者的期望,而技术同时也在改变业务。业务期望 IT 能够在其使用和部署 IT 的过程中高效灵活。架构师必须找到在业务解决方案中创建持续灵活性的方法。因此,IT 架构师必须理解其作为架构师与作为设计者之间的角色差异,以及体系结构规划与设计工作之间的差异。IT 架构师必须考虑将来的需求。

IT 架构师必须确定如何使灵活性成为业务解决方案的一个持续特征,以便实现业务流程灵活性,使 IT 不再是置于业务创新和灵活性之上的一个约束。这就要求 IT 架构师能够抛弃旧的思维方式,转而以面向服务的方式进行思考,而这正是 IT 架构师的一个主要思维转变。新的“生态系统”业务范式正在逐渐形成,其具有的灵活性和响应能力成为了它的关键竞争优势。业务服务现在必须组件化,且需采用分布式方式——分布到员工、客户和合作伙伴的相应位置。实际上,随着对业务流程灵活性的关注越来越多,在企业内外出现了相应的业务服务动态访问需求。IT 架构师必须采用面向服务的体系结构所支持和反映的这种新业务范式。

IT 架构师必须理解并将业务服务作为体系结构中的第一要素考虑,同时还要了解如何使用服务组件体系结构(Service Component Architecture,SCA)等规范改善组件间的连接。IT 架构师不仅必须了解 SOA 的特征,还必须了解如何设计业务解决方案的体系结构,以利用以下 SOA 特征消除业务、应用程序和基础设施顾虑:

  • 模块性,业务功能分解并打包为具有自包含和自描述特征的模块化服务。服务可以由其他模块化服务组成,也可能根据需要进行混合和匹配,以创建新的组合服务。
  • 封装,SOA 服务的数据和业务逻辑同其具有自描述特征的接口分离。封装隐藏了服务的内部复杂性和实现细节,并同时公开基础功能,以便进行发现和访问。
  • 联合控制,SOA 组件、服务甚至服务域根据一组特定的策略和协议彼此进行交互。契约和服务水平协议可促进流程一致性。
  • 松散耦合,应用程序间的依赖关系得到最小化或完全消除。松散耦合可保护 SOA 服务不受其与之交互的系统和服务内的更改的影响,从而能够跨域和企业边界发现和调用服务。
  • 分离关注点,因为在 SOA 中,复杂业务操作被分解为了多个功能。这些功能封装为多个离散服务,这些服务可以彼此独立地进行操作和管理。关注点分离减少了复杂性,提高了企业系统的适应能力和可伸缩性。架构师必须了解如何实现性能、可用性、安全性和环境管理方面的非功能需求。
  • 共享服务,由于 SOA 服务具有模块化、封装和松散耦合的特性,因此可以由多个用户(和服务)从多个位置和多个上下文中进行访问。在新组合服务的构造过程中,服务可以作为构建块共享甚至重用。
  • 开放标准,如 Web 服务标准 XML、SOAP、WSDL 和其他标准。

组织实现和部署技术的方式已成为组织的一个主要不同点。这是两年任期的 CIO 和五年任期的 CIO 之间的区别。这也是对业务有影响的重要 IT 架构师之间的差异。采用面向真实业务的体系结构思维是今天 IT 架构师面临的一项挑战。

需求和设计渐变

Jorge Diaz今天的架构师面临着在急剧变化的业务环境中设计解决方案的艰巨任务。这就带来了不仅要准确而且还要灵活的体系结构设计压力。随着架构师开始着手解决此环境中的问题,需求渐变(也称为功能范围渐变)就会变得非常明显。这个术语指增加的需求并未出现在初始基准列表中。

进行更改时,很可能引起需求集的更改。首次确定后引入的需求越多,达到事先确定的计划的可能性就越小。架构师务必指定可靠的计划来管理需求,并严格遵守此计划。此计划应包含建立需求优先级确定过程和影响分析的明确方法。

与需求渐变相关的另一个问题是设计渐变。这个术语指的是添加与初始基准指定的需求不相关的设计元素。技术(而不是业务需求)驱动的架构师经常会遇到这种情况。务必确保设计决策与业务需求紧密结合。可以帮助处理这种情况的一项技术是使用依赖关系矩阵。此方法可以进一步应用到软件开发生命周期中,全面涵盖实现元素和测试用例。对于大中型解决方案,IBM Rational RequisitePro 之类的需求管理产品可以帮助提供所需的自动化功能。

六种平衡措施

Ali Arsanjani对我而言,IT 架构师在组织中扮演着关键的平衡角色。以下是架构师必须考虑的多个方面的平衡:

问题 1:在业务和 IT 间进行平衡

软件 (IT) 体系结构要对彼此冲突的约束进行平衡。IT 架构师正越来越多地要求在业务与 IT 间(即不断发展的业务期望和支持它们的 IT 基础设施的需求)进行平衡,并弥合二者之间的差异。业务中的灵活性要求具有相应的 IT 灵活性。此灵活性在 IT 体系结构(即面向服务的体系结构 (SOA))中的最新方法上得到体现。

让业务和 IT 人员坐到一起进行协商的需求通常需要利用 IT 架构师的技能。SOA 提供了一个中间地带,双方可以在此确定一组与业务一致的 IT 服务,来同时支持组织的业务流程和目标,从而帮助解决这个问题。

问题 2:在新旧之间进行平衡

现有系统和资产是公司中的最大投资。新需求要求对现有结构进行更改,以适应满足服务质量目标以及在某些情况下业务间的服务水平协议的新功能。

利用较旧的(遗留)系统并在某些情况下对其进行转换(使用基于编译器的更为直观的代码分析工具)有时难以与新方向和新 IT 活动协调一致。较旧的结构和由于对灵活的新系统功能的需求而带来的约束之间的阻碍性不匹配是进行创新和应用体系结构最佳实践的一片沃土。

问题 3:即时可用还是自定义

应当自己构建,还是购买?即使您利用现有系统,仍然可能会存在需要求助于体系结构解决方案的另一个重要因素:您如何在即时可用的解决方案的能力和自定义这些解决方案的需求之间进行协调?如何进行此操作,以防止被程序包供应商限制在某个范围内?您如何在不会将项目降级为另一个打包实现的前提下创建 SOA?

问题 4:配置或自定义

每个业务部门都具有其独特的需求,但各个业务部门之间也存在共同点。您是否应该进行重新创建或自定义,或者是否应该构建能进行配置的可插入解决方案?也就是说,您是否应多次构建类似解决方案,并针对每个客户或业务部门对其进行自定义?或者,是否应该构建一个高度可配置的解决方案,并多次对其进行配置?答案并不明显,因为每种做法都有其优缺点,具体取决于当时的情况。

问题 5:您是否应完全从头做起?或者,是否应该构建资产?

当然,尽可能不要从头做起。请充分利用现有体系结构和代码。但与构建资产相比,利用现有资料的相关成本和工作又如何呢?资产或可重用软件组件已成为了软件工程的圣杯。它的可行性如何呢?与更快地从头进行构建相比,项目中可用于创建资产的工具和基础设施如何?很多项目都会经历在工厂生产与家庭作坊式生产之间进行选择的艰难问题。

问题 6:您完全按照理论行事,但为什么您的项目并未完全成功?

控制是良好体系结构赖以存在的保护伞。应遵循并自定义用以构建在软件体系结构上运行的系统的方法。不过,如果没有控制,则失败的可能性很大。

关于专家

Bobby Woolf

Bobby Woolf 是一名 IBM Software Services for WebSphere 咨询师,负责帮助客户成功使用 WebSphere 产品。他与人合著了 Enterprise Integration PatternsThe Design Patterns Smalltalk Companion。请参阅 developerWorks 上 Bobby 的博客,以了解更多信息。

Andras Robert Szakal

Andras Robert Szakal 是 IBM Federal Software Group 的首席架构师,同时也是杰出工程师和高级认证 IT 架构师。他还是 The Open Group 理事会成员。

Sridhar Sudarsan

Sridhar Sudarsan 是 IBM Software Services for WebSphere 的一位高级 IT 架构师。他曾负责过全球很多客户的企业体系结构解决方案的工作,包括金融、政府机构、汽车和供应商关系管理(Supplier Relationship Management,SRM)等垂直行业的大公司。他是 Java™ 2 Platform Enterprise Edition (J2EE) 中的批处理编程模型(该模型现在是 WebSphere XD 中的一个组件)的创建者之一,目前正在向客户推广这个模型,并致力于构建此技术相关的最佳实践。他目前正在负责一家大型保险公司的大型 SOA Center of Excellence 的工作。

Richard Schwerdtfeger

Rich 是 IBM Emerging Technologies Group 的一位杰出工程师,他所在的部门负责 Software Group 的可访问性策略和体系结构。Rich 是 IBM Accessibility Architecture Review Board (AARB) 的主席,同时也是 IBM Master Inventor。Rich 全面负责 IBM 内的所有业务单位,并且是 W3C WAI 和 HTML 工作组以及 OASIS ODF Accessibility 子团队的成员。Rich 在 IBM 负责 Java 可访问性开发,其中包括 IBM/Sun 可访问性协作。Rich 负责 W3C 中的 DHTML 可访问性工作,并是 IBM 内负责 Web、Eclipse、UNIX®、Windows 和 Java 平台的可访问性的体系结构团队的负责人。

Kerrie Holley

Kerrie Holley 是 IBM Fellow,并且担任 IBM 的 Service-Oriented Architecture and Web Services Center of Excellence 的首席技术官。他擅长的领域包括软件工程、体系结构以及将业务要求转换为以网络为中心的分布式解决方案的设计。

Jorge Diaz

Jorge Diaz 是 IBM Software Services for WebSphere 的一位解决方案架构师。他的工作重点是提供中间件和分布式系统集成领域的策略体系结构,负责欧美地区的相关工作。Diaz 先生与各个大客户密切合作,帮助他们使用各种技术(包括 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 内部和外部的实际应用。请访问他的博客:Best Practices in Service-Oriented Architecture


相关主题

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=172679
ArticleTitle=观点与展望,第 6 部分: 定义最重要的 IT 体系结构问题
publish-date=11062006