在讨论不同层次的系统时，清晰的定义模糊给出不同定义以及使用的词语，是十分重要的。
企业架构有许多的定义。您可以将企业架构看做一个合适的名词（例如，企业架构的原则），正如您看到的那样，我们没有安装那种方式来使用它。我们所讲的企业架构，是作为企业架构的描述。企业架构的原则将不同视角的业务，战略，过程，方法以及组件联系到一起。这些视角是由企业架构的不同方法定义并改变的。企业架构是由企业架构师创建的。所以企业架构师的责任远远超过了这里所讨论的。
一个程序会变更企业的状态，以提供一些新的或者改善的功能。它的目的是通过变更企业的一部分，来使企业从初始状态转化为完成状态。程序是由一个或者多个（通常更多）项目来执行。注意程序拥有比整个企业更小的范围。但是为了简化这里的讨论，我们只会讨论对整个企业有影响的程序。
图2.程序和项目是怎样影响企业的
不管是否得到记录，每一个企业都有一个架构，它由组件以及它们的关系还有合作组成的，通常获取到图片，图表，文件，模型以及等等。除了架构以外，企业也有一系列它需要满足的需求。也会有测试来决定企业完成需求的程度。
再一次，不管是否得到记录，每一个企业都有它的需求和测试。当企业组件的新版本得到部署时，将会执行一系列的测试以确保组件满足了它的需求，包括它不会破坏高层次的功能，因为它与其他组件交流的方式。如果这些测试发现一些问题的话，那么它们会被当做企业缺陷直到它们得到解决（问题可以是新发布的组件，或者交流组件的不能预料的行为）。
因此，我们将会看到这些产品，当它们存在并得到合并时，将会组成企业关键元素的完整描述（见于图3）：
图3.企业的初始产品
正如以上定义的那样，程序的目的就是将企业从初始状态移到完成状态。许多次，这个包括创建一系列描述完成状态的产品。但是，如果当前的状态得到完善的记录，那么重新记录程序变更的部分事情（需求，架构和测试）就不是必要的。只需要更新带有程序描述的变更的已存在初始产品。这些变更就是需要向初始产品应用的三角区，以描述需要的完成状态。
程序不是从无到有的，而是描述初始状态的变更。这假设初始状态得到良好的理解（获取）。如果不是这种情况，那么所有就没有失去。因为以任何方式记录完成状态是必要的，创建的产品可以在程序完成以后变成企业层次的初始产品。
程序的范围可以从变更企业的一方面，到转变整个的企业。因此，为企业产生整个系列的初始产品，就很容易超出单个程序的范围。随着越来越多的程序接触到企业的更多领域，这个空白就得到了填补。这种方法避免了任意变更程序可以开始之前，需要等待完整系列的初始产品的问题。这种方法可以一直进行，直到企业初始产品的剩余空白，相对变小，并通过单独的努力来处理以直接使空白消失。为了达到企业的完整和稳定代表，所有的企业程序必须使用标准的惯例，来代表初始和完成的产品（或者至少将它们的产品从标准的惯例转变或者转变至标准的惯例），而且实际上企业必须开始在前面程序创建的程序之上构建产品。否则在不同程序创建的产品之间建立联系，并达到企业的单个稳定代表，会变得极端困难。而且，初始产品必须作为单个稳定的储存库进行维护。储存库是如何构建的，它是否是单个文件或者数据库的联合已变得不再重要。重要的是它可以作为一个稳定的代表进行维护和访问。
如果（或者一旦）企业初始产品可以得到利用，程序应该从这些产品开始，并获取需要执行程序的变更。这包含了需求，架构的更新，以及变更初始以与需求的变更保持一致这三者的三角区。这些需求的变更，就算它们稍后进行非正式的交流或者改善之后也是这样，驱动架构三角区。不管是需求三角区还是架构三角区都可以使变更进到测试集中。
随着程序得到实现（这就是说，程序在实现之后），测试可以得到实施，以证实需求得到满足，并探测到实施中，需求中，或者测试本身的所有缺陷。正常情况下，所有发现的缺陷都可以在程序的范围之内得到解决，因此变成额外的企业层次的缺陷。
在程序的结尾，企业就处在程序定义的完成状态中。因为这是企业的新初始状态，所以企业层次的初始状态需要得到更新。这是很直接的，因为程序已经产生了对产品的所有需求的变更。查看图4中产品流的图示（注意因为多个程序可以同时进行运行，所以这次企业可能实际上会有超出本程序讨论范围的额外变更。这些额外的变更可以合并到程序结尾的企业初始状态中）。
图4.程序和企业层次之间的产品流
程序定义了一系列创建或者变更端到端功能的变更。为了达到这些新的功能，创建新的系统和/或变更多个已存在的系统（可能通过获取新的程序或者变更一个过程），是十分必要的。定义并执行多个项目是通常的，每一个影响的系统都有一个，以达到总体的程序目标。
程序层次的需求在多个系统的合作中得到执行是最常见的。在这些条件下，创建一个程序层次的设计，以显示系统是如何合作的。这种设计向每一个涉及到的系统分配责任。并且责任与它们在合作中扮演的角色相对应。但是，有时一个程序层次的需求会在单个系统中完整的执行。在这些情况下，程序层次的需求会直接分配给单个系统。查看图5以得到这些关系的图示。
图5.程序到项目需要流程
但是在这里，在执行项目时，我们并不需要从无开始，除非项目是从新系统中创建的。如果项目的目标是变更一个已存在的系统，那么系统就有一个初始的状态了。它拥有满足的需求，一个架构，执行的测试，可能还会有一些公开的缺陷。如上所述，对于初始的企业产品，如果这些产品不能获取，那么它们可以创建一系列的项目。这对企业产品也是成立的，系统产品需要在储存库中以一种稳定的形式进行维护，以有效的评价它们。
初始的系统产品，就像初始的企业产品那样，包含了需求，架构，测试以及已存在的缺陷。这样，如果一个系统拥有已存在的初始产品，那么它就不必从空白开始，而是创建它的完成状态以作为存在产品的变更。就像程序对企业产品提供了更新一样，项目队系统产品也提供了更新。查看图6以得到系统初始产品和项目产品之间的关系。
图6.项目和系统层次之间的产品流程
上面介绍的，通过执行程序和项目，为企业和系统的发展提供了端到端的流程，包括它们的初始产品。需要承认的是，这是一个简化的视图，假设企业及其系统之间只有一步。显然还存在额外步骤的可能性。但是，相同的方法也适用。方法可以稳定的应用到每一个层次的分解，以及对于哪一个机理（程序，子程序，项目，子项目等等）更新了这些干扰层次做出合适的决定。图7为这个简化的视图提供完整的端到端的流程。
图7.从企业到系统的端到端流程
一些公司有管理拥有企业和系统层次的产品的成熟经验，并从评价这些产品中获益匪浅。其他公司刚刚起步，已经意识到未来的利益。但是，目标和方法总是一致的。为了有效的管理企业的发展，全面理解当前的需求和功能，以及怎样达到这些功能（它的功能）是必需的。而且，理解系统在测试和已存在的缺陷方面的运行情况，是十分必要的。
重构每一项项目上的产品是没有什么效率的。而且，公司想要重复使用已存在的知识，并让产品按企业要求的那样进行发展。因此，对当前状态有精确认识的公司，能够有效的计划企业的发展，并通过评价每一项项目上的产品来减少总共的花费。就算对整个公司来说，要获取完整系列的产品时不现实的，但是公司仍然在从获取企业部分产品中获利，获取的部分越大，收益就越大。
没有对当前状态的精确观察，每一个项目都必须a）通过在继续发展项目之前检查企业，来创建当前状态的代表；b）通过连续的应用前面程序执行的变更，来尝试构建当前状态的代表；或者c）放弃尝试代表当前的状态，并试着变更未知的架构，希望变更不会产生不想要的结果。我们看见了有公司尝试了所有的三种选择，结果只是痛苦的发现，保持当前企业状态的精确看法，对有效操作是十分必要的。
公司从再利用系统层次的产品中也受益匪浅。一家企业有许多的系统，因此系统的数量大大增加了再使用的收益。大多数系统的复杂性，发展的已经超出了单个人可以完全保持在心的能力范围。获取需求，架构，测试以及系统缺陷的产品对交流都是必需的。评价从一个项目到另一个项目产品的利益包括：更好的稳定性，更少的错误以及总体减少的无用功。
我们已经论证了企业的架构，是怎样为程序的发展提供一个基础的。私人程序和整个的公司都指定企业状态变更的程序中获益匪浅。项目进化系统从初始状态不断发展的。但是这样做只是会满足项目提供的分配以及获得的需求。为了完成这个循环，项目和程序必须对初始状态以及企业产品应用它们的变更，这样它们对下一次变更所做的努力就是很精确的。
IBM?提供了一系列的产品和方法，以支持贯穿生命周期的EnterpriseArchitect和SystemsEngineer。如果您想要知道关于这些特定产品的更多信息，那么就是一个好的开始地方。对于这种方法，图8验证了这些方法时这样应用在整个软件生命周期的。
模型驱动的系统开发服务型建模&架构*1组件业务建模*1IBM全球服务方法*1视图战略获取需求业务架构服务架构同时技术架构设计实施测试部署*1IBM全球商业服务图8.支持整个软件生命周期的EnterpriseArchitects与SystemsEngineers的方法
还有一些值得提及的话题，但是全力的介绍它们超出了本文的讨论范围：