数据

理论上，数据存储库应被视为改进技术架构中的独立目标。在实践中，这些存储库是作为应用程序处置工作的一部分，而不是作为独立的评估和计划来处理的。

这些存储库应作为单独的数据层组件进行处理。除非，它是某一企业的数据仓库和其他分析存储库。但因为这些库由企业的分析业务部门来管理，并不是你该处理的问题。所以你可以放心地将它们排除在评估过程之外。

除非一个或多个平台层的配置工作会影响整个分析存储库。

这是技术架构政治化的情况之一。

应用

现在事情变得有趣了。

你可以对应用程序运行状况进行评分，就像对技术结构体系中较低层中的组件的运行状况进行评分一样：只需平均评估标准分数，即可获得总体应用程序分数。

优先级：即使是中型企业，其产品组合中也有数百或数千个应用程序，这种情况并不少见，因此，一次确定一个应用程序的优先级是不切实际的。为应用程序确定优先级也不是一个好主意。你最好将优先级视为业务功能和应用程序映射的属性，你已经使用业务功能模型记录了这些映射。

在大多数技术架构中，每个业务功能都由一个或两个核心应用程序支持，这些应用程序通常是来自ERP软件包或其他各种套件中的模块。

核心应用程序被附属应用程序所包围，这些附属应用程序提供了核心应用程序中欠缺的功能。附属应用程序和核心应用程序可以相互共享和同步数据。

此外，许多业务功能都会使用实用程序，即独立且不需要与支持相关业务功能的其他应用程序集成的应用程序。

若要确定优先级，首先计算业务功能应用程序运行状况指数，并将其作为支持它的应用程序的加权平均运行状况指数，再为核心应用程序分配10的加权因子，根据每个应用程序的大小和范围为附属应用程序分配3到7的加权因子，为实用程序分配1的加权因子。

你应该已经记录了业务功能的运行状况。这是被业务架构团队当作其 BCM 的一部分提供给你的。

你的首要任务是处理业务功能运行状况和应用程序运行状况组合最差的那个业务功能。

• 处置：与处理技术架构的较低层相比，技术架构师在处理应用程序方面有更多的选择。具体而言，对于每个应用程序，你可以：
• 保留：继续使用应用程序，随着业务需求的变化对其进行维护和优化。
• 替换：丢掉应用程序，用功能等效但整体更健康的产品代替。
• 重新配置平台：将应用程序"提升并转移"到成本较低但其他等效的平台上。
• 重构：重写应用程序以符合你的技术架构工程标准。
• 调整：如果一个平台要进行调整(参见上文的平台配置)，一些应用程序也将需要随之改变。
• 整合：如果某个应用程序是冗余的(比如，企业也同时在使用功能等效但更高级的应用程序)，请迁移到更高级的应用程序上，尤其是当更高级的应用程序被视为公司的目标标准时。
• 停用：停止使用应用程序并取消其许可证。如果情况需要，请先对应用程序的数据进行存档。

那么云端呢?在你完成分配应用程序部署之前，云对于此项分析既不相关也不重要。

一旦你完成此操作，如果你的技术策略包括云迁移，则云可能是你对某一应用程序进行替换、重构或重新构建应用程序平台的正确选择。

作者：Bob Lewis ，专栏作家

原文网址：

http://www.cio.com/article/3640510/the-secret-art-of-technical-architecture-improvement.html