许多企业架构（Enterprise Architecture，EA）项目无法达成所有目标或实现架构团队最初定义的各种收益。虽然团队在执行项目时使用了良好的架构框架和方法作为指引，但最终还是不可避免地出现了这样的结果。

为了帮助EA团队成功交付The Open Group架构框架（The Open Group Architecture Framework，TOGAF）9项目，本文着力强调架构团队应遵循的10个关键步骤。这些步骤是从TOGAF 9中摘录出来的。TOGAF9是世界各地的组织和从业者采用的行业标准框架，全球已有超过16,000名架构师获得了TOGAF认证。

有了TOGAF，EA从业者就可以充分利用全球各地的组织和自由架构师的经验和知识。

第一步：定义对组织的理解

EA从业者谙熟组织的内部运营，包括熟悉组织内部部署的各种流程、系统和技术。但是，我们发现，极少从业者真正理解部署这些流程、系统和技术的原因。

对问题“我们为什么开展这项业务”的回答能让架构团队洞察组织的业务目标，并让他们更清楚地识别那些对组织具有实际影响的计划。在批准新计划时，多数业务主管，包括管理层主要关心如何降低成本、管理风险和增加价值。架构团队必须能够证明他们如何增进计划的价值。如果他们不理解业务目标，就无法清晰解释架构工作将如何支持这些计划。

第二步：识别影响组织的关键因素

组织经营并非虚无缥缈。多数发达国家的金融机构仍在设法从几年前的次贷危机中艰难恢复，而且至今全球依然能够感受到次贷危机的影响。次贷危机迫使金融机构改变银行以前的做法（特别是抵押资产证券化），而新的政府监管规定也在影响着银行业的跨国经营。例如，行业的业务驱动力影响着组织的战略和目标，新的环境立法影响着许多国家的自然资源行业（尤其是矿业及石油开采）和对电信业的管制力度，而技术创新和互联网宽带普及迫使零售商们参与国际竞争，也使中小型企业加入了与现有专业服务组织的竞争行列。

这些驱动力影响着特定行业中组织的业务目标和战略，而新的业务目标则需要新的或改进的业务能力，使组织能够应付这些变化。EA从业者有责任了解行业的业务驱动力，确保在新计划执行期间开发的架构设计符合业务发起人的期望并且能够支持组织的业务目标。

第三步：明确架构开发的职责

“协作”、“介绍”、“讨论”、“推动”以及“交互”等都可以用来描述参与某个架构计划的EA专业人员的部分职责。EA专业人员必须与组织中的各级雇员进行互动，包括从高管到行政人员，还要与厂商、供应商以及监管机构进行沟通。

架构团队要了解组织的期望和为其设定日程的执行发起人。如果不能清楚地了解所有利益相关者（包括EA团队自身）对团队的职责和要求，架构项目交付可能会遇到来自组织策略的挑战。企业架构，顾名思义，是一项跨组织的活动。对一个团队来说，即使是规模较小的组织有时也会因为过于复杂而难以管理整个架构，因此必须对工作进行分割。在具有若干EA团队的大型组织中，对每个团队的职责有一个清醒的认识尤为重要。

第四步：识别架构原则并将其与组织价值和驱动力联系起来

处于同一行业、具有同等规模、在同一国家经营并同处于其细分市场顶端的不同组织可能具有截然相反的组织文化、结构和对待风险的态度。所以，这些组织会各自具有驱动其架构决策的差异巨大的架构实践和原则。

例如，在零售行业可能存在两家相互竞争的食品零售商，他们遵循完全不同的战略。一家零售商可能采用特许经营模式，所有的零售网点均独立经营；另一家零售商可能会自己经营所有门店。第一家零售商选择的架构原则可能会围绕通用词汇和数据定义（如TOGAF的第14条原则）展开，以确保能够最低限度地建立互操作性标准，实现交易数据与总部和供应链合作伙伴的集成。而第二家零售商可能会采用类似的原则--数据托管（如TOGAF的第13条原则，该原则要求所有数据有一个管理员，负责批准和执行跨组织的特定数据元素共享。

架构原则是组织价值和业务原则的一个子集。通过奠定架构治理的基础，架构原则要驱动组织中各架构团队的行为。因此，在启动各架构项目之前，建立一整套明确定义且获得认可的原则非常重要。

第五步：了解架构治理融入组织治理框架的方式

架构治理是指将模型存储库转换成企业所需的真实价值的过程。架构开发周期中交付的架构文件必须受治理结构控制。如果组织初次尝试EA实践，则必须对当前的组织治理结构进行更新以便适应新的架构流程。

例如，架构治理委员可能会批准一项旨在定义针对整个组织的标准集成层的计划。与此同时，某个业务单元可能决定为其环境实施一个不同的集成协议。如果IT采购部门和项目管理办公室（Business Project Office，BPO）依照不同的治理结构办事，则寻求某个适当解决方案的业务请求很可能会获得批准，而试图为企业范围集成设定标准的架构计划则会流产。

第六步：集成架构开发流程与其他管理框架

TOGAF9中的架构开发方法（Architecture Development Method，ADM）是EA从业者在执行某个架构项目时遵循的步进式指南。ADM 可以作为一种独立方法使用，也可以集成到其他架构框架或行业特定的管理框架之中。第五步已经指出，架构治理框架必须与组织的治理框架保持一致。同时，还需强调的一点是，流程步骤必须与其他管理框架的步骤保持一致，这样就可以避免重复劳动和输出重复的交付物。

实施TOGAF9时要解决的第一个可能发生的重叠是项目管理交付物和流程步骤。如果组织已经实施了某个架构管理框架（如Prince2），则TOGAF的某些关键交付物（如SOW、沟通计划、实施与迁移计划）就会与之发生重叠。如果允许这些框架独立运作，架构项目经理会创建类似但实则不同的交付物，并将它们提交给不同的决策机构。这将在组织中造成混乱。在第三步中，我们会创建一份利益相关者地图。可以利用该地图标出各方面的利益相关者，包括项目管理（如Prince2）、开发（如SCRUM）、操作管理（如ITIL）、IT 管理（如COBIT）以及采购等等。同时，要确保架构团队有权访问已经在组织中部署的所有业务与IT管理框架和流程。

第七步：进行架构成熟度评估

可以利用能力成熟度模型（Capability Maturity Mode，CMM）来判定企业打算采用EA方法来管理变更和复杂性的准备度。架构成熟度的度量是主观的，其结果将反映那些完成评估指标的参与者的意见。要想获得真实结果，重要的是识别那些要度量的关键特征，并从某个成熟的且可以根据组织需要加以调整的成熟度评估开始。TOGAF9提供了一些NASIO架构成熟度模型、CMMI以及DOC架构CMM的例子，可以作为定义组织架构成熟度指标的起点。

第八步：将架构职能纳入组织

组织中任何可持续的架构计划都需要规范化的架构职能。我们知道，很多组织以项目群或项目的方式实施了它们的架构计划，但却没有为扮演组织中与架构有关的各种角色的专业人员提供组织职业发展通道。

架构职能的结构受前面列举的很多因素的影响。基于行业、组织成熟度、人力资源战略、预算约束以及治理结构等因素，必须制定组织结构图，列出团队结构、各种角色及其职责。将人力资源构件规范化将使管理团队能够启动后续规划、技能开发、资源分配以及绩效管理。

许多EA项目由于组织人员流动（辞职）、过度使用外包或临时员工等原因导致失败或不能实现其最初目标。根据组织战略，使用外包或临时员工是可以接受的，但是必须要清楚这样做存在的风险和对项目的影响，使管理团队能够灵活决策。

第九步：定制TOGAF

TOGAF 9是一个不断演进的框架，用于解决各行各业的问题，包括公共部门和非盈利组织。在第五和第六步，我们已经讨论过TOGAF 9需要和其他的管理框架保持一致，以确保各交付物纳入组织治理流程和结构之中。这一步是为了推动EA从业者正式编写定制化的TOGAF流程以及组织要求的任何交付物。

如果有新人加入架构团队，或者架构流程必须进行规范化和突破（如达到CMMI二级），又或者架构职能在组织中获得了扩展，则本文极具价值。

第十步：实施之前应考虑的架构存储库构件

要想在TOGAF9的基础上建立可持续的EA实践，需要一个卓越的架构存储库。存储库必须提供用以支持TOGAF9成功部署的构件如下：

1.架构存储库必须具有一个易于定制化的模型存储构件（架构景观），使众多项目和用户可以在同一服务器存储具有制品级安全的内容。

2.元模型必须开放，易于定制。

3.一个提供参考材料（如ITIL、APQC PCF、COBIT、TRM等）的独立参考库构件，以及允许将内部组织特定的架构加入各参考库构件的能力。

4.一个治理日志构件，可以存储治理内容（如架构项目文件和决策等）并与某个外部项目管理存储库共享这些内容。

5.一个文件库或内容管理构件，所有非制品架构相关的内容存储在一个版本受控环境中（包括架构能力文件、项目文件以及差距分析报告）。

6.一个视点库，具有能够在组织中重用的一整套预定义视点，并且能够为组织中的其他制品添加预定义视点。

7.一个分析引擎（使架构师能够进行假定分析、差距分析、动态视图创建等）。

结论

EA从业者通常专注于项目交付，极少考虑在EA实践之前定义项目环境和进行规划。本文基于TOGAF9标准着重强调的10个步骤是所有架构师在启动一项新计划或项目之前必须完成的工作。

EA从业者要想获得更好的资金支持或提高当前架构项目成功率，唯一途径就是回归根本。必须确保有一位理解项目价值的执行发起人、一个理解其作用和组织定位的内部架构师团队以及对通过自动工具发布并符合需求的一整套视点认可的各种利益相关者。