从两个著名的专家那里学习有关企业架构和系统工程师之间的关键连接点，以及企业架构是怎样同时影响并限制系统开发的。

系统工程师还要在开发下关注当前的系统，而并不需要再关注它所支持的大型企业。本文探讨了企业架构和系统架构之间连接点，并讨论了企业架构是怎样向系统架构提供输入，同时还对其有所限制的。它的目标是帮助系统工程师获取深入理解系统支持的企业的架构，是怎样限制并改造创建系统的项目了。在今天的商业驱动的企业中，在企业的业务功能和项目执行的功能之间，有一种直接的关系。

系统开发的变更蓝图

今天的企业，正在从提供单独功能的管道系统，向评价服务以提供强壮有效操作的更加集成的系统进行转变。结果，企业内的系统得到更紧密的集成，变更它们的努力也变得更加复杂。处理项目的系统工程师就不再能够只关注变更的系统，还需要意识到系统是怎样与企业中的其他系统进行交流的。

图 1 提供了这种变更的强调的概述。以前业务架构是由独立的烟囱架构支持的。从企业架构到系统工程师有完全不同的切换及其相关的问题。今天，系统开发是更加有业务驱动的。IT 和系统花费的金融责任性有强烈的需求，花费必须返回至他们的商业利益。因此，商业和开发之间并列是关键的。在企业架构的参入与系统工程师之间是更加连续的，产生更大的业务/IT 并列，并贡献于生命周期内的技术管理。企业架构停留的时间变长，系统工程师更早的参入其中。最后，执行的服务支持操作期间的数据采集以及监控工作。对回馈的分析驱动了进一步的变更。

图 1. 生命周期早期的并列架构和工程

定义

在讨论不同层次的系统时，清晰的定义模糊给出不同定义以及使用的词语，是十分重要的。

企业

企业的定义是一家商业公司 ⁱ 。机构可以是一家公司的一部分，一个完整的公司，或者是不同公司之间的合作部门。为了简化我们的讨论，让我们想象一家企业作为我们的公司。虽然查看一家企业有很多种方法，但是为了合理的研究企业的发展，把它想象成一个大型的系统时很有用的，就像一个系统：a）它像投资者提供特定的价值；b）它的资金允许它的正常操作；c）它执行一些操作，满足一系列的需求；d）它由一系列的组件组成，工人和低层次的系统，他们联合在一起完成它们的功能。（贯穿这篇文章的词语“组件”，是用于指与其他部分相合作的整体的一部分）。

企业架构

企业架构有许多的定义。您可以将企业架构看做一个合适的名词（例如，企业架构的原则），正如您看到的那样，我们没有安装那种方式来使用它。我们所讲的企业架构，是作为企业架构的描述。企业架构的原则将不同视角的业务，战略，过程，方法以及组件联系到一起。这些视角是由企业架构的不同方法定义并改变的。企业架构是由企业架构师创建的。所以企业架构师的责任远远超过了这里所讨论的。

这样企业架构的目的，正如文章中定义的那样，是描述企业的组件，它们的关系，它们是怎样合作的，以及它们是怎样与“外部的世界”相联系的、一个企业架构为企业组件的执行提供了方向。组件的执行导致了企业状态的变更。

系统

系统组成一个统一完整的，服务一个共同目 ⁱⁱ 的一组项目。共同的目的就是系统存在的原因。一个或者多个投资者会意识到系统需要完成的目的。因此系统的目的是满足一系列投资者的需求，也就是所谓的系统需求。这些需求包含展现的功能，以及对于给定的质量和限制因素，这些展现的功能是怎样实现的（例如，非功能性的需求）。系统通过执行一系列的操作来满足它们的需求。这些操作能够满足投资者的需求。因为系统是一组项目，所以系统的操作实际上是由这些组件的操作来实现的。

注意到组件可以是任何事情会是十分重要的：硬件，软件或者人员。参入一个系统作为合作组件的人员叫做工人。有一些组件本身就可以当做独立的系统，通常被叫做亚系统。实际上，工人也可以被当做系统，如上所述，但是我们并没有像这样对待它们，而是当做一个基本的对象，因为我们不关注它们的部分是怎样在内部协作的。

系统工程师

标题系统工程师应用于与系统工程 应用于使用与系统工程有关的个人。我们看到“系统工程师”会对一切事情负责，从计划到需求获取，到架构获取，到集成再到测试。许多这些活动超出了传统系统工程的原则。在本文中，我们关注系统工程师的角色，以确保开发努力的结果会与企业的剩余部分相“配合”，并以稳定的格式操作。基本上，在与大型企业强制的限制因素相一致时，创建或者更新系统架构是系统工程师的责任。

程序

一个程序会变更企业的状态，以提供一些新的或者改善的功能。它的目的是通过变更企业的一部分，来使企业从初始状态转化为完成状态。程序是由一个或者多个（通常更多）项目来执行。注意程序拥有比整个企业更小的范围。但是为了简化这里的讨论，我们只会讨论对整个企业有影响的程序。

项目

项目是带有特定关注，开始，以及末端的开发活动，它想要交付贡献功能的可评价的结果。项目关注向企业引入新系统或者变更一个已存在的系统是很常见的，虽然他的范围可以更大或者更小。项目拥有它们自己的目标和预算。它们一般会与其他项目相联合以作为程序的一部分（见于图 2）。

图 2. 程序和项目是怎样影响企业的

企业层次的描述

不管是否得到记录，每一个企业都有一个架构，它由组件以及它们的关系还有合作组成的，通常获取到图片，图表，文件，模型以及等等。除了架构以外，企业也有一系列它需要满足的需求。也会有测试来决定企业完成需求的程度。

再一次，不管是否得到记录，每一个企业都有它的需求和测试。当企业组件的新版本得到部署时，将会执行一系列的测试以确保组件满足了它的需求，包括它不会破坏高层次的功能，因为它与其他组件交流的方式。如果这些测试发现一些问题的话，那么它们会被当做企业缺陷直到它们得到解决（问题可以是新发布的组件，或者交流组件的不能预料的行为）。

因此，我们将会看到这些产品，当它们存在并得到合并时，将会组成企业关键元素的完整描述（见于图 3）：

• 需求（以及它们的驱动因素诸如动机和目标）
• 架构（包括设计和实现）
• 测试
• 缺陷

图 3. 企业的初始产品

程序变更了企业

正如以上定义的那样，程序的目的就是将企业从初始状态移到完成状态。许多次，这个包括创建一系列描述完成状态的产品。但是，如果当前的状态得到完善的记录，那么重新记录程序变更的部分事情（需求，架构和测试）就不是必要的。只需要更新带有程序描述的变更的已存在初始产品。这些变更就是需要向初始产品应用的三角区，以描述需要的完成状态。

程序不是从无到有的，而是描述初始状态的变更。这假设初始状态得到良好的理解（获取）。如果不是这种情况，那么所有就没有失去。因为以任何方式记录完成状态是必要的，创建的产品可以在程序完成以后变成企业层次的初始产品。

程序的范围可以从变更企业的一方面，到转变整个的企业。因此，为企业产生整个系列的初始产品，就很容易超出单个程序的范围。随着越来越多的程序接触到企业的更多领域，这个空白就得到了填补。这种方法避免了任意变更程序可以开始之前，需要等待完整系列的初始产品的问题。这种方法可以一直进行，直到企业初始产品的剩余空白，相对变小，并通过单独的努力来处理以直接使空白消失。为了达到企业的完整和稳定代表，所有的企业程序必须使用标准的惯例，来代表初始和完成的产品（或者至少将它们的产品从标准的惯例转变或者转变至标准的惯例），而且实际上企业必须开始在前面程序创建的程序之上构建产品。否则在不同程序创建的产品之间建立联系，并达到企业的单个稳定代表，会变得极端困难。而且，初始产品必须作为单个稳定的储存库进行维护。储存库是如何构建的，它是否是单个文件或者数据库的联合已变得不再重要。重要的是它可以作为一个稳定的代表进行维护和访问。

如果（或者一旦）企业初始产品可以得到利用，程序应该从这些产品开始，并获取需要执行程序的变更。这包含了需求，架构的更新，以及变更初始以与需求的变更保持一致这三者的三角区。这些需求的变更，就算它们稍后进行非正式的交流或者改善之后也是这样，驱动架构三角区。不管是需求三角区还是架构三角区都可以使变更进到测试集中。

随着程序得到实现（这就是说，程序在实现之后），测试可以得到实施，以证实需求得到满足，并探测到实施中，需求中，或者测试本身的所有缺陷。正常情况下，所有发现的缺陷都可以在程序的范围之内得到解决，因此变成额外的企业层次的缺陷。

在程序的结尾，企业就处在程序定义的完成状态中。因为这是企业的新初始状态，所以企业层次的初始状态需要得到更新。这是很直接的，因为程序已经产生了对产品的所有需求的变更。查看图 4 中产品流的图示（注意因为多个程序可以同时进行运行，所以这次企业可能实际上会有超出本程序讨论范围的额外变更。这些额外的变更可以合并到程序结尾的企业初始状态中）。

图 4. 程序和企业层次之间的产品流

项目实施程序

程序定义了一系列创建或者变更端到端功能的变更。为了达到这些新的功能，创建新的系统和/或变更多个已存在的系统（可能通过获取新的程序或者变更一个过程），是十分必要的。定义并执行多个项目是通常的，每一个影响的系统都有一个，以达到总体的程序目标。

每一个项目都有一个它想要达到的特定范围。该范围与执行新功能所需的架构变更直接相关。这就是说，程序定义了影响系统需要什么新功能，以执行功能，每一个项目执行了它的系统的新功能。虽然对于项目来说执行超过一个程序的变更是可能的，但这是一种非常特殊的情况，因此不在此做讨论。

程序层次的需求在多个系统的合作中得到执行是最常见的。在这些条件下，创建一个程序层次的设计，以显示系统是如何合作的。这种设计向每一个涉及到的系统分配责任。并且责任与它们在合作中扮演的角色相对应。但是，有时一个程序层次的需求会在单个系统中完整的执行。在这些情况下，程序层次的需求会直接分配给单个系统。查看图 5 以得到这些关系的图示。

图 5. 程序到项目需要流程

但是在这里，在执行项目时，我们并不需要从无开始，除非项目是从新系统中创建的。如果项目的目标是变更一个已存在的系统，那么系统就有一个初始的状态了。它拥有满足的需求，一个架构，执行的测试，可能还会有一些公开的缺陷。如上所述，对于初始的企业产品，如果这些产品不能获取，那么它们可以创建一系列的项目。这对企业产品也是成立的，系统产品需要在储存库中以一种稳定的形式进行维护，以有效的评价它们。

初始的系统产品，就像初始的企业产品那样，包含了需求，架构，测试以及已存在的缺陷。这样，如果一个系统拥有已存在的初始产品，那么它就不必从空白开始，而是创建它的完成状态以作为存在产品的变更。就像程序对企业产品提供了更新一样，项目队系统产品也提供了更新。查看图 6 以得到系统初始产品和项目产品之间的关系。

图 6. 项目和系统层次之间的产品流程

整合到一起

上面介绍的，通过执行程序和项目，为企业和系统的发展提供了端到端的流程，包括它们的初始产品。需要承认的是，这是一个简化的视图，假设企业及其系统之间只有一步。显然还存在额外步骤的可能性。但是，相同的方法也适用。方法可以稳定的应用到每一个层次的分解，以及对于哪一个机理（程序，子程序，项目，子项目等等）更新了这些干扰层次做出合适的决定。图 7 为这个简化的视图提供完整的端到端的流程。

图 7. 从企业到系统的端到端流程

结论

一些公司有管理拥有企业和系统层次的产品的成熟经验，并从评价这些产品中获益匪浅。其他公司刚刚起步，已经意识到未来的利益。但是，目标和方法总是一致的。为了有效的管理企业的发展，全面理解当前的需求和功能，以及怎样达到这些功能（它的功能）是必需的。而且，理解系统在测试和已存在的缺陷方面的运行情况，是十分必要的。

重构每一项项目上的产品是没有什么效率的。而且，公司想要重复使用已存在的 知识，并让产品按企业要求的那样进行发展。因此，对当前状态有精确认识的公司，能够有效的计划企业的发展，并通过评价每一项项目上的产品来减少总共的花费。就算对整个公司来说，要获取完整系列的产品时不现实的，但是公司仍然在从获取企业部分产品中获利，获取的部分越大，收益就越大。

没有对当前状态的精确观察，每一个项目都必须 a）通过在继续发展项目之前检查企业，来创建当前状态的代表；b）通过连续的应用前面程序执行的变更，来尝试构建当前状态的代表；或者 c）放弃尝试代表当前的状态，并试着变更未知的架构，希望变更不会产生不想要的结果。我们看见了有公司尝试了所有的三种选择，结果只是痛苦的发现，保持当前企业状态的精确看法，对有效操作是十分必要的。

公司从再利用系统层次的产品中也受益匪浅。一家企业有许多的系统，因此系统的数量大大增加了再使用的收益。大多数系统的复杂性，发展的已经超出了单个人可以完全保持在心的能力范围。获取需求，架构，测试以及系统缺陷的产品对交流都是必需的。评价从一个项目到另一个项目产品的利益包括：更好的稳定性，更少的错误以及总体减少的无用功。

我们已经论证了企业的架构，是怎样为程序的发展提供一个基础的。私人程序和整个的公司都指定企业状态变更的程序中获益匪浅。项目进化系统从初始状态不断发展的。但是这样做只是会满足项目提供的分配以及获得的需求。为了完成这个循环，项目和程序必须对初始状态以及企业产品应用它们的变更，这样它们对下一次变更所做的努力就是很精确的。

IBM®提供了一系列的产品和方法，以支持贯穿生命周期的 Enterprise Architect 和 Systems Engineer。如果您想要知道关于这些特定产品的更多信息，那么这项链接就是一个好的开始地方。对于这种方法，图 8 验证了这些方法时这样应用在整个软件生命周期的。

图 8. 支持整个软件生命周期的 Enterprise Architects 与 Systems Engineers 的方法

文章中呈现的简单视图，为公司中的共同理解提供了一个基础。通过清晰的验证我们已经描述过的关系，系统工程师最好能够理解他们的努力是怎样被全体的企业架构限制，以及对其有所贡献的。而且，我们验证了企业业务功能和项目执行的功能之间的直接关系。

高级话题

还有一些值得提及的话题，但是全力的介绍它们超出了本文的讨论范围：

• Service Oriented Architecture （SOA）：通过建立初始的企业产品，特定的架构以及贯穿企业的普通服务可以变得更加清晰。结果，分析架构和定义程序以执行 SOA 就变得更加容易了。
• 分布式开发：通过弄清产品类型以及程序和项目之间的关系，那么他们必须满足的责任和标准的并立就变得更加清晰了。这就使得责任可以有效地分布到地理上分散的开发中心，不管是在公司内部还是外部。
• 标准的环境：虽然不做要求，但是一个标准的环境（普通的开发过程和工具，变更管理，配置管理，以及评价收集和报告），可以再整个项目和程序中得到利用，产生额外的利益。另外，普通的环境会支持项目中产品需要的普通代表。

致谢

我想要感谢 Ernest Vogel，Cindy VanEpps，以及 Arvind Sathi 对原始产品工作流程所做的贡献。另外，下面的人员以他们的评论提高了文章的质量：Pete Eeles，Jos Jennekens，Jim Densmore，以及 Fred Mervine。

注解

1. Webster 的 Ninth New Collegiate Dictionary，1985 Merriam-Webster Inc，ISBN 0-87779-509-6。
2. ibid.

参考资料

• 参见 Rational 适用于系统的软件平台页面。
• 参见企业架构页面：加速变更 － 创建一个业务和 IT 蓝图的共享视图。
• 参见 Rational 企业架构管理 页面。
• IBM Rational 敏捷开发工具包：本工具包将帮助您了解 IBM Rational 为敏捷开发所提供的技术和解决方案，以及最佳实践。帮助您更好地运用 IBM Rational 软件实施敏捷开发，将敏捷开发的实践落到实处。
• 查看 Rational Edge 电子期刊 其他精彩文章，获得了解高效软件开发背后的概念。
• 访问 developerWorks 上的 Rational 软件专区，了解有关 Rational 软件交付平台产品的技术资源和最佳实践。
• 了解 IBM Rational 软件交付平台，包括适用于并行开发和地域分布式团队的协作工具，以及用于架构管理、资产管理、变更和发布管理，集成需求管理、过程和组合管理，和质量管理。
• 订阅 IBM developerWorks 时事通讯，获得有关最佳的 developerWorks 教程、文章、下载、社区活动、网络广播和事件的每周更新。
• 浏览 技术书店，获得有关这些和其它技术主题的书籍。

• 下载 IBM Rational 软件的试用版。
• 下载这些 IBM 产品评估版，并着手使用来自于 DB2®、Lotus®、Tivoli®，以及 WebSphere® 的应用程序开发工具和中间件产品。

• 查看 developerWorks 博客，并加入 developerWorks 社区。