[[435229]]

技艺架构提供了描述、评估和野心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的评分(仅限整数)后果很好。这是一个五分制的野心，适合统统东谈主的习气。可是通过将野心蚁合在零点，它是一个更当然的系统，因为负数对应于负数，而正数对应于正数。 澌灭加权。在将权重身分添加到评估圭臬之前，需要三念念尔后行。原则上应该这么作念，因为有些属性比其他属性更进犯。但在奉行中，东谈主们可能会发现，举例，在三点权重范畴(高、中、低)上将属性的进犯性评分为高或中之间的影响互异，不会对规定产生饱和的影响，因此不值得畏怯。相通，进犯性较低的属性可能不进犯，不错统统删除它们。 不要依赖电子表格。不要依赖电子表格来照拂荟萃的关系技艺架构的数据。栽种一个数据库，岂论是我方构建的曾做商业业的架构照拂系统。需要照拂的多数数据触及多对多关系是其中一个原因。举例，一些足下行径提拔多个业务功能，而大多数业务功能依赖于多个足下行径。

栽种在电子表格上的技艺架构存储库很快就会造成一个难以照拂的絮叨步地。此外，淌若在电子表格中照拂技艺架构数据，可能面对更多的问题。

企业领有所需的所特等据。需要知谈每个足下行径提拔哪些业务功能以及每个足下行径提拔哪些硬件和软件，并需要知谈每个组件的健康景色。而况对于每个组件，需要知谈是否有其他组件不错完成疏浚的责任，淌若有，是哪一个作念得更好。

企业还要了解将来的架构在那边保执不变，在那边必须调动，以及进行调动的优先事项是什么。