【首席架构师看敏捷模型】纪律：企业建模反模式
Chinese, Simplified
过程反模式是一种常见的策略，在理论上听起来不错，但在实践中证明是有害的，即使不是彻头彻尾的灾难。 本文概述了与IT组织内的企业架构工作相关的反模式集合。 这些反模式是：
- 30,000英尺和攀登
- 出血边缘
- 脑信托停车场
- 流行语驱动的架构
- 详细的企业建模
- 企业停车场
- 镀金
- 象牙塔架构
- 建模的清醒建模
- 一个真理高于一切
- 真实的断开连接
- 力求完美
- 被困在杂草丛中
- 技术首先
- 明天会遭受今天的困扰
- 未来的未来
- 昨天的企业模型
| 反模式 | 问题 | 方案 |
| 30,000英尺和攀登 | 企业模型是如此高级，以至于它对应用程序团队来说是有限的或没有实际用途。 |
开发参考体系结构，提供体系结构各个方面的工作示例。 根据开发团队的反馈来制定您的模型。 |
| 出血边缘 | 架构师在成熟或足够稳定以便有效部署之前，不断尝试新技术和新技术。 | 接受旧技术确实能够很好地工作的事实; 您的大多数业务可能仍然是在IBM大型机上运行的批量COBOL，而这实际上是这些系统的最佳平台。 |
| 智囊团停车场 | 您的企业建模组由许多非常聪明的人组成，他们在IT中的任何其他地方都不适合，但您不想失去他们的知识。 | 找到一种方法使它们对现有项目团队有用，可能作为业务领域的建模指导者或主题专家（SME）。 认识到如果他们现在无法在您的组织内提供价值，那么他们就不太可能这样做。 激励他们在其他地方找到工作。 |
| 您的企业架构模型描绘了一系列技术，当有人读到“真正酷”的新技术时，其中许多技术被添加到模型中。 | 认识到您的首要任务是满足您实际需求的架构，而不是您可以在高尔夫球场上向您的朋友吹嘘的架构。 添加新技术的决定应该由具有专业知识并且花时间证明其有效的人员做出。 这不应该是一个政治决定。 |
|
| 详细的企业模型 | 企业模型过于详细，通常是为了全面定义企业的行为（或应该做什么）。 |
认识到人们很少阅读细节，通常是因为他们对这些细节不感兴趣，或者因为他们不相信它们是准确的。 通常需要的是对所需内容的可靠概述和愿景。 与您的观众合作开发模型：他们是他们需要的最佳评判者，而不是您。 |
| 企业停车场 | 一个组织形成一个企业建模或企业架构组，并在那里“停放”很多非常聪明的人，因为他们不想失去人，但同时却找不到实际的位置。 |
认识到仅仅因为某人真的很聪明，这并不意味着他们已经为企业集团做好了准备，或者永远都是。 适当资助您的企业集团。 |
| 镀金 | 架构师过度构建体系结构以实现您在某些时候可能需要的非常酷的功能，但是这些功能今天不会增加价值（并且可能永远不会增加）。 | 通过做一些初步构想来考虑大局，但也要相信你明天解决明天问题的能力。 如果您现在有能力解决问题，那么您是否也有能力及时解决（JIT）何时以及是否需要？ |
| 象牙塔架构 | 您的企业架构模型反映了一个如意，完美的世界场景，而不是您实际环境的现实。 | 查看30,000英尺和攀登的解决方案。 |
| 建模的清醒建模 | 有人认为开发一个企业模型是一个好主意，但没有具体的计划如何在实践中使用它。 开发团队能够使用该模型进行指导的模糊想法是不够的。 | 首先获得对企业建模的支持，然后只有足够的模型来为您的IT组织增加直接和明显的价值。 |
| 一个真理高于一切 | “一个真理”的哲学说，希望对数据元素或业务术语有一个单一的定义，对于主参考数据甚至可能是您的主要业务实体应该有一个共同的共享定义。 当这种哲学走向极端并且你试图了解环境中所有数据实体和数据元素的真相时，就会出现“一个真理高于一切”的反模式。 | 认识到真正的目标是提供商业价值，而不是完美的数据。 要求和优先级发生变化，因此您无论如何都必须愿意改进数据库。 灵活定义数据的语义。 |
| 真实世界断开连接 | 企业模型反映了建模者的愿景和误解，但并未反映您的业务利益相关者实际需要的内容。 | 认识到仅仅因为20年前在域中工作的人并不意味着他们仍然了解当今业务中发生的事情。 让实际执行业务流程的人员参与并在建模过程中获得他们的观点。 |
| 力求完美 | 架构师总是在进行原型设计和修补，但实际上从未实际推出任何东西，因为它并不“完美”。 | 接受这样一个事实，即您的架构需要不断发展，然后开发出“现在足够好”的架构。 今天开发人员宁愿提出不完善的建议，而不仅仅是等待企业架构师准备就绪的请求。 |
| 被困在杂草丛中 | 您对细节太过深入，试图为应用程序团队完成所有工作。 | 架构中的导师开发人员与他们一起作为开发团队的平等合作伙伴，并在他们开始之后，专注于为他们提供所需的指导和建议。 |
| 技术首先 | 架构师使技术成为业务驱动因素而非业务推动因素。 | 将您的企业架构建立在利益相关者定义的实际需求上。 其他任何东西都会“乱砍大片”。 |
| 明天会遭受今天的困扰 | 在尝试改进业务流程时，常见的错误是在不探究如何完成任务的情况下描述当前的工作方式。 | 探索新的可能性，同时牢记今天的现实。 考虑一种独立于技术的模型方法，可能使用基本/抽象用例，使您能够在不探索解决方案空间的情况下探索业务。 |
| 未来的未来 | 企业模型反映了您组织近乎完美的“乌托邦式”未来，但没有为未来提供明确的途径。 | 认识到您受到组织文化，人类不完善和资源限制的约束。 在尝试改进之前，调查并了解当前的情况。 虽然目前的流程可能不是最优的，但可能有理由说明事情是按照原样完成的。 了解这些原因将有助于制定切合实际的流程。 |
| 昨天的企业模型 | 您的企业模型已声明完成并放在架子上。 由于环境的变化，“完成的模型”很快就会过时，从而降低了模型的价值。 | 随着业务的变化，定期更新您的企业模型。 |
推荐资源
- 15 Agile Strategies for Enterprise Architecture
- Agile Enterprise Architecture
- Agile Modeling Core Practices
- Software Development Context Framework (SDCF)
- Agile Strategies for Enterprise Architecture (in Enterprise Architecture Trends 2007, Cutter Consortium)
- Core Practices for Agile/Lean Documentation
- Big Modeling Up Front (BMUF) Anti-Pattern
- Enterprise Architecture Anti-Patterns (Soumen Chatterjee)
- EUP Enterprise Architecture Discipline
- EUP Enterprise Business Modeling Discipline
- Initial High-Level Architectural Envisioning
- Initial High-Level Requirements Envisioning
- The "One Truth Above All Else" Anti-Pattern
- 15企业架构敏捷策略
- 敏捷企业架构
- 敏捷建模核心实践
- 软件开发上下文框架（SDCF）
- 企业架构的敏捷策略（2007年企业架构趋势，Cutter Consortium）
- 敏捷/精益文档的核心实践
- 大模型前方（BMUF）反模式
- 企业架构反模式（Soumen Chatterjee）
- EUP企业架构学科
- EUP企业商业建模学科
- 最初的高层架构构想
- 最初的高级要求展望
- “一个真理高于一切”的反模式
原文：http://agilemodeling.com/essays/enterpriseModelingAntiPatterns.htm
本文：https://pub.intelligentx.net/agilemodeling-enterprise-modeling-anti-patterns
讨论：请加入知识星球或者小红圈【首席架构师圈】
- 32 次浏览
SEO Title
agilemodeling ： Enterprise Modeling Anti-Patterns