分类：
2009-09-23 15:56:48
系统工程师还要在开发下关注当前的系统，而并不需要再关注它所支持的大型企业。本文探讨了企业架构和系统架构之间连接点，并讨论了企业架构是怎样向系统架构提供输入，同时还对其有所限制的。它的目标是帮助系统工程师获取深入理解系统支持的企业的架构，是怎样限制并改造创建系统的项目了。在今天的商业驱动的企业中，在企业的业务功能和项目执行的功能之间，有一种直接的关系。
今天的企业，正在从提供单独功能的管道系统，向评价服务以提供强壮有效操作的更加集成的系统进行转变。结果，企业内的系统得到更紧密的集成，变更它们的努力也变得更加复杂。处理项目的系统工程师就不再能够只关注变更的系统，还需要意识到系统是怎样与企业中的其他系统进行交流的。
图 1 提供了这种变更的强调的概述。以前业务架构是由独立的烟囱架构支持的。从企业架构到系统工程师有完全不同的切换及其相关的问题。今天，系统开发是更加有业务驱动的。IT 和系统花费的金融责任性有强烈的需求，花费必须返回至他们的商业利益。因此，商业和开发之间并列是关键的。在企业架构的参入与系统工程师之间是更加连续的，产生更大的业务/IT 并列，并贡献于生命周期内的技术管理。企业架构停留的时间变长，系统工程师更早的参入其中。最后，执行的服务支持操作期间的数据采集以及监控工作。对回馈的分析驱动了进一步的变更。
图 1. 生命周期早期的并列架构和工程
|
在讨论不同层次的系统时，清晰的定义模糊给出不同定义以及使用的词语，是十分重要的。
企业的定义是一家商业公司 i 。机构可以是一家公司的一部分，一个完整的公司，或者是不同公司之间的合作部门。为了简化我们的讨论，让我们想象一家企业作为我们的公司。虽然查看一家企业有很多种方法，但是为了合理的研究企业的发展，把它想象成一个大型的系统时很有用的，就像一个系统：a）它像投资者提供特定的价值；b）它的资金允许它的正常操作；c）它执行一些操作，满足一系列的需求；d）它由一系列的组件组成，工人和低层次的系统，他们联合在一起完成它们的功能。（贯穿这篇文章的词语“组件”，是用于指与其他部分相合作的整体的一部分）。
企业架构有许多的定义。您可以将企业架构看做一个合适的名词（例如，企业架构的原则），正如您看到的那样，我们没有安装那种方式来使用它。我们所讲的企业架构，是作为企业架构的描述。企业架构的原则将不同视角的业务，战略，过程，方法以及组件联系到一起。这些视角是由企业架构的不同方法定义并改变的。企业架构是由企业架构师创建的。所以企业架构师的责任远远超过了这里所讨论的。
这样企业架构的目的，正如文章中定义的那样，是描述企业的组件，它们的关系，它们是怎样合作的，以及它们是怎样与“外部的世界”相联系的、一个企业架构为企业组件的执行提供了方向。组件的执行导致了企业状态的变更。
系统组成一个统一完整的，服务一个共同目 ii 的一组项目。共同的目的就是系统存在的原因。一个或者多个投资者会意识到系统需要完成的目的。因此系统的目的是满足一系列投资者的需求，也就是所谓的系统需求。这些需求包含展现的功能，以及对于给定的质量和限制因素，这些展现的功能是怎样实现的（例如，非功能性的需求）。系统通过执行一系列的操作来满足它们的需求。这些操作能够满足投资者的需求。因为系统是一组项目，所以系统的操作实际上是由这些组件的操作来实现的。
注意到组件可以是任何事情会是十分重要的：硬件，软件或者人员。参入一个系统作为合作组件的人员叫做工人。有一些组件本身就可以当做独立的系统，通常被叫做亚系统。实际上，工人也可以被当做系统，如上所述，但是我们并没有像这样对待它们，而是当做一个基本的对象，因为我们不关注它们的部分是怎样在内部协作的。
标题系统工程师应用于与系统工程 应用于使用与系统工程有关的个人。我们看到“系统工程师”会对一切事情负责，从计划到需求获取，到架构获取，到集成再到测试。许多这些活动超出了传统系统工程的原则。在本文中，我们关注系统工程师的角色，以确保开发努力的结果会与企业的剩余部分相“配合”，并以稳定的格式操作。基本上，在与大型企业强制的限制因素相一致时，创建或者更新系统架构是系统工程师的责任。
一个程序会变更企业的状态，以提供一些新的或者改善的功能。它的目的是通过变更企业的一部分，来使企业从初始状态转化为完成状态。程序是由一个或者多个（通常更多）项目来执行。注意程序拥有比整个企业更小的范围。但是为了简化这里的讨论，我们只会讨论对整个企业有影响的程序。
项目是带有特定关注，开始，以及末端的开发活动，它想要交付贡献功能的可评价的结果。项目关注向企业引入新系统或者变更一个已存在的系统是很常见的，虽然他的范围可以更大或者更小。项目拥有它们自己的目标和预算。它们一般会与其他项目相联合以作为程序的一部分（见于图 2）。
图 2. 程序和项目是怎样影响企业的
|
不管是否得到记录，每一个企业都有一个架构，它由组件以及它们的关系还有合作组成的，通常获取到图片，图表，文件，模型以及等等。除了架构以外，企业也有一系列它需要满足的需求。也会有测试来决定企业完成需求的程度。
再一次，不管是否得到记录，每一个企业都有它的需求和测试。当企业组件的新版本得到部署时，将会执行一系列的测试以确保组件满足了它的需求，包括它不会破坏高层次的功能，因为它与其他组件交流的方式。如果这些测试发现一些问题的话，那么它们会被当做企业缺陷直到它们得到解决（问题可以是新发布的组件，或者交流组件的不能预料的行为）。
因此，我们将会看到这些产品，当它们存在并得到合并时，将会组成企业关键元素的完整描述（见于图 3）：
图 3. 企业的初始产品
|
正如以上定义的那样，程序的目的就是将企业从初始状态移到完成状态。许多次，这个包括创建一系列描述完成状态的产品。但是，如果当前的状态得到完善的记录，那么重新记录程序变更的部分事情（需求，架构和测试）就不是必要的。只需要更新带有程序描述的变更的已存在初始产品。这些变更就是需要向初始产品应用的三角区，以描述需要的完成状态。
程序不是从无到有的，而是描述初始状态的变更。这假设初始状态得到良好的理解（获取）。如果不是这种情况，那么所有就没有失去。因为以任何方式记录完成状态是必要的，创建的产品可以在程序完成以后变成企业层次的初始产品。
程序的范围可以从变更企业的一方面，到转变整个的企业。因此，为企业产生整个系列的初始产品，就很容易超出单个程序的范围。随着越来越多的程序接触到企业的更多领域，这个空白就得到了填补。这种方法避免了任意变更程序可以开始之前，需要等待完整系列的初始产品的问题。这种方法可以一直进行，直到企业初始产品的剩余空白，相对变小，并通过单独的努力来处理以直接使空白消失。为了达到企业的完整和稳定代表，所有的企业程序必须使用标准的惯例，来代表初始和完成的产品（或者至少将它们的产品从标准的惯例转变或者转变至标准的惯例），而且实际上企业必须开始在前面程序创建的程序之上构建产品。否则在不同程序创建的产品之间建立联系，并达到企业的单个稳定代表，会变得极端困难。而且，初始产品必须作为单个稳定的储存库进行维护。储存库是如何构建的，它是否是单个文件或者数据库的联合已变得不再重要。重要的是它可以作为一个稳定的代表进行维护和访问。
如果（或者一旦）企业初始产品可以得到利用，程序应该从这些产品开始，并获取需要执行程序的变更。这包含了需求，架构的更新，以及变更初始以与需求的变更保持一致这三者的三角区。这些需求的变更，就算它们稍后进行非正式的交流或者改善之后也是这样，驱动架构三角区。不管是需求三角区还是架构三角区都可以使变更进到测试集中。
随着程序得到实现（这就是说，程序在实现之后），测试可以得到实施，以证实需求得到满足，并探测到实施中，需求中，或者测试本身的所有缺陷。正常情况下，所有发现的缺陷都可以在程序的范围之内得到解决，因此变成额外的企业层次的缺陷。
在程序的结尾，企业就处在程序定义的完成状态中。因为这是企业的新初始状态，所以企业层次的初始状态需要得到更新。这是很直接的，因为程序已经产生了对产品的所有需求的变更。查看图 4 中产品流的图示（注意因为多个程序可以同时进行运行，所以这次企业可能实际上会有超出本程序讨论范围的额外变更。这些额外的变更可以合并到程序结尾的企业初始状态中）。
图 4. 程序和企业层次之间的产品流
|
程序定义了一系列创建或者变更端到端功能的变更。为了达到这些新的功能，创建新的系统和/或变更多个已存在的系统（可能通过获取新的程序或者变更一个过程），是十分必要的。定义并执行多个项目是通常的，每一个影响的系统都有一个，以达到总体的程序目标。
每一个项目都有一个它想要达到的特定范围。该范围与执行新功能所需的架构变更直接相关。这就是说，程序定义了影响系统需要什么新功能，以执行功能，每一个项目执行了它的系统的新功能。虽然对于项目来说执行超过一个程序的变更是可能的，但这是一种非常特殊的情况，因此不在此做讨论。
程序层次的需求在多个系统的合作中得到执行是最常见的。在这些条件下，创建一个程序层次的设计，以显示系统是如何合作的。这种设计向每一个涉及到的系统分配责任。并且责任与它们在合作中扮演的角色相对应。但是，有时一个程序层次的需求会在单个系统中完整的执行。在这些情况下，程序层次的需求会直接分配给单个系统。查看图 5 以得到这些关系的图示。
图 5. 程序到项目需要流程
但是在这里，在执行项目时，我们并不需要从无开始，除非项目是从新系统中创建的。如果项目的目标是变更一个已存在的系统，那么系统就有一个初始的状态了。它拥有满足的需求，一个架构，执行的测试，可能还会有一些公开的缺陷。如上所述，对于初始的企业产品，如果这些产品不能获取，那么它们可以创建一系列的项目。这对企业产品也是成立的，系统产品需要在储存库中以一种稳定的形式进行维护，以有效的评价它们。
初始的系统产品，就像初始的企业产品那样，包含了需求，架构，测试以及已存在的缺陷。这样，如果一个系统拥有已存在的初始产品，那么它就不必从空白开始，而是创建它的完成状态以作为存在产品的变更。就像程序对企业产品提供了更新一样，项目队系统产品也提供了更新。查看图 6 以得到系统初始产品和项目产品之间的关系。
图 6. 项目和系统层次之间的产品流程
|
上面介绍的，通过执行程序和项目，为企业和系统的发展提供了端到端的流程，包括它们的初始产品。需要承认的是，这是一个简化的视图，假设企业及其系统之间只有一步。显然还存在额外步骤的可能性。但是，相同的方法也适用。方法可以稳定的应用到每一个层次的分解，以及对于哪一个机理（程序，子程序，项目，子项目等等）更新了这些干扰层次做出合适的决定。图 7 为这个简化的视图提供完整的端到端的流程。
图 7. 从企业到系统的端到端流程
|
一些公司有管理拥有企业和系统层次的产品的成熟经验，并从评价这些产品中获益匪浅。其他公司刚刚起步，已经意识到未来的利益。但是，目标和方法总是一致的。为了有效的管理企业的发展，全面理解当前的需求和功能，以及怎样达到这些功能（它的功能）是必需的。而且，理解系统在测试和已存在的缺陷方面的运行情况，是十分必要的。
重构每一项项目上的产品是没有什么效率的。而且，公司想要重复使用已存在的 知识，并让产品按企业要求的那样进行发展。因此，对当前状态有精确认识的公司，能够有效的计划企业的发展，并通过评价每一项项目上的产品来减少总共的花费。就算对整个公司来说，要获取完整系列的产品时不现实的，但是公司仍然在从获取企业部分产品中获利，获取的部分越大，收益就越大。
没有对当前状态的精确观察，每一个项目都必须 a）通过在继续发展项目之前检查企业，来创建当前状态的代表；b）通过连续的应用前面程序执行的变更，来尝试构建当前状态的代表；或者 c）放弃尝试代表当前的状态，并试着变更未知的架构，希望变更不会产生不想要的结果。我们看见了有公司尝试了所有的三种选择，结果只是痛苦的发现，保持当前企业状态的精确看法，对有效操作是十分必要的。
公司从再利用系统层次的产品中也受益匪浅。一家企业有许多的系统，因此系统的数量大大增加了再使用的收益。大多数系统的复杂性，发展的已经超出了单个人可以完全保持在心的能力范围。获取需求，架构，测试以及系统缺陷的产品对交流都是必需的。评价从一个项目到另一个项目产品的利益包括：更好的稳定性，更少的错误以及总体减少的无用功。
我们已经论证了企业的架构，是怎样为程序的发展提供一个基础的。私人程序和整个的公司都指定企业状态变更的程序中获益匪浅。项目进化系统从初始状态不断发展的。但是这样做只是会满足项目提供的分配以及获得的需求。为了完成这个循环，项目和程序必须对初始状态以及企业产品应用它们的变更，这样它们对下一次变更所做的努力就是很精确的。
IBM®提供了一系列的产品和方法，以支持贯穿生命周期的 Enterprise Architect 和 Systems Engineer。如果您想要知道关于这些特定产品的更多信息，那么就是一个好的开始地方。对于这种方法，图 8 验证了这些方法时这样应用在整个软件生命周期的。
| 模型驱动的系统开发 | 服务型建模 & 架构 *1 | 组件业务建模 *1 | IBM 全球服务方法 *1 | |
| 视图 | ||||
| 战略 | ||||
| 获取 | ||||
| 需求 | ||||
| 业务架构 | ||||
| 服务架构 | ||||
| 同时 | ||||
| 技术架构 | ||||
| 设计 | ||||
| 实施 | ||||
| 测试 | ||||
| 部署 | ||||
| *1 IBM 全球商业服务 | ||||
图 8. 支持整个软件生命周期的 Enterprise Architects 与 Systems Engineers 的方法
文章中呈现的简单视图，为公司中的共同理解提供了一个基础。通过清晰的验证我们已经描述过的关系，系统工程师最好能够理解他们的努力是怎样被全体的企业架构限制，以及对其有所贡献的。而且，我们验证了企业业务功能和项目执行的功能之间的直接关系。
|
还有一些值得提及的话题，但是全力的介绍它们超出了本文的讨论范围：
|
我想要感谢 Ernest Vogel，Cindy VanEpps，以及 Arvind Sathi 对原始产品工作流程所做的贡献。另外，下面的人员以他们的评论提高了文章的质量：Pete Eeles，Jos Jennekens，Jim Densmore，以及 Fred Mervine。
|
|
|
Dave Brown 是 IBM Rational® 的服务组织的一员。他在全球解决方案交付保障团队担任职位，为 Rational 技术团队在大多数的战略客户合作中提供指南。之前，他是 IBM Rational 软件品牌中的解决方案架构实践社区的全球负责人。Dave 从 1997 年一直是 Rational 的咨询师，关注于软件和系统架构和过程。在这之前，Dave 在 TRW 有七年的工作生涯，参与了软件开发生命周期的所有方面。 | |
|
|
Peter C. Bahrs 博士是一名 IBM 杰出工程师，高级认证 IT 架构师，发明家，IBM 技术学院以及 IBM 中的 CTO 政府解决方案的成员。他在 IT 行业有二十多年的经验。 | |
