下载掌阅APP，畅读海量书库
立即打开
自21世纪初以来，企业架构一直是一个“热门”的、被广泛讨论和过度炒作的话题。今天许多关于企业架构实践的描述都是未经证实、误导性的、不现实的，甚至完全是虚构的
。若想消除围绕企业架构实践的众多神话和谣言，重要的是先了解企业架构实践不是什么。
企业架构实践不应该与IT部门内部所完成的纯技术规划和决策或IT架构相混淆。因此，从企业架构实践的角度来看，许多技术性问题（如选择合适的技术、应用框架和编程语言，特定网络拓扑结构的优势，系统集成方法或其他架构模式）在很大程度上与企业架构不相关，本书也未就此讨论。尽管大多数架构师以前都是IT专家，而且大多数架构职能部门都向CIO报告，但企业架构实践的通用目的是弥合业务规划和IT规划之间的差距，从而提升业务和IT的对齐度。成功的企业架构实践自然需要与业务规划紧密结合，而与业务规划脱节的IT独立规划只会导致错位。
尽管企业架构实践对大多数依赖IT的大型组织来说都是有益的，无论其所在的类别或行业是什么，但并不存在容易复制的“万能”方法或通用的循序渐进方法来组织成功的企业架构实践
。成功组织中的企业架构实践，虽然通常遵循本书描述的高阶模式，但在许多低阶细节上，如具体的企业架构工件、架构师的角色或企业架构相关流程的特殊性，总有其特殊性。工作中的企业架构实践不能简单地从其他公司“逐字复制”，而需要在内部建立，然后不断地进行微调，以适应独特的组织需求。本书目的只是描述在多个组织中发现的成功企业架构实践的一般性规律，而不是为企业架构实践提供一套精确的操作指南或“银弹”。
企业架构实践是使用特定的EA工件进行有效沟通、平衡决策和规范信息系统规划的实践。然而，使用EA工件并不能自动生成组织中的规划。换句话说，企业架构实践本身并不能以自动化、准机械化的方式将业务战略转化为具体的信息系统。EA工件只是帮助不同的参与者进行合作，实现相互理解，并在考虑到所有利益相关者最佳利益的情况下制定合理的规划决策。在企业架构实践中，规划工作本身仍然只能由人完成，而非由EA工件完成。EA工件仅促进了信息系统的规划过程，而非使其自动化。EA工件虽然对规划很有用，但无法为人们做出任何艰难的规划决策，例如选择合适的技术、确定战略投资的优先级或定义合理的解决方案结构。它们既不能代替人们计划和实现协议的能力，也不能使实际的计划活动自动化。
企业架构实践可以帮助组织中的人员做出最佳的规划决策并实施这些决策。然而，企业架构实践无法将无能力（人员）的思想和行动转变为有能力的思想和行动。例如，企业架构实践不能帮助无能力的企业高管制定成功的业务战略，因为他们不知道当前的业务趋势和市场机会
。企业架构实践不能帮助无能力的IT领导制定成功的IT战略，因为他们不了解最新的可用技术及其能力。同样地，企业架构实践也不能帮助无能力的IT专家实施IT解决方案，因为他们不熟悉相关技术，也不能按时交付高质量的工作。换句话说，企业架构实践虽然能促进信息系统的规划和交付，但却无法弥补相关人员的不胜任。
企业架构实践需要多个业务和IT利益相关者积极参与规划过程。架构规划不能只由孤立的架构师或专家代表整个组织来进行。任何计划，无论其质量如何，都是无用的，除非这些计划的所有基本利益相关者清楚地了解这些计划是如何制定的、为什么会做出某些决策，以及当情况发生变化时应该如何修改这些计划。因此，成功的企业架构实践需要业务代表和IT代表参与协作规划工作。虽然企业架构实践的关键角色是架构师，但架构师的角色意味着让所有相关的业务和IT利益相关者参与规划活动中，而非企业架构实践的唯一参与者。任何由一小群架构师代表其真正的利益相关者所产生的架构计划，最终都会被束之高阁
。
企业架构实践是持续的组织活动，需要不同参与者不断沟通和协作，而非一次性的规划项目或活动，生成一些完美的计划
。在已建立的企业架构实践中，持续的规划和沟通过程本身比实际规划更重要
。成功的企业架构实践需要所有利益相关者对计划进行持续的讨论和调整，而EA工件仅仅被视为支持这种讨论的工具，甚至是这种讨论的副产品
。企业架构实践意味着密集的组织学习，并随着时间的推移而成熟，因为其主要利益相关者通过使用EA工件学会了协作。同时，大量描述理想未来快照的EA工件，作为单一的一次性规划工作，通常最终会束之高阁，而无法改善业务和IT的对齐度
。与持续重新调整计划的成功企业架构实践相比，即使是不连续或间歇性的规划也只能产生有限的效果。
企业架构实践是技术非相关和供应商中立的实践。它与任何特定的技术、方法或范式无关。从这个角度来看，企业架构实践可被认为是一种通用的组织实践，有利于信息系统的规划，而不管组织愿意使用什么具体的系统、产品或技术。由于企业架构实践旨在实现有效的沟通、知识共享和决策平衡，因此其主要焦点不是技术，而是人（因此，各企业架构最佳实践在本质上相当稳定，其发展速度比技术慢得多）。所以对于企业架构实践来说，组织是否要利用大数据、人工智能或任何其他技术革新，是否要部署基于云的或内部部署的解决方案，是否要从IBM、HP或Oracle购买必要的产品，是否要坚持面向服务架构（SOA）、微服务或任何其他架构风格
，基本上与企业架构实践没有关系。企业架构实践的作用只是在选择合适的系统、产品、技术和方法方面提供做出最佳决策的帮助，以满足组织的需要。
企业架构实践不应该与企业建模相混淆
。尽管实践企业架构意味着某种形式的建模，并且使用专门的建模符号或语言来创建EA工件可能是有益的，但企业架构实践和企业建模的实际重合度相对较低。成功的企业架构实践包含建模，但并不多。首先，企业架构实践是一个比建模更复杂、更广泛的活动。使用企业架构实践不仅需要开发EA工件，还需要涉及多个不同的参与者，让他们进行富有成效的沟通，建立一致的决策过程和治理机制。建模本身只是企业架构实践中一个狭窄且相对不重要的部分。其次，作为企业架构实践的一部分而创建的所有EA工件都是为了明确具体的目标而务实地开发的，通常是为了促进不同利益相关者间的沟通或支持对特定问题的决策
。这些工件应该足以满足其目的，而无须完全正确。创建全面的模型，准确描述组织的每一个细节，并非企业架构实践的目标。为建模而建模是无用的活动，在企业架构实践中应该避免这种活动
。最后，用复杂的建模语言或符号创建的图表对于大多数业务利益相关者来说几乎无法理解，在企业架构实践中的应用也很有限。大多数实际有用的EA工件使用简单和直观的格式来表示，不依赖任何正式的建模方法。先进的或“正确的”建模对于企业架构实践并不是特别重要
。
企业架构实践不应与企业工程相混淆。即使企业架构实践包括一些带有定量估计的分析工作，它也不意味着任何类似于传统工程中使用的严格分析——合成程序
。企业架构实践通常不需要制作任何正式的蓝图或使用任何复杂的计算
。与“硬性”机械工程相比，企业架构实践可以被认为是“软性”有机规划方法，它依赖于务实的文档、非正式的讨论和快速的估算，而不是细致的图纸、严格的流程和精确的计算
。真正的组织是令人难以置信的复杂生命系统，无法用传统的工程方法来设计
。在大多数情况下，企业工程只能被视为一种不适合现实世界的乌托邦式想法，而企业架构实践是一种务实的、被广泛采用的管理真实组织演进的方法。
企业架构实践不应与系统思考相混淆
。虽然系统思考肯定比非系统思考要好，且系统思考被广泛认为是架构师最关键的能力之一，但组织中业务和IT之间的错位不能仅仅通过思考来解决。与计划、决策和行动协调不力有关的管理挑战需要合作的改善，而不是应用更好、更系统的思维。思考是一种孤立的活动，不能帮助解决因个人知识有限和决策者利益冲突而产生的组织问题。尽管企业架构实践无疑可从其参与者的系统思考中获益，但它仍主要依赖于制度化的协作和决策过程。因此，企业架构实践不能等同于系统思维的运用，它远不止是思考。企业架构实践首先意味着实施有效的沟通方式，而不是有效的系统思考。简而言之，实践企业架构主要是指沟通和行动，而非思考。
尽管企业架构实践提供了一套行之有效的规划工具和方法来解决组织中的业务和IT对齐的问题，但它不应被视为能够完全消除这一问题或大幅提高生产力的神奇解决方案。任何复杂的组织和管理问题都不可能被完全解决，只能降低到可接受的水平。虽然不负责任的顾问和大师们经常承诺，通过应用他们所提倡的技术
，企业效率会有数量级的提高，但在现实世界中，这种彻底的改善并不可能，也无法实现。因此，成功的企业架构实践可以使业务和IT对齐问题得到控制，并实现组织绩效各方面的逐步提高，但它们并不能令绩效成倍提高。组织和他们的领导应该通过建立企业架构实践来预期可以有适度但健全和持久的效果，而非推销员经常兜售的对所有问题简单、即时和突破性的解决方案。
如前所述，实践企业架构不应与实施流行的企业架构框架相混淆，例如TOGAF、Zachman、FEAF和DoDAF。尽管这些框架被积极推广，并与企业架构的概念密切相关，但它们只是市场驱动的管理风潮，与工作中的企业架构实践无关，也没有成功实施的例子
。所有试图在实践中遵循企业架构框架实际建议的尝试都会导致失败
。从这个角度来看，流行的企业架构框架只能被看作被证实的反模式，也就是应该避免的不切实际的方法。无论是具体的细节还是一般的想法，成功组织中的企业架构实践在任何真正意义上都不像这些框架所开的处方。例如，成功的企业架构实践从未填满Zachman框架的单元格，从未遵循TOGAF架构开发方法（ADM）的步骤，也从未开发TOGAF推荐的大量EA工件，即使是在开放集团自己提供的TOGAF用户名单中的组织
。此外，成功的企业架构实践甚至没有遵循大多数企业架构框架所倡导的一般高阶顺序逻辑，即制定一个理想的未来状态的全面计划，然后实施这个计划
。虽然流行的企业架构框架是营销专家和管理大师的无用产品，但本书所讨论的真正的企业架构最佳实践是在业界出现和成熟的，与这些框架没有太多共同之处
。