基于业务驱动的企业安全架构-第二章架构的意义

第二章：架构的意义

本章探讨了“架构”的真正含义。

特别是它检查了“架构”和“管道”之间的本质区别。 这两个学科都有很大的价值，但它们不是一回事。 在 ICT 世界中，人们有时会混淆哪个是哪个。

在本章中，您将了解：

架构的概念是一种将解决方案集成到各种复杂需求的手段，并作为管理这种复杂性的手段；

架构的概念分层方法和架构参考模型的使用；

与采用具有战术目标的单点解决方案相比，采用整体的战略架构方法的好处。

2.1. 架构的起源

架构起源于城镇和城市的建设，每个人都理解这个词的含义，所以从在这个传统语境中考察“架构”的含义开始是有道理的。

架构是一套规则和惯例，我们根据这些规则和惯例，在功能和美学上创造服务于我们预期目的的架构。我们的架构理念是支持我们生活、工作、经商、旅行、社交和休闲的需求。必须支持这些各种活动的多样性和复杂性的相互作用，这包括活动本身之间的关系以及它们与整个生活方式的整合。架构建立在对其必须满足的需求的理解之上。

这些需求体现在功能、美学、文化、政府政策和公民优先事项方面。他们考虑到我们对自己和邻居的感觉以及他们对我们的感觉。通过这些不同的方式，架构必须为所有将以任何方式体验它的人服务。

架构也受到许多特定因素的驱动和约束。其中包括当地可用于建筑的材料、地形、盛行气候、技术和人们的工程技能。

这一切都归结为决定我们将创建什么样的架构的三个主要因素。 这些因素是：
 我们的目标；
 环境；
 我们的技术能力。

2.1.1. 案例研究：澳大利亚文化的象征

悉尼歌剧院可能是世界上最著名的建筑之一。 不仅如此，它可能是现代建筑中最著名的例子。

像这样的建筑是如何形成的？ 许多小型项目团队能否建造它，每个团队都对应该如何做事有自己的想法，每个人都从头开始设计自己的建筑物，每个人都将整体业务目标作为其动力的狭隘观点？

显然这行不通。 这种口径的建筑（无论您是否是设计的狂热者）永远不可能以零碎的方式设计和建造。 创造真正建筑的唯一方法是从其设计的单一中心愿景 – 一个整体概念。 本书后面的部分，尤其是第 10 章，详细讨论了概念架构。

架构师的工作是创建愿景和方向，同时考虑到所有可能的相关方的所有可能需求的最广泛的观点。 然后，这一愿景成为指导所有其他将从事该项目的人的路线图。 建筑师始终保持控制，监督工作并确保建筑设计的完整性在后期不受影响。

2.2. 管理复杂性

作为架构师的产品，架构的关键功能之一是提供一个可以成功管理复杂性的框架。 小的、孤立的、单独的项目不需要架构，因为它们的复杂程度是有限的，首席设计师可以单枪匹马地管理整体设计。 然而，随着项目规模和复杂性的增长，很明显需要许多设计师，他们都作为一个团队工作，以创造具有由单一设计机构设计的外观的东西。
此外，如果单个项目不是孤立的，而是旨在和谐地融入更广泛、高度复杂的一组其他项目中，那么需要一个架构作为路线图，在其中可以将所有这些项目组合在一起 成一个无缝的整体。结果一定就像它们确实是一个单一的、大型的、复杂的项目的一部分。 这适用于单个项目是同时设计和实施的，还是在较长时间内独立设计和实施的。
随着复杂性的增加，需要一个框架，每个设计师都可以在其中工作，为整体设计做出贡献。 每个设计团队成员还必须确信他或她的工作将与同事的工作协调一致，并且设计的整体完整性不会因工作分散在一个大型设计团队中而受到威胁。
架构的作用是提供将复杂性分解为表面上的简单性的框架。 这是通过分层技术实现的— 将注意力集中在特定的概念层次上，并通过模块化 — 将整体设计分解为具有定义功能和定义接口的可管理部分。 这个过程也称为系统工程，在第 5 章中有更详细的讨论。

2.3. 信息系统架构

建筑中的架构概念已经适应了城镇建设以外的生活领域。 例如，有人谈到海军建筑师是设计和监督船舶建造的人。 最近，该术语已在设计和构建商业计算机系统的背景下采用，因此信息系统架构的概念已经诞生。
与传统架构定义建筑物设计和建造的规则和标准的方式相同，信息系统架构为使用这些技术实现的计算机、通信网络和分布式业务系统的设计和建造解决了这些相同的问题。
与建筑物、城镇和城市的传统架构一样，信息系统架构因此必须考虑：
 通过系统实现的目标；
 构建和使用系统的环境；
 人们构建和操作系统及其子系统的技术能力。
如果一个人接受了这种分析，那么一个人已经很好地认识到信息系统架构所关注的不仅仅是技术因素。 它关注企业想要实现的目标以及影响这些成就的环境因素。
在一些组织中，这种信息系统架构的广泛观点并没有得到很好的理解。技术因素通常是影响架构的主要因素，在这些情况下，架构可能无法满足业务的期望和需求。
本书主要关注信息系统架构的一个方面：即业务信息系统的安全性。
然而讨论这个专业领域时，作者试图就如何采取更广泛的观点提供尽可能多的建议。 因此，重点是企业安全架构，强调企业及其活动需要得到保护，而计算机和网络的安全只是实现此目的的一种手段。
然而，首先，这里有一些现代信息系统架构的一般概念，因为安全架构必须适合这个整体框架。 图 2-1 显示了整个业务系统架构的参考模型 1 。 对于大多数人来说，这有几个主要的组件子架构，如下面的部分所述和图表中所示。

图 2-1：业务系统架构的高级参考模型

2.3.1. 业务架构

业务架构从企业范围的角度描述了业务本身是如何构造成一个组织模型、一组流程、功能等的。 这是所有的主要架构。 其他子架构都是为了支持这个业务实际运作方式的单一覆盖框架而创建的。 在其他情况下，这通常被称为“商业模式”。

2.3.2. 信息架构

业务由信息表示。 每一个商业关系、每一个商业流程、每一个商业交易，实际上是关于商业的一切、它的计划、它的控制、它的管理以及它的成功或失败，都是由信息来表示的。 信息是真实和有形事物的抽象表示。 这就是为什么信息对业务如此重要的原因，因为信息就是业务，以特定的形式表示。

信息架构描述了业务信息在其中创建、组织、处理、存储、检索和通信的框架，在参考模型中（参见图 2-1），它被表示为业务本身的下一个抽象级别 .

信息架构描述信息类型及其整体结构化关系和组织、信息行为、信息管理过程以及信息的物理位置和存储库。 特别是，它识别并描述了支持业务战略和目标所需的主要信息类别。

2.3.3. 应用架构

应用程序是代表真实业务用户对业务信息执行操作的计算机程序套件。 在参考模型（见图 2-1）中，应用架构显示为第三层，支持信息架构，而信息架构又支持业务架构。

这些应用程序反映了业务流程的关键自动化部分。 应用程序架构描述了如何设计应用程序，它们如何相互操作，以及它们如何在基础设施（硬件、软件和通信网络）中得到支持。 应用程序当然必须与它们支持的业务流程以及它们创建、维护和处理的信息资源相关。

现代应用程序架构的特征可能是：
 基于组件 — 可重用的通用模块，因此可以快速适应新的业务需求；
 面向服务 — 组件相互提供服务；
 建立在战略中间件层之上 — 用于服务集成；
 提供分布式处理。

应用程序架构的主要目标是启用业务流程。 它通过创建灵活、经济且对业务变化做出响应的应用程序来实现这一目标。

2.3.4. 基础架构

应用程序需要在逻辑和物理基础设施上得到支持。 稍后将详细讨论“基础设施”一词，但目前它被定义为包括：

计算机平台（硬件和操作系统）；

计算机网络（电缆、线路、交换机、路由器等）；

在具有不同物理特性的基础设施之间架起桥梁并为应用程序提供一致虚拟接口的软件层。 这通常被称为“中间件”。

基础设施架构是大多数人认为的“技术架构”的核心。

2.3.5 风险管理架构

在参考模型（参见图 2-1）中，已经描述的四个层被表示为一个在另一个之上。 穿过这个分层结构的是另一个标有“风险管理架构”的前面板框。

这里表示的参考模型更多的是一种商业模型，而不是一个系统模型（尽管它表现出一些迹象表明它是一个信息系统设计的框架）。必须将风险管理视为发生在所有其他四个层面的普遍活动。 这种风险管理架构与安全架构的概念很接近，但并不完全相同。 第 9 章和第 15 章对风险管理进行了更详细的讨论。

2.3.6 管理和治理架构

最后，围绕参考模型中的所有其他组件（参见图 2-1）是标记为“管理和治理架构”的无所不在的部分，并在图中显示为背板，围绕着其他所有组件。

将其表示为一个包罗万象的组件是至关重要的。 高级管理团队正是通过这种架构框架来控制业务、管理风险以及管理信息、应用程序和基础设施的业务使用。
管理和治理架构描述了分配给决策实体（个人或委员会）的决策过程和权限级别。 它本质上是一个关于组织内如何行使权力以及与每个实体相关联的控制范围的模型。

2.4． 信息系统架构参考模型

这个业务系统架构的参考模型（见图 2-1）是一个有用的概念模型，它描述了各种主要组件以及它们如何相互关联。 “信息系统架构”的总体定义可能是：

“一套一致的原则、政策和标准，为组织的业务信息系统的开发和运营设定方向和愿景，以确保符合和支持业务需求”

2.5. 基础架构架构参考模型

然而，基础设施组件需要一个更详细的参考模型，因为这是大部分业务系统技术所关注的部分。 图 2-2 显示了此技术基础架构架构的参考模型。

应用程序位于此处显示为“服务集成”的层之上。 这实际上是传统的中间件加上数据管理服务和广泛的通用服务，这些服务通过中间件层透明地提供给应用程序。 在本书后面关于概念安全架构的详细讨论中，对安全架构中所需的公共服务进行了更仔细的研究。

在服务集成层之下是另外两个层。 “信息传输”层是通信网络，而数据处理层包括平台，包括硬件和操作系统，在这些平台中进行物理位和字节的原始操作。
图 2-2：基础架构架构参考模型

在这些组件后面，参考模型显示了三个背板，它们跨越了所有其他分层组件。 这些服务类型普遍存在于整个基础架构中：
 安全服务（包括用于控制基础设施的所有服务，例如时间服务）；
 目录服务；
 服务管理。

最后，整个基础架构模型覆盖在另一个标有“运营服务”的背板上。 运营服务代表人员及其执行的运营流程和程序。 运营服务关注的是人，而不是技术，但它仍然是系统基础设施的一个组成部分。

2.6. 企业安全架构

许多企业组织的共同经验是，信息安全解决方案通常是在战术基础上设计、获取和安装的。 确定需求，制定规范，并寻求解决方案来满足这种情况。 在这个过程中，没有机会考虑战略层面，结果是组织在特别的基础上构建了混合的技术解决方案，每个解决方案都是独立设计和指定的，并且不能保证它们将兼容和可互操作。通常没有对长期成本的分析，尤其是在总体拥有成本中占很大比例的运营成本，也没有可以确定的战略来支持企业的目标。

2.6.1. 案例研究：用户身份验证

零碎的设计方法如何导致业务问题的最常见示例之一是对多个业务应用程序的业务用户进行身份验证。

通常每个应用程序都需要一个单独的用户 ID，并且经常强制执行不同的语法规则，以便用户不能简单地跨多个系统复制一个 ID。对于每个用户 ID 都有一个密码，同样通常需要异构的语法规则、不同的更改机制等，这样每个用户最终都会为每个系统使用不同的用户 ID 和不同的密码。

撇开这种方法的安全隐患（这是一个经常被安全专家争论的有争议的问题），这些应用程序的拥有成本受到用户支持水平的不利影响，用户支持水平只是为了确保用户可以登录到他们的 授权系统。 多个用户 ID 和密码的复杂性导致了极大的混乱和许多操作问题。 费用包括：
 管理多个用户 ID 和密码的创建、维护和删除；
 为大量用户登录问题提供帮助台支持；
 用户在尝试解决身份验证问题时失去了生产力。

正是这类常见问题导致采用战略方法跨多个业务应用程序（单点登录）提供用户身份验证服务。

那些遭受这些问题困扰的企业通常很清楚这些问题，但很难找到一种可以让事情变得更好的方法。 然而，悉尼歌剧院永远不可能用这种方法建造。 真正的架构绝不会偶然发生，因此企业必须找到帮助其通过更具战略性的架构方法取得成功的技能、方法和工具。

避免这些零碎问题的一种方法是开发一种企业安全架构，该架构是业务驱动的，并且描述了一种结构化的相互关系。支持业务长期需求的技术和程序解决方案。 如果架构要成功，那么它必须提供一个合理的框架，在该框架内可以根据安全解决方案的选择做出决策。 决策标准应源自对业务需求的透彻理解，包括降低成本、模块化、可扩展性、易于组件重用、可操作性、可用性、内部和外部互操作性以及与企业集成的需求 ICT架构及其遗留系统。

此外，信息系统安全只是信息安全的一小部分，而信息安全又只是更广泛主题的一部分：业务保障。 业务保障包括三大领域：信息安全； 业务连续性； 物理和环境安全。 更广泛的观点认为，业务保证涉及操作风险管理的所有方面。 只有通过对业务保证这些广泛方面的综合方法，企业才有可能在操作风险管理方面做出最具成本效益和最有益的决策。 因此，企业安全架构和安全管理流程应该涵盖所有这些领域。

本书的作者多年来（自 1995 年以来）一直在研究企业安全架构模型。 这种被称为 SABSA ®2 的模型是他们用于与许多客户进行重大咨询任务的基础，多年来，该方法已根据经验和各种来源的新想法进行了审查和改进 .本书本质上是对 SABSA ® 模型及其应用的描述。 第 3 章更详细地描述了模型本身及其推导。
该模型的主要特征是一切都必须从对安全业务需求的分析中得出，尤其是那些安全具有支持功能的业务需求，通过该功能可以开发和利用新的业务机会。 该模型是分层的，顶层是业务需求定义阶段。 在每个较低层都开发了一个新的抽象级别，通过概念架构、逻辑架构、物理架构的定义，最后在最低层，技术和产品（组件架构）的选择，换句话说， 购物清单。 此外，整个安全管理、管理和运营领域都通过运营架构来解决。

该模型本身是通用的，可以作为任何组织的起点，但通过其结构所隐含的分析和决策过程，输出变得特定于企业，最终高度定制为独特的业务 模型。 应用模型的输出实际上成为企业安全架构，并且是组织内信息安全管理战略计划成功的核心。

2.7. 为什么架构有时无法带来好处——以及如何避免这种命运

2.7.1 历史背景

“那些不记得过去的人注定要重蹈覆辙”。 ——乔治·桑塔亚纳

许多企业组织在战术基础上针对业务安全要求实施技术解决方案。 通常需要确定一个要求，然后寻找并获得一种产品以满足该要求，而不考虑更广泛的含义。实施了一种单点解决方案，该解决方案通常可以有效地提供一些安全性，但通常没有人真正确定安全性是否适合风险，或者成本是否与收益相称，或者它是否可以满足各种各样的其他业务 与风险无关的要求。 安全性通常是业务信息系统设计中最后考虑的事情，并且当所有其他设计决策都被冻结时，安全性通常会降级为一些附加修复的状态。

这会导致很多问题。 安全解决方案通常是孤立的，无法集成在一起或相互操作。 安全解决方案的多样性导致支持的复杂性和成本增加，特别是可能导致与行政和管理有关的工作量呈爆炸式增长。 最糟糕的是，由于对业务需求的关注不够，“解决方案”有时会阻碍业务流程而不是帮助它，并且商业界的安全声誉越来越差。
适当的业务安全性是指以具有成本效益的方式保护业务免受不当运营风险的影响。 如果业务安全要有效地增强业务流程和实现业务目标（以及它还有什么其他可能的用途？），那么必须避免上述方法。 应该开发一个更具战略性的观点，其中业务需求是开发有效信息安全解决方案的主要驱动力。

2.7.2 更广泛的业务需求

现在让我们回到信息安全问题上，以它为例，同时记住我们对业务保障和运营风险管理的要求也涵盖业务连续性以及物理和环境安全领域。 下面开发的相同原则可以应用于整个业务保证领域。

信息安全的主要业务需求是特定于业务的。 它们通常表现为保护业务信息的可用性、完整性、真实性和机密性，以及在信息系统中提供问责制和可审计性。 要了解这些要求，需要对业务流程进行详细分析，将通过直接采访运营业务经理收集的信息作为源数据。

然而，业务需求远不止纯粹的安全和控制。 信息安全为整个组织的商业目的提供了信息使用的信心。 信息安全解决方案的一般业务需求通常包括以下内容：

 可用性
该解决方案必须适合预期用户的技术能力，并且在人体工程学上为这些用户所接受。

 互操作性
该解决方案必须满足通信信息系统和应用程序之间互操作性的长期要求。

 一体化
该解决方案必须与长期可能需要的各种计算机应用程序和平台集成。

 可支持性
该解决方案必须能够在其设计使用的环境中得到支持。

 低成本开发
该解决方案应采用模块化设计，因此能够以最低成本集成到开发程序中。

 快速上市
该解决方案应该能够以最小的延迟集成到开发程序中。

 平台的可扩展性
该解决方案应适合可能需要与之集成的计算平台的范围。

 成本的可扩展性
入门级成本应适合解决方案所针对的业务应用范围。

 安全级别的可扩展性
该解决方案应支持实现所需安全强度范围所需的一系列加密技术和其他技术。

 可重用性
该解决方案应可在各种类似情况下重复使用，以便在其收购和开发中获得最佳投资回报。

 运营成本
应尽量减少对系统操作的成本影响。

 管理费用
该解决方案应该为安全管理提供一种有效的方法来优化此活动的成本。

 基于风险的成本/收益有效性
风险（收益）的降低应该与购置、开发、安装、管理和运营的成本相适应。

2.7.3 处理冲突的目标

最困难的挑战之一是这些不同的业务需求经常相互冲突。 通过将一组更广泛的要求简化为基本的三项要求：成本控制、安全性和可用性，很明显这三者在相互矛盾的方向上相互拉扯。 要获得更高的安全性或可用性将花费更多。 提高安全性通常会影响可用性，反之亦然。 图 2-3 将这种冲突描述为一个永恒的三角形，其中三个需求处于恒定的张力中，向相反的方向拉动。

图 2-3：冲突目标的永恒三角

2.7.4 赋能业务

最后，通常有许多特定于业务的需求会影响安全策略。 其中包括安全在产生适当的信心水平方面发挥重要作用的要求，以便利用信息和通信技术的最新进展实现新的业务方式，例如：

 利用互联网的全球影响力；
 使用全球电子邮件和电子信息；
 外包网络和计算机系统的操作；
 向第三方提供远程访问；
 发展网上商务服务；
 提供数字娱乐产品（视频、音乐等）；
 通过信息集成和用户界面的一致呈现来改善客户服务；
 通过供应商远程访问获得软件升级和系统支持；
 远程办公、移动计算、公路勇士和虚拟办公室。

2.7.5 成为一名成功的安全架构师

除非安全架构能够解决如此广泛的运营需求并提供真正的业务支持和业务支持，而不是仅仅关注安全性，否则它很可能无法满足业务的期望和需求。

这种类型的故障是整个信息系统行业的普遍现象，而不仅仅是信息系统安全领域。 在这本书中，整个重点都是通过始终牢记业务的真正需求来避免这种错误的必要性。 仅仅编译一组业务需求，将它们记录下来并放在架子上，然后继续设计一个仅由技术思维驱动的安全架构是不够的。

成为一名成功的安全架构师意味着始终从业务角度进行思考，即使您深入了解真正的细节和构造的具体细节。 您始终需要牢记以下问题：我们为什么要这样做？ 我们在这里试图在商业方面实现什么？

与你周围许多不了解战略架构并认为这完全与技术有关的人作战也将是困难的。 这些人会不断地挑战你，攻击你，嘲笑你。 你必须准备好处理这个问题。 您必须意识到，成为一名成功的架构师也意味着成为一名成功的沟通者，他可以向企业中需要接受有关这些问题教育的其他人推销想法和利益。

成功的最重要因素之一是获得企业高级管理层的支持和支持。 除非最高级的决策者站在您这边，否则无法实现企业架构。 整个企业都将享受架构工作的成果，但前提是整个企业能够开始以战略方式思考和行动。 创建这种接受和支持的环境可能是您在工作的早期阶段将面临的最困难的任务之一。

最后，关于成为一名成功的安全架构师的主题，这里是解决方案架构师的十条规则。

2.7.6 解决方案架构师的十条规则

倾听和学习：在您尝试向他们推销您的解决方案之前，客户会更加欣赏您对他们的环境和业务需求的充分了解。 这会建立客户对您的信任。

引导交流：在大多数情况下，客户不仅要为服务付费，还要有积极性来负责情况并提供明确的方向。 时刻准备好给别人时间和空间来表达自己。

深耕专业领域：深入了解特定技术领域并在其中发挥领导作用。 与可以补充您在其他领域的知识的其他领导者合作。

可重复性：利用已经为其他客户完成的工作。 通过使用来自类似客户情况的经验并使其适应客户的情况，您可以更快地交付解决方案并提高成功率。

市场意识：对市场上可用的替代解决方案有全球视野，并能够与您的解决方案进行讨论和比较。

商业意识：了解您提出的技术和解决方案的成本和业务影响。 将业务利益和客户的优先事项放在首位。

设计验收：在设计阶段的初始阶段，对客户保持开放和坦诚，并寻求解决方案的验收。 这比花费数周孤立地开发一些东西，然后再争取接受要好得多。 讨论设计原则和限制因素，并准备好捍卫解决方案背后的设计原理。

不要走极端：采用常识性的方法来规划和设计解决方案，并将其与客户的情况相匹配。 营销炒作所宣传的内容，或者您认为可能有趣的实验内容，可能并不总是合适的。 对一个客户好的东西可能不适合其他客户。 保持开放的心态。

最适合：如果解决方案对客户来说太复杂或成本太高而无法实施，请查看可以解决大多数问题的部分。 建议在客户预算范围内并带来最大利益的最佳解决方案。
充分利用客户的投资：尽可能使用现有的基础设施来实现过渡。 质疑将技术用于短期使用并带来可疑利益的感觉。 这方面的一个例子是一个成本高昂的过渡性基础设施，在项目完成后就变得过时了。

2.7.7安全架构需要整体方法

许多人错误地认为，在信息系统中构建安全性只是参考技术和程序控制清单并在清单上应用适当的安全措施。 然而，安全有一个重要的属性，大多数人都知道，但很少有人真正注意：它就像一条链条，由许多环节组成，链条的强度和适用性仅与其最薄弱的一环一样好 . 在最坏的情况下，如果一个环节完全缺失，那么链条的其余部分就毫无价值。

清单方法也失败了，因为许多人专注于检查链中的链接是否存在，但没有测试链接是否真正适合在一起以形成安全链。 链条是一个相当不错的类比，但问题实际上比这更糟糕。想象一个包含以下项目的清单：发动机缸体、活塞、活塞环、活塞杆、轴承、阀门、凸轮轴、车轮、底盘、车身、座椅、方向盘、变速箱等。假设这个清单全面列出了每一个 制造汽车所需的组件。 如果您仔细检查清单并确保您拥有所有这些组件，这是否意味着您拥有汽车？ 不完全是！

汽车是复杂系统的一个很好的例子。 它有许多子系统，而这些子系统又具有子系统，最终还有大量的组件。 设计和制造汽车需要一种系统工程方法。 （有关系统工程作为一门学科的详细讨论，请参阅第 5 章）。

汽车制造清单方法未解决的一些关键问题是：

 您能确定所有部件都设计为作为一个平稳运行的系统协同工作吗？
 您能保证汽车已正确组装吗？
 发动机调好了吗？
 此时系统实际上运行流畅吗？
 是否有人在控制速度、润滑运动部件、维持其燃料供应并监控其性能？

清单并不是完整的答案。 与所有其他形式的架构一样，安全架构需要一种整体方法：
 你了解要求吗？
 你有设计哲学吗？
 你有所有的组件吗？
 这些组件是否协同工作？
 它们是否形成一个集成系统？
 您确定它已正确组装吗？
 系统运行流畅吗？
 系统是否正确调整？
 您是否正确操作系统？
 你维护系统吗？

将汽车类比为需要整体架构设计的复杂机器比链条的想法要强大得多。 安全架构更像是汽车，而不是链条。

2.8 总结：架构意味着什么？

架构意味着从一个整体的、企业范围的观点出发，制定系统（建筑、汽车、船舶、商业信息系统）的设计和建造原则、政策和标准。

架构的目的是确保跨大型复杂系统或跨复杂的小型系统阵列的设计方法的一致性。 架构方法打破了复杂性，从而呈现出更大的简单性，从而使设计活动更易于管理。

简化复杂性的方法之一是创建架构参考模型，该模型使用功能分层将复杂的整体分解为一系列不太复杂的概念层。

企业安全架构必须从业务角度出发，并且必须考虑到可能经常相互冲突的广泛需求。 成功的架构平衡了这些相互冲突的目标之间的紧张关系。

使用零散的方法而不是战略架构方法通常无法满足业务需求并提供真正的业务利益。 企业安全架构需要一种整体的系统工程方法，这不仅仅意味着满足清单上的所有要点。

成功的安全架构师是一位经验丰富且聪明的人，他善于沟通，能够汇集来自团队多个部门的许多技能和广泛的知识 — 能够应对业务需求并使用架构技能将复杂性转化为简单性的人。