「技术架构」EA874:技术架构的原则和标准

简介: 「技术架构」EA874:技术架构的原则和标准

企业技术架构中EA原则的应用

原则经常是正式EA工作的一部分。它们在个人决策和广泛适用且独立于具体决策的基本业务目标之间提供了更强的联系。原则是组织为激发最佳行为而选择的准则或最佳实践。它们很可能(在最高级别)被追溯到基本的业务需求和策略。如果使用得当,给定解决方案中的关键选择或决策应该可以追溯到解决方案的目标,特别是在创建过程中应用的原则,这些原则代表了IT组织(ITO)或IT中的特定参与者甚至业务的所有IT项目或解决方案的更一般的目标作为一个整体。这使得ITO能够提醒业务部门为什么要这样做,特别是在建议某个特定项目之外的问题应该影响该单个项目的预算时。毕竟,通过批准EA原则,企业表明这一原则是重要的;ITO只是在某一特定领域根据这一建议或愿望行事。

因此,对于企业技术架构或基础设施规划,在完成设计或模型(如技术模式和技术服务)之前,定义关键的ETA设计架构原则(DAPs)并就其达成一致也是很有用的。将ETA与整个EA(或IT)和业务原则联系起来有助于简化采用,并且坦率地说,有助于促进行为的真正变化



图1

原则(或其含义)应继承自更高层次的原则,并针对这些更具体和更实用的技术模型和/或基础设施设计进行专门化(或形成新的一般原则)。原则随后成为最高级别EA指导和更详细的ETA建模或基础设施设计工作之间的主要联系。直观显示连杆的矩阵是分析基于原理的分析或设计的连通性和完整性的常用工具。

优先原则

由于有许多原则可以帮助定义使用原则来管理或评估解决方案的规则,因此需要对原则进行一些优先级排序。在某些情况下,原则(或者至少是单独原则的含义)可能存在直接冲突。例如,组织可能有一个“低成本”原则,但也有一个“高可用性”原则-显然,在特定情况下,其中一个设计目标必须大于另一个。因此,必须对哪些原则应优于其他原则的某些预设决定进行定义。但是,对于任何给定的项目,所有原则都可以被项目目标覆盖。在这一点上,应该简单地指出,具体的项目要求或更一般的、先前商定的原则正在被具体拒绝,并指出这一决定可能产生的后果。至少这些原则没有被完全忽视。

使技术标准发挥作用

在许多组织中,技术标准被忽略。这在业务人员很少或根本不参与体系结构的企业中尤其常见。企业架构师总是在努力改变这种行为。

缺少的一个关键元素是架构和业务好处之间的链接。特别是,企业架构必须从业务策略中驱动。此链接为架构提供了适当的上下文,并允许在架构标准的好处和向项目授予标准豁免之间进行权衡。然而,架构仍然有许多障碍需要协商才能使这种连接有效。其中包括:

  • ·寻找商业战略
  • ·商业战略分析
  • ·获得架构的业务支持
  • ·制定适当的治理安排

获得企业架构的执行支持有一个重要的文化因素。另一个可能遇到的障碍是来自IT人员的阻力,他们经常对自己设计选择的限制感到不满。

为了克服这种阻力,建筑师可以做以下工作

1] 创建架构恐慌图-

架构恐慌图可以生动地传达降低IT产品组合复杂性的需要。下面是一个架构恐慌图的例子。



图2

2] 机会主义地选择项目——

寻找涉及多个业务部门变更的项目。这样的项目优化了跨多个业务单元运行的端到端业务流程,或者它可能正在构建一个通用的、企业范围的客户或产品视图。架构师必须警惕这些项目带来的机会,并主动提出一个解决方案,使他们能够推进自己的事业。在这一点上,建筑师必须务实。

3] 在企业中交朋友-

在项目中与企业建立良好的关系。尝试理解业务问题,并帮助提出解决方案,该解决方案也可能有助于为体系结构创建下一个迭代。

4] 在技术标准的制定中包括关键的利益相关者——

利益相关者为支持标准设置的评估和意见带来了有价值的视角。参与技术标准决策的制定必然会获得更高水平的支持,这意味着更愿意在实践中应用标准。

5] 积极主动地与项目合作-

架构师应该在项目.If架构师是项目高级设计团队的一部分,与项目中的所有利益相关者和人员建立了更健康的关系。

6] 使技术标准易于项目查找和使用-

这些标准必须易于通过企业内部网访问并清楚地记录在案。然后,将技术标准聚合到可重用的技术模式中,以解决特定的用途,例如大容量在线事务处理或友好和安全的客户Web访问。

相关文章
|
7月前
|
敏捷开发 缓存 架构师
Apache 架构师总结的 30 条架构原则
Apache 架构师总结的 30 条架构原则
82 0
|
7月前
|
设计模式 负载均衡 网络协议
【分布式技术专题】「分布式技术架构」实践见真知,手把手教你如何实现一个属于自己的RPC框架(架构技术引导篇)
【分布式技术专题】「分布式技术架构」实践见真知,手把手教你如何实现一个属于自己的RPC框架(架构技术引导篇)
290 0
|
4月前
|
存储 监控 安全
大数据架构设计原则:构建高效、可扩展与安全的数据生态系统
【8月更文挑战第23天】大数据架构设计是一个复杂而系统的工程,需要综合考虑业务需求、技术选型、安全合规等多个方面。遵循上述设计原则,可以帮助企业构建出既高效又安全的大数据生态系统,为业务创新和决策支持提供强有力的支撑。随着技术的不断发展和业务需求的不断变化,持续优化和调整大数据架构也将成为一项持续的工作。
|
5月前
|
NoSQL Redis UED
业务架构问题之在流程建模中,“定职责”的重要性是什么,流程建模中的交互设计原则是什么
业务架构问题之在流程建模中,“定职责”的重要性是什么,流程建模中的交互设计原则是什么
|
4月前
|
消息中间件 监控 Java
解锁Spring Cloud微服务架构的奥秘:深度剖析拆分原则,打造高内聚低耦合的业务创新引擎!
【8月更文挑战第3天】踏入微服务领域,Spring Cloud以丰富组件助力高效系统构建。微服务拆分需遵循原则确保系统高内聚低耦合且能适应变化。首要原则为单一职责,每个服务专注一个业务功能,降低复杂度并提高可维护性。其次,追求高内聚低耦合以减少服务间影响。围绕业务域拆分有助于保持逻辑清晰及团队协作。处理数据一致性问题时,考虑采用最终一致性模型。Spring Cloud提供Eureka、Zuul/Gateway、Sleuth和Config等工具支持服务发现、路由、跟踪及配置管理,共同构建灵活健壮的微服务架构。
91 2
|
5月前
|
存储 设计模式 前端开发
软件架构设计的原则与模式:构建高质量系统的基石
【7月更文挑战第26天】软件架构设计是构建高质量软件系统的关键。遵循高内聚、低耦合、单一职责等设计原则,并灵活运用分层架构、微服务架构、客户端-服务器架构等设计模式,可以帮助我们设计出更加灵活、可扩展、可维护的软件系统。作为开发者,我们应该不断学习和实践这些原则与模式,以提升自己的架构设计能力,为团队和用户提供更加优秀的软件产品。
|
4月前
|
边缘计算 Kubernetes 持续交付
构建高效后端系统:面向未来的架构设计原则
【8月更文挑战第8天】在技术飞速发展的今天,后端系统的架构设计显得尤为关键。本文将探讨如何通过采用微服务、容器化及自动化等现代技术手段,来构建一个可扩展、高可用且易于维护的后端系统。我们将深入分析这些技术背后的原理及其在实际场景中的应用,同时也会讨论如何在保障数据一致性和系统安全性的前提下,提升系统的响应速度和处理能力。
|
5月前
|
搜索推荐
业务系统架构实践问题之有效地实现“域间不可见”原则问题如何解决
业务系统架构实践问题之有效地实现“域间不可见”原则问题如何解决
|
5月前
|
监控 Java API
Java面试题:解释微服务架构的概念及其优缺点,讨论微服务拆分的原则。
Java面试题:解释微服务架构的概念及其优缺点,讨论微服务拆分的原则。
83 0
|
5月前
|
XML 缓存 API
REST原则、RESTful架构
REST原则、RESTful架构
53 0