什么是应用程序架构?
数据架构解释并实现了 企业的数据需求. 它通过 四个要素—数据需求, 主要数据来源, 主要数据类型, ,以及所需的 数据管理资源.
我们使用四个 企业架构模型 描述您的数据架构 主题模型, 主题领域模型, 逻辑数据模型, 和 逻辑文档模型.
应用程序架构在以下方面发挥着作用 信息系统架构. 接下来 数据架构. 信息系统架构是一种特殊的 架构领域 对齐 功能, 数据流, 和 数据管理. 。实际上,这意味着确保应用程序提供所需的数据流和数据管理,而不仅仅是提供功能。.
让我们暂时关注一下这个断言。应用程序的存在是为了处理和管理数据。如果没有对数据架构的深入理解和设计,应用程序就会变成互不相连的孤岛。它们在交付功能的同时,也带来了技术债务。它们增加了数据流和数据管理的复杂性。复杂的数据流和数据管理会加速你的技术债务,并增加数据治理的复杂性。.
这意味着你的 应用程序架构 专注于 提供所需功能和数据管理的应用程序的结构和交互,, 您有一个信息系统架构。.
没有成功 数字化转型 将基于功能构建。它们始终基于数据构建。.
功能
应用程序架构从功能开始。.
功能分为四类:
- 功能 需要做的工作:当应用程序执行任务时。这是自动化系统中最有趣的功能。.
- 功能 需要记录工作:当其他程序执行任务时,该功能仅记录创建的数据或已完成的工作。大多数软件功能都属于此类——它为人员或其他自动化系统记录信息。.
- 功能 需要管理工作:调度、任务管理、协调以及所有活动跟踪。这对于高效管理业务活动至关重要。当我们谈论 工作。.
- 所需功能 需要管理数据:存储、检索、混合、评估、移动和保护数据。.
你需要一套一致的功能。在我们的大多数模型中,我们将记录和执行区分为属性。.
当我们忽视管理的功能(工作或数据)时,我们就会降低系统的价值。.
功能直接与 逻辑功能模型.
集会
考虑如何最好地组装功能是应用程序架构师最重要的工作。.
组装是创建或最小化集成和数据流复杂性的地方。组装可以实现重用、专业化,并满足独特的运营需求。.
组装不是从 理论上最佳. 这取决于现实情况和运营需求。考虑定制 ASIC 的性能和功耗优势。或者,该功能是在移动设备还是数据中心执行对性能和数据的影响。或者,在平衡多个商业系统和定制附加组件时面临的集成挑战。.
大会直接与 逻辑服务模型.
数据管理
以适当的质量、可信度和安全性在何处、何时、以何种方式提供所需数据的工具和系统。.
像交互一样,简单的决策将推动数据质量、安全性、风险和可持续性。.
导航应用程序架构模型种类
导航 提供端到端架构模型。我们通过离散的模型类型创建此端到端模型。模型类型可以支持特定的分析,也可以专注于端到端模型的某个方面。简单来说,模型类型是一种特定的建模类型。.
我们围绕四种常规应用程序架构模型进行构建:
这些专门的模型结合起来,按照最佳实践开发 EA 景观,即一次逐步扩展一个架构项目。.
使用模型种类可以提高一致性和可重用性,从而提高整个 EA 团队的生产力和一致性。.
导航模型种类描述
每种模型类型定义如下:
- 目的:为什么存在这种模型以及它旨在回答什么问题。.
- 范围:概述模型类型中包含和排除的内容的界限。.
- 内容与结构:创建模型类型的实例时应使用的组件、关系和属性。.
- 建模方法:指导如何包含或排除哪些内容,以关注与目标相关的具体方面。.
- (可选)与其他模型类型的关系:描述链接的目的以及使用什么关系来连接两个模型。.
信息系统模型
信息系统模型范围
提供自动化系统格局的整体表示,说明核心信息系统(如 CRM 或 SCADA 系统)。.
我们使用 自动化系统 故意的。自动驾驶卡车、物联网和应用程序都是 自动化系统
强大的信息系统模型提供了 共同理解 应用格局。它通过共同理解构建对话框架。使用此模型为信息系统组合提供广泛的方向
信息系统模型指导
企业范围
- 10-20个主要系统
全部门建筑项目
- 预计有5-10个主要系统
转型计划
- 预计5-15个主要系统
信息系统属性
-
-
我们将如何进行购买或构建(商业套件、商业 BoB、开源套件、开源 BoB、定制演进、定制云就绪、定制、Saa)
-
敏捷
-
-
意外变化的压力有多大?意外变化的压力来自威胁和机遇。在与价值主张、产品和服务直接相关的系统中,这种压力最高。.
-
弹性
-
-
需要多大的弹性?
-
复制
-
-
我们想要重复吗?我们会接受重复吗?还是我们会额外付费来防止重复?
-
标准化
-
- 我们会为了标准化而付出额外的代价吗?我们会接受差异化吗?还是我们会要求专业化?
托管
逻辑应用模型
我们的模型功能分为三类:
- 功能 需要做或记录工作
- 功能 需要管理工作
- 所需功能 需要管理数据
逻辑应用模型指导
我们使用 2-3 个级别的简单分类法。.
5-10 信息系统中的逻辑应用程序
每个 1 级逻辑应用程序分解为 3-5 个
目标是将逻辑应用程序的数量控制在 20-25 个左右。必须确保模型易于管理。.
低于 25% 的建筑风格会很有趣
另一个 75% 提供完整性和覆盖范围
逻辑应用程序属性
敏捷
-
- 如何适应意外的威胁和机遇
发展重点
-
- 功能深度、TTM 或可持续性
弹性
-
- 系统是否需要吸收故障并继续运行
寿命
-
- 所需寿命是多少
标准化
-
- 我们需要标准化吗?我们应该寻求重叠吗?
离线支持
-
- 它需要在某个地方运行吗?笔记本电脑、手机、潜艇上
逻辑服务模型
我们称之为 服务模型, 由于历史原因,面向服务架构语言促使我们重新思考。我们谈论的只是'黑匣子'' 提供一组功能,并可与其他 ''黑匣子'.
逻辑服务模型:
- 定义边界
- 明确集成点
- 实现以消费者为中心的组装
- 驱动合同条款
变更条款、使用和访问限制是什么
逻辑数据模型指南
创建功能包来推动实施。.
组件内部有:
- 一致的合同条款
- 一致的交付方式
- 数据管理边界
- 整合边界
逻辑服务属性
敏捷
-
- 如何适应意外的威胁和机遇
复制
-
- 多元化、复制化、共享化
开发/采购
-
- 正确的获取途径是什么
发展重点
-
- 功能深度、TTM 或可持续性
弹性
-
- 系统是否需要吸收故障并继续运行
寿命
-
- 所需寿命是多少
标准化
-
- 我们需要标准化吗?我们应该寻求重叠吗?
离线支持
-
- 它需要在某个地方运行吗?笔记本电脑、手机还是潜艇?
逻辑集成模型
逻辑集成模型解释了信息系统或逻辑服务之间发生的情况。.
它解决了所有重要的界限,而不仅仅是自动化信息流。.
曾经
- 定义集成模式和参考架构
- 公开数据转换
- 执行数据要求(安全性、血统、来源)
逻辑集成模型指导
我们要么建立一个正式的逻辑集成模型来定义接口和'经纪人 在中间,或者使用一个简单的语句 架构模式。. 正式模型将解释一个或用作 参考架构 以及集成模式的基础。.
逻辑集成属性
敏捷
-
- 如何适应意外的威胁和机遇
复制
-
- 多元化、复制化、共享化
提供者
-
- 内部、外部
弹性
-
- 系统是否需要吸收故障并继续运行
寿命
-
- 所需寿命是多少
标准化
-
- 我们需要标准化吗?我们应该寻求重叠吗?
技术的 合身
-
- 这种集成是否需要遵守特殊的技术要求?
一切都围绕数据需求
是的,你的应用程序架构围绕 数据需求— 应用程序用于处理和管理数据。.
没有数据我们就不需要软件。.
您的业务活动会创建、混合和使用数据。这些数据用于管理流程。用于记录活动。或者,这些数据是业务活动的核心。.
在应用程序和业务活动中你需要匹配
- 来源和需求
来源和需求定义流程,推动数据管理 - 数据管理
质量、流程和安全决定了所需的数据管理资源
记住:
数据需求推动着一条穿越破碎应用格局的道路
数据需要打破孤岛
数据需求驱动真实数据流