如何使用架构框架理论为政府以及各个机构建设企业架构呢？企业架构的建设、维护和使用又该如何融入到各个机构中？面对这些问题，2001年CIO委员会发布了《ApracticalguidetoFederalEnterpriseArchitecture》，用于为各个机构提供一份关于建设和维护企业架构的详细指南，并且该指南还介绍了如何将企业架构融入到各机构的生命周期中，从而促进机构的良性发展。这份指南虽然名称上是为联邦政府各机构提供一份实施导则，但是对于联邦政府之外的各种企业也有着重要的意义。
企业生命周期
在企业的存续和发展过程中，企业需要不断的吸收新的技术、业务流程等新鲜事物，并将其转换为能够促进企业前进的各项能力，而这样一个循环往复的过程就可以看作为企业的生命周期。为了维持这个过程的良性发展，企业需要借助于各种管理过程和方法，并通过他们之间的协调合作来达成。在联邦政府中，相比于项目管理以及资金规划和投资控制，企业架构过程可以说是一个新晋技术，因而为了确保整个组织的良性持续发展，仅仅强调企业架构过程而忽视其他过程的结合是不够的。在这份指南中，企业生命周期被描述为上图所示的样子。在这里，企业架构过程（EAProcess）是一个独立运行的迭代过程，而除此之外一个企业的良性发展还需要企业工程和项目管理（EnterpriseEngineeringandProgramManagement）和资金规划和投资控制过程（CPIC，CapitalPlanningandInvestmentControl）。在这三个核心过程中企业架构过程是用于企业架构的建设、维护和使用的指导过程；企业工程和项目管理用于负责针对企业各个实施或采购项目的管理；资金规划和投资控制过程是企业关于投资的选择、控制和评估方面的重要工具。这三个过程并不是相互隔绝的，企业架构过程的实施最终要落实到一个个具体实施项目之上，而确保这些项目能按时按质的实现就需要企业工程和项目管理以及资金规划和投资控制过程方面的强力支持。除了企业架构过程受益于这两个核心过程之外，企业架构过程所产生的企业架构内容也为这两个核心过程提供了准确可靠信息基础，并且企业架构过程还可以保证这些信息能够快速反映和消化外界环境的变化。除了这三个核心过程之外，企业生命周期的良性发展还需要系统生命周期、人力资源以及安全管理这三个支持性的管理过程的帮助。这三个支持性过程具有普适性，他们不像上面三个核心过程那样直接作用于企业的具体任务，但是他们确实是支持各个核心过程并保证企业任务能够顺利进行的重要保障。
企业架构过程
理解了企业架构过程在整个企业生命周期中的位置以及与其他重要管理过程的相互关系，我们再来了解一下CIO委员会对于企业架构过程是如何进行阐述的。与FEAF不同，在CIO委员会的这份指南中采用步进的方式将企业架构的开发、维护与应用描述成一个循环往复的迭代过程（如下图所示）。这一循环往复的企业架构过程与后面将要介绍的TOGAF的架构开发方法（ADM）有着异曲同工之妙，两者都采用了循环迭代的方式，并且大部分的步骤都有着相似的意义和内容，不过在针对每个步骤的具体描述方面，CIO委员会只是针对此过程中的每个步骤进行了较为详尽的说明，而TOGAF的ADM的描述方式则更具标准性，除了各步骤的说明之外还包括了每个步骤的目标、输入、输出以及进一步细化的分支步骤。
企业架构过程
CIO委员会将企业架构过程分为九个部分，除了最后的“控制与监督（ControlandOversight）”之外，其余八个部分是都是如上图所示那样以前后衔接的方式来布置。也就是说，按照箭头所指方向前面步骤的完成为后面步骤的启动奠定基础，并且这八个步骤都处于“控制与监督”这一过程的控制之下。这些步骤按照在企业架构的开发中的出现顺序列举如下：
● 取得上层主管的认同和支持（ObtainExecutiveBuy-InandSupport）
● 建立管理结构和控制（EstablishManagementStructureandControl）
● 定义架构过程和方法（DefineanArchitectureProcessandApproach）
● 开发基线企业架构（DevelopBaselineEnterpriseArchitecture）
● 开发目标企业架构（DevelopTargetEnterpriseArchitecture）
● 开发序列计划（DeveloptheSequencingPlan）
● 使用企业架构（UsetheEnterpriseArchitecture）
● 维护企业架构（MaintaintheEnterpriseArchitecture）
● 控制与监督（ControlandOversight）
取得上层主管的认同和支持
取得所有上层主管的认同和支持是一个企业架构过程建设的起始，也是决定一个企业架构是否能够被成功建立的先决条件。由于企业架构是一个涉及到全组织的信息资产，其开发和维护需要整个组织提供持续的资源支持，因而得到组织全体尤其是高层的支持是非常重要的。在此企业架构过程各步骤之中，作为企业架构的主要推动和执行核心，CIO和主架构师需要在企业的不同层面分别获得相关人员的支持和认同，而其中最主要的是获得管理层对架构过程所必需的资源支持的承诺、各业务负责人和领域专家在业务角度对企业架构目标的认知以及在预算及其他约束方面的分析。
首先企业CIO需要创建市场策略，并与企业最高领导进行交流，使其了解企业架构开发在战术和战略上的价值。在取得最高领导的认同之后，CIO需要取得他对企业架构支持的承诺，为获得必要的资源支持打下基础。同时，CIO需要与最高领导在高层管理团队中选择主架构师。然后，CIO还要和最高领导一起基于各项用于治理企业架构的开发、实施和维护的架构原则创建企业架构方针(ArchitecturePolicy）。
接下来，CIO需要起草市场方案来进一步强化企业架构的价值，并在高层管理团队中获得认可，并得到他们以及他们下属组织和资源会积极投入的承诺。主架构师需要起草一份更为具体的企业架构计划，从而获得企业中包括业务负责人和领域专家在内的各个业务单元的支持，并且还需要他们从业务策略角度，结合预算以及其他约束条件对架构的业务层以及相关序列计划的合理性进行分析。
最后，CIO和主架构师需要举行一个企业架构项目的启动会议，用于阐述企业架构的目标、里程碑、流程、产品，以及企业架构过程与系统生命周期活动、资金规划和投资控制过程等相关过程之间的关系，从而在业务的中层和下层的参与人员中获得共识和支持。
建立管理结构和控制
企业架构管理组织结构概念图
在此步骤中，企业需要建立用于管理、控制和监督企业架构过程中各项活动的组织结构。在这个组织结构里，各种角色的责任以及他们之间的责任和沟通关系需要被清晰地定义出来，而且该组织架构的构成应该有助于其中的各个角色在企业架构中职能的发挥。需要注意的是，由于企业规模的差别以及业务复杂度等方面的不同，此企业架构管理组织中角色的构成以及角色的职能也是具有不小的差别。在CIO委员会的这篇指南中，该企业架构管理组织包括了企业架构执行委员会（EAESC，EA Executive Steering Committee）、技术审查委员会（Technical Review Committee）以及企业架构项目管理办公室（EA Program Management Office）这样的专为企业架构过程所设的部门，也包括诸如质量保证（Quality Assurance）、配置管理（Configuration Management）、风险管理（Risk Management）、安全以及评估这样的较为通用的信息技术支持职能单元。
定义架构过程和方法
架构内容深度和详细度制约因素
在此步骤中，企业需要指定用于建设企业架构的过程和方法。首先，企业需要明确企业架构的使用目的和范围，而这也是推动后续企业架构过程活动的主要动力。在确定了企业架构的使用目的和范围的基础之上，企业还需要判断出其对企业架构在内容深度和详细度方面的需求，并保证各个视角下的视图内容都遵循相同的深度和详细度标准。接下来，企业需要选择适当的企业架构制品，并使用上一步指定的深度和详细度水平来约束架构制品的内容。这个选择既包括挑选包含了必要内容的核心架构制品，也包括明确用于进一步阐述核心制品或在特定领域和范围内对其进行描述的支持性架构制品。从架构制品内容这一角度来看，他们需要包含企业的业务和技术资产这两个方面。
在明确了针对架构制品内容的需求后，企业需要选择适当的架构框架理论和用于辅助架构建设的自动化工具。在联邦政府的范围内，已经出现了不少企业架构框架理论，例如上面提供过的FEAF，DoDAF和TEAF等，因而各机构可以按照自己的实际情况在这些框架中选择并定制出符合自身情况的框架理论。同时，为了加强架构的可用性并提升架构开发的效率和准确性，选择适当的自动化架构工具是必不可少的。需要注意的是自动化工具的选择也要照顾到企业的规模、复杂度以及员工熟悉度等多个方面，因而主架构师对于自动化架构工具的选择既可以是诸如微软Office办公软件系列这样的通用性工具，也可以是像Rational Rose这样的专业建模软件，当然也可以是它们的组合。
开发基线企业架构
在开发基线企业架构这一过程中，各个企业或组织需要根据已经确定的架构目标、范围和所采用的架构框架对当前自身的状态进行各种制品的开发，这既包括针对核心架构制品的开发，也包括对支持性架构制品的开发，同时还包括针对其他由于特定需求而单独定义的架构制品（简报图表、会谈纪要等）的开发。在这份CIO委员会的这份联邦企业架构指南中，关于企业架构核心团队对于架构开发过程（对基线企业架构和目标企业架构的开发均适用）所要进行的各种活动做了如下图所示的归纳：
架构制品开发过程
● 数据收集：识别和收集用于描述企业或机构当前状态的各种信息。
● 初步架构制品制定：在此步骤中各种初步的架构制品将会被创建。需要注意的是由于架构开发过程是一个循环往复的过程，因而在一次迭代中也许并不能创建所有的架构制品，或者架构产品的详细度也不能达到最终要求，这都需要在后续的迭代过程中加以改善。
● 审核与修订：该过程用于审核架构制品的准确性和完成度，并根据审核结果对架构产品进行修订和改善。该审核过程应该在架构开发过程中的多个时点进行，而不是一个一次性的过程，并且每次审核过程应该分为两个阶段：首先由架构核心团队的资深成员对架构制品进行一个快速审查，在此之后提交给各个课题专家（在这一次的审查中，参与的成员可能包括主架构师、架构核心团队、质量保证人员、风险管理人员、课题专家以及各业务领域负责人）进行再一次的审核。在审核结束后，需要针对架构制品进行适当的修改和完善，之后提交给企业架构执行委员会（EAESC）和技术审查委员会（TRC）用于对架构制品进行验证和最终确定。
● 发布和交付：在架构制品被提交给企业架构执行委员会（EAESC）和技术审查委员会（TRC）后，如果得到了通过，那么这一包含各种架构制品的企业架构将会被发布，而且相关文档也会被一并交付，同时相关的数据库以及架构工具也要被更新。
开发目标企业架构
其实“开发目标企业架构”与上面的“开发基线企业架构”只是在内容方面有着区别，前者用于为企业或组织未来的目标状态而制定架构，而后者则用于描述企业或组织当前的状态。因而前面如图12所示的架构制品开发过程同样也适用于开发目标企业架构制品。实际上，在这个架构制品开发过程中关于基线（当前）企业架构制品的开发和关于目标企业架构制品的开发应该是同步进行的，所以这两个过程可以被统称为“企业架构制品开发过程”。
开发序列计划
为了实现从当前架构到目标架构的过渡，企业或机构需要通过一系列相互关联的活动以一种增量的方式逐步实现，而为了管理和维护这样一个繁复的演进过程，企业或机构就需要制定和维护一个系统过渡路线图或者序列计划。由于目标企业架构往往是描述企业在一段时间之后（可能三到五年的时间）的未来状况，因而为了增强这一过渡过程的可行性和应变能力，企业或架构需要在当前架构和目标架构之间采用与之相同的描述方式建立起一系列用于描述中间过渡状态的架构。由于环境是不断变化的，符合实际的当前架构和目标架构也需要在环境的推动下而发生变化，因而这些描述中间过渡状态的架构也需要通过维护来确保其准确性和可行性。为了将这样一个包含若干中间状态的过渡过程加以细化，从而得到一个可以用来指导实施的序列计划，企业或组织可以通过如下几个步骤来实行：
● 进行差距分析：企业或组织需要以当前架构和目标架构为依据，通过差距分析方法并对其进行对比，在两者的相关架构制品中寻找演进的机会，从而得出为了达到目标状态而需要进行改变的各个组件。
● 识别遗留、过渡和新系统：此三种系统组成了演进至目标架构所需的各技术组件。其中遗留系统指的是当前在运行，但是在目标架构部署后会被淘汰的各种系统和应用；过渡系统是指当前在运行，甚至在过渡过程开始后或者在目标架构被部署后的一段时间内都需要被使用的各种系统和应用；新系统，顾名思义，是指在当前还不存在，但是在目标架构中需要被实现的系统和应用。在这些系统被识别之后，他们之间的关系以及在过渡过程中的演进情况需要被明确（例如，通过系统迁移图）。
● 进行迁移规划：企业或机构需要把当前和目标架构的差距进一步细化为一个个的可执行项目，并为这些项目配置合适的资源，同时还需要按照优先级顺序为这些项目制定实施规划。这既需要企业或机构了解自身的变化适应能力，也需要掌握这些项目在资源需求、风险、优先级等方面的情况。
· 对变化了的业务过程所做的实施工作可以被表示为一个个包含若干可执行项目的方案倡议（programinitiatives）。通过差距分析，企业或机构可以发现需要被增强、修改或替换的各个方面，并通过依赖性分析决定用于实现演进的各种活动的各种组合方式（例如，顺序执行或并发执行），以及每个项目所需要完成的工作内容，并借此定义每个项目。
· 对项目进行依赖性分析、衡量每个项目的重要度，并借此为每个项目评估其优先级，从而为项目组合制定序列规划的草案。
· 最后，根据企业或组织的短期需求、财务约束下各业务单位潜在的动荡因素等方面对序列规划进行审核和修缮。
使用企业架构
将企业架构集成到企业的日常工作当中有着非常积极的作用。在前面介绍过的企业生命周期中，企业架构过程通过与其他企业中的管理过程和方法进行结合可以促进企业或组织的良性发展，因而使用企业架构的过程就是将企业架构与其他管理过程相协同的过程。企业架构描述了企业或组织的当前状态、未来的期望状态，以及实现未来状态的过渡实施方案，因而总的来说企业架构为企业或组织提供了一个包罗万象但组织有序的信息库。企业或组织中的各种活动都可以将该信息库作为基础，从而在信息充足且可靠的情况下做出各项决策，并且企业中原本隔绝的各个角色也可以使用相同方式进行交流，从而加强了企业或组织内外的合作。例如，在资金规划和投资控制（CPIC）过程中，企业架构可以为其提供目标状态，从而企业或组织的投资可以在符合未来期望的前提下进行，并且企业架构所提供的各种企业当前状态也为企业或组织的投资决策提供了准确可靠的信息。此外，企业架构还可以有如下用途：
· 即使一个企业或组织并不打算进行一个大幅度的IT升级，企业架构也可以作为库存管理、日常维护以及咨询等方面的资源而存在。针对企业当前架构的分析可以为在企业或组织中寻找各种改进机会提供帮助。
· 企业或组织可以借助企业架构中的各种制品来对企业的业务和技术方面的培训进行辅助。
· 可以使用企业架构对企业或组织进行调研和验证。由于企业架构对企业或组织的自业务到技术的各个层面都进行了建模和描述，因而可以基于这些信息对企业或组织以模拟的方式进行调研和概念证明（proofs-of-concepts）。
· 企业或组织可以在CPIC过程之外进行小型、低风险的项目开发，但是项目的管理还是需要与企业架构相一致。与企业架构相一致有助于项目与企业或组织的集成。
· 各个运维项目需要以当前架构作为其背景，而且他们的优先级和决策会受到企业架构过渡计划和目标架构的影响。
维护企业架构
不论是企业或组织自身还是其所处的环境都处在不断变化的状态之中，而企业架构的核心就是客观的反应企业或组织的当前和期望状态，并根据当前情况制定达到期望状态的计划，所以企业架构也需要跟随这些变化而进行不断的演进。在各个企业或组织中，负责维护企业架构演进的工作应由CIO、主架构师和企业架构项目管理办公室（EAPMO）负责，并且通过监管流程系统和独立的审核机制，企业架构核心团队可以周期性地对企业架构与不断变化的业务实践、资金配置和技术引入等方面的相符合情况进行评估和校准。企业架构的内容包括了当前企业架构、目标企业架构和序列计划中所涉及到所有架构制品，因而针对企业架构的维护就是确保这些制品与企业或组织的实际情况相一致。
控制与监督
控制与监督过程并不是企业架构过程循环中各个前后衔接步骤中的一个，该过程作用于整个企业架构过程中的所有步骤，用于确保企业架构在开发、使用和维护过程中遵守由CIO委员会制定的这份联邦企业架构实施指南中对于各步骤所做的约定。首先企业或组织需要确定企业架构项目管理控制的有效性。在企业架构管理组织架构的建立中，企业架构项目被交由CIO、主架构师和企业架构项目管理办公室负责，而为了得到关于项目进行情况的可视性，并借以监督管理企业架构项目的执行，这些责任实体需要在如下几个方面进行定义：
· 所需要知道的企业架构项目相关信息。
· 何时以及如何获得这些信息。
· 这些信息的具体内容和表现形式。
当这些企业架构过程的责任实体按上述定义获得了有关企业架构项目的信息，他们就可以借此识别出企业架构项目中不符合实施指南要求的地方，并针对这些问题采取相应的修正措施。
联系客服
