让架构起作用

Making Architecture Matter 让架构起作用

该文章最初发表于 IEEE 软件杂志，现由 InfoQ 和 IEEE 计算机协会联合向您提供。

作为架构师，我们希望我们的架构起作用。我们希望通过项目实现我们的宏伟设计，一次完成一小步，每一步都是软件架构的大难题中的完美的组成部分。我们希望给整个公司的开发人员提供援助，告诉他们使用特定的数据库或者 Web 服务器，因为我们希望他们的代码易于维护并遵守我们那些很好的架构设计原则。

但现实颇为棘手。在 Statoil（挪威国家石油公司），我们曾喜欢使用花哨的门户架构，采用许多模型和复杂的设计，但是我们发现没人看我们写的东西，或按我们说得去做。随着时间的推移，这带来了许多额外的费用，因为我们要艰难地维护各种 Web 服务器生态系统，中间件生态系统等等。几年前，公司在几次事故后开始聚焦于合规管理，并实现了一种叫企业管理系统的东西。这种交流在 Statoil 运营中面对各种需求的新奇方法给了我们一个黄金机会，让我们的架构更知名，更有影响力。

一片新景象？

大多数大公司都有 IT 部门， Statoil 也不例外。我们的 IT 机构拥有 1000 多名雇员、承包商、咨询顾问，他们遍布全球。他们需要合适的 IT 工具应对手头的工作。在这样一个大型组织，我们不能依赖个人关系解决架构的所有干系人（商业分析师、软件开发者、IT 管理者、基础运维人员等等），相反，我们需要使用其他的方法进行沟通。

这一问题的传统解决方法是建立软件架构文档，或稍时髦一点的做法利用架构门户供干系人咨询。因为保持软件架构正确非常重要，所以我们在企业内部门户首页建立了一个指向架构门户的链接，以便于相关干系人可以轻松找到它。我们发现，在一个石油公司里，IT 并不看作业务核心，所以我们的架构门户网站难以找到，不管我们为 IT 组织做了多少工作，仍然很少有人过来咨询。当他们咨询时，通常是无法理解架构时，或者不能将架构与他们的工作关联时。在几次侥幸脱险后，管理层决定更加关注公司合规要求，以便满足挪威石油的运营所面临的各种需求。这一工作由上层驱动，有清晰的合规目标，期望从 CEO 传递到执行副总裁，再传到世界各地分管工作的副总裁。这时，公司管理系统出现了许多需求，数千文档详细描述了从海底石油施工到 IT 安全性的各种各样的需求。虽然管理层希望挪威石油雇员和承包商了解这些需求，但是这些文档事实上是难于阅读和理解的。另外，它们通常互相矛盾，阅读的人难以弄清哪些需求才是有效的。

保持条理

为解决公司管理系统面临的挑战，管理层决定遵从“让体制组织员工，让工作流组织工作”的原则，按工作流程组织需求。对所有日常重复工作，开发一个流程，然后授予某人进行维护，确保时时更新。这些流程拥有者也负责恰当的最佳实践，包括 IT 工具。为每个流程所有者配备一个助手，帮助开发他们各自领域的最佳实践和需求分析。这些流程开发完成后，来自公司管理系统的所有的旧文档被分解为单个需求，并委派到相关的流程活动中。在这项工作的过程中，需求也被简化，并调整到适当的详细程度。

在 IT 中，我们有我们的流程所有者（他同时也是 CIO），并且开发了一系列流程，描述了在挪威石油 IT 工作是如何执行的。

图 1 展示了一个例子。(点击可以放大）

图1. IT 领域的一个工作流例子。它展示的信息包括，由哪些事件启动流程，涉及到哪些角色，哪些活动应该被执行，什么时候流程结束。与每项活动相关的是需求和最佳实践，读者可以很容易的看到那些想要看到的内容。

让管理关注于合规和需求，公司花费了大量资源用于培训和确保管理系统的内容时新。挪威石油也花费了大量资源在管理系统本身，以便使用户能方便地找到他们需要的信息。

新特性和收益

我们管理系统的一个重要特性是能够分派给特定领域的有效流程或需求。这些有效的领域基于组织、地理、角色或者这些的组合。当一个用户浏览管理系统时，系统根据该人的组织部门、位置和角色显示相关的流程和需求，隐藏那些可能使用户困惑的不可用的需求。

作为软件架构师，我们立刻看到了管理系统在交流架构方面的潜力，个性化的特性意味着我们可以向SAP 开发者展示SAP 开发相关的架构和需求，也可以向Java 开发者展示Java 开发相关的架构和需求。（见图2）多亏了这个管理系统，我们能够把我们的架构理念在组织中广为传播，并且比传统的基于文档的方式花费更少的精力，却带来更大的影响。架构和需求就在开发者周边，通过个性化特性植入系统中。

图2. 面向不同用户的不同需求(a) 给SAP 开发者展示来自管理系统的一个活动（b) 给Java 开发者显示的相同的活动。通过只展示相关的需求给用户，用户只用关注他们真正想要关注的。

在若干年后，我们开始回顾企业管理系统在交流架构需求方面的作用。通过开发企业标准和需求，我们已经减少所用数据库平台数量，分享其用法。现在我们的数据库运营部门维护了相当于10 年前10 倍的服务器和数据库，并且这个数量每年增长15%。然而，我们的人员数量与10 年前相当，并未我们也没有打算雇佣更多的人。在IT 组织的其他部门也发生了同样的事情，如网络设施、Web 服务平台和集成软件等。

另一个看以看到的效果是，我们的应用和设施的可靠性提高，它们变得如此强健几乎没有任何中断事故。按照我们的展望，IT 对挪威石油运营会越来越重要。若没有IT 支持的情况下，几乎没有流程可以工作，它现在成了保持支撑公司的应用和设施每年365 天每天24 小时运行的必不可少的部门。企业管理系统将成为强大的工具，它是一个沟通必要需求的高可用性IT 投资组合。

最重要的是我们学到了要让架构起作用，我们不得不把它提供给所有干系人，我们不能期望所有干系人来找我们。只有让架构需求贯穿IT 组织，我们才能比传统架构文档或者门户接触到更多干系人，并且使架构系统更重要。即使你们的组织没有像我们这样的管理系统，你会接触到更多干系人，通过你所拥有的管理系统发挥更大影响，而不是另搞一套。

关于作者

HARALD WESENBERG 是一名拥有 15 年以上经验的软件开发者，主要为油气企业开发关键业务应用。他是挪威石油（全球财富 100 强的油气企业）的企业解决方案架构师。并且经常撰写和在世界会议上讲述他的经验。通过

hwes@statoil 联系他。

EINAR LANDRE是一名有 25 年经验的软件专家，主要从事开发、架构师、管理、咨询顾问、作者 / 演讲者。他目前是挪威石油的一名生产线管理者。通过

einla@statoil.com 联系他.

这篇文章最早发布于

IEEE 软件杂志。

IEEE 软件的目标是构建领导未来软件实践的社区。杂志提供可靠、有价值的、尖端的软件开发信息，以便于工程师和管理者紧跟技术快速发展的步伐。

查看英文原文： Making Architecture Matter

感谢马国耀对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。