21世纪企业规划和架构战略

关于企业规划和企业架构（Enterprise architecture）设计，在现有的企业管理者中往往存在一些错误的观点，比如完美主义、“大而全”等。本文提出了企业EA设计和构建的两个原则：Just In Time和Just Enough，企业架构设计的团队只有依照这两个原则才能够真正实现企业架构设计的预期结果，获得最大的投资收益。

企业架构任务的规模和复杂性都可能非常巨大。如果没有细致的规则，企业架构（EA）的团队常常变成“细节驱动”，失去企业总体的视图。专注的EA团队应用系统的EA流程来在业务的“上下文”中定义战略需求，然后根据实际优先级创建未来状态依赖的可递交件。

EA成功将由公司和业务线经理理解、迟迟和实现架构的程度决定。到2007年为止，15%的EA核心团队从IT组织的管理结构中转移出，直接向企业战略或者企业变更管理部门报告。2007年之前，40%的企业架构设计师将在业务战略或者流程工程方面拥有主要专家技能。

完美主义是最大的敌人。这个众所周知的信条必须被每个企业架构设计师深刻理解。在关于EA团队的研究中，我们常常看到他们迷失在细节中，失去了对总体结构的预测能力。企业架构设计师常常被来自用户的大量的细节需求所驱动，这些用户希望EA团队作为工程组织工作。在他们决定实现时，与他们作为工程师的主要训练一致，很多企业架构设计师非常愿意提供这方面的帮助。他们经理的实现完美的模型，在所有可能的细节层次上，对于所有的观众而言。企业架构设计师常常夸大他们的状态，方法是通过成功、显示特定项目的能力、以及设定未来细节问题解决的障碍。企业架构设计师必须记住他们的主要目标不仅是作为工程中心，而且要为企业战略决策制订提供现实的、环境的基础，并且提供跨企业的实现一致性。

很多EA团队驱动自身到总体的详细视图中，方法是通过错误地尝试从开始就完全移植模型的完美“地图”。为“完整性”而奋斗可能导致团队在实际任务上偏离方向。虽然很多完美完整的模型中有很多的属性，这些属性很少可以帮助架构设计师鉴别从何处开始，或者决定何时完结。高水平的模型分类学在使用时可以作为澄清架构思维的工具。不幸的是，他们可能导致大的、包容一切的EA努力，这种努力在失败以前几乎毫无意义。

正如业务需求可能驱动EA努力一样，业务需求应该驱动流程，这种流程是由EA开发的。这些流程必须考虑业务文化问题，以及业务驱动。

卓越架构团队的特点

1.解释架构努力将是不断进行的过程，而不是单一的事件。早期的结果将不会是完全包括，或者完全详细的。团队产生了架构文档，作为建立的基础。

2. 通过鉴别“闪电战工程”所需的组成部分，确定优先级，通过致力于这些领域得出结果。

3. 他们评估标准化和文化对应的业务规则水平，不允许EA设定于不现实的目标。

Just In Time：只涉及最需要的部分

企业需要必须首先通过公共需求图景（CRV）定义，但概念架构必须被开发。只有当这些先决条件已经满足后，架构团队才应该专注于详细的架构模型开发。最佳实践是，EA的努力首先致力于对业务最关键的模型。两个主要的检验可以用来为工作排定优先级，现实架构努力的早期结果：

最高优先级应该给予那些直接与战略机会有关的模型，正如CRV驱动的早期分析所显示。业务战略和低水平细节之间的“战略契合”应该是业务架构设计师和LOB经理的共同任务。第二个检验鉴别已经很好定义和标准化的架构模型，即使还没有完全宣布。现存的规则和标准可能需要澄清、修改、再工程，但是至少已经应该可以在现实世界中被检验。其优势和弱点被理解，执行个人已经被检验来处理这些问题。如果这些规则和标准仍然有价值，增加的移植努力应该得到更早的结果。

作为一个例子，正在进行全球市场扩张的公司对于以下要素有较强的需求，包括：通用全球通讯环境、跨区域协同和知识管理。关注于全球整合标准、信息政策和协同工具的EA努力客户很快表现出业务价值。公司通过在在同样的地理区域购买相关业务公司来增长收入，他们可能从跨业务协同的客户管理和目标市场中获益。EA模型开发战略应该首先关注信息管理、整合、CRM和企业分析相关的问题。其他的领域拥有比较少的优先级。

有些现存的实现可能已经表示出了公司内的事实标准。很多年的系统投资导致很多公司创建了“工程平台”，这些平台严格文档化、经过压力测试并且在严格的管理规则下升级。架构团队应该通过快速将这些管理规则放置于EA雨伞之下。通过在一些领域快速产生结果，识别和包括现存的最佳实践，架构团队强调EA努力，并将之作为可以产生业务需求相关的可行结果的机会。EA努力成为了双面的方法：持续实现已定义的架构（通过转换和EA保险流程）；进一步创建额外的、新的或者更多的扩展模型。两条路径可以通过一致性和依赖性一起管理。