什么是企业架构模式？
架构模式提供了解决可预测问题的通用方法。它描述了问题以及如何解决该问题。
我们将使用两种模式——CISR运营模式 和 扼杀者图案——探索共同的方法和可预测的问题。
每个尝试迁移 IT 产品组合的人都面临过遗留应用程序、遗留基础设施和遗留数据的问题。旧的流程、组织和管理使得部门很难改变。可预见的问题是，你如何在继续经营的同时继续前进？扼杀者模式提供了一种常见的方法——旧的方法被放在外观后面。随着时间的推移，新服务取代旧服务。
没有一种单一的运营模式适用于所有地方。可预见的问题是，如何组织部门、产品和服务？ CISR的运营模式提供了一个通用的方法——选择统一、协调、多元化或复制。
这些模式都没有告诉您具体如何进行。他们为您提供了通用的方法。他们确定了该方法的具体挑战。它们提供了一种架构模式。
架构模式被描述为“在一个实际情况下有用并且可能在其他情况下有用的想法”。
为什么企业架构模式很重要？
由于生产力的原因，企业架构模式很重要。我们知道生产力最高的企业架构师是 效果提高50-100倍 高于平均水平。 root被重新使用。使用模式意味着架构师不 白手起家。由于模式不是一个全面的解决方案，因此它有助于防止主题专家在不同情况下应用相同答案的常见陷阱。
使用架构模式有助于平衡 组织的个性 并分享行业挑战。企业架构模式通过提供确定性和理解来帮助决策。
使用架构模式的好处
架构模式提供了类似的好处 参考架构 和 企业架构框架。架构模式可提高生产力和信心。
我们使用架构模式来：
- 致力于最有效的改变，而不是重新发明轮子
- 提高架构克服困难并提供成功答案的信心
- 简化 架构权衡
- 级联首选答案和方法
- 增强对实施成功的信心
- 简化实施治理期间的解决方案评估
企业架构模式为您提供解决问题的模板。它们可以在不同的环境中使用，并为常见问题提供可靠的解决方案。它们提供一定程度的保证并帮助指导决策。
无论采用何种企业架构模式，其缺点都是不可避免的。在查看模式时，了解正在做出哪些权衡非常重要。
参考架构和架构模式之间的区别
架构模式和参考架构是所有领域都使用的概念 企业架构领域——业务、应用程序、数据、技术和安全。架构模式通常与应用程序或软件架构相关。
技术上存在区别 参考架构 和架构模式。然而，随着架构项目细节的变化，区别变得模糊。适用于 支持战略的架构或组合，看起来像是项目和解决方案交付的参考架构。简而言之，主要区别是：
- 问题范围：架构模式总是有问题。参考架构可能没有问题。这 绞杀者图案 永远不会被视为参考架构。
- 适应性：架构模式可以适应多个项目和领域。参考架构通常与特定上下文相关联。消费品供应链参考架构将很难适应。
- 领域特异性：参考架构通常是针对特定行业或技术而制定的。架构模式更加通用。
总之，架构模式为解决常见的架构挑战提供了高级指导和方法。我们的重点同时 创建企业架构 是提供有用的指导而不是担心语义差异。
企业架构模式的力量
企业架构模式告诉您解决可预测问题的常见且经过验证的方法。模式描述告诉您使用模式的挑战所在。您不必发明解决方案。您可以查看已知的解决方案并确定哪一个最适合您的企业。您可以将时间和技能集中在实现企业架构的好处上。
进一步实践最佳实践企业架构流程和方法
最佳实践 企业架构 从 Conexiam 导航
企业架构模式模板
在 导航，我们有一个用于记录架构模式的简单模板：
- 名称：一个标签 具有重要意义并牢牢记住
- 可预测的问题（用例）： 正在解决什么常见问题
- 方法： 描述如何实现预期目标和目的
- 硬点： 需要做哪些工作或限制会影响成功使用模式
架构模式存在于所有架构领域
架构模式可以用于软件和应用程序架构之外的其他领域。应用技术——解决可预测问题的通用方法。
以下是如何在应用程序架构之外应用架构模式的一些示例：
- 业务架构模式：针对像提高效率这样的问题，他们提供了通用的方法。数字化模式和精益改进模式有不同的方法来解决同一问题。
并购 (M&A) 模式：针对合并等问题，他们提供了通用方法。市场多元化模式将以不同于地理扩张模式的方式定义业务流程、组织、关键能力、关系和信息流。
- 技术架构模式：针对 IT 现代化等问题，他们提供了三层模式或无服务器模式等基础设施设计方法。这些模式定义了已知有效的可扩展且可靠的基础设施的截然不同的方法。这些模式之间的选择将基于上下文和硬位。
- 数据架构模式：考虑到个人信息和国家数据保护等问题，他们提供了类似 Data Masking Pattern 的模式。此模式提供了一致的方法来替换和模糊无法访问的数据。
- 安全架构模式：考虑到保护 IT 系统免受威胁的问题，他们提供了零信任模式或不可变基础设施模式等模式。这些模式解决了重叠的安全问题。
- 应用程序架构模式：有一组丰富的应用程序架构模式。从四人帮开始。许多经典的应用程序模式都解决了软件设计问题。应用程序架构模式可以基于设计，例如桥接模式；现代化方法，如绞杀者模式，或获取，如模块化系统获取模式。现代化和采购模式可以很容易地适应业务和基础设施问题。
- 系统获取模式：考虑到管理成本等问题，他们提供了不同的方法来获取 IT 系统。供应商整合模式和开源采用模式提供了截然不同的 IT 成本管理方法。和其他人一样 架构替代方案，这些模式之间的选择将基于上下文和硬位。
- 企业架构和敏捷参与模式：我们在什么时候使用这些 发展 EA 团队。取决于 企业架构用例 和 治理需要，敏捷有不同的参与模式。
虽然不同领域的术语和细节可能有所不同，但架构模式的概念（为常见问题提供可重用的、经过验证的方法）是通用的。
企业架构师的好处始终是生产力和质量。架构师可以简化他们的工作、提高效率并确保遵循最佳实践。关键是要调整和定制这些模式，以适应特定领域的独特要求和约束。
企业架构培训和TOGAF培训
Avolution ABACUS 培训课程
Avolution ABACUS 培训 有效的企业架构依赖于正式的建模和分析。我们提供来自实践企业架构师的 Avolution ABACUS 培训。学生在此获得创建集成企业和域架构的技能和知识[...]
TOGAF企业架构培训课程
您想要 TOGAF 认证培训吗？通过 TOGAF 认证展示您的企业架构知识 TOGAF® 企业架构培训课程 通过 TOGAF 标准第 10 版，向成为更好的企业架构师迈出重要一步 [...]
企业架构师的 Kickstart
企业架构师的快速启动 我们需要保持技能与时俱进。现在比以往任何时候都更加需要。使用企业架构快速启动来提高您提供变革性企业架构的能力。这个为期 90 天的快速启动是 Conexiam Consulting 的 […]
业务架构模式
业务架构模式是构建组织的可重用方法。组织使用这些模式来调整其业务目标、运营和技术，以提高效率和创新。以下是一些常见的业务架构模式：
- 数字化（业务流程自动化）模式
可预测的问题-提高效率
方法—自动化日常和手动业务 - 精益改进模式
可预测的问题—提高效率和质量
方法—遵循精益原则和六西格码方法逐步改进业务流程。 - 生态协作模式
可预测的问题——与外部合作伙伴、供应商、客户和利益相关者的协作方法
方法—在生态系统内进行协作
这些模式帮助企业理解、改进和调整其运营和战略。组织可以调整和组合这些模式，以适应其特定的业务目标和挑战。
业务架构并购 (M&A) 模式
业务收购模式是公司获得其他业务的方式。这些模式可帮助组织实现并购及其战略目标。以下是业务收购模式的一些示例：
- 垂直整合模式
可预测的问题—加强对供应链的控制，降低成本，提高效率
方法—通过供应链寻找收购，确保每一步的控制，调整供应链以使用内部步骤，追求端到端的效率 - 市场多元化格局
可预见的问题——与市场波动和经济衰退相关的风险
方法-收购不同市场或行业的企业，以减少对单一细分市场的依赖，然后进行交叉销售 - 技术获取模式
可预见的问题——与创新技术开发和落后竞争对手相关的风险和时间
方法 —重点收购开发新技术的组织，然后将技术整合到现有和新业务中 - 客户群拓展模式
可预测的问题—不断增长的客户群的风险、时间和成本
方法-收购在新地区和市场拥有成熟客户群的组织 企业收购具有强大品牌知名度或规模较大的公司 - 协同驱动模式
可预测的问题——获得规模效益
方法-重点收购赢得了在市场、产品和价值主张方面相似的组织，然后标准化运营以实现规模和效率 - 地理扩张模式
可预测的问题——将业务扩展到新地区的风险、时间和成本
方法—重点收购具有类似产品和服务以及新地区价值主张的目标。然后合理化产品、服务和运营 - 周转（不良资产）模式
可预见的问题——以可接受的速度增长股东价值
方法-收购陷入困境或陷入困境的企业，然后运用管理专业知识和资本来扭转它们 - 能力模式
可预见的问题——与开发业务能力相关的风险、成本和时间
方法 —识别关键能力差距并将收购重点放在展示能力的组织上，然后用所获得的能力取代现有的组织、流程、技术和知识产权
这些业务收购模式是解决可预测问题的已知方法。模式的选择取决于公司的战略目标和行业格局。
下载 TOGAF 标准简介，第 10 版
下载 TOGAF® 标准第 10 版简介 TOGAF 标准第 10 版使企业架构最佳实践的采用变得更加容易。它将通用概念与经过验证的最佳实践区分开来。标准强调在哪里 […]
下载 TOGAF 和 SABSA 集成
下载 TOGAF 和 SABSA 集成 将世界上最好的安全架构框架 SABSA 和行业标准企业架构框架 TOGAF 结合在一起。下载 TOGAF 和 SABSA 集成 TOGAF 和 SABSA 集成包括 SABSA 使用 [...]
企业架构和敏捷参与模式
企业架构和敏捷结合起来可以降低风险。架构用于在开始实施之前降低风险和成本。开始实施后，敏捷可以降低风险和成本。
我们在工作时创建了企业架构和敏捷参与模式 数字化转型 项目：
- 定义敏捷方法模式
- Sprint 模式中的指导待办事项列表
- 指导产品模式的路线图
可预测的问题：拥有集成的跨产品路线图。
方法：使用 架构路线图技术 产品或产品系列代替产品组合。确保正常的产品报告包括过渡状态的活动。 - 指导史诗模式的路线图
可预测的问题：使用史诗将自上而下的结果和约束实施到产品中。
方法：在一个 架构路线图技术 产品或产品系列代替产品组合。确保正常的产品报告包括过渡状态的活动。 - 企业价值格局
可预测的问题：确保过渡和目标状态中包含的关键成功因素可以指导敏捷的待办事项整理和史诗般的规划。
方法：将自上而下的措施和目标转化为敏捷待办事项整理的可消耗标准。确保正常的产品报告包括活动选择和完成规定值。 - 限制“自下而上”的产品负责人模式
可预测的问题：产品所有者通过产品及其直接用户的视角来看待整个企业。
方法：记录生态系统中的产品和角色。记录适用于产品的限制。记录评估标准。确保正常的产品报告包括过渡状态的进展以及与企业价值一致的活动。
- 指导产品模式的路线图
- 约束冲刺模式
- 验收标准模式
可预测的问题：确保软件符合企业架构规范和标准。
方法：提供适用于史诗结束和发布之前的强制性验收标准。我们经常使用 应用程序架构模式 和 数据架构模式 创建验收标准。在所有测试报告中包括强制性验收标准。 - 价值（测量和休息点）模式
可预测的问题：了解什么是有价值的以及如何衡量价值。
方法：企业架构需要明确如何描述和衡量价值。价值陈述需要关键成功因素 (CSF) 和有效性衡量标准 (MoE)。确保价值衡量包含在产品、史诗和发布报告中。 - 未开发、进化或革命模式
可预测的问题：确保遵循实施策略。
方法：使用产品路线图和发布周期来强制方法发生根本性改变。 - 约束接口模式
可预测的问题：识别所需的接口并确保它们被使用。
方法：将自上而下的工作重点放在接口和共享数据结构上。通过史诗和发布周期提供需求。使用验收标准。我们经常使用 应用程序架构模式 和 数据架构模式 到稍微具体的接口。在所有测试报告中包括接口一致性。
- 验收标准模式
- 解决依赖模式
- 解锁投资组合模式
可预测的问题：数字产品组合之间的冲突阻碍了多个产品的进展。
方法：使用企业架构技术来找到允许进展的最小更改。 - 识别真正的利益相关者模式
可预测的问题：确定真正的利益相关者，他们可以在复杂的内部产品组合中提供指导和批准。
方法：使用企业架构技术来识别利益相关者和利益相关者代理、关注点和偏好。使用企业架构技术 备择方案 和 权衡 指导利益相关者做出指导产品组合的决策。确保有效的数字投资组合治理。 - 跨越投资组合模式
可预测的问题：本地优化的战术决策无法成为有效且可持续的数字生态系统。
方法: 保持足够即可 应用架构 和 数据架构。推动该架构中的组织优先级。应用程序架构需要关注共享服务和接口。数据架构必须关注主数据、参考数据和高安全级别的数据。需要元数据描述。使用指定生态系统方法的架构模式。 - 发布影响模式
可预测的问题：足够的架构意味着在发布之前不会发现每一个意外情况、每一个约束、每一个冲突。
方法：在决议期间将双手插在口袋里等待叫号。除非接到电话，否则请在事件审查期间等待参与，以找出您未能识别可预测问题、低估风险或错过测试要求的地方。
- 解锁投资组合模式
这些参与模式用于指导 EA 团队的参与。
数据架构模式
数据架构模式是解决组织中常见数据问题的技术。这些模式提供了一种结构化的数据建模、存储、处理和集成方法。以下是一些标准数据架构模式：
- 数据湖模式
可预见的问题——将大量数据转化为有用的信息和可操作的见解
方法—开发数据湖（大型原始数据存储、数据目录、数据处理和数据访问层）以及使用数据湖的数据分析能力 - 主数据管理 (MDM) 模式
可预测的问题—改进业务操作系统中数据的集成和重用
方法—为端到端操作系统开发主数据和参考数据、数据治理和数据质量 - 数据中心模式
可预见的问题——集成不同系统之间的数据
方法—集中数据集成和转换逻辑，为数据消费者提供单点访问。 - 数据复制模式
可预测的问题—在具有地理访问和性能问题的不同系统之间集成数据
方法— 近乎实时地将数据从一个源复制到一个或多个目标系统。
这些是各种行业和环境中使用的一些标准数据架构模式。企业架构师使用这些模式来解决他们的数据管理问题。
安全架构模式
安全架构模式是解决 IT 系统和网络安全问题的可重用方法。组织使用这些模式来实施保护其资产、数据和操作的安全措施。以下是一些常见的安全架构模式：
- 周边安全模式
可预测的问题—防止未经授权的访问和网络攻击
方法—在网络或系统周围建立安全边界，以保护其免受外部威胁 - 零信任模式
可预测的问题—防止未经授权的访问和网络攻击
方法-微分段网络和应用程序，建立身份和访问管理（IAM）、持续身份验证和严格的访问控制。 - 不可变的基础设施模式
可预测的问题—防止未经授权的访问和网络攻击
方法—将基础设施视为代码并替换（重建）已部署的基础设施，而不是修补或修改它们，从而减少漏洞。 - 数据屏蔽和编辑模式
可预测的问题—保护敏感数据免遭泄露
方法—用非敏感信息替换或编辑敏感数据，同时仍然允许授权用户执行其任务。
这些安全架构模式为设计安全系统和网络提供了基础。组织可以使用这些模式来满足其独特的安全需求。
基础设施架构模式
基础架构架构正在设计支持组织 IT 基础架构的技术组件和系统。这些模式帮助组织构建可扩展、可靠且高效的技术环境。以下是一些常见的基础设施架构模式：
- 分层基础架构模式
可预测的问题——技术系统的模块化、可维护性和可扩展性
方法-将基础设施分为不同的层，每个层负责特定的功能，例如表示、应用程序逻辑和数据存储。 - 高可用性 (HA) 和冗余模式
可预测的问题——系统可用性、容错性和可维护性
方法——重复的关键组件和服务。 - 横向扩展架构模式
可预测的问题——技术系统的模块化、可维护性和可扩展性
方法- 通过添加更多实例或节点来处理增加的工作负载进行扩展 - 无服务器架构模式
可预测的问题——技术系统的模块化、可维护性和可扩展性
方法- 自动分配和扩展基础设施资源以响应事件 - 混合云模式
可预测的问题—提高应用程序开发和技术系统的模块化、可维护性和可扩展性
方法—通过公共云和本地环境将基础设施作为自动化服务提供
这些基础架构模式为组织提供了设计可扩展、可靠和安全的技术环境的指南和最佳实践。组织使用这些模式来满足其特定的基础架构要求和目标。
应用程序架构模式
最经典的应用程序架构模式是软件设计模式。四人帮应用程序设计模式在软件工程中众所周知。它们在《设计模式：可重用面向对象软件的元素》一书中得到了介绍。
- 微服务模式
可预测的问题—应用程序组合的敏捷性、可扩展性和维护
方法—将应用程序分解为可以独立开发、部署和扩展的小型独立服务 - MVC（模型-视图-控制器）模式
可预测的问题——代码组织、可维护性和可测试性
方法— 将应用程序分为三个互连的组件 — 模型（数据和业务逻辑）、视图（用户界面）和控制器（处理用户输入并相应地更新模型和视图） - 绞杀模式/绞杀模式
可预测的问题—替换遗留系统
方法—通过围绕现有遗留系统构建新组件来逐步替换或“扼杀”现有遗留系统，以逐步替换系统
四人帮应用程序设计模式分为三种类型：创建模式、结构模式和行为模式。以下是四人帮设计模式的概述：
四种应用程序创建模式组合
- 单例模式- 确保一个类只有一个实例并提供对该实例的全局访问点
- 工厂方法模式—定义用于创建对象的接口，但允许子类更改将创建的对象的类型
- 抽象工厂模式— 提供用于创建相关或依赖对象系列的接口，而无需指定它们的具体类
- 建造者模式——将复杂对象的构造与其表示分离，允许相同的构造过程创建不同的表示
- 原型模式- 通过复制现有对象（称为原型）来创建新对象，而不是从头开始创建它们
四帮应用结构模式
- 适配器模式—允许现有类的接口用作另一个接口，使其与期望不同接口的客户端兼容
- 桥梁图案——将对象的抽象与其实现分开，以便它们可以独立变化
- 复合图案——将对象组合成树结构来表示部分-整体层次结构。客户可以统一处理单个对象和对象组合
- 装饰模式- 动态地将额外的职责附加到对象上装饰器为扩展功能提供了子类化的灵活替代方案
- 立面图案——为子系统中的一组接口提供简化的接口，使其更易于使用
- 享元模式——通过尽可能多地与相似对象共享来最大限度地减少内存使用或计算费用
四种应用程序行为模式组
- 观察者模式—定义对象之间的一对多依赖关系，以便当一个对象更改状态时，其所有依赖项都会收到通知并自动更新
- 命令模式- 将请求封装为对象，从而允许使用队列、请求和操作对客户端进行参数化
- 策略模式—定义一系列算法，封装每个算法，并使它们可以互换。客户可以动态选择要使用的算法
- 责任链模式—沿着处理程序链传递请求。收到请求后，每个处理程序决定处理该请求或将其传递给链中的下一个处理程序
- 状态模式——允许对象在其内部状态改变时改变其行为该对象似乎改变了它的类
- 命令模式— 将操作表示为对象，允许使用队列、请求和操作对客户端进行参数化
- 解释器模式—定义用于解释语言的语法并提供解释器来解释该语言的句子
这些应用程序架构模式为开发软件应用程序以满足特定要求和挑战提供了指导和最佳实践。四人帮模式是常见软件问题的设计解决方案。建筑师将 将这些模式指定为约束.
系统获取模式
获取模式通常是指获取新技术、系统或资产以支持组织目标的既定方法。它们通常用于企业架构策略和组合用例。这些模式可帮助组织就其技术投资和收购做出明智的决策。以下是获取模式的一些示例：
- 供应商整合模式
可预测的问题—复杂的供应商管理、不断增长的成本
方法—通过将多个合同和服务整合到较小的供应商下来减少技术供应商的数量 - 云优先采购模式
可预测的问题—可扩展性、本地复杂性和灵活性
方法—在获取新技术或更换旧系统时优先考虑基于云的解决方案和服务。 - 开源采用模式
可预测的问题——创新、成本和灵活性
方法——积极寻求开源软件解决方案 - 模块化系统获取模式
可预测的问题——企业敏捷性、集成性和可扩展性
方法—获取以模块化方式设计的系统或技术，允许扩展和定制 - 战略合作模式
可预测的问题-风险
方法—与技术提供商或其他组织建立战略合作伙伴关系，共同开发或共同投资创新解决方案
这些获取模式为组织提供了一种制定技术相关决策的系统方法。
系统采集模式代表常见的业务 情景分析中使用的选择.
结论企业架构模式
企业架构模式提高了企业架构师的生产力。架构模式还提高了他们的工作质量。重复利用是生产力和质量的根源。架构模式提供了解决可预测问题的已知成功方法。使用架构模式，您可以专注于确定最佳更改而不是方法。
在我们的 企业架构咨询 我们使用我们的企业架构模式库。我们始终致力于提高企业架构师的生产力。我们有更多的时间来研究不同的架构选项，并帮助利益相关者选择正确的架构。我们有时间解决利益相关者的标准并制定 架构视图 改善决策。最多 企业架构的重要组成部分 通过提高对变革的理解和信心来指导有效的变革。
架构模式存在于所有架构领域中。利用的力量 企业架构模式 在你的工作中。您的第一步是查看您的 企业架构用例 并从您可预见的问题开始 EA 团队旨在解决.
