关键业务核心应用分析-CSDN博客

本文讨论了在快速变化的IT环境中，核心业务应用程序面临的挑战，包括复杂性、依赖性管理和决策过程中的风险。强调了全面分析和综合平台的重要性，以确保应用程序转型的透明度和成功实施，同时考虑到技术细节和业务需求。

不断变化的 IT 格局中的核心应用程序

每个大型且不断发展的 IT 应用程序环境都有广泛的关键业务应用程序，这些应用程序是在多年的时间里单独开发的。他们承受未来的能力必须受到考验。这些定制的核心应用程序可以在公共和私营部门的组织中实施核心流程或管理大量财务数据。这些应用程序的任何失败都会给公司造成巨大的财务损失和/或对其形象造成不可挽回的损害。

这些应用程序的未来取决于决策者——是否应该更换、重新实施或现代化？在此决策阶段对某些方面（例如复杂性、专业知识、透明度、治理）的错误或考虑不足将导致项目失败（“钱坑”）或错过最后期限和预算，而不会增加业务或其价值。

为了降低风险、最大化潜在效益并确保项目成功，决策过程中必须纳入广泛的核心应用分析。分析必须考虑核心应用程序的技术和业务功能以及所有相关利益相关者（例如业务部门、用户、程序员和 IT 运营）的知识。

最终目标是逐步、透明和可控的应用程序转型，满足不断增长的数字世界当前和未来的需求，而不损害现有应用程序的内在价值或操作。

需要综合分析

如果系统之间的依赖关系不明确、模块和元素不透明、接口维护不善且文档记录很少，那么转型如何能够成功？如果您无法分辨业务流程中使用了哪些模块和组件以及如何使用，那么如何进行转换？当工作人员即将退休时，哪些应用知识将会丢失？在这些条件下，您如何实际计算成本、时间和风险等因素的价值？

必须进行全面分析来解决这些问题，以便为决策建立坚实的信息基础，从而以受控方式将应用程序发展为面向未来的架构。

核心应用分析与改造

应用程序的分析必须涉及所有相关的组织实体，例如业务部门和研发部门。分析必须涵盖核心应用程序的业务和 IT 环境，例如行业特定方法、业务流程、软件产品、IT 基础设施和 IT 架构。

只有对业务和 IT 环境进行全面分析，您才能对核心应用程序进行全面评估，从而在计算风险的情况下做出决策。除了应用程序细节之外，系统组件和系统在开发和运行时环境（例如，编程语言和环境、数据库系统、中间件、作业控制）以及IT基础设施（例如，操作系统、硬件、设备）中的依赖关系也必须保持透明。

必须考虑静态方面（例如，应用程序结构、源代码、接口）以及动态标准（例如，运行时行为）。所有相关业务及其因素必须一致且相互关联地记录下来。所有利益相关者都应该能够访问分析结果以查看和用于协作决策。

核心应用

核心应用程序的复杂性

关键业务应用程序，无论是对话应用程序还是批处理应用程序，都非常复杂。这不仅体现在源代码中，还体现在各自的业务和数据库事务逻辑中。它还涉及多个接口，紧密连接内部和外部 IT 系统，为各种业务流程和用户组提供服务。

核心应用程序主要运行在大型机平台或高度可扩展的服务器平台上，并采用natural、cobol、adabas、db2® 或 vsam™ 等技术。由于这些系统经过多年优化，它们实现了高水平的运营质量，这一点通过履行严格的服务级别协议 (SLA) 即可看出。

由于员工退休和随后的代际过渡等因素，这些关联应用程序的完全透明度和完整知识面临风险。通常无法获得有关 IT 实施和相关业务功能的最新、一致的文档。

核心应用的复杂性

综合分析平台

为了记录所有与上下文相关的元素、建立它们的关系并与各个利益相关者共享它们，您需要一个集成的协作分析平台。这是关于业务功能信息的定义，涉及核心应用程序以及 IT 组合和企业架构的首要元素。

这为所有利益相关者提供了一个全面、一致、集中的知识库，用于查询和决策。

核心应用分析

核心应用程序分析必须考虑结构（静态）和运行时（动态）方面，以便确定应用程序使用的复杂性和关键性级别。

综合分析平台

静态应用分析

业务和流程逻辑由源代码以及相关的程序结构和库来实现。然而，源代码通常包含比结构更多的“意大利面条代码”，这使得识别和更改业务逻辑变得困难。

静态应用分析

理想的分析平台提供以下功能：

用于 cobol、ibm® cics® 表、jcl 和自然源代码的分析工具。
支持 3gl 语言和功能，例如各种编程类型（如子程序和抄写本）以及不同的产品版本。
接口识别和文档。
自动生成多种格式的应用文档、结构图（例如，控制流、决策表）、报告和影响分析（例如，microsoft® excel®、microsoft® word、pdf 和 html）
识别数据库、数据库结构和访问类型。
复杂性指标（例如，mccabe、halstead）。
识别过时或冗余的源代码。
基于网络的工具，用于程序结构和依赖关系的交互式导航。