企业框架描述了很多的问题，因此它比仅仅实现商业和IT技术的整合这一单一目的要复杂得多。因此我们可以简化这些模型、仅仅考虑一些有共同点的子架构，全面地研究和修正企业架构框架中的这些概念已超出了本文讨论的范围。如果将整合作为主要目的，一个企业架构有四个基本组件：商业架构、信息架构、应用架构和技术架构。这并不是新提出来的，这个观点已经被企业架构公共组织接受了。
我们将陈述基于这四种架构组件的整合的相关问题。架构所拥有的组件越多，整合就越复杂，因为有更多的规则和推理需要考虑和管理。因此为了完成整合，首先要弄清楚的是各个架构的组件。
至于技术架构的整合，主要取决于技术本身。我们正在研究面向服务概念怎样去与以前的架构交叠，怎样来实现在模型中整合的形式化的问题。这是在研究的问题超出了本文讨论的范围。
商业架构
商业架构是定义商业决策、步骤和功能要求的结果。它是规定信息系统要求的基础，通常包括以下内容：企业高层次的目标;企业整个或至少是重要的商业运作步骤、商业功能的实现;主要组织的架构和这些内容之间的联系等。
在此文中，我们考虑一个简单的情况，即商业架构仅包括商业活动过程。每个商业活动过程由一系列商业活动组成，而每个商业活动又与信息、时间和人相关联。商业活动过程具有危急性、安全性、有延时性、在线性等一些属性。
信息架构
正如在商业架构中所讲述的，信息架构描述组织为了运营商业活动需要知道些什么。它提供除了IT数据库以外的商业信息。在信息架构中，商业信息以信息实体的形式组织着，它们每一个对于管理和执行诸如查询、分类、质量控制、显示、分布、评定等操作，都有着各自的责任。
信息实体必须都有一个从商业角度定义的标识符、一组描述和一系列属性。属性和使用或制造它们的商业活动过程、创建、阅读、更新和删除它们的应用程序都相关，它们的分类根据的是不同的性质，如安全性、可用性等。
比如：客户和雇员都是典型的信息实体。雇员有“所修课程”、“能力”、“意外事故”、“职位”等属性。这些属性都可以由一个复杂的数据库模式来提供物理支持，这个数据库模式可被用于不同的数据库中，被一些不同的应用程序来使用。
应用架构
应用架构描述了为达到以下两个目标所需的一些应用程序：
应用架构通常源于对商业和信息架构的分析。
应用架构通常包括：对支持商业活动的自动化服务描述;对组织应用系统的交互和接口的描述;对开发新应用程序、以达到企业目的而需进行的对旧的应用程序的修正和相关技术平台的描述;
应用程序也有必需的属性，如可用性、可扩展性和基于固定模式的可访问性。
整合和架构组件
在定义了主要的架构组件之后，我们将要讲述这些组件和它们之间整合的关系。
商业和应用之间的整合
如果商业和应用架构高度整合，那么工作人员所花的时间和所付出的努力都仅仅用在值得的功能上;反之，在以下这些事情上工作人员将会消耗额外的工作：
- 多次在不同的应用中插入相同的数据
- 每次为了一个应用，都必须登录一次
- 从多系统的失败操作中恢复，恢复到正常的状态需要细心的人工分析
需克服不方便的应用功能。如因为没有多份打印的接口而只能一张张打印发票。
注意：上文中商业和应用架构的整合并不是指一个灵活的IT架构，事实上，对灵活的IT架构的度量是人们为了在商业活动变化的情况下仍保持商业和应用架构整合的结果。下面将要讨论这一主题。
信息和应用的整合
在信息和应用高度整合的架构中，IT工作者仅仅在商业功能和逻辑的编程上花费时间和精力。反之，IT工作者必须为以下事情做一些额外的编程工作：
- 因为被多个应用程序更新，需对同样的数据保留复制多份。
- 需保证多交易操作的一致性，因为单个商业活动涉及到多个应用程序。
- 从多系统中收集信息，为了保持组织商业信息一致性而编写规则。
- 当数据在应用程序之间迁移时需转换数据架构
在更改这两种架构是额外的代码始终是必须的，但是运行信息架构的关键信息比支持应用架构的应用程序要稳定得多，所以实际上大部分精力都花在应用程序的更改上。
商业和信息架构的整合
当商人拥用运营商业活动所必需的信息时，信息和商业架构就整合在一起了。这些信息是指准确的，足够详细的和及时的信息。不像以前的不协调架构，这里关键不是时间或是努力，而是得到足够多的与商业相关的信息。
例子有很多：一个执行总裁想得到一份销售额按服务类型分类的报告。假设总裁想得到的这份报告或者是目前的商业，或者是将来的商业，能或不能完成这样一份报告分别是信息和商业架构整合或不整合的证据。为了完成这份报告我们必须有足够多的基本数据和数据挖掘的应用程序，因此这件事应该由前面的整合(信息和应用以及商业和应用的整合)处理。