技术架构提供了描述、评估和规划IT管理和企业所依赖的IT技术演变的一种方法。 构建高效IT可以采用框架来描述技术架构，并将其分解为组合和子组合，其中包括应用程序(记录系统、集成应用程序)、数据(结构化和非结构化)、技术(设备、基础设施和平台)。

该框架使人们能够识别和分类拥有的东西，但它并没有告诉企业拥有的技术架构是否是正确的。这就是需要解决的问题。以下概述了企业将如何看待自己的技术架构，并提供了评估技术架构的关键标准。

技术架构的两个视角

对于技术架构的描述分为两个互补的视角：整体设计和组合视图。

整体设计描述了技术架构的每个组件的作用——提供的功能以及这些组件如何组合在一起创建整体功能。

另一方面，组合视图植根于投资理论。它将技术架构中的组件视为投资组合中的股票。就像投资者定期审查他们的投资组合以决定购买更多、持有或出售哪些股票一样，技术架构师根据这一模型定期审查其技术投资组合每个组件的健康状况，以确定哪些组件继续作为标准，哪些组件应该逐步淘汰，以支持更好地提供所需功能的替代方案。

但与投资者有所不同的是，技术架构师有更多的选择，而不仅仅是采用、持有和放弃。技术架构师将他们的选择称为处置。

需要记住的是，如果没有整体设计，IT团队将管理一堆构思拙劣的组件。如果没有投资组合视图，将会发现自己管理着一个精心设计的纸牌屋：虽然所有东西都放在一起，但不会想住在里面。

业务架构及其连接方式

如果不将应用程序映射到它们支持的业务功能，就不可能设计和规划连贯的技术架构。因此，负责记录业务架构的人员必须向IT技术架构师提供四个关键信息。

• 分类。在这里谈论的是业务功能的分类，可以分为三个级别——能力(L1)、职责(L2)和流程(L3)。例如，人力资源(L1)包括薪酬管理(L2)，薪酬管理又包括工资单(L3)，就像财务和会计(L1)包括应收账款(L2)，会计包括收款(L3)。如果采用流行术语描述的话，可以将这一分类称为业务能力模型(BCM)。
• 映射。第二个关键信息是BCM中每个功能所依赖的应用程序的映射。业务架构师可能很想在能力级别映射这些，但如果没有L2和L3映射，BCM的重要性将很有限。
• 评估。第三个关键信息是对每个BCM功能的整体有效性的评估。
• 重要性。第四个关键信息也是最具争议的——每个业务功能的相对重要性。关于这一点有两条建议：(1)将重要性定义为对竞争优势的影响;(2)对其进行评级，而不是对其进行排名。

例如，人们不会就薪资是否比销售更重要达成共识，但很容易达成一致，即在五分制(推荐)上，他们都应该获得最高分(5)，如果卖不出去产品，就会失去市场份额，如果不给员工发工资，就难以更好地销售产品。

分类法、应用程序映射、业务功能有效性、业务功能重要性这四部分是连接业务和技术架构的东西。

值得一提的是：虽然BCM通常类似于企业的组织结构图，但组织结构图并不是BCM。对于企业(尤其是大型企业)来说，根据功能以外的其他内容进行组织是很常见的，例如，根据地理位置、客户类型或产品类别。这导致一些业务功能在企业的多个部分中表现出来。

评估技术架构

为了评估技术架构，架构师需要了解组件和集成的健康状况，冗余和整合机会，以及业务功能支持的质量。以下是需要了解的有关组件运行状况评分的信息。

技术架构中每个投资组合和子投资组合的每个组件都是关键的资产，将影响IT的工作能力和各个支持业务领域的工作能力。

用于评估架构组件的完整标准列表非常广泛。使用的框架包括仅针对应用层的30个潜在评估标准。但即使是一层，30个标准也会过多。从数据收集和管理的角度来看，10个标准是切合实际的最大值。

根据投资组合和子投资组合采用以下简化的标准集，将为评估技术架构奠定坚实的基础：

(1)功能性：这是显而易见的标准——组件是否完成了需要它完成的任务。

(2)灵活性：组件如何适应新的和不断变化的情况。

(3)稳定性和性能：很明显，应用程序、平台或基础设施组件在可用时经常崩溃，运行速度非常慢，这是一个需要解决的问题。

(4)内部工程：组件组装的好坏(更容易确定组件何时在内部开发)是否符合工程标准。

(5)集成和接口：这仅适用于应用程序和数据存储库。它对每个应用程序和数据存储库如何与其他应用程序和数据存储库交换数据以同步重叠数据进行评分，如果特别复杂，还可以同步重叠的业务逻辑。

(6)遵守架构原则：企业需要花费时间阐明这些原则，采用的技术应该符合这些原则。

(7)安全性：虽然如今大多数网络攻击事件都是社交工程的结果，但这并不意味着不需要强化技术。

(8)供应商和产品可行性：组件及其供应商在其市场上是否具有临界质量?也就是组件是否会得到支持和增强。企业能招募到优秀的人才来从事这项工作吗?

(9)更新版本：该组件是否仅比其供应商当前发布的版本落后一个版本，或者在另一个极端情况下，提供组件的供应商不再支持该组件。

(10)低层的健康状况：由于每层的组件依赖于下层的组件，它们继承了那些下层组件的健康状况或缺陷。例如，应用程序可能依赖于分层存储在大型机托管的IMS数据库中的数据。大多数IT组织认为IMS是一个过时的平台，导致该应用程序的平台层得分为负。此外，对于大多数IT商店而言，分层数据设计将会违反结构化数据设计标准(规范化)，从而根据应用程序的信息存储库特征降低其分数。

(11)冗余：当企业的其他地方正在使用其他功能相似且可能更好的替代方案时，该组件就是冗余的。如果是这样，在冗余组件中应建立一个标准并获得较高的排名;其他的应该被评价有问题，因为它们是多余的。

评分

无论企业决定采用哪种属性来衡量架构组件的运行状况，以下是三个提示：

• 为所有属性建立一个共同的指标。在专家的咨询工作中，发现+2到-2的评分(仅限整数)效果很好。这是一个五分制的指标，符合所有人的习惯。但是通过将指标集中在零点，它是一个更自然的系统，因为负数对应于负数，而正数对应于正数。
• 放弃加权。在将权重因素添加到评估标准之前，需要深思熟虑。原则上应该这样做，因为有些属性比其他属性更重要。但在实践中，人们可能会发现，例如，在三点权重范围(高、中、低)上将属性的重要性评分为高或中之间的影响差异，不会对结果产生足够的影响，因此不值得费心。同样，重要性较低的属性可能不重要，可以完全删除它们。
• 不要依赖电子表格。不要依赖电子表格来管理收集的有关技术架构的数据。建立一个数据库，无论是自己构建的还是商业的架构管理系统。需要管理的大量数据涉及多对多关系是其中一个原因。例如，一些应用程序支持多个业务功能，而大多数业务功能依赖于多个应用程序。

建立在电子表格上的技术架构存储库很快就会变成一个难以管理的混乱局面。此外，如果在电子表格中管理技术架构数据，可能面临更多的问题。

企业拥有所需的所有数据。需要知道每个应用程序支持哪些业务功能以及每个应用程序支持哪些硬件和软件，并需要知道每个组件的健康状况。并且对于每个组件，需要知道是否有其他组件可以完成相同的工作，如果有，是哪一个做得更好。

企业还要了解未来的架构在哪里保持不变，在哪里必须改变，以及进行改变的优先事项是什么。