我的第一个观察是安全是每个人的责任。没有人能够监管整个组织的代码库。安全设计和企业设计在目的和目标上本质上是不同的，但两者应该密切互动以获得最佳结果。企业架构师的目标是设计一个满足业务需求并准确表示业务流程的系统，并提出实现此类功能的一致模式。安全架构师的目标是设计一种安全模式并为其实施和实施提供一致的模式。

在大型环境中，这两项任务的规模可能需要不同的人来处理它们，并且在业务流程和安全流程之间的责任分离方面可能会有一点好处，但总的来说我看不到任何一个具有跨界技能的人不能同时做这两件事的有力理由。（我是作为具有安全设计背景的企业软件架构师这么说的。）

发表与 AJ 出色答案相反的观点：

在大型公司中，架构可能最终由不同部门、国家、地区等的多个团队负责，以便为每个地区提供高性能，而企业安全可能会从全局角度进行管理，以降低风险组织作为一个整体。

因此，我倾向于将安全架构作为架构或安全的子学科的想法，从业者与企业架构师合作以达到两全其美（或妥协）的解决方案。

首先，如果您谈论的是企业架构中的学科，我假设您谈论的是这四个：

• 业务架构
• 数据架构
• 应用架构
• 技术架构

当然，存在很多子学科，但我认为上面给出的一个是最常用的一个（也是 TOGAF 使用的一个）。

尽管安全性是一个非常重要的方面，但我认为它提供了一个过于详细的视图，无法作为额外的学科包含在上面给出的四个方面。企业架构提供了组织结构的视图，包括其业务流程、数据（信息）对象、应用程序和基础设施。所有这些都需要是安全的，但它们需要更多，这取决于组织设定的目标。

如果组织没有将安全设置为目标（意味着它永远不会出现在Zachman框架的动机列中），则不应将其转换为流程、数据对象、应用程序或基础架构。这是在 EA 中不应将安全架构视为单独学科的核心原因之一：安全不是组织基本结构的一部分，而是可以对结构做出选择。

这并不是说安全架构不重要。作为比较：业务流程需要高效。为什么需要高效？因为很明显，尽管理论上它应该只有在有动机（Zachman，再次）使该过程高效时才有效。这同样适用于安全性。应用程序应该是安全的，因为它是显而易见的（对我们来说）。然而，理论上，应该存在使应用程序（或业务流程、或数据或基础设施，就此而言）安全的动机。

最后引用TOGAF的作者的话：

安全问题普遍存在于整个架构领域和架构开发的所有阶段。安全性被单独调用，因为它是业务功能很少能看到的基础设施。其根本目的是保护企业系统和信息资产的价值。

一句话提醒我们，安全性实际上对企业架构师和相应的框架很重要。它只是不属于一般分类（业务、数据、应用程序、技术）的一部分。当然，如果您的问题是“为什么企业架构不关心安全性？” 或“为什么 EA 方法论从不谈论安全性？”，我完全不同意你的观点，因为他们（我）确实关心，而且这些方法论确实在谈论安全性。

现在，在总结这个答案时，我注意到我实际上并没有直接回答你的问题。因此最后一句话：在 EA 开发期间将安全性作为主要关注点是有好处的，企业架构师应该已经知道这些好处。将其作为一个单独的学科包含在 EA 的四个众所周知的子学科旁边只是一座桥梁。