级别： 初级 Kunal Mittal, 执行 IT 主管, 自由开发人员
2008 年 8 月 29 日 通过本文了解 IT 团队在与企业架构师合作时所面临的一些基本挑战，并了解如何将企业架构标准应用于应用程序开发，并在项目交付中合作以达到所需的成果。
企业体系结构（Enterprise Architecture，EA）的作用在不断变化。面向服务的体系结构（Service-Oriented Architecture，SOA）、Web 2.0 和其他技术的采用在不断改变着软件系统的构建方式。传统的 EA 概念是在 SOA 和 Web 2.0 诞生之前形成的。它们更适合于大型应用程序开发项目，而不是适合于敏捷的、基于服务的开发。
但是，本文并不是真正讨论 Web 2.0 和 SOA 的发展如何影响 EA。相反，本文讨论大型组织中在业务部门 IT 团队如何与 EA 团队合作方面，我所发现的一些基本挑战。其中指出了如何组建和管理 EA 组织的问题，并提供了如何组织 EA 的建议。我略微谈到了 Web 2.0 和 SOA，以强调所有的问题是如何复杂化的。
不负责任的权威
尽管拥有强大的 EA 团队具有种种好处，但是企业架构师与负责向业务交付应用程序和解决方案的项目团队之间通常存在紧张的关系。是什么导致这种紧张关系呢？
在许多组织中，EA 团队将自己视为项目团队的决策制定和批准权威。EA 团队可能要求项目团队设法让其项目的若干不同方面获得批准，包括技术平台和版本、接口和通信，以及软件开发流程。EA 团队还可能要求提供项目状况检查点。下面查看一个假想的场景。
示例：使用 Web 服务来集成两个应用程序
我曾经看到 EA 团队坚持使用 Web 服务来实现两个独立的 Java™ 2 Platform, Enterprise Edition (J2EE) 应用程序之间的所有通信。从表面上看，这似乎是一个合理的要求。然而，项目团队可能确定，Web 服务集成将使其中一个应用程序无法满足其性能服务水平协议 (SLA)。项目团队决定将其中一个应用程序中的数据与其系统中的数据联结。然后，当用户在网页上执行搜索时，该团队使用 Asynchronous JavaScript™ + XML (Ajax) 来显示由联结数据（即来自两个系统的数据）组成的搜索结果。
在这个简单场景中，Web 服务是否为适当的集成机制呢？也许是，也许不是。企业架构师没有考虑到 SLA，并尝试强制执行 Web 服务集成。项目团队没有选择，只得采用 Web 服务，并且在质量保证或用户测试期间，性能 SLA 没有得到满足。项目团队最终花了几天，每天工作 12 小时以尝试满足 SLA，并按时部署了该应用程序。
在此例中，做出决策并强制要求采用 Web 服务的企业架构师到哪里去了呢？通常，他或她不知所终。这是不负责任的权威的经典示例。
这一切似乎很愚蠢。然而，如果您是曾经在具有成熟 EA 的较大型组织中工作过的项目团队成员，您也许可以讨论一下。您可以自问，为什么我的企业架构师没有和我坐在一起解决这个问题？
解决方案：卷起您的袖子
对此问题的解决方案是非常容易的（虽然可能是说比做更容易）。企业架构师必须具有两个功能：治理功能和项目交付功能。企业架构师必须与应用程序架构师和应用程序团队的其他人员一样保持对项目的交付负责。他们的作用并不只是定义和强制标准的使用，而是——更重要的是——帮助项目团队使用那些标准。在上述的场景中，企业架构师决不应该过分热心于帮助项目团队。
对标准进行创建、建模和编制文档并不足够。我宁可看到企业架构师少定义一些标准，但是要确保花足够的时间来作为项目团队交付工作的一部分支持那些标准。他们需要与项目团队并排工作，或者旅行以便与项目团队会谈。他们应该在场和可沟通，以充分理解正在开发的项目的所有方面——从业务、技术和政治的角度。
权威和权力来自于影响力。企业架构师必须与项目团队建立强有力的关系，并且项目团队需要将他们珍视为真正的合作伙伴，并在出现问题的时候设法让他们与项目团队并排工作。此方法将自动产生影响力，从而产生作为企业架构师关键功能的治理。
下面是另一个假想的场景。
示例：将您的应用程序定义为服务。
在此示例场景中，EA 团队已开始讨论 SOA。一个大型的新项目即将启动，企业架构师将其视为演示 SOA 的机会。企业架构师希望将该应用程序构建为服务，以向组织的其他部分公开服务。从表面上看，这同样是个合理的预期。然而，企业架构师常常提供某种“万能”的方法。他们没有花时间去了解项目的需求和业务驱动因素，并且没有专心地处理细节。项目交付团队急得焦头烂额，因为他们在会议中不断受到有关如何以及为什么需要公开和使用服务的质问。从他们的角度看，企业架构师是在纸上谈兵，根本不理解交付该项目的压力和轻重缓急。
如果您是一位企业架构师，或者是管理 EA 组织的人，当您读到这里时，也许认为这是荒谬的。这些示例是否有点太极端了？即使作为一个项目交付团队成员，您也可能会这么认为。
请恕我无法苟同。我经常看到这些场景，并且听到许多项目团队以类似的方式抱怨他们的 EA 组织，可以肯定地说，这些是非常真实的问题。许多财富 500 强公司在不同的程度上面临着这些问题。
那么，我们如何解决这个场景呢？
解决方案：了解业务
EA 团队的每个成员了解业务是至关重要的。认识到 EA 标准和实践必须随着业务的发展而发展同样非常重要。业务的发展必须包括 IT 战略更改，IT 战略更改又应该帮助确定体系结构战略。
这里的关键词是流程、支持和一致性。企业架构师为交付团队带来流程。他们还需要为这些团队提供支持，并将他们的战略和目标与每个项目背后的业务驱动因素保持一致。
现在，让我们调整一下思路，看看典型的 IT 组织实际所做的工作而不是他们应该做的工作。
EA 与业务不一致
我采访过的大多数 EA 团队似乎更多地集中于技术而不是业务。他们可能首先构建战略 IT 计划或与业务部门访谈，但他们最后以技术活动而不是业务活动而告终。许多 EA 团队花更多的时间定义数据中心战略或者处理电子邮件或目录活动、采购等等。请不要误会我：这些是需要适当关注的重要 IT 活动。然而，从 EA 的角度看，它们全都是战术性而不是战略性的项目。
在其他情况下，我看到 EA 团队致力于定义技术路线图、标准和 SOA 策略。这是另一组对 IT 组织非常关键的活动，但是处理它们可以使您获得 EA 组织的真正价值吗？这些活动具有 IT 影响，但是没有直接的业务影响。
谁应该执行这些任务，以及 EA 团队应该做什么呢？
这是一个没有正确答案的难题。我并不是想说，企业架构师不应该从事前面描述的活动和项目。他们绝对需要做那些工作。然而，这不应该是他们所做工作的全部。如果此类任务就是他们使用人员、时间和预算去做的工作的全部，那么他们也许不应该将自己标榜为企业架构师。或者，他们应该从事这些任务，但是要避免本文前面描述的问题。
许多 EA 团队花更多的时间去定义数据中心战略，或者从事电子邮件或目录活动和采购，而不是与业务部门团队合作交付具有很高业务价值的项目。团队成员必须同时与业务负责人和 IT 团队建立强有力的关系。需要将他们视为合作伙伴而不是警察。应该将 EA 的定位定义为一组帮助制定业务决策的工具和服务。
归根结底，EA 团队应该是业务战略与 IT 实现之间的桥梁。
SOA 如何切入？
SOA 涉及到 IT 如何能够适应不断变化的业务环境。SOA 背后的关键驱动因素是业务敏捷性。如果您同意这一点，那么将会同意要支持业务，EA 必须随业务一起不断发展。企业架构师是 IT 战略的持续建模人员，以支持业务体系结构的发展。
在 SOA——尤其是在 Web 2.0 SOA——领域中，您必定会看到更多针对僵化 EA 流程、指导原则、框架和方法的阻力。克服这些阻力的最佳方法是让企业架构师与交付团队合作，并以敏捷的方式定义他们的流程和框架——我的意思是指框架、流程、方法和治理策略全都必须内在地能够更改和适应 SOA、Web 2.0 等等。
参考资料 学习
- 您可以参阅本文在 develperWorks 全球网站上的 英文原文。
- 在 developerWorks 的 Architecture 架构专区 中，获取用以提高您在体系结构方面的技能的各种资源。
- 通过 架构新手入门 了解关于软件架构方面的基础知识。这里同时提供了 IBM 的体系结构原则，以及 developerWorks 上的其他架构资源，这些资源能够帮助您了解有关架构的更多信息。
获得产品和技术
- 下载 IBM 产品评估版，获得来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。
- 获取免费的 架构师工具包系列，了解最新的 IBM 企业架构师开发工具技术文档和资源。
讨论
关于作者  | 
| | Kunal Mittal 是一位擅长 Java 技术、J2EE 和 Web 服务技术的顾问。他已经和人合作出版了多本有关这些主题的书籍。他是 Sony Pictures Entertainment 公司 Domestic TV IT 小组的主管，负责该部门应用程序的技术架构和管理。在业余时间，他为 IBM developerWorks 撰写文章，提供 SOA 咨询服务，同时他还是一位私人飞机驾驶员。有关更多信息，请访问 Kunal 的网站 www.kunalmittal.com。 |
对本文的评价
| 
