配多多技术架构改进的秘诀

[[436505]]配多多

选择一个词来描述你公司的技术架构，这可能就是“非常复杂”。

大多数技术架构确实非常复杂。想弄清楚如何对其简化和改进吗?我们需要多次重复使用“非常”一词：这是真的，非常非常复杂。

当然，当一件事情如此复杂或令人费解时，在制定改进计划之前，将事情进行分解，这是很有帮助的。在此，我们就是这样做的，以帮助你破解一些“非常复杂”的事情，这样你可以制定一个切实可行的策略，以确保你公司的技术架构能最好地为业务提供服务。

拆解技术架构

本系列的前一期给出了一个描述技术架构的框架，并将技术架构分解为三个资产组合及其子组合：

应用程序：记录系统、接口和集成以及附属应用程序数据：结构化和非结构化技术：设备、基础设施和平台

后一期补充了一个观点，即技术架构需要有两个互补的视角：资产组合的视角和整体设计的视角。该部分内容还为评估构成该技术架构的组件的运行状况提供了指导。

该部分内容讲述了如何将技术和业务架构进行连接，特别是通过“业务功能模型”(BCM)——技术架构中的每个应用程序都可以映射到业务功能分类中。

所有这些要素让你可以识别、分类和评价自己所拥有的东西。

但从这里开始到制定出一个改进技术架构的可行计划，你还需要决定如何处置每个资产组合和子组合中的每个组件——每个组件需要如何调整——以及处置每个组件的优先级。

具体情况取决于你要处理哪些资产组合和子组合。在此，我们将从下往上进行分解讲述。

设备和基础设施

在改进技术架构的过程中，确定优先级始终是你的首要任务。使用流程、框架和标准对每个组件的运行状况进行评分。根据依赖该组件的应用程序的数量对其重要性进行评分。将运行状况与重要性评分相乘，计算出每个组件的优先级指数。将结果生成一个可视化的热图，其中较红的组件，其优先级就更高。

接下来是处置工作。对于设备和基础设施而言，你有以下处置方式：

停用：尽管不太可能发生，但你可能会发现一些并未在使用的设备或基础设施。将其关闭，停止使用，并取消其相关租约或产品支持合同。升级：你可能会发现在设备或基础设施中的一些组件已过时、无法获得产品支持或需要更新到该产品的最新版本。请对其进行更新升级。替换：你可能会发现某个组件已经过时、无法获得产品支持，而且如果有一个更新的可用版本，但你认为它不可行。那么，就将其扔掉，然后用一个功能相当但更稳健的产品来替换。整合：对于一个技术架构而言，拥有冗余的设备或基础设施组件并不罕见。尤其是在企业合并或收购之后，多个数据中心或网络通常会为我们提供一些整合的机会。

对于设备和基础设施，你现在知道最迫切需要关注的是什么，以及该如何应对这种情况。

平台

确定平台的优先级和处置方式不同于为设备和基础设施选择平台，因为平台之间具有更多的相互依赖性。处理这种复杂情况的一个好方法是明确各个堆栈。一个堆栈是至少由一个应用程序所使用的多个平台的组合，其包括服务器操作系统、开发环境(包括库)、DBMS、CMS(内容管理系统)、Web 服务器和所支持的浏览器(假设应用程序的 UI 是通过浏览器打开)，以及运行各种平台的操作系统。

值得注意的是，堆栈是递归的：各平台可以依赖于其他平台。同样值得注意的是，某些应用程序也可以是平台。例如，SharePoint 是一个应用程序，也可以用作构建自定义应用程序的开发环境。

优先级：堆栈的运行状况是其组件运行状况的平均值，可使用流程、框架和取样标准进行评分。

其优先级处于什么位置?对此没有一个绝对可靠的“最佳做法”。克服该复杂情况的一种方法是找出运行状况不好的平台，是否在对其进行补救之后，可以最大程度地改善大多数堆栈。为了说明这一点，假设在你的技术架构中选定了 60 个堆栈。还假设你在使用中且运行状况最差的平台是 Windows Server 2003 — 假设其运行状况评分为 -1.5。

在这个假设示例中，假设将其评分提高到 +2，这会使 14 个堆栈的评分从 -1 升至 0，而使另外 6 个堆栈的评分从 0 升至 +1。这就是说，通过解决 Windows 2003 Server 的问题配多多，可以改进 22 个堆栈。Windows 2003 Server 的优先级指数是 60 个堆栈中的 20 个得到改进，即是 0.33。

对每个平台组件重复这一操作，你就拥有了一种对平台优先级进行排序的实用方法。

数据

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

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

除非一个或多个平台层的处置工作会影响某个分析库。

这是技术架构变得政治化的一种情况。

应用程序

现在事情变得很有趣。

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

优先事项：即使是一家中型企业，其资产组合中拥有数百或数千个应用程序的情况也并不少见，因此，每次为一个应用程序确定优先级，这是不切实际的。为应用程序确定优先级也不是一个好主意。你最好将优先级视为业务功能的一个属性以及你使用业务功能模型所记录的应用程序映射的一个属性。

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

核心应用程序周围环绕着一些附属应用程序，这些应用程序可提供核心应用程序所欠缺的功能。附属应用程序和核心应用程序可彼此共享和同步数据。

此外，许多业务功能会使用一些实用工具——独立的应用程序，不需要与支持该业务功能的其他应用程序进行集成。

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

你应该已经记录了业务功能的运行状况——这是业务架构团队作为业务功能模型的部分内容提供给你的。

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

处置工作：与处理技术架构的较低层相比，技术架构师在处理应用程序时拥有更多的可选方案。具体来说，对于每个应用程序而言，你可以：

保留：继续使用该应用程序，随着业务需求的变化，对其进行维护和优化。替换：抛弃该应用程序，用一个功能相当且总体上更稳健的产品来替代。重新配置平台：将该应用程序“提升并转移”到一个成本较低，而其他方面都相当的平台上。代码重构：重新编写该应用程序以符合你的技术架构工程标准。调整：如果某一平台要进行调整，则一些应用程序也需要随之进行调整。整合：如果一个应用程序是冗余的——即，一个功能相同且更好的应用程序正在企业的其他部门使用——那么就要转向使用该应用程序，尤其是如果该应用程序被认为是公司未来的标准。停用：停止使用该应用程序，并取消其许可证。如果情况需要的话，请先对应用程序的数据进行存档。

那么云端呢?在你已完成所确定的应用程序处置工作之前，云端对于此项分析工作既不相关也不重要。

当完成这项工作后，如果你的技术策略包括云迁移，则云端可能是你对某一应用程序进行替换、代码重构或重新配置平台的正确选择。

从优先事项和处置工作，再到制定计划

许多技术架构师专注于瀑布方法，在规划技术架构改进工作时，以甘特图风格的处置时间表方式，将工作路线图视为最重要的东西。

但是路线图是瀑布式思维的遗留产物。在最优先的处置计划顺利进行之前，超出最优先的平台或业务功能来规划技术架构的调整工作，这几乎没有意义。正如我们在敏捷应用程序开发工作中所学到的那样，一个过早制定的计划会在开始实施之前就早已过时了。

通过灵活处理待办工作的方式来管理技术架构规划，其远优于传统的路线图。

这种方法有两种版本——平台驱动的架构和业务功能驱动的架构。首先，平台堆栈取代了待办工作中的灵活“场景”。第二个是围绕业务功能来构建待办工作的场景。

平台驱动的架构调整：使用这种方法，无论是基于上述的优先级方式，还是基于一些更适合自己企业的替代方案，通常都会选择一个平台组件。无论哪种方式，规划人员都会去寻找平台级的涟漪效应(其他受影响的堆栈)和应用层的涟漪效应(能利用受影响堆栈的一些应用程序)。

在实施最高优先级平台的处置工作过程中，技术架构师将在剩余的待办工作事项中审查当前平台场景的优先级，如果合适的话，对其进行修改以适应不断变化的情况，然后开始为下一个最高优先级场景制定计划。

业务功能驱动的架构调整：借助业务功能驱动的架构调整工作，尽管相关性并不能证明因果关系，但业务和应用程序运行状况评分都很低的功能是寻找造成业务流程瓶颈的应用程序缺陷的一个合理位置。

从技术架构的角度来看，业务功能驱动的调整工作从处置具有最高优先级业务功能的核心应用程序开始，然后从此处向外延伸去处置附属应用程序。

同时，公司的业务架构师们将合作设计和实施通过应用程序调整来实现的流程改进。