【集成架构】速度分层的集成架构,支持企业的数字化唤醒

简介: 【集成架构】速度分层的集成架构,支持企业的数字化唤醒

在自适应企业中实现整合

在现代企业中,很难看到统一整个环境的单一整体应用程序。虽然仍然可能存在大型主机或其他系统来保存组织的主要数据和事实来源(SoT),但如今大多数环境都具有满足各种业务功能的中型到大型应用程序。根据企业的规模和复杂程度,这些应用程序可以从少数应用程序到数百种应用程序。

虽然很明显集成成本随着应用程序的数量而增加,但人们也可以争辩说,随着您逐渐远离“一个应用程序完成所有”模型,变更成本会降低。这一论点背后的原因是,每一次变化,无论多小,通常都会导致整体应用程序的完全重新部署,并且必然会导致整个系统的回归测试成本。


但除了成本和应用数量之外,还有一个额外的维度需要考虑 - 时间。并非所有应用都是平等的。任何架构图的问题在于它代表了历史中的单个点 - 它本质上是一个快照。现实是应用程序随时间而变化; 一些已升级,另一些已修改或扩展,其他可能被删除或替换。这些应用程序的变化率各不相同,因为有些系统的变化速度比其他系统慢。这可以在分层视图中表示:


应用程序架构中的层概念并不新鲜;大约十年前,Gartner创建了Pace分层应用战略,以解决业务领导者(他们希望系统灵活并适应业务环境变化)与IT所有者(通常希望系统保持一致)之间的共同脱节。他们运行顺利)。识别这些不同的变化率并相应地对应用程序进行分组有助于应用适当级别的治理,变更控制,测试和DevOps - 使业务能够在需要的地方进行创新,同时保护其关键数据和核心流程。

了解Pace-Layered Architecture

Gartner的Pace-Layered模型由三层组成:

记录系统(SOR) -

这些系统支持组织的核心功能,没有这些功能,企业就无法运行。由于这些通常是整个行业的标准,因此这些功能并非给定品牌或业务所独有(例如,每家银行都需要管理帐户,交易,客户等)。因此,这些系统通常是供应商提供的商业现货(COTS)产品。由于组织的核心能力不会经常发生变化,因此这些系统也不会发生变化 - 变化是递增的,而且速度很慢。

差异化系统 -

虽然核心功能在同一行业中从一个组织到另一个组织的变化不大,但业务流程确实如此。例如,您的银行和我的银行都可以提供贷款,但这两家银行处理贷款的方式可能会有所不同。此层中的应用程序代表使组织独一无二的流程,并且通常不会由供应商提供的记录平台系统开箱即用。业务流程可能不会每天都在变化,但它们确实比核心功能更快地发生变化,例如简化流程和/或整合新技术。

创新系统 -

这一层移动速度最快。这是测试新想法和技术的“沙坑”。这里的实验可能包括特定的概念验证(PoC)应用程序,这些应用程序可以快速开发,然后手动部署和测试。


图片基于Michael Guay(Gartner)的演讲

让我们看一个示例企业,例如银行机构,看看他们的一些应用程序如何映射到速度分层模型。

系统/应用 特点
记录系统 ABC银行有几个关键系统,包括核心银行系统,贷款管理系统和文件库。
  • 这些系统由供应商提供和安装。
  • 预计它们的寿命很长(例如7  -  10年)
  • 变更控制非常严格,数据受到严密保护。
  • 系统受到立法机构的审计。
差异化系统 自动贷款处理功能由定制的集成解决方案管理,该解决方案集成了多个外部SaaS服务,用于房地产估价,标题搜索,信用评分和在线Web表单提供程序。
  • 该解决方案通过大型项目的多个阶段提供。
  • 预计中等寿命(3  -  4年)。
  • 修复和变更请求通过BAU团队进行管理。
创新系统 ABC银行希望提供一个基于聊天的界面,用于提供由智能机器人提供支持的贷款申请。
  • 概念验证解决方案采用最少的功能构建并手动部署
  • 它由一小部分客户进行测试。
  • 在解决方案稳定之前,无需正式的变更控制流程即可快速完成调整和错误修复。
  • 经过几个月的试用后,决定是将解决方案推进到完全成熟的应用程序还是取消该计划。


在Pace-Layered架构中集成

现在我们了解了分步模型,我们如何在其中实现集成?让我们看一下API / Services的逻辑模型如何看待它们如何在各层之间组合成应用程序:


从底层开始,我们看到每个记录系统通常是一个包含多个服务/ API的包。但是,由于与逻辑数据模型,过时协议或其他原因不一致,这些API可能无法由业务直接使用。在这些情况下,最好引入API的“子层”,将SoR与组织内的其他API联系起来。这些抽象API(称为产品适配器)与底层SOR紧密耦合,但以更加可口的格式公开功能。它们还可能引入比SOR本身更严格的访问控制,验证和安全性。API通常代表核心数据实体(客户,产品,订单等),因此它们是粒度的并且是为可重用性而设计的。因为它们与核心系统紧密相连,所以它们以相同的速度移动,因此被认为是记录系统层的一部分。由于数据的重要性以及使用这些API的服务和流程的高度依赖性,治理和变更控制在此级别通常会非常严格。

在差异化系统层中,我们看到的应用程序由源自记录系统层的粒度服务/ API以及可能的外部API组成。这是组织的业务逻辑所在的位置,例如贷款处理或用户供应。应用程序可以在此层中执行的功能包括数据聚合,路由,过滤以及通常编排/编排。由于它们特定于进程,因此它们可能比它们可能使用的底层SOR API更不可重用。在该层中,组织内的大部分集成发生。而且由于业务流程可以(并且将会)随着时间的推移而发生变化,因此这些应用程序也需要进行调整,而且肯定会比SOR应用程序更快地进行调整。治理也应该在这个层面上应用,尽管可能不像SOR层那样严格;组织希望他们的业务流程足够灵活,以适应效率的提高和功能的扩展。

创新系统层还具有同时使用SOR API和外部API的应用程序,以及可能在差异系统层中使用业务流程的应用程序。作为最快的移动层,它将具有更轻的治理,以促进新应用程序和技术的实验。此层中启用的功能通常是业务核心功能的外围设备,因此在发生故障时可以降低组织的风险。此外,为了证明概念而快速创建的应用程序很少会采用自动化测试或成熟的CI / CD管道,因为它们将被手动部署和测试。

最后,我们使用消息总线以便促进层间和层内通信。异步消息传递模式(如发布 - 订阅)可以使系统松散耦合,并提高可扩展性和灵活性。发布者无需了解订阅者的任何信息,您可以随时添加或减少订阅者,而不会破坏现有的集成。消息总线是润滑不同速度变化的应用之间摩擦的关键因素。

此图提供了几个属性的横截面视图以及它们在各个层之间的变化:


Microsoft如何帮助实现Pace-Layered Integration?

Microsoft提供一系列服务和产品,包括本地和云端,以帮助构建功能强大的集成解决方案,以应对企业应用程序层的不同步伐。在这里,我们将仅讨论其中一些产品以及它们如何适应速度分层架构(请注意,有许多可能的解决方案;这些建议只是一种可能的方式来看待这一点):


记录系统层

以下产品非常适合在SOR应用程序之上构建API层:

技术  场景 考虑

产品

APIs

  • 产品具有粒度API和现代界面
  • API符合业务需求
  • 供应商支持可用

+与记录系统紧密集成

 - 更改或定制困难或昂贵

 - 可能不适合业务数据模型

Web

服务

/REST 

API


  • 公开REST或SOAP接口
  • 实现自定义验证/安全性
  • 映射到规范模型

+主机价格低廉

+易于消费

+可以在本地或Azure(IaaS)托管

 - 需要开发工作

API管理
  • 在云中公开API
  • 实施基于策略的安全性和访问控制
  • 利用缓存/审计/分析/等。

+可定制的外观

+开发者门户促进了新的应用创建

 - 需要VNet集成 - 没有本地选项

 - 如果不使用其他功能,则选择昂贵的选项

Service Fabric
  • 与微服务架构对齐
  • 迎合多种编程语言
  • 自动冗余,负载平衡和
  • 无需停机部署

+可以在任何地方托管

+支持容器

 - 需要大量开发工作(不提供OOTB软件组件)

BizTalk Server
  • OOTB适配器可用/适用
  • 需要强大的平台

+ BAM跟踪可用

+单一平台集成

 - 昂贵的选择

 - 需要专业的开发技能

 - 未来的支持模型


差异化系统层(System of Differentiation Layer)

这些产品能够实现业务逻辑,提供与内部和外部应用程序和服务的连接,并支持跨云和本地应用程序的混合连接:

技术 场景 考虑
Logic Apps
  • 业务逻辑可以是云托管
  • 连接SaaS系统或其他Azure服务

+快速发展

+超过200个内置连接器!

 - 没有VNet支持(直到ISE可用)

 - 没有本地选项(尚未)

Azure Functions
  • 需要按需运行离散的无状态任意代码片段
  • 与其他Azure服务集成
  • Visual Studio开发是首选
  • 自动化单元测试是必须的

+良好的CI / CD支持

+ VNet支持

+可以在本地运行

 - 没有Logic Apps那么多的连接器

Web/Mobile Apps
  • 云托管是理想的
  • 支持多种设备
  • 需要灵活的编程模型
  • 需要接触外部客户
  • 期待 Blue / Green部署插槽

+良好的CI / CD支持

+众多部署选项

+支持Azure Relay / VNet集成

 - 对于长时间运行的过程本身并不理想

 - 考虑混合应用程序的安全层

Service Fabric
  • 与微服务架构对齐
  • 迎合多种编程语言
  • 需要自动冗余,负载平衡和无停机时间部署

+可以在任何地方托管

+支持容器

 - 需要大量的开发工作

 - 基础设施投资(仅限本地)

BizTalk Server
  • OOTB适配器可用/适用
  • 需要强大的平台
  • 需要可靠/耐用的工作流程功能
  • 利用业务规则引擎和/或BAM

+单一平台进行整合

+可以在本地或Azure(IaaS)托管

 - 昂贵的选择

 - 需要专业的开发技能

 - 未来的支持模型


创新系统层

在这里,我们需要能够将技术范围扩展到人工智能,预测分析和业务洞察领域,同时实现快速(甚至临时)开发。这里有很多可能性,因为与使用它的方式相比,它更少涉及您使用的技术。但这些产品都非常适合创新的解决方案:

技术 场景 考虑

Microsoft

Flow

  • 自动化简单的流程和任务
  • 使业务用户能够创建自己的集成
  • 现有连接器适合用途

+快速发展

+可以轻松迁移到Logic Apps

*需要Office365

Power 

Apps

  • 开发设备的内部应用程序
  • 利用内置连接器

+与Flow / SharePoint /轻松集成

    Dynamics 365 /团队/等

+多平台

*需要Office365

Power BI
  • 需要快速构建自定义图表和视觉效果
  • 与多个数据源集成
*依赖于对数据源的访问
Cognitive Services
  • 寻求高级见解和分析能力

+提供多种服务/ API(Vision,Knowledge,

     语言,语音,搜索)

*需要编程技能

Machine Learning
  • 通过预测分析寻求见解
*需要数据科学技能
Bots
  • 寻求与客户的更多人际互动
  • 自动化例行信息检索或路由到适当的支持人员

*需要编程技能

*机器人需要经过良好的训练才能按预期运行


消息总线

如果您主要集成本地系统,BizTalk Server的核心是一个功能强大的消息传递引擎,它不仅可以支持全部的消息传递模式,还可以提供几个开箱即用的连接器以实现连接。强大的业务流程自动化功能 这就是它在很多层中的特征。然而,当在云中集成时,Azure Service Bus为企业消息传递,大数据流,事件处理和混合连接提供了许多产品:

技术 场景 考虑
Event Grid
  • 构建事件驱动的应用程序
  • 管理通知
  • 需要高可扩展性和吞吐量
  • 处理Azure(或任何地方)内的事件

+弹性(重试最多24小时)

+推 - 推模型

+易于集成

*小消息大小

Event Hubs
  • 摄取大数据/流数据
  • 需要重播/存档

*至少需要一个下游处理器

 - 没有本地选项

Relays
  • 需要混合连接,无需更改防火墙
+可以使用混合连接或WCF中继
On-Prem Data Gateway
  • 将逻辑应用程序连接到本地系统
  • 将SaaS应用程序桥接到LOB系统

+如果使用Logic Apps,则可以替代VNet

 - 仅少数Logic App连接器支持

Service Bus Queues
  • 解耦发送方/接收方进程
  • 每条消息只应处理一次
  • 数据可以流经云端

+极具弹性和功能齐全

 - 没有本地选项

Service Bus Topics
  • 通过pub / sub解耦系统/进程
  • 支持多个订阅者的消息
  • 数据可以流经云端

+极具弹性和功能齐全

 - 没有本地选项

BizTalk Server
  • 需要强大的发布/订阅消息
  • 利用BAM进行跟踪
  • 使用OOTB适配器
  • 仅限于本地解决方案

+单一平台进行整合

 - 昂贵的选择

 - 需要专业的开发技能

 - 未来的支持模型

提示和最佳实践

以下是有关如何在步调分层的企业架构中维护自适应集成的一些技巧。

考虑如何使用您正在集成的应用程序。

  • 整合任务是否至关重要?那么Logic Apps将是比Microsoft Flow更好的选择。
  • 需要考虑哪些安全风险?API管理层可以提供基于策略的治理,威胁防护和访问控制。
  • 解决方案有多快变化?这将影响自动化测试,CI / CD管道等方面的投资。

确保您的系统记录图层是可靠的。

  • 您的API是否足够精细且定义明确?请记住,这些将构成其他层中应用程序的可组合单元。
  • 是否强制执行安全性和数据验证?不要依赖消费者;保护您的关键数据靠近源!

限制每个记录系统中的自定义

  • 如果您自定义SOR,下一次供应商升级会发生什么?
  • 尽可能地使用差分系统层进行自定义,或者至少在每个SOR的API层中进行自定义。

考虑使用规范数据模型来避免与供应商系统紧密耦合。

  • 这通常需要声音信息架构来定义业务数据实体。
  • 信息架构师可以构建独立于软件实现的逻辑模型;投资于此。

松散地耦合层间通信。

  • 垂直依赖性很难维护 - 除非您是整个堆栈的所有者。
  • 尽可能选择发布 - 订阅消息传递模型,以最大化松散耦合和可扩展性。

留出创新空间!

  • 在每一层采用适当的治理级别。避免严格的变更控制政策,实验既必要又安全。
  • 使业务负责人能够创建自己的解决方案(例如,使用Microsoft Flow自动化普通流程)。
  • 鼓励实验!使用Microsoft iPaaS功能实现“以业务速度进行集成”(Jim Harrer,Microsoft)。
相关文章
|
29天前
|
边缘计算 Cloud Native 安全
构建灵活高效的下一代应用架构 随着企业数字化转型的加速,云原生技术正逐渐成为构建现代化应用程序的关键支柱。
随着企业数字化转型加速,云原生技术逐渐成为构建现代化应用的关键。本文探讨了云原生的核心概念(如容器化、微服务、DevOps)、主要应用场景(如金融、电商、IoT)及未来发展趋势(如无服务器计算、边缘计算、多云架构),并分析了面临的挑战,如架构复杂性和安全问题。云原生技术为企业提供了更灵活、高效的应用架构,助力数字化转型。
63 4
|
1月前
|
缓存 Devops jenkins
专家视角:构建可维护的测试架构与持续集成
【10月更文挑战第14天】在现代软件开发过程中,构建一个可维护且易于扩展的测试架构对于确保产品质量至关重要。本文将探讨如何设计这样的测试架构,并将单元测试无缝地融入持续集成(CI)流程之中。我们将讨论最佳实践、自动化测试部署、性能优化技巧以及如何管理和扩展日益增长的测试套件规模。
48 3
|
29天前
|
人工智能 前端开发 JavaScript
前端架构思考 :专注于多框架的并存可能并不是唯一的方向 — 探讨大模型时代前端的分层式微前端架构
随着前端技术的发展,微前端架构成为应对复杂大型应用的流行方案,允许多个团队使用不同技术栈并将其模块化集成。然而,这种设计在高交互性需求的应用中存在局限,如音视频处理、AI集成等。本文探讨了传统微前端架构的不足,并提出了一种新的分层式微前端架构,通过展示层与业务层的分离及基于功能的横向拆分,以更好地适应现代前端需求。
|
28天前
|
运维 供应链 安全
SD-WAN分布式组网:构建高效、灵活的企业网络架构
本文介绍了SD-WAN(软件定义广域网)在企业分布式组网中的应用,强调其智能化流量管理、简化的网络部署、弹性扩展能力和增强的安全性等核心优势,以及在跨国企业、多云环境、零售连锁和制造业中的典型应用场景。通过合理设计网络架构、选择合适的网络连接类型、优化应用流量优先级和定期评估网络性能等最佳实践,SD-WAN助力企业实现高效、稳定的业务连接,加速数字化转型。
SD-WAN分布式组网:构建高效、灵活的企业网络架构
|
13天前
|
Kubernetes Cloud Native 云计算
云原生技术深度解析:重塑企业IT架构的未来####
本文深入探讨了云原生技术的核心理念、关键技术组件及其对企业IT架构转型的深远影响。通过剖析Kubernetes、微服务、容器化等核心技术,本文揭示了云原生如何提升应用的灵活性、可扩展性和可维护性,助力企业在数字化转型中保持领先地位。 ####
|
13天前
|
运维 Cloud Native Devops
云原生架构:重塑企业IT的未来####
随着数字化转型浪潮的汹涌,云原生架构凭借其高度灵活、可扩展和高效的特性,正逐步成为企业IT系统的核心。本文将深入探讨云原生架构的核心要素、技术优势以及如何引领企业实现业务创新与敏捷交付。 ####
|
1月前
|
存储 人工智能 算法
精通RAG架构:从0到1,基于LLM+RAG构建生产级企业知识库
为了帮助更多人掌握大模型技术,尼恩和他的团队编写了《LLM大模型学习圣经》系列文档,包括《从0到1吃透Transformer技术底座》、《从0到1精通RAG架构,基于LLM+RAG构建生产级企业知识库》和《从0到1吃透大模型的顶级架构》。这些文档不仅系统地讲解了大模型的核心技术,还提供了实战案例和配套视频,帮助读者快速上手。
精通RAG架构:从0到1,基于LLM+RAG构建生产级企业知识库
|
28天前
|
Cloud Native Devops 持续交付
云原生架构:重塑企业IT的无形之手####
本文旨在探讨云原生架构如何成为推动企业数字化转型的核心动力,它不仅是一种技术升级,更是业务与开发模式的深刻变革。通过剖析云原生的核心要素——微服务、容器化、持续集成/持续部署(CI/CD)、以及DevOps文化,本文揭示了这一架构如何提升系统的弹性、可扩展性和敏捷性,为企业在竞争激烈的市场环境中赋予快速响应和创新的能力。不同于传统综述,本文将以一个虚构案例贯穿始终,直观展示云原生架构从理论到实践的转化过程,为读者提供一幅生动的技术蓝图。 --- ###
|
1月前
|
运维 Cloud Native 持续交付
探索云原生架构:企业数字化转型的新引擎
在当今数字化浪潮中,云原生架构以其独特的优势成为企业转型的关键。它通过容器化、微服务、DevOps和持续交付等技术,使企业能够快速响应市场变化,实现应用的高效开发、部署和运维。本文将深入探讨云原生的概念、核心技术及其在现代IT环境中的重要性。
|
1月前
|
运维 Kubernetes Cloud Native
探索云原生架构:企业数字化转型的新引擎
【10月更文挑战第9天】 在当今数字化浪潮中,云原生架构以其独特的优势成为企业实现高效运营和快速创新的关键。本文将深入探讨云原生的核心概念、关键技术以及实际应用案例,揭示其如何助力企业加速数字化转型步伐。通过对云原生技术的剖析,我们将看到这一新兴架构是如何重新定义软件开发、部署和运维模式的,进而推动企业在激烈的市场竞争中脱颖而出。

热门文章

最新文章

下一篇
无影云桌面