文/Franki Schafrik, 资深企业架构师, IBM

　　企业架构是业务及其支持数据、应用程序和 IT 基础架构的逻辑组织，为未来的业务成功明确定义了目的和目标。典型的架构由展示业务的各个方面如何关联的一些图或模型组成。例如，组织结构图是表示业务单元如何相互关联的模型。

　　企业应该有一个代表其当前状态的 “原样” 架构，并且有一个规划架构，以显示在未来一年至五年的业务方向。

　　企业架构应该协调以下关键领域。请注意每个领域中的示例：

业务：流程、战略、组织结构图和职能

信息：概念性、逻辑和物理数据模型，显示需要哪些信息，以及如何与其他信息（比如客户和订单）关联

应用程序：应用程序组合、接口和服务

基础架构：网络概念图、技术参考模型

　　为了实现协调一致，需要从每一个关键领域的视角对其进行建模，然后从各个角度链接模型。例如，从业务的角度对业务流程建模。不包括应用程序等内容。然后，将业务流程链接到支持它们的应用程序，这样就可以帮助您实现协调一致。我们这样做是为了确保每一个决策都是根据业务需求制定的，因此，应用程序并不会规定业务流程的设计方式。

　　本文假设您有一个建模工具，可以用该工具创建您的架构。本文中特定于实现的信息以 Rational System Architect 为基础的。

　　“我们打算做架构......我们要做架构！”

1. 如果您没有一个目标，您的项目将会失败

　　确保您的架构失败的最简单方法是毫无目的地制定架构。我已和数百家客户合作过架构项目。当项目没有成功时，我问他们为什么要创建企业架构。他们回答：“因为我们想要一个架构！”

　　第 1 步. 确定架构的目标

　　您可以通过询问以下问题来定义架构的目标：

哪些信息对于架构是重要的？

支持分析和决策需要多少细节？

谁将生成或使用架构？

架构的预期投资回报率是多少？

维护的考虑因素是什么？

　　如果您无法回答这些问题，您的架构项目很可能会失败。如果没有目标，您可能会浪费几个月来绘制没有人关心的业务流程图。或者您可能绘制了一些复杂的应用程序接口图表，但无法提交给高级管理人员，因为这让他们感到头疼。

　　以一家连锁酒店为例，将酒店经理确定为 EA 的受众。

　　通过了解架构的目的，您可以确定必需的模型和所需要的数据的范围，从而确保人们使用您的架构进行分析和制定业务决策。

　　首次涉足架构时不要走极端。即使您拥有一个非常大的经验丰富的团队，您也无法捕获有关组织的所有信息。

　　同样重要的是，请记住，全面的架构可能会混淆重要的事项。例如，如果只有 50 个业务流程对您的业务是至关重要的，捕获 5000 个业务流程就是没有意义的。识别您的关键业务问题，并使用它们成为您的第一个架构项目的重点。

2. 架构为回答问题提供了一条路线

　　第 2 步. 确定业务问题

　　我与客户做的第一件事，是讨论对其业务至关重要的一些问题；然后我帮助他们确定哪些是他们难以解决的问题。许多客户都需要回答以下问题：

　　酒店做架构的目的是改善入住登记和退房的体验，使他们能更具竞争力。

不使用某个应用程序的影响是什么？

某个位置迁移的影响是什么？

需要使用哪些应用程序来支持业务流程？

更换服务器的影响是什么？

需要制定什么流程来支持新的战略？

在我们的应用程序组合中，存在哪些不足或重复现象？

　　您的问题将促进架构内容的形成。如果大多数问题都涉及您的应用程序组合，那么您需要将重点放在定义应用程序领域。如果需要了解流程如何支持一个新的战略，那么应该将重点放在业务领域。然后，就可以开始通过新的业务问题拓展架构的范围。

　　第 3 步. 确定假设和业务规则

　　现在，您已经确定了受众、目的和问题，然后应该确定用来限制或解释关注领域的业务规则。

　　每个业务都有规则。例如，如果您打算捕获关键业务流程的信息，则必须捕获该流程的所有法规或企业标准。举个法规方面的例子，健康保险流通和责任法案 (Health Insurance Portability and Accountability Act, HIPAA)，该法案保护工作变更的人的健康保险的承保范围。然后将创建一个企业规定，显示该公司是否满足 HIPAA 的要求。

　　您应该捕获与架构有关的假设，如 “新应用程序的信息将在周五上传” 或 “每一个业务单元都要负责记录业务流程”。

　　第 4 步. 确定框架

　　以下行业标准框架可以帮助您创建一个企业架构：

ToGAF

Zachman

EA3

DoDAF

　　使用标准框架，可以为您的架构提供一个 “骨架”，然后，您可以利用它建立您的模型。

　　框架还提供了一些指导，指导您了解需要根据将要使用架构的利益相关者来捕获哪些信息。它提供有关组织信息的指导，但没有为您的架构建议具体的实现。

　　Internet 有大量关于这些框架的信息。您要选择什么框架主要取决于您的架构的目标、团队的经验，以及您是想遵循 ToGAF 这样的已定义的流程，还是仅像 Zachman 那样，帮助确定出于什么目的使用哪个模型。

　　您还可以组合多个框架。TOGAF 和 Zachman 经常一起使用。

3. 您的选择应以您的目标为基础，不要作出随机选择

　　如何将框架融入架构？

　　框架提供关于建模对象的指导。然后使用一些方法来创建模型。

　　方法是一个规则集，说明了如何对某个对象建模。例如，业务流程建模符号 (Business Process Modeling Notation, BPMN) 方法提供了用于业务流程建模的精确的规则和符号。

图 4. 框架有助于确定方法的选择

　　框架有助于组织架构的关键领域，并确定您需要建模的视图，比如，解决业务问题所需的角度和数据。

　　连锁酒店决定使用 Zachman 框架。

　　尽可能使用行业标准的方法，而不是 “内部开发” 的方法。行业标准的方法包括规则集和标准的建模方式。多数内部开发的方法无法以有用的方式捕获信息，因为没有明确定义的规则集，这使人们以多种方式对相同的信息进行建模。这也会影响分析，因为信息没有按照标准进行捕获。

　　根据需要的信息类型，可以生成多种模型来支持框架。

图 5. 框架及所支持的方法

　　第 5 步. 创建一个元模型

　　元模型是架构的一个抽象视图。它显示您正在尝试捕获的数据以及数据之间的关系。这是您实现协调一致的地方，它以您的业务问题的解答为基础。

　　例如，如果您需要了解支持特定业务流程的应用程序，在您的元模型中必须存在这两者之间的关系。否则，数据之间不存在任何联系，您无法解决您的业务问题，架构也无法发挥其作用。

　　请注意，在元模型中，您可能并不希望所有数据之间都存在直接关系，您应该只将存在逻辑关系的东西放在一起。例如，将组织部门与技术相关联没有任何意义，但将技术与应用程序相关联就有意义了。Rational System Architect 等良好的建模工具支持通过遍历元模型来创建复杂的报告。所以，在这个元模型示例中，您可以报告支持某项业务功能的硬件，即使两者在元模型中并没有直接关系。在元模型中，您可能从业务功能遍历到该功能所拥有的某个业务流程，再遍历到业务流程的位置，然后遍历到该流程所需要的支持应用程序，最后，遍历到支持该应用程序的技术。

图 6. 关系（元模型）示例

　　您的元模型应该包括以下特性：

架构元素之间的关系。例如，业务流程和应用程序的关系。

元素的定义。例如，术语 “应用程序” 的意义和您将捕获的属性。

业务问题的可追溯性。例如，如果您的问题是 “什么应用程序支持什么业务流程？” 那么您应该知道，元模型中需要一个业务流程和一个应用程序，它们之间存在直接或间接的关系。

　　第 6 步. 确定架构中所需的模型

　　现在您已经确定了您的业务问题、框架以及解决问题所需的元模型，然后还需要了解要绘制什么样的模型。

　　将业务流程作为一个例子，有许多行业标准支持业务流程的建模，如 BPMN 和流程图。请根据以下条件选择您的建模方法：

信息的受众。管理者理解如 BPMN 等简单的图表；软件开发人员通常喜欢 UML 序列图或用例。

元模型的元素。如果在您的元模型中，您需要了解数据以及与它相关的业务流程，请考虑使用 BPMN 对其建模。相反，如果您只是担心流程步骤的顺序，请考虑创建一个流程图。

　　知道受众和您想建模的内容之后，您就可以确定您需要创建的图表。在上面的例子中，因为您需要有关业务流程和系统接口的信息，您可以选择以下模型：

BPMN （捕获业务流程）

系统架构（捕获应用程序）

　　以酒店为例，他们需要回答的业务问题是 “什么应用程序支持什么业务流程？”

　　重要的是，请记住，您不能用单一图表来创建 EA 中的一切。此外，架构视图的分离是一种最佳实践，如应用程序视图与业务视图分离。如果您尝试在同一个图表中完成两个视图的建模，这样做往往会造成混乱，并且无法以有意义的方式捕获信息。

图 7. 使用模型来解决业务问题，所以架构是有用的…

图 8. …不要为了建模而建模

　　正如 Will Gadd 所说，“只是出来走走，做点不那么重要的事情，这样做我就已经觉得很高兴了。”

　　使用合适的工具

　　单一的建模工具或方法并不能提供完整的解决方案。除了开发模式的工具之外，您也应该有发布、需求管理和仪表板显示等工具。仪表板在饼图和条形图等容易理解的图表中展示您的企业架构信息。

　　如果您的架构工具是可定制的，则意味着将使用一些改变工具原有用途的问题定制。大量的定制通常标志着使用了错误的工具或方法。还请记住，定制会带来架构上的管理开销。

　　有些客户通过定制架构工具来创建自己的模型。这并不是最佳实践的方法，特别是如果 “模型” 是占满了整面墙的单一图表，其中包含了关于您的架构的所有信息，这肯定不是一个最佳实践。我们不应该创建墙纸，而是建议创建报告。并不是一切都需要在一张图上显示。

　　在创建架构时，人和工具同样重要。一个人不可能在架构的每个方面都是专家，因此需要发展一个成熟的团队来支持架构。关于架构团队的理想特性的列表，请参阅本系列的第一篇文章，从您的企业架构顾问身上获取最大价值。

　　第 7 步. 整合架构

　　将您根据之前所确定的关系捕获的数据链接在一起。无论销售人员跟您说的话有多漂亮，不要相信，一个工具是无法奇迹般地做到这一点。此外，如果没有一个资料库，关系的链接真的很难做到。如果有人建议说该项目可以使用电子表格做到这一点，那么寻找另一个项目可能会是一个明智的决定。

　　如果您现有的项目或业务线已经有架构，并且您想创建一个企业架构，那么最简单的方法是自下而上填充您的 EA。采用现有架构，并将共同的元素放进一个资料库中。具体而言，可以尝试标准化整个组织中使用的模型和术语，因为可能每个人都对同一个组织使用同一个名称，比如，不是同时使用 “财务部”、会计或财会等别名，而是将它们标准化为 “财务”。

　　如果这是您的第一个企业架构，那么请在整个组织中使用一个公共的蓝图，使用与企业架构相同的框架、术语和模型为业务线创建一个架构。这样，您就可以报告整个业务。

　分析架构

图 9. 为分析节约能源！

　　如果您不愿意花时间来分析架构，可能就不会去分析它。如果不分析它，那么为什么要构建它呢？在时间表中，这关键的一步常常被忽视。至少应该将 50% 的模型开发时间分配给分析，这包括审查模型以验证和确认它。

　　然后执行定量和定性分析。此时数学很重要，在显示投资回报率时尤为如此。如果您使用行业标准方法（如 BPMN），则可以使用定量分析来显示缩短流程、节省时间、节省成本和消除冗余中的瓶颈。 BPMN 是 “结构化” 的，因为它有一个您不能违反的规则集。这些规则确保您可以执行分析，比如分析模拟业务流程的变化，看看该变化是否能够节省时间或金钱，或者是否会造成瓶颈等负面影响。

　　通过查看模型，可以找出潜在的问题所在，然后完成定性分析。例如，如果您有一个业务流程反馈到流程的早期阶段，那么这通常标志着该流程必须返工。消除流程中的反馈回路是改进流程的一种方式。

　　完成分析后，就可以与他人共享成果。如果人们学会了如何使用架构，就会看到它的价值。报告在这里是关键，所以在选择企业架构工具时，请确保它提供了强大的报告功能。

　　不要忘记，您需要一个游戏计划

图 10. 制定您的 EA 游戏计划

　　人们常常忘记，需要在解决了许多管理问题之后，才能启动和支持 EA 项目。需要解决的一些管理问题包括：

如何部署企业架构？

在哪里部署它（Web 站点，等等）？

谁是团队成员？

审查委员会

项目管理

行政管理

谁将使用信息？

谁将可以访问信息？

将要遵循什么标准？

命名约定

颜色编码

　　团队里有一个 'EA'

图 11. 良好的 EA 团队确保成功

　　您不能凭空创建架构。您必须做好准备，与 EA 团队以外的人合作，否则用户无法采纳和使用您的架构。此外，您还要确保利益相关者（例如，付钱让您构建架构的人，或者帮助您构建架构的人）参与了您的决策。

　　治理是制定决策所必不可少的。治理有助于定义您将在架构中使用的规则和战略。以组织中的业务线命名的治理为例，人们可能不希望出现某人将这个部门称为 “会计” 而其他另一个人将它称为 “财务” 的情况。治理也决定了哪些模型已准备好发布为 “批准”。成功的 EA 所需要的典型委员会包括：

架构审查委员会

配置和控制委员会

管理指南（例如，谁可以创建模型，审批流程的什么，变更请求的流程是什么）

　　越多人参与支持架构，使用该架构的机会就会越多。

　　最后几点建议

　　如果建立架构看起来很难，那是因为它的确很难。但这也表示您在以下其中一个方面犯了错误：

模型。例如，使用一个 BPMN 模型来捕获应用程序界面。

利益相关者。例如，不熟悉业务流程的人提供输入或反馈，而不是由真正做流程的人来提供这些信息。

　　学会从架构中将政治原因分离出来

“不要记录那条信息，否则人们会知道我们做错了！”– 这是对企业架构的一个常见反应。但是记录理想化的视图是没有意义的，因为您无法规划未来纠正问题的方式。

“我的组织正在使用不同的方法捕获我们的架构。” – 在我合作过的每一个组织中，总会有一个业务线不希望以标准的方式开发他们的架构。没有人是特殊的。没有人有不以标准方式做事的正当理由。处理这种情况的最佳做法是培训那些希望与众不同的笨蛋。如果他们对期望的目标感到满意并了解他们的期望，那么他们会愿意遵循标准。如果这个方法无效，那么您惟一的选择就是打断他们的腿。

　　使用架构打破独裁

“我们没办法跟那些家伙沟通，您知道，他们是做软件的。”– 在大多数公司都有些人认为与软件开发人员谈话是一种挑战。在您了解他们后，就会发现他们其实都是一些好人。并且，如果他们发现可以用简单的方式与您沟通，可以使用图片，而不是无意义的 500 页需求文档，那么他们对您的态度也会随之改变。

“我倒是愿意把数据给您，但我需要先与我的管理层确认一下。我下次再回复您好吗？”– 有些人认为隐瞒信息可以保住工作。如果 Barney 是惟一了解您的应用程序如何连接在一起的人，那么您就不能解雇他。其他业务线可能不希望共享信息，因为他们怕您用这些信息来解雇员工。通过解释将要采用哪些信息，以及如何让提供信息的人从中受益，可以处理这些情况。如果您带着不可告人的目的（如，解雇员工）来使用信息，那么您会看到愿意向您提供信息的人数会急剧下降。