本文转载自微信公众号《电脑世界》，作者BobLewis。转载本文请联系电脑世界公众号。数据从理论上讲，数据存储库应被视为改进技术架构的独立目标。实际上，这些存储库是作为应用程序部署工作的一部分来处理的，而不是作为独立的评估和计划来处理的。这些存储库应作为单独的数据层组件处理。除非，它是企业的数据仓库和其他分析存储库。但是因为这些库是由企业的分析业务部门管理的，所以这不是你应该处理的事情。因此，您可以安全地将它们排除在评估过程之外。除非一个或多个平台层的配置工作影响整个分析存储库。这是技术架构被政治化的案例之一。应用程序现在事情变得有趣了。您可以按照对技术架构较低层中组件的健康状况进行评分的方式对应用程序健康状况进行评分：只需对评估标准得分进行平均即可获得总体应用程序得分。优先级排序：对于中型企业来说，在其产品组合中拥有数百或数千个应用程序的情况并不少见，因此一次对一个应用程序进行优先级排序是不切实际的。优先考虑应用程序也不是一个好主意。您最好将优先级视为您使用业务功能模型记录的业务功能和应用程序映射的一个属性。在大多数技术架构中，每个业务功能都由一个或两个核心应用程序支持，通常是来自ERP包或各种其他套件的模块。核心应用程序被卫星应用程序包围，这些卫星应用程序提供核心应用程序所缺少的功能。卫星应用和核心应用可以相互共享和同步数据。此外，许多业务功能使用独立的实用程序和应用程序，不需要与支持相关业务功能的其他应用程序集成。确定优先级时，首先计算业务功能应用健康指数作为支持它的应用的加权平均健康指数，然后为核心应用分配一个权重因子10，根据每个应用的大小和范围分配辅助应用的权重系数为3至7，公用事业的权重系数为1。您应该记录业务功能的健康状况。这是由业务架构团队作为其BCM的一部分提供给您的。您的首要任务是解决业务功能健康和应用程序健康组合最差的业务功能。建议：技术架构师在处理应用程序时比在处理技术架构的较低层时有更多选择。具体来说，对于每个应用程序，您可以：保留：继续使用该应用程序，随着业务需求的变化对其进行维护和优化。替换：放弃应用程序并用功能相同但整体更健康的产品替换它。重新平台化：将应用程序“提升并转移”到成本较低但其他方面相当的平台。重构：重写应用程序以符合您的技术架构工程标准。调整：如果调整了平台（请参阅上面的平台配置），一些应用程序也需要更改。合并：如果一个应用程序是冗余的（例如，企业也在使用功能等效但更高级别的应用程序），则迁移到更高级别的应用程序，尤其是当更高级别的应用程序被认为是公司的目标标准时.停用：停止使用该应用程序并取消其许可证。如果情况需要，首先归档应用程序的数据。那么云呢？在您完成分配应用程序部署之前，云与此分析既不相关也不重要。完成此操作后，如果您的技术战略包括云迁移，那么云可能是您替换、重构或重新构建应用程序平台的正确选择。作者：BobLewis，专栏作家原文网址：http://www.cio.com/article/3640510/the-secret-art-of-technical-architecture-improvement.html
