企业架构用例

企业架构常见问题用例

我们不断被要求为基于问题的常见用例优化企业架构团队。这些企业架构用例中的大多数都是面向 IT 的。他们以 IT 倾向解决 EA 问题。

减轻技术风险用例

技术债务。许多组织积累了技术债务。当组织面临真正的现金债务时，他们会做两件事，解决债务来源或宣布破产。

技术风险就是风险，纯粹而简单。风险是实现目标时不确定性的影响。需要处理产生实现目标风险的技术。

组织依靠技术来正确管理所有行业的运营。网络危险是任何技术都存在的，并且可能从许多来源采取许多不同的形式。最常见但最可避免的数据泄露原因是 IT 故障、老化的应用程序以及支持它们的基础架构。就金钱和声誉损失而言，从网络灾难的影响中恢复可能非常具有挑战性。

无论您的团队多么有才华，技术风险管理都是一个庞大而复杂的问题，无法通过手动数据维护来解决。企业架构师可以轻松获取所有技术的最新产品数据。这些知识对于正确设计、管理和淘汰技术组件以及评估应用程序环境的风险是必要的。

降低技术风险的 EA 团队设计

当我们面临缓解技术风险时，我们使用 浏览 SABSA Atlas 和 Navigate Program & Portfolio Management Atlas.我们将 SABSA 的风险域提取出来，并从投资组合的角度来看待这项技术。

在所有情况下，您都在寻找一个清晰、可操作的路线图来推动这些结果。

IT 现代化用例

信息技术就像其他基础设施一样——它会老化。随着年龄的增长，IT 越来越无法满足当前的希望和梦想。我们喜欢将 IT 基础设施视为不会物理磨损的基础设施。其他基础设施遭受磨损 - 卡车行驶里程。风、雨、盐、锈、嘎嘎声和翻滚。它磨损了。

相比之下，IT 基础设施一直在工作。想想旧的 Model-T。启动，运行，漏油，就像它是新的一样。但是，它不能像现代半挂卡车那样以 65 MPH 的速度承载 50,000 磅。

现代化 这通常就像更换车队一样——一切都已连接。我们喜欢这个理论，削减或远离资源密集型应用程序。为那些拥有高拥有成本的人寻找替代品。然后你发现旧应用程序处理了三分之一的收入，业务专注于新服务以获得新收入。

IT 现代化计划经常使用增量策略，包括逐步实现 IT 资产现代化，直到整个系统升级。事实证明，逐步实现 IT 系统的现代化是有帮助的，特别是可以减少在一次完成所有操作时可能出现的操作危险。这种策略的缺点是开发团队孤立地运作，缺乏广阔的视野。企业架构集成了组织的每一层，从业务到 IT 基础架构，允许 IT 主管根据业务目标确定现代化计划的优先级，并了解这些项目将如何影响他们的 IT 系统。

企业架构在 IT 现代化的背景下将业务目标与业务能力联系起来。为了映射当前的业务能力并了解它们如何发展，企业架构师与业务团队协作。这个长句子表示您将平衡可行性、成本、企业敏捷性和风险。你需要掌握 信息技术管理协会 适用于数字产品和 IT 服务。这将为未来几年产能应如何发展或是否针对新的消费类别提供更清晰的了解。

通过在时间线上调整转型目标、业务能力和必要的 IT 功能，企业架构师可以使用企业路线图来捕捉当前和未来的业务需求。将定义完全支持预期业务功能的未来 IT 架构。

企业架构还可以指定未来的IT架构，这很有帮助。企业架构师将当前的 IT 环境作为起点。为此，必须对组织的应用程序和技术进行盘点。应用程序生命周期、成本、部署、交换流以及它们如何服务于业务只是进行应用程序清单时可能使用的几个方面。当应用程序清单完成时，企业架构师可以根据公认的业务能力创建新的IT架构。 业务能力图 帮助展示当组织为解决新问题而进行变革时支持业务运营所需的 IT 资源。

通过 IT 现代化计划，可以在建立包括应用程序和技术在内的预期 IT 架构之后更新 IT 环境的某些组件或部分以满足新的业务能力。

最后但并非最不重要的一点是，企业架构可以使您的 IT 计划与您的企业目标相协调。每个项目都有一个基本原理或商业案例，概述了为什么应该这样做，以及成本、资源、时间表和任何潜在的危险。

公司可能会组建一个由 IT 和业务专家组成的执行委员会来确定这些计划的优先级。根据每个利益相关者的目标，通过将两种类型的领导者聚集在一起来确定项目的优先级。

一旦确定了任务的优先级并放置在时间表中，我们就可以制定 IT 路线图。战略业务目标的声明、项目时间表、业务案例、预期成本和每个项目的长度都是有效 IT 路线图的必要组成部分。

IT 现代化的 EA 团队设计

好的 企业架构团队 帮助您清楚地了解您的 IT 投资及其当前价值，并就投资地点提供务实的建议。投资建议是一个投资组合问题。 IT 现代化不仅仅是一个技术问题。我们始终加强 业务架构 能力，因为仅仅为技术而设计不会成功。

为了启用 IT 现代化用例，我们与 设计架构以支持产品组合.

数字化转型用例

我们经常看到人们谈论 数字化转型 云转型作为基础设施交换机。胡说些什么。

有  数字化转型的七个杠杆.您可以控制所有七个杠杆，或者您可以尝试在不控制轨迹、速度或...的情况下进行更改... 每个杠杆启用或禁用不同的更改功能。

如果你没有控制它，每个杠杆都会产生负面影响。

• 杠杆 1 - 业务流程转型
• 杠杆 2 - 客户参与和体验
• 杠杆 3 - 产品或服务数字化
• 杠杆 4 - IT 和交付转型
• 杠杆 5 - 组织文化
• 杠杆 6 - 策略
• 杠杆 7 - 生态系统和商业模式

EA 数字化转型团队设计

数字化转型需要一些策略 问题得到解答。然而，许多问题可以很快得到答复，而无需执行。结果，我们对齐 设计架构以支持产品组合.

云转型用例

借助云技术，新的价值创造服务驱动型公司模式现在成为可能。降低成本、提高生产力、加快上市时间以及随需求增长的能力只是云计算的一小部分优势。切换到云后，企业还可以显着提高资产利用率，节省运营成本，并重塑与 IT 员工的关系。

决定 IT 和业务战略的一个重要因素是云。但是，复杂的企业环境和不断发展的技术严重阻碍了对云过渡的理解。

要成功迁移到云，需要进行重大的组织、运营和技术变革。预算限制、指数增长的要求、随着业务规则变得越来越复杂而变得越来越复杂以及外部法律只是影响沿途采用云计算的障碍中的一小部分。实施从传统基础架构到云的路线图的能力对于企业架构师来说是必须的。

企业架构为企业规模的多云基础架构提供自动化、全方位的视角，有助于管理和改进您的云项目。成功的云过渡应考虑广泛的要素，包括现有和未来的能力、应用程序组合战略、与人员和流程有关的运营和组织问题以及成本指标。为了降低风险并维护跨云部署的合规性，必须充分理解这些复杂性。为了简化数据的导入，企业架构与顶级云提供商集成，并提供了对云架构的看法。企业架构师可以指定目标功能，选择应用程序是留在本地还是转移到云端，并定义目标功能。

云转型的 EA 团队设计

云转型是一个投资组合问题。该企业正在重新设计其 IT 组织。我们始终加强 业务架构 能力，因为为技术设计会失败。我们必须 重新架构 IT 组织.

为了实现云转型，我们与 设计架构以支持产品组合.

应用程序组合合理化用例

我们可以做好应用合理化，或者做得不好，如果做得好，IT支出可以减少20%以上。如果做得不好，就没有储蓄。曾经。

应用程序合理化是由业务影响和业务价值驱动的，而不是 IT 成本。您需要根据技术概况和业务价值来整理您的 IT 产品组合。投资于那些具有面向未来的技术概况和商业价值的人。探索退休或替换那些阻碍你的人的最佳方法。

业务方面经常忽略协调支持 IT 环境的要求，因为它主要关注促进经济发展。因此，根据不同团队的需要，经常会在不同时间引入不同的应用程序。业务方面对这样一个事实视而不见，即拥有一个由生命周期冲突、技术重复和功能重叠的应用程序组成的 IT 环境经常会导致严重的集成问题和组织效率低下。运营成本高昂、限制性强的 IT 环境会导致在 IT 上多花费数亿美元，同时会立即降低依赖它的人们的满意度和服务质量。

大型企业经常同时启动大量应用程序。因此，运行旧系统和维护应用程序会消耗相当大一部分 IT 开支。这些程序不一定都是关键任务。企业受益于拥有适当合理化的应用生态系统，以保持现代创新趋势的领先地位，提供世界一流的客户服务，降低成本并在全球范围内扩张。虽然应用程序减少项目需要一次性支出，但节省的费用远远超过成本。

随着业务方继续授权购买左右应用程序，企业架构师可以开始着手优化应用程序组合。

企业架构师可以首先收集有关所有已部署应用程序的所有相关数据，并将其导入到他们首选的软件中。企业架构师可以确定应用程序合理化项目，并根据公司的运营模式确定优先级.

然后，企业架构师可以使用应用程序矩阵和应用程序合理化调查来快速评估应用程序的实用性，并就可以容忍、投资、重新定位或删除哪些应用程序提供数据驱动的建议。

企业架构师现在将拥有创建路线图所需的知识，以通过一系列退役计划来执行合理化工作。这个道路规划也可以作为未来的基准，以确定是否需要额外的应用程序。

应用程序合理化的 EA 团队设计

应用程序合理化是一个组合问题。应用程序合理化总是失败，没有一个坚实的 业务架构.我们始终确保 EA 团队具有业务架构能力，即使我们专注于逆向工程。

我们对齐 设计架构以支持产品组合 用于应用程序现代化用例。

采集集成用例

始终根据收购的战略和目的整合收购。

出于几个简单的原因进行收购

• 获客
• 获取产品
• 收购实物资产
• 获取能力

我们喜欢医学誓言， 首先不要伤害.如果我们为客户群进行收购，那么我们的整合首先需要确保我们保留现有客户。

能力获取是最困难的。通常，收购公司在这方面存在差距，并希望通过使用新能力来加速其能力开发。我们使用这个能力发展的例子在我们的 使用 TOGAF 和 Navigate 的点播课程企业架构 课程。

企业和私募股权领导人预测，并购活动将在未来几年增加，无论是收购数量还是美元价值。

然而，并购往往会因为所涉及的公司无法正确整合或无法实现预期的协同效应而失败。 IT 集成不足的原因有很多。合并后，两个组织很难在成功整合其 IT 系统的同时仍保持商业运营。需要统一各种技术项目、标准和程序。

合并有几个起始条件。有时一个大企业吃掉一个小企业，而其他时候则发生在平等之间的合并。获得技术熟练度或占领新的地理市场是两个可能的目标。企业架构可能对上述每个场景中 IT 集成的成功极为重要。企业架构为通用目标 IT 环境选择合适的应用程序奠定了基础，这有助于合理化应用程序、整合位置和整合位置。这使企业能够利用协同效应、节省开支并战略性地调整其运营。合并的长期成功受两个 IT 部门之间协同作用的影响。

用于采购集成的 EA 团队设计

收购整合是一个投资组合问题。以 IT 为中心的采购集成总是会失败。 业务架构 是有效整合收购的基础。在不知道贵公司为何进行收购的情况下，默认方法是更改被收购的组织。将其更改为破坏价值主张的程度。 EA 团队需要扎实的业务架构能力，即使我们专注于逆向工程。

第二个关键能力是 风险架构.这些简单的原因告诉您需要保护哪些价值。 导航的治理、风险和合规地图集 使用资产和风险来阐明需要保护的内容以及会损坏资产的威胁。

我们对齐 设计架构以支持产品组合 用于采集集成用例。

安全架构用例

安全架构是跨领域的关注点。它与其他所有存在 架构领域.

这 SABSA 关注价值，无论是通过实现收益还是防止负面影响，都是至关重要的。

作为企业架构师，您的工作是保护资产并消除不确定性。当您的组织确信它会满足其期望时，它是最安全的。

简而言之，安全架构是企业架构中与保护企业数据有关的部分。组织用于保护数据的基本安全策略和实践由其安全架构描述，该架构还包括人员团队及其角色和职责，以及其他系统。这是对安全架构的更完整的解释。为帮助确保安全架构与当前和未来的业务需求相匹配，这些信息在组织要求、优先级、风险承受能力和相关考虑因素中提供。

为了通知各级安全规划，拥有强大的安全架构是必不可少的。它提供了对在整个 IT 环境中使用的程序和解决方案做出最佳选择所需的深入细节，以及如何管理技术生命周期。完整的业务信息安全架构文档和发布对于遵守各种当前的行业标准和法律要求也是必不可少的。

TOGAF 的一系列工具首次可用于从头开始构建企业安全架构。它有助于定义精确的目标并弥合您的 EISA 的多个级别之间的差距。这 TOGAF 框架 足够灵活，可以在您公司的安全要求发生变化时为您提供帮助。

针对安全架构用例的 EA 团队设计

安全架构用例将专注于消除不确定性或减少威胁。在这两种情况下，这都是一个投资组合问题。

我们利用 导航的治理、风险和合规地图集 将资产与风险和威胁相结合。我们看有价值的东西。是什么威胁了它们的价值，又是什么造成了不确定性。解决不确定性和威胁的基础是 风险架构.  导航的治理、风险和合规地图集 使用资产和风险来阐明需要保护的内容以及会损坏资产的威胁。

我们利用 将风险和安全与 TOGAF 集成.我们编写了本指南 SABSA研究所 带来了最佳实践 安全架构和企业风险管理.

我们对齐 设计架构以支持产品组合 用于采集集成用例。