传统系统工程(TSE)的目的是将不同学科的专家聚集在一起，以解决在一个大型、复杂的“单一”系统的开发中所固有的广泛问题(Blanchard and Fabrycky 2010;大厅1989;Sage and Rouse 2009)。企业系统工程(ESE)超越了这一传统基础，“考虑信息密集型系统正在成为企业业务战略核心要素的现代组织日益需要的SE服务的全部范围”(Carlock and Fenton 2001, 242-261)。系统工程(SE)的传统作用是大量参与系统采买和实施，特别是在政府采买非常大的、复杂的军事和民用系统(例如F22战斗机和空中交通管制系统)的背景下。

ESE包含了系统收购中的这个传统角色，但也包含了企业战略规划和企业投资分析(以及下面所述的其他角色)。企业层面的SE的这两个额外角色“与组织的高级线管理共享，并且与经典系统工程的技术性质相比，在本质上更具有企业家精神、业务驱动和经济性质”(Carlock and Fenton 2001, 242-261)。

缩小差距

ESE实践最近经历了重大发展。

今天的口号是企业系统工程，反映了一个日益增长的认识，一个“企业”可能包括许多来自不同政府部门的组织，来自私人和公共部门，在某些情况下，来自其他国家的组织。(斜方2004)

Rebovich(2006)说“新的和正在出现的思维模式越来越被认为是企业中成功的系统工程的关键。”例如，除了TSE过程领域，MITRE还在ESE过程(DeRosa 2005)中包括了以下过程领域，以缩小ESE和PSE之间的差距:

• 战略技术规划，
• 企业架构，
• 基于能力的规划分析，
• 技术规划，
• 企业分析与评估。

这些 ESE 流程显示在下图中的整个企业的上下文中（DeRosa 2006）。 ESE 流程显示在中间，左侧是业务流程，右侧是 TSE 流程。 这些业务流程在名为“ 相关业务活动 ”的文章中进行了描述。 TSE 流程在许多来源中都有详细记录，尤其是在 ISO/IEC/IEEE 15288 标准 (2015) 中。

图 1. 整个企业背景下的企业 SE 过程域 (DeRosa 2006)。 经© 2011 许可转载。MITRE Corporation。 版权所有。 所有其他权利均由版权所有者保留。

许多组织都将SE视为系统开发项目的起点和终点，并在许多过程定义中将其描述为。在MITRE中，这个受限制的定义被称为TSE。许多人采取了更广泛的观点，试图将SE应用于“整个系统”和“整个生命周期”。例如，希钦斯(Hitchins, 1993)提出了以经营目的为中心的整体、全生命周期、更广泛的SE系统观。Elliott和Deasley(2007)讨论了开发阶段SE和现役SE之间的差异。

与TSE相比，ESE更像是一种“制度”(Kuras和White 2005)，负责确定“结果空间”，塑造开发环境，将开发与操作耦合起来，并奖励结果而不是感知到的承诺(DeRosa 2005)。ESE必须不断地描述运营环境和企业或SoS干预的结果，以刺激企业投资组合中各种系统内部和之间的进一步行动。结果空间的特征是一组能够帮助满足企业目标的期望功能，而不是基于近期需求的确定的“用户需求”。企业能力必须足够健壮，以便在未来处理未知的威胁和情况。Rebovich和White(2011)的一篇作品中详细描述了MITRE之前对ESE的看法。

需求在ESE中的作用

TSE通常将用户需求转换为驱动系统元素设计的系统需求。系统需求必须被“冻结”足够长的时间，以便系统组件能够被设计、开发、测试、建造，并交付给最终用户(这有时需要数年的时间，而对于非常大的、复杂的系统，如航天器和战斗机，则需要超过10年)。

另一方面，ESE必须考虑这样一个事实:企业必须不是由需求驱动的(需求很少能够被定义，更不用说稳定了)，而是由不断变化的组织愿景、目标、治理优先级、不断发展的技术和用户期望驱动的。企业由人员、流程和技术组成，其中人员充当企业的“代理”:

Ackoff将企业描述为一个“有目的的系统”，由选择自己的目标和实现这些目标的手段的代理人组成。人员、组织及其策略的多样性造成了企业内在的复杂性和不确定性。ESE必须考虑到这些代理人的关切、利益和目标。(Swarz, DeRosa和Rebovich, 2006)

TSE侧重于基于输出的方法(例如，功能分析和面向对象分析)，而ESE有义务强调结果(例如，业务分析和任务需求分析)，特别是那些与企业目标和关键任务需求相关的结果。

企业主体及关系

企业“系统”与产品/服务系统具有不同的实体和关系(参见注1)。这些可以有效地分为两类:资产项目和概念性项目。资产的一个例子是硬件和软件。概念性项目的例子包括分析、金融要素、市场、政策、流程和战略。

注1。“企业系统”不应与“被视为系统”的企业混淆。企业系统是跨企业使用的产品(或服务)系统，例如工资单、财务会计或企业资源规划应用程序，以及跨一个或多个组织使用的合并数据中心、数据仓库和其他此类设施和设备。

产品和服务有时被视为“资产”，如下图所示(Troux 2010)。企业项目的这种分类来自Troux Architect建模工具中用于企业架构表征和分析的语义模型(即元模型)。其他相关的企业实体包括信息、知识、技能、财务、政策、过程、战略、市场和资源，但这些都被归类为“概念”项(在这个特定的模式中)。关于如何使用这个元模型的实体和关系的更多细节由Reese(2010)提供。

表1。企业实体的资产领域和概念领域类别。(Troux 2010)版权许可转载©2010 Troux Technologies。版权所有人保留所有其他权利。

应用程序/软件和基础设施/硬件领域可能是系统工程师最熟悉的（如下图所示）。 应用程序/软件域包含诸如已部署软件本身之类的内容，以及应用程序、模块、服务器、补丁、功能和消息。 基础设施/硬件域包含硬件本身，以及网络和不同种类的硬件，如计算硬件、机柜和网络设备。 可能有不同的计算硬件子类型，如计算机、服务器、台式机、笔记本电脑和大型机。 您可以从这些领域的详细说明中看到，企业架构“模式”在它可以建模的事物种类上非常广泛。

图 2. 企业实体和关系示例 (Troux 2010)。 经版权 © 2010 Troux Technologies 许可转载。 所有其他权利均由版权所有者保留。

技术含量较低的领域是政策、市场、战略、转型、财务、知识和技能以及分析。 在像这样的典型企业架构模式中，可能有超过一百种类型的建模对象分组到这些域中。 上面给出的示例来自用于企业架构活动的 Troux Architect 建模工具 中的 Troux Semantics 元模型。 其他企业建模工具也有类似的元模型（有时称为“模式”）。 有关如何使用上图所示元模型的更多详细信息，请参阅 Reese (2010)。

企业架构框架和方法

企业架构框架是可在开发企业架构描述时使用的标准化视点、视图和模型的集合。 这些架构描述可以是非正式的，基于简单的图形和表格，也可以是正式的，基于更严格的建模工具和方法。 ISO/IEC 42010 (2011) 规定了如何创建架构描述。

这些框架与企业的描述性模型相关，并在特定社区中达成共识。 有多种可用的框架和方法可帮助开发 企业架构 。

Urbaczewski 和 Mrdalj (2006) 提供了五个突出的架构框架的概述和比较，包括：

• Zachman 企业架构框架（Zachman 1992），
• 国防部架构框架 (DoDAF) (DoD 2010),
• 联邦企业架构框架 (FEAF) (FEA 2001)，
• 财政部企业架构框架 (TEAF)（美国财政部 2000），
• 和开放组架构框架 (TOGAF) (TOGAF 2009)。