阐述企业结构空间 (Enterprise Architectural Space)
2007-02-23 12:21:01 来源:WEB开发网本文将向你介绍一个可用于表达出企业架构空间的组织表格,显示空间中所有人为产物间的关系,并呈现出在你企业中不同角色对企业架构的观点。本文同时以实例来说明模式作者是如何使用组织表来组织现有的模式并找出目前尚未产生出模式的区域。
下载 |
| ||||
Webcast |
| ||||
社区 |
|
简介
有效的组织是帮助我们对周围混杂环境取得全面了解的关键。标准且协调的组织系统已运用在每个地方,从化学元素周期表与有机体的生物分类到图书馆里的杜威十进分类系统。在信息技术的世界中也有很多像这样的系统。举个例来说,像DNS系统以有意义的方法来协助组织全球的电脑,同理,在文件存储器里文件系统则以提供目录结构的方式来组织文件。
企业层级的软件与系统结构可成熟地应用于相似的组织系统。如果你要求任何技术团体来阐述一个系统的结构,你有可能听到不同的见解。每个人经常会有他或她自己对系统的看法,这是正确的,这就与其他技术专家看待同一个系统的观点不同。对企业软件集中的系统有一个统一且协调的观点可以让技术专家彼此分享对企业结构空间的了解,其结果将会更完整而精确。
本文将向你介绍一个组织表,此表是Microsoft patterns & practices 团队在过去二年用于模式开发的组织表,像Enterprise Solution Patterns Using Microsoft .NET即为Microsoft patterns & practices 团队所发表的使用此表格产生出来的成品之一。文章中揭露了有关以动态的方法来组织与使用模式的初期想法。本文作者预料再过一段时间后此组织表的结构可能会更加精确而且此组织表也将会被运用在其它很多地方。
企业结构空间组织表
当企业对特定的商业作出反应的初期,他们会提出很多的人为产物来获取结构上的决议,包含:计划、摘记、模型、指令码与程序。在你的企业中不同的角色根据这些人为产物以不同的方式来观察企业结构。如果你拥有一个有意义的方式来组织这些人为产物,此方式被重覆使用的可能性就会增加。
组织人为产物是个复杂的任务,尤其是企业与技术不断的在变化。分析空间中所有稳定的元素与元素间所有交错的关联,我们很难将其完整的呈现在一个多维阵列表格中。二维阵列表格可让你以直觉的方式来分析企业软件集中的系统。
企业结构空间组织表就是这样的一个二维阵列表格,此表格可用于获取并组织商业的人为产物以与产品决策达到一致。组织表中横向定义结构化观点,纵向则为疑问点。图1为组织表的基本结构。表格中详细的行与列将于之后的章节中探讨。
图1. 织组表结构
之后你将会看到,组织表的行提供了企业信息空间的各个特定的焦点。此组织表设计用于:
• | 提供结构空间完整全面的看法。此说明被设计用于组织结构元素与示范它们之间的关连。 |
• | 特别是针对企业软件集中的系统。你可以选择扩大描述范围以满足你企业的需求。 |
此组织表是建立于四个主要模型之上:作为企业体系结构的Zachman [Zach]、IEEE 1471 [IEEE]、Andersen Consulting 的企业信息体系结构 [Andersen],以及驱动测试开发。像Zachman框架,在表格中使用疑问点作为列而角色作为行。然而,此表格的不同之处是在横向显示了一个高度间隔尺寸,而在每个单元格中放置了人为产物所含有的更独有的特点。此外,基于驱动测试开发的原则,此表格加入了额外的列来确定每行可被成功的测试。理论上,每个特定的行,包含于测试栏位中的人为产物应该可确实追踪至包含于目标栏位的人为产物。
组织表近结构的层次将所有的行集合在一起,这显示出了企业信息结构框架的影响。这种行的分组显示全部的商业与技术之间的对应与可追溯的关系。每个行中是一些离散的观点,此则是受了IEEE 1471结构标准描述的影响。总合来说,这些元素呈现出一个由观点与疑问点组织而成的企业空间的高细度图表。
此组织表的主要优点之一就是你能使用它将许多不同种类的人为产物存贮起来。将包含于传统人为产物中的信息经过提取、撷取以及抽象概括出来与企业软件集中的系统进行结合,你就可以为你的企业演绎出一个模式、实践以及向导。然后你可以将这些模式存贮于组织表中。若欲得知更多有关将模式存贮于表格中的详细信息,请参阅本文之后的 "使用表格来组织模式" 章节。
结构的观点与角色 (组织表的行)
组织表将企业结构分割成五个主要的企业观点。这些观点呈现在表格的行中,它以由一般到特别的方式加以组织而你可以由上到下来查看。这些观点为:
• | 商业结构 (Business architecture) |
• | 综合结构 (Integration architecture) |
• | 应用程序结构 (Application architecture) |
• | 可操作结构 (Operational architecture) |
• | 开发结构 (Development Architecture) |
虽然观点是广泛地结构化人为产物加以分类的有效方式,这个组织表更进一步地将这些观点根据特定角色及其相对应的特别技术划分得更细。如同前面所提及的,这些附加的详细信息让你跨表格追踪人为产物。
注意 此处定义的角色可能无法直接对应至你企业里的个体。在大型的企业里,这里所列示的角色有可能直接对应到一个团队 (例如,结构团队)。相反地,在较小的企业中,一个人可能需要担任许多角色。然而,某些时候大多数的企业系统会以这些角色的透视观点来检视,而且这些角色将会影响你对整体结构的想法。
下段文章中将更仔细地分析这些观点以及其所包含角色。
商业结构观点
商业结构观点为其他的结构观点提供了一个基础。企业软件的存在就是要为你的企业提供商业价值,而且它必须与你的商业目标一致。若没有一个定义良好的企业结构,任何在企业结构方面的努力都有可能陷入被动,临时准备技术对策。
商业结构观点包括下列角色:
• | CEO |
• | 总经理 |
• | 流程负责人 |
• | 流程执行者 |
综合结构观点
综合结构观点与执行于企业内部和防火墙外部的集成系统有关。一个简单的企业可能仅需要一些独立的应用程序来维持运行,但是许多企业需要将他们内部与防火墙外部的应用程序加以综合。防火墙内部,标准的企业应用程序综合(EAI)方法是用于在数据、功能、API、以及表示层整合系统。通常一个信息中介结构被开发用于智能型路由、传输,以及商业规则处理。防火墙外,企业与其他企业连结,能为有跨企业综合需求的贸易伙伴建立延伸的企业网络。此为企业—企业(B2B)综合服务器(BizTalk)领城与Web服务互通性框架,他们被设计用于在处理层综合多重商务。
综合结构观点包括了下列角色:
• | 企业结构分析人员 |
• | 设计人员 |
• | 开发人员 |
应用程序结构观点
应用程序结构观点包括了所有系统及可执行的应用程序所必备的软件元件,比如数据库、Web服务器、应用程序服务器、网络、表示层结构、元件(基层结构与自订)、Run-time结构、商业逻辑以及应用程序本身。任何可用来产生商业价值的应用程序都是确实可执行的知识或是可执行的商业过程。使用者通过不同的界面使用这些应用程序以自动或可执行的工具来处理部分或全部的商业程序。
应用程序结构观点包括下列角色:
• | 企业结构分析人员 |
• | 结构分析人员 |
• | 设计人员 |
• | 开发人员 |
可操作的结构观点
可操作的结构观点关系到以稳定、安全、可调整、可预测以及可管理的方式来维护及运作系统。这个类别包括了事件、远端及性能管理、使用者管理、备份、监视、调整的相关元件。
操作结构观点包括下列角色:
• | 系统结构分析人员 |
• | 系统工程师 |
开发结构观点
开发结构观点关系到其他结构的实现。应用程序必须以一种系统且有效的方法来建构与维护。开发结构是由相关元件所组成,比如设计及开发工具、知识库、构建主要公用程序、测试套件、追踪工具以及其他工具。
开发结构观点包括下列角色:
• | 组态管理工程师 |
• | 主要建构者 |
• | 测试工程师 |
• | 开发人员 |
结构空间疑问点 (组织表的列)
虽然观点与角色提供了对结构的不同看法,依据与生产人为产物的商业积极性相关联的问题,通过将人为产物加以分类你可以在结构化空间提供更多的细化信息。这些问题、或质疑都来自于下面组织表中的列:
• | 目标 (为什么)。决定商务积极性的结构因素为什么? |
• | 资料 (有些什么)。在商务积极性的决策结果裁定时需要什么信息或将呈现什么结果? |
• | 功能 (如何)。决定商务积极性的结构是如何运作? |
• | 时间点 (何时)。什么时候执行事件或是呼叫动作、或是被认可、做出决定? |
• | 网络 (何处)。产品应存放于何处? |
• | 人 (谁)。在开始后哪些人将受惠,或是被影响?通过那些界面会造成这些影响? |
• | 评分表 (测试)。你怎么知道当初目标已经达成? |
这些列的顺序是可以任意改变的,左边的目标列是很有用的,因为它定义了结构决策的原因。
将观点、角色与疑问点结合于组织表中
将观点、角色、以及质疑结合在一起就产生了企业软件集中式系统的组织表。图2 显示了组织表,其中包含人为产物的叙述。
图2. 企业结构空间组织表
使用组织表表格提供了一个能让企业以多个观点与角色的方式来了解企业结构的需求。你可以通过几种方式来使用本表格,包括:
• | 了解企业解决方案的全貎。仅有少部分的人能了解企业解决方案需求的全貎。你可以辨识结构内特定的人为产物并且探测邻近的单元以扩大你对企业结构的理解。 |
• | 识别人为产物之间的关系。通过检查表格中的每个小单元格,你就可以识别单元格之间的关系。在这些单元格内,你可以了解人为产物之间的相互关联。例如,人为产物下的个别角色可能与其它人为产物的其它角色相关联。 |
• | 为企业中的元素的一致性及可追踪性做交互检查。例如,你可以使用疑问点测试来检查目标疑问点的正确性。 |
使用此表格来组织模式
组织表组织了企业软件集中式系统的人为产物,也因此提供了整体结构的看法。你也可以使用结构中的传统人为产物来建立模式、实践以及指导方针,正如图 3 所示。
图3. 组织表的一般使用方法
如图所示,你可以提取出重要的决策并将它们分离出来成为模式、实践以及企业集体学习的指导方针。将这个新的知识放置于组织表中能够为模式作者提供具体的益处。身为一个模式作者,你可以利用几种不同的方式来使用本表格,包括:
• | 了解整个企业模式的情况。你可以识别结构中的特定模式并且探测邻近的单元格以扩大你对企业结构的理解。 |
• | 识别出表格中没有包含模式的区域。目前没有包含模式的表格区域可能表示该区域尚未有足够的信息以产生模式。 |
• | 识别模式间的关联。通过分析表格内的小单元格,你可以识别单元格以及单元格内模式之间的关联。例如,人为产物下的个别角色可能与其它人为产物的其它角色相关联。 |
• | 依据不同的特点与使用方式来更近一步取得细致且一致的模式分类。 |
Microsoft patterns &practices团队使用了组织表来对现存的模式进行分类同时为新产生的模式来识别区域。图4 显示的组织表,是依据最近发布的Microsoft模式所绘制出来的。显示在表格中有着超链接的模式名称缩写会链接到 MSDN 发布的模式。若需要已经排序的样本清单,请参阅文件最后的"图4样本名称索引表"。
- | - | 目标 | 资料 | 功能 | 时机 | 网络 | 人员 | 评分表 |
商业结构 | CEO | . | . | . | . | . | . | . |
. | 总经理 | . | . | . | . | . | . | . |
. | 流程负责人 | . | . | . | . | . | . | . |
. | 流程执行者 | . | . | . | . | . | . | . |
综合结构 | 企业架构师 | . | MDC | AMDC | MCD | DAR | ETL | ENT | DAT | SDA | FIT | PRO | POR | FUN | DOI | MOM | SOI | PRE | . | TDC | . | . |
. | 设计者 | . | MMR | MSR | MMRS | MSSR | CTD | MSTR | Nam | DBr | InBr | MBR | MBU | PUB | PIP | GAT | . | MSCR | . | . |
. | 开发者 | . | IMMRS | IMSSR | IMSTR | IPRO | IMBR | IGAT | . | . | . | . |
应用结构 | 企业架构师 | . | . | . | . | . | . | . |
. | 架构师 | . | . | LAYA | 3LAYA | LAY | . | TID | 3TID | DEP | 4TID | . | . |
. | 设计者 | . | . | MVC | PCO | FCO | INF | PCA | OBS | BRO | DTO | SIN | SIF | SGW | ABF | ADA | APC | ASM | BDC | BRI | COM | DEC | FAC | LAYS | MAP | MED | MON | PAC | PRX | REF | SPE | STR | TDG | TAM | TEM | . | SCI | LBC | FCI | SFAR | . | . |
. | 开发者 | . | . | IMVC | IPCO | IFCO | IINF | IPCA | IOBS | IBRO | IBRO | IDTO | IDTO | ISIN | ISIF | ISGW | IDTO | PDC | PFC | UTC | . | . | . | . |
可操作结构 | 系统架构师 | . | . | . | . | . | . | . |
. | 系统工程师 | . | . | . | . | . | . | . |
开发结构 | 组态管理工程师 | . | . | . | . | . | . | . |
. | 主要建构师 | . | . | . | . | . | . | . |
图4. 绘制于组织表中 Microsoft 模式 (Pattern)
将样本加入组织表中
将来,本文的作者想要从主要模式作者处新增模式。与广大的模式社区来分享组织表,我们相信我们能够对于所有可用的模式提供广泛且更一致性的观点。通过成果的结合,模式社区就能够提高模式的使用率且能更符合开发者与结构使用者的需求。
你也可以贡献一己之力,将你自己现有的模式加入组织表中。
新增模式 (Pattern)到组织表中
1.分析问题与模式的来龙去脉。
2.依据列与行将模式放在最相符的位置。
3.了解对应到的与其临近单元格的内容并且将模式置于最符合的单元格中。
修改表格
在大多数的案例中,你将会发现修改表格以符合你的特定需求是很有用的。例如,你可能选择通过增加额外的行或列以更精确的定义人为产物或模式来增加表格的精细度。在某些出版物中patterns & practices 团队的成员也是使用这个方法来自行修改表格。例如,企业解决方案模式使用了一个部署列,如同下列组织表中的小单元格所示。
图5. 企业解决方案模式 (Enterprise Solution Pattern) 组织表
这个组织表,企业解决方案模式所指的就是模式框架,是为企业结构空间组织表的应用程序结构行的子集合。图5 的部署列由图2 中的组织表增加了细部栏位到网络列中。
若你仔细的比对模式架框与组织表,你将会注意到列名称已被更改了。企业解决方案模式 (Enterprise Solution Pattern) 的作者为读者自订了列名称而且考虑了组织表子集合中所放置列之间的约束关系。
总结企业结构内人为产物的一个全面的描述能够帮助你推论及表达有关企业结构。通过使用包括了观点、角色、以及疑问点的组织表,你可以帮助企业内部工作者了解企业软件集中式系统的范围同时增进商务和技术的一致性。你也可以组织由表格里这些人为产物所产生的模式、实践、与指导方针来导出表格中的人为因素。组织它们让你能够为它们分类、识别它们之间的关系,也能够替新的模式与方式确定适当的区域。
更多精彩
赞助商链接