ADMIT（信息技术架构设计（开发）方法学）是一种决策工具，用于系统地开发健壮的系统，它使用了二十种设计驱动力和策略以及十五个方面的生命周期过程。该方法学定义了一个架构的开发生命周期、周期的每个阶段、管理架构开发的流程，可以和其他框架一起使用。另外本文还讨论了架构设计级别和领域、资源维度，以及架构如何与质量和设计相关联。

引言

在信息技术领域，架构在业务现代化、IT转型、软件开发和企业内的其他重要举措等方面发挥了重要作用。使用架构可以为业务问题提供高效、灵活、高质量的技术解决方案。架构可分为三种不同的类别：企业架构、解决方案架构、系统架构。根据具体情况的业务范围、组织结构和企业文化，每个类别在设计和实现上都有所变化。

架构级别

按照组织层次结构和沟通方式，每个架构级别代表了不同的范围边界和架构活动应具有的细节粒度。

企业架构（公司级）提供架构的监督和指导，从而使技术战略和执行计划与业务愿景和目标保持一致。

解决方案架构（部门级）建立了一个解决方案愿景的模型，它定义了相对应的IT系统、业务流程以及用于某个特定的业务部门的可重用服务，横跨业务和技术架构。

系统架构（团队级）则从各种子系统组件以及它们与内外部其他各种系统之间的关系等方面来定义了某个信息系统的结构。系统架构关注于应用、数据和技术，在某些组织中也被称为软件架构。

表1 IT架构分类/层次结构

架构领域

按照企业的构成单元、解决方案和系统结构，从信息管理的视角来看，IT架构包含了四个领域。

图1 IT架构领域

业务架构（Why domain）从功能视角代表了以业务为中心的企业视图。业务流程、业务服务以及业务规则与业务操作模型、业务性能目标、组织结构一起被定义和设计。任何层次的架构都以本域为出发点并层层向下至技术架构。

信息/数据架构（What domain）描述了用以支持关键性业务功能的数据资产和管理资源以及可跨企业地共享数据的管理模型，比如信息目录、数据模型、数据流、数据质量和数据安全性。

应用/服务架构（How domain）为应用和服务以及它们与其他业务流程和服务之间的协作提供了蓝图。应用架构定义了逻辑和物理组件、对象模型、流程流，以及像缓存、验证和事务等这些横切关注点。

科技/技术架构（Where domain）则解决了技术栈、数据中心、云交付、网络拓扑结构以及安全架构方面的问题。技术栈包含了服务器、存储、虚拟化、操作系统和中间件。

架构和资源维度

技术架构优化了系统资源的使用，从而准备好基础设施环境来满足关键业务需求。为了获取很好的性能指标，需要针对所期望的处理能力和冗余对工作负荷、请求、吞吐量和延迟做出平衡。

工作负荷是指系统内所执行的计算任务。工作负荷消耗了可用的处理器能力，这就减少了其它任务的可用资源。

请求则指用户负荷，并代表了在系统内某个特殊时刻的用户的平均和峰值能力。请求大多会消耗内存用于会话、状态和缓存信息。

吞吐量对应于与某个存储媒体之间数据传输容量，按每秒执行的I/O操作数或每秒传输的M字节数来衡量。

延迟衡量了往返时间和网络资源的处理延迟。

处理能力是设备最原始的资源。可以通过增加CPU、内存、网络连接、服务器的存储容量来增加能力，这也有助于向上扩展架构（垂直扩展）。

冗余是指当多台机器共享工作负荷或当主设备失效时，可以无缝地切换至其他设备的情形。这有助于向外扩展架构（水平扩展）。

架构如何与质量和设计相关联

为了满足功能需求并获取所希望的质量特性集，ADMIT将信息系统的“架构”定义为运行时环境中的结构和基础，这包含于其构建组件，并在它们的属性和关系中表示出相应特性。

现代IT架构共享了与古希腊人为建造建筑所定义的同样的维特鲁威三美德（vitruvian triad）。很多专家将质量定义为目的的满足程度（功能）和使用的满足程度（属性）。架构通过展现形式、适用度和功能性支持和承载了系统的质量特性。

系统架构关注于功能性和非功能性需求，并代表了其高级别的视图，而系统设计处理大部分的功能需求，并代表具有更多实现细节的低级别视图。架构由战略举措或业务需求所驱动，而设计则是基于并遵循于架构。架构和设计互相补充从而实现了一种可持续发展的业务解决方案。

IT架构设计方法学

ADMIT由两个组件构成：

1.架构设计驱动力（ADF）

2.架构开发生命周期（ADLC）

设计驱动力关注于系统地创建架构的策略和技巧。

生命周期定义了管理架构创建的阶段和过程。

架构设计驱动力（ADF）

为了创建系统质量特性良好的架构，我们鼓励使用结构化的思考过程，以便作出正确的决定来选择最有可能的选项。我们使用ADFs驱动，从而有条不紊地创建任何架构。如下图所示，它们跨越了几个所关心的区域。

图2 架构设计驱动力

业务驱动力

为了提供一种成功的解决方案，要首先考虑来自于业务部门的需求评估。业务和IT互相协作以识别出可以满足需求并遵循IT战略和标准的创新解决方案。架构师将想法和概念转换成系统和解决方案；应用自己广博的领域知识和业务专长来定义业务流程和服务。

运营驱动力

系统健康监控、管理、服务水平协议等非功能性需求和运营关注点通常来自于业务和IT的运营。尽管那不是源自于直接客户的需求，但满足这些需求并始终追求运营卓越是任何架构工作至关重要的组成部分。

唯美主义驱动力

因为人们是在与我们所创造的系统进行交互，所以应发挥艺术性和唯美主义的作用。架构设计应让人感到愉悦，并使他们精神高昂。无缝的、毫不费力的、吸引人的用户界面会增强用户体验和互动。而实用主义使用合适的技术组合、过程来帮助业务，是科学和艺术的结合。为此，我们应融合左右大脑打破常规地进行思考。

未来驱动力

除了现在的需求外，架构师还应为接下来的五到十年间考虑该解决方案的相关性，以便能构建合理和稳健的架构，来满足预期的增长模式。通过引入抽象层（将流程图或代码中的接口封装起来）来未雨绸缪，但直到需要时才实现。

简单性驱动力

简单性不仅让利益相关者更易于理解系统系统，而且从长远来看也会节省成本。然而，有些时候在企业中是无法完全避免复杂性的。架构师应能通过抽象或分解来识别出并管理必需的复杂性，并防止设计熵的发生。在现实世界中，复杂系统总是从简单的工作系统演变而来的。

变更驱动力

为了在市场中具有竞争力，我们要快速地拥抱和接纳变更。为此系统应能容易地使用元数据和属性来配置。如果是基于通用的基础和组件来提供敏捷性和灵活性，那么此架构将会表现更好。

流程驱动力

为了满足当前和将来的需求，我们应对过时的业务流程和自定义的解决方案进行重建。标准化的和集成的业务流程为执行和成长打造了核心能力。工业标准的流程适用于大多数功能，除非某个自定义的解决方案存在很明显的竞争理由。

集成驱动力

集成在以下数据共享上起着重要作用：应用之间、应用与企业收购的外部业务之间。为了保持灵活性和互操作性，集成应是松耦合的、标准的。常用的集成模式和消息协议防范了冗余技术的扩散并减少了维护成本。

实现/模式驱动力

架构应为交付团队提供实现细节，比如对象模型（UML），数据模型（ERD），共享组件、数据流图、依赖关系图、服务APIs、通讯协议、消息结构等。这些模式、框架和标准在架构设计中占据了重要的位置。模式是在给定上下文中关于某个问题的已经证明了的解决方案。框架是架构和设计模式的实现包。技术标准用于改进系统间的互操作性。

企业驱动力

相对于为每个业务垂直建立一个业务孤岛，拥有企业系统、共享的IT基础设施和企业范围的核心数据存储则提供了全局协作，提升了流程效率，并节省了开销成本。我们应关注于系统的可重用性、核型业务流程以及主要数据管理。

约束/环境驱动力

在组织中，可能存在一些无法避免而又不得不解决的约束。这些约束可能是与人事、技术或时间相关的。我们在设计架构的时候需要平衡这些约束。很多环境因素——比如组织的结构、文化、个别雇员的影响力、公司政策等——都会影响架构。

故障驱动力

通过在架构中考虑容错、冗余和数据复制来保护系统免于受到单点故障的影响。随着时间的推移，所有的硬件和软件最终都会出现故障。我们既要为成功的场景计划，也要为故障场景做计划，以便减少这种风险。

渠道驱动力

公司通过多种渠道来为不同的客户群来提供独特的、与众不同的用户体验，这些渠道有移动电话、网站、社交媒体、线上购物场所（premises kiosks）等。架构需要考虑到各种能到达客户的有形设备，以及大量在适应这些设备时在客户端层它们所关联的技术。

内容驱动力

诸如数据和信息这样的内容是企业需要管理并高效交付的资产。内容生成、集成、分发都是内容战略的重要方面。

平台驱动力

平台涵盖操作系统、虚拟服务器、中间件、数据库以及其他交付产品的技术。它们在应用和数据空间的总体架构中起着重要的作用。

基础设施驱动力

为了设计一个可很好伸缩和可靠的基础设施，架构要考虑服务器规模以及集群环境来平衡多个服务器间的负荷，以保护系统免于单点故障。基础设施包括硬件栈和数据中心设施。

网络驱动力

为了给全球化的环境设计一个分布式系统，我们必须得考虑包含移动电话和云在内的下一代网络，并准备好具有合适的网络分段和周边安全受防火墙保护的部署技术。

存储驱动力

保护数据的完整性是IT中最重要的基本元素之一。这些资产应保存于像NAS、SAN这样的持久性存储媒体中。我们要仔细地制定数据复制策略、备份和保留策略、恢复和清理程序。

安全性驱动力

公司制定安全策略不仅是为了保护组织和自身品牌免受各种风险，还要满足合规、管理、隐私相关法律和监管要求。这些政策作为网络安全、应用、数据安全、平台安全性、物理安全性的一部分被强制执行。

成本驱动力

最小化成本和最大化质量是每个人在IT上所做的事情。在决定哪个是特定的业务问题最可能的解决方案之前，架构师会利用多个设计选项以及与它们相关的各种折中来衡量它们的成本和效用。高效的技术对公司的底线来说总是好的。

架构开发生命周期（ADLC）

为了有效地管理架构开发，在生命周期中定义 了15个过程。这些过程是敏捷和可迭代的，并且分组成如下图中的五个阶段：计划、设计、管理（开发区域）、优化（优化区域）和自动化（自动化区域）。

图3 生命周期图

表2 架构开发生命周期中的过程、阶段和区域

识别业务愿景和战略

在此阶段识别业务愿景和战略计划。由某个业务用例和其目标提出架构。这将形成业务架构的基础。

计划利益相关者管理（需求管理）

利益相关者是指架构的提出者。管理他们的预期、需求和沟通需求对于任何架构实现来说都至关重要。关系管理、沟通和协商在此阶段起着重要的作用。

定义架构和技术战略

通过技术标准、资产管理、投资组合管理来定义管理和战略方向。技术战略包含诸如购买还是构建、使用云还是使用自有设备等这样的关键技术决策方面。

评估现有架构

审查新系统的总体需求并将它们与现有架构的状态进行比较以执行架构评估，可使用SWOT、MosCow或其他技巧来进行比较。在该评估的基础上推荐一张最佳做法清单，以供在晚些阶段的架构演化使用。

设计目标架构

为了执行所提出的业务战略或为了满足业务需求，我们使用前面所提到的架构设计驱动力开发带有将来应有流程的目标架构。我们有时候也要识别出在到达目标架构之前的过渡架构以提供持续的商业价值。

执行差距分析

比较现有和目标架构并识别出它们之间的差距。分析对上下游系统和已存在流程的影响；找出依赖关系、协作关系、风险、假设以及在实现过程中应解决的约束。

开发执行路线图

在找出的差距的基础上，基于业务的优先级和期望值，开发出一个带有多个项目、方案举措和顺序行动计划的执行路线图，以便从当前状态迁移到将来的状态。

构建参考架构（架构模式）

参考架构通过其解决方案蓝图和模型为将来跨多个组织或业务部门的实施提供了架构基础和指导。架构师们需实现标准的可重用平台，并在其自身技术的“卓越中心”中制定最佳做法以及可重复的模式。

与利益相关者审查架构

为了获得支持并达成一致的共识，架构师们需要将自己的解决方案与利益相关者进行交流。利益相关者在定期安排的检查点会议中审查工程解决方案、架构视图和路线图，并验证可行性以获得他们的认可和购买。

启动速赢项目

为了尽快实现业务价值，推荐先从一个基础项目开始，该项目着重于加速实施时的市场化时间。该项目为即将实施的将来的解决方案准备好了组织和IT环境。

执行实施管理

架构团队将会在定期安排的项目架构审查中管理并监控架构标准和指南的应用，各个交付团队遵循这些标准和指南。

管理生命周期变更

本过程确保在架构在其生命周期中响应业务的变更需求。评估和分析架构变更的影响，然后主动、可控地管理这些内容。

管理架构资产

利益相关者利用架构资产来沟通彼此的关注点，架构资产也是将来架构工作的知识领域。在内容存储库中记录和管理诸如视图、模型、目录和其他资产等这些可交付的作品，以便符合版本、审批和访问控制。

持续改进架构和过程

在交付有质量的解决方案中，持续改进产品、过程、人事是关键性的因素。迭代地改进和优化架构来最大化其对于业务的价值。类似地，为了获取效率，随着时间的推移生命周期过程理应持续改进和精简。

使用工具和技术自动化生命周期

创建架构是一个有着特定目标，并使用工具和技巧来将输入转化为可交付的输出的过程。创建架构和其各个过程的管理很依赖于架构师的经验和专长。我们应使用适合的工具和技巧来自动化创建生命周期中的某些部分，这样就能用某种成熟的的架构做法来协助架构师。

结论

这种通用的方法学只是描述了高层次的驱动力和过程目标而缺少实施细节。基于每个组织的需要、组织的大小、解决方案的规模，各个组织可通过定制其设计驱动力和实施过程的方式来进行裁剪。

ADMIT是将经典的古希腊人建筑设计模式应用于现代IT架构以实施优胜的解决方案的方法。对架构师们和那些每天都勇敢地面对技术改变和挑战的朦胧之海的人来说，这种开放的方法学可能是很有用的工具。