关于企业规划和企业架构（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保险流程）；进一步创建额外的、新的或者更多的扩展模型。两条路径可以通过一致性和依赖性一起管理。

    Just Enough：只为本公司服务

    EA项目的文化和总体接受度驱动了何时、何处以及多少EA模型详细可以被引入。EA流程模型定义了每个模型的一些维度。最终取决于业务经理实现的架构顺从度；他们将实现架构标准超出了他们认为可能产生收益的点。因此，虽然EA团队可能感觉到有驱动力要实现某个详细，开发必备的详细是不必要的，也可能导致达不到预期效果。

    EA模型：ETA例子

    我们鉴别了每个企业技术架构（ETA）领域，架构标准化的一些维度。鉴别列表的那些部分可能对标准化每个部分有意义：

    例如，一个激进的企业公司可能没有定义按照所有领域的配置水平定义标准。在此公司，标准方法的感知价值当用创新和市场时间加权时是有问题的。按照定义，业务模型确保了实验和文化反映的特定自有。即，合理的业务管理实际上再次发明了已经存在的“轮子”。业务经理通常同意：通用方法（如规则、技术）是必须的，将他们实现在某些领域，但却没有看到更多详细规范的好处。

    达到架构详细的正确水平常常是发现性的努力。缺乏细节成为了实现业务目标时刻的可见障碍。很多公司看到这种需求，因此再次述诸EA努力。但是，“反架构”的态度不会一夜间消失。成功的架构团队逐步剥落反对情绪。关键点是，架构设计师有时的失败是由于他们解决的问题是没有人愿意提出的。但是通过关注对业务有价值的现实细节水平，EA努力在在面对业务和IT社区时保持可信度。

    Just-Enough, Just-in-Time：风险

    此方法不是没有风险的，通过开发基于业务优先级的模型，很容易过分最优化“初生的”模型，代价是未来模型的高成本。以下要点非常重要：根据EA流程和在最高的细节水平上定义满足整体论的早期模型，使最终结果很容易见到，同时可以取得企业水平的最优化。

    业务冲击

    驱动企业架构到正确的细节水平的组织加总了改善企业绩效、质量和获利能力的实现。

    要点

    架构战略意图如果超越业务需求并且没有显示早期的、有意义结果，这样的战略意图就不能被维持。EA努力可能没有考虑与被忽略的规则和标准相关的长期文化偏差。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。