体系架构(Enterprise Architecture, EA)的开山之作,之前一直引用,从来没有系统的学习,通过翻译加深理解,与感兴趣的朋友一起学习探讨。作者继续对框架中数据描述列(第一列)的业务呈现(第二行)做了分析和解读。介绍过程中作者辨析了业务视角实体与信息系统视角实体的差异,也提出对现实业务进行精确描述和表达,操作上还是具有难度的。
翻译中自己理解的东西加的比较多,不对的地方大家多多指正。
业务架构模型(所有者的视角)-数据描述列。从业务视角进行的数据描述,描述模型采用“实体-关系-实体”。但当所有者(用户)描述业务,他们脑中业务实体是指什么呢?
Model of the business (owner’sperspective)-data description column. Since thismodel (or description) appears in the data description column, the descriptivemodel will be “entity-relationship-entity,” and when owners (users) describethe business and say “entity,” what they have in mind are business entities?
例如,当所有者(或用户)提到“员工”这个“实体”,他们描述的是真实的人,即为企业工作的有血有肉的员工。但是,这里“员工”的含义与信息系统架构模型(设计师的角度)中的“员工”指代完全不同,在信息系统架构模型中,“员工”指的是计算机中的记录,同样被命名为“员工”,但在概念上是完全不同。图3给出了一个业务视角进行数据描述的示例。
For example, when owners (users) specify anentity such as “employee,” what they have in mind would be real beings, thatis, flesh and blood employees who work for the business. That meaning of “employee”is entirely different from the one used in an information systems model (thedesigner’s perspective), in which “employee” would refer to a record on amachine, which also happens to be called “employee,” however conceptually andentirely different it is. (This data entity, as opposed to business entity,would be found in the cell directly below.) Figure 3 is an example of a modelof a business, oriented to data.
图3. 一个简单的实体关系模型——业务架构模型(所有者视角)-数据描述列
此外,当所有者在描述一个业务,会指出两个业务实体之间的关系。这里,他们考虑的是关联两个实体的业务规则或策略。例如, “在A业务中,我们只从某个仓库发运产品”。而完全不同的规则是,“在A业务中,我们可以从任何仓库发运产品”。这里描述的都是业务规则,而不是下面单元格中的信息系统模型(设计者的视角)中所呈现的数据关系。
Further, when owners, describing abusiness, specify a relationship between the entities, what they have in mindwould be the business rule or strategy that relates one entity to anotherentity.5 A business rule or strategy, for example, might be “in this businesswe ship this product from that warehouse only.” An entirely different rule wouldbe “in this business, we ship this product from any warehouse we have.” Theseare business rules and not data relationships such as would be expected in themodel of the information system (designer’s perspective) in the cell below theModel of the Business shown in Figure 2.
实上,找到“现实生活”镜像(“real-life” examples)去清晰刻画任何一种架构是很困难的。造成这种困难有两个原因。首先,当描述现实生活时,没有一个框架来明确定义和区分各种表达。因此,许多现实生活中表达是交叉重叠的,这种交叉重叠体现在概念上(例如,业务实体和数据实体里相同的命名的概念),也体现在实际指代上(例如,用户视角,这里的实体和流程描述列中的输入输出是一个东西)。其次,通过现实生活镜像有时也很难准确的理解设计者在提出这些描述时的真实想法。
Finding good “real-life’’ examples whichcrisply illustrate each of the architectural representations is difficult.There are two reasons for this difficulty. First, when the real-liferepresentations were being developed, no framework existed to clearly defineand differentiate one representation from the others. Therefore, many real-lifeillustrations are a mixture of representations, both conceptually (e.g.,business entities and data entities get mixed together) and physically (e.g.,entities and inputs/outputs, that is, user views from the process descriptioncolumn of Figure 2, get mixed together). Second, real-life examples are hard tounderstand because it is not always clear what model, or cell, the author hadin mind when developing the representation.
图3说明了这一困难。很明显,这个模型描述的是数据,而不是过程,但问题是,作者想到的是对业务的描述还是对信息系统的描述?对图3来说,它的描述更像是一个业务描述,因为里面存在“多对多”的关系。在现实生活中,有大量“多对多”关系,但是关系型数据库在处理“多对多”关系时,需要创建“关系”实体(“artificial”entities)来保障机器的正常处理。图3中的模型需要被“规范化”,才能成为信息系统模型。因此,无论如何,由于图3中的模型对信息系统视角来说不是“标准化的”,至少以今天的标准来看,图3显然是一个业务视角的数据模型,而不是一个信息系统视角的数据模型。
An illustration of this difficulty is foundin Figure 3. It is clear that this model is describing data and not process,but the question is, did the author have in mind a description of a business ora description of an information system? In this case, it is likely that thedescription is of a business because of the existence of the “many-to-many’’relationships. In real life, there are many “many-to-many’’ relationships, butthe database management concepts that are popular today require that the“many-to-many’’ relationships be resolved in order to run on a machine.Therefore, “artificial” entities have to be created to resolve the“many-to-many’’ relationships, and the model in Figure 3 would have to be“normalized” before it could be a legitimate model of an information system. Inany case, since the model in Figure 3 is not “normalized,” by today’s standardsat least, it is clearly a model of a business as opposed to a model of aninformation system.
<<未完待更>>