经过7月初到现在的十几天的努力，我们终于有了ppt的初稿，由于我们想要表述的内容很多，所以我们严重超时了，大家对自己的演讲也准备不是很充分。我们需要精简一下我们的内容，在40分钟内展示我们LAB-1109的特色与实力。不多说了，我们要在最后的两天内充分准备，在复赛中取得好成绩。

在家里知道我们队进入了第二轮的比赛，当时很激动，虽然第一阶段我们做了一些工作，但是也有很多的不足，由于我上学期课程很多，投入SOA的时间很少，所以队中其他成员不得不多承担更多的工作，在这里表示歉意。今天回到学校就来到了实验室，见到了其他三个队友都已经开始做了一些工作，我也要快速进入状态，把以前没有弄懂的其他部分弄懂，多做一些工作。回忆从5月中旬开始的奋斗历程，大家克服了很多困难，一直没有放弃坚持到现在，在这几个关键的工作日更要团结起来，更改我们方案的不足与缺点，紧密团结在组长的周围，以SOA思想为核心，创新与进取，继续开拓我们的信息整合之路！！（后几句喊个口号振奋士气，呵呵）

今天收到了IBM的邮件通知，入围队伍名单上我们Lab-1109赫然在列。说实话，我个人对这个结果感到相当意外……文档提交后我并没有抱太大的希望，最后时刻的咬牙坚持，主要是为了对得起大家在这上面所花费的两个月时间——没想到竟能收获这样一个不错的结果。

 

这次能进入二阶段复赛，算是靠一点实力和几分运气吧。离复赛只有10天左右的时间了，从今天起要放下其它一切事情，专心搞SOA。既然获得了这样的机会，就不要让自己以后后悔。

 

最后俗套一句：大家一起努力吧！^_^

 

 

 

----------------------------------

 

软件工程中业务模式的使用（第二部分）

发布日期： 2005-10-22 | 更新日期： 2005-10-22

Philip Teale

微软公司

Robert Jarvis

SA Ltd

本文研究了怎样去开发基于业务功能、数据、业务构件的业务模式，并且演示了怎样利用这些业务模式来构建软件系统。

本页内容

介绍

业务功能

数据模型

业务模式和行业方案

结论：设计模式和行业方案的框架和方法

介绍

文章一共有两个部分，旨在探讨是否能够用一种结构化的方法去定义业务模式，如果能，这些业务模式又是否能够为那些支持业务的系统构建者们提供有用价值。本文的观点是这种价值是确实存在的。

文章的第一部分已经出版在刊物第二期上了，第一部分探讨了怎样去定义对软件工程师有用的业务模式。在这一部分中，介绍了企业结构框架SAM，来分析可能性，并得出以下结论：

•

业务模式支持业务功能

•

业务模式需要数据来支持描述业务功能

•

业务构件是业务所需要的数据和功能的IT代表

•

业务模式的结构应该能够随意地支持业务功能、数据和构件。这在分布的企业、决策者或者应用不同技术和运作环境的单位都是非常必要的

而且，也给出了具有上述特点的业务模式的定义。

文章的第二部分描述了怎样去开发基于业务功能、数据和业务构件的业务模式，同时介绍了工程软件系统中业务模式的使用方法。

第二部分摘要

本文用一个现实简单例子来阐述开发业务模式所需的业务功能、数据、业务构件的标准方法。这里并不讨论它的理论基础，也不讨论理论之间的关系。文章的目标在于证实：“这种方法能够被实现，并且知道怎样去实现”，而不是提供具体的实现步骤。文章的开始，介绍了一种方法，来定义所需的业务功能、数据、业务构件，然后用PRM来指导接下来的整个过程。文中采用的例子是关于医疗行业的，但所用的技术是任何领域通用。并且这些技术也已经应用在实际的项目中。需要着重申明的是，不是必须刻意地使用这些技术，技术本身并不重要，关键的是结果。正是因为这些结果，才使得设计更加精确的模式和可交付的软件系统成为可能。

模式和系统之间的不同点

如果没有太多关于模式的经验，那么，你在阅读这些例子的时候，就应该把它们看作是一个系统开发而不是模式，这是因为在软件工程中，模式是开发局部系统的踏脚石。模式保证了从一个可靠的起点开发到最后的目标系统的部分方法。它看似简单，实际上它本身也不是一种具体的解决方案而是抽象的，使得你不得不去创建一种符合自己需要的具体方案。创建模式时最谨慎的是正确获取它的抽象层次，很少有抽象来约束模式的有效性，因为它是被逐渐具体化的。但是许多抽象也限制了模式的实用性，从而使得它提供的实践价值比较少。

今天一个共同的趋势就是设计一个叫“消息经纪人”的服务去提供消息的路线和保证各种IT服务之间的转换。高度抽象的模式应该十分精确—如果想要提供消息的路线和保证各种IT服务之间的转换，就用“消息经纪人”，它的益处在哪里呢？这个思路虽然有些作用，但却不能提供更多实际的帮助。

另一方面，当银行操作统一的顾客视图时，我们建立一个消息经纪人来处理那些需要的IT服务。那么，能够称这种方案为业务模式吗？答案是肯定的，但是它有多少价值呢？这种方案太具体并可能存在潜在的可重复的方案，所以还是不能视之为业务模式。最有效的业务模式应当有这样的优势：能够被抽象、反复地应用到系统构建时的各个层次中，解决许多行业问题。本文给出的业务构件规格书的例子就是医疗行业业务模式。我们应该能清楚地认识到业务模式的以下重要特性，即一些模式将对行业外并无益处（像本文中的例子），而另一些却不（它们能够代表通用的功能）

诚然，那些跨行业通用的业务模式确实能够被相当成熟地用来识别某些行业领域，但那将是另外一种完全不同的讨论了

返回页首

业务功能

为了开发业务模式，我们首先必须发现、定义和文档化相关业务功能。以下是主要任务：

1.

发现描述问题空间的原子功能集，在功能建模里称之为“原始功能”，类似地，在业务过程重组里称作“基础过程”

2.

把这些原子功能聚合成更大的更条理的功能组

“原子”的意思是功能不能够被分解，一旦开始，功能就应该被完成和接受。

因此我们实际追求的业务模式是将业务功能定义在一种可以分解的层次，这些层次间有紧密联系。特别是数据层，如果发现业务功能定义在整个体系结构的第四层，通常可以形成数据层实体间的CRUD（创建、读取、修改、删除）关系。业务功能可以采用自底向上或者自顶向上或者二者混合的方式来分析和定义。

自底向上分析

分析员使用这种方法，聚焦用户典型业务领域，去分析他们的业务过程。用例图或者任何能表达业务过程中执行顺序和并行任务的方法，将会被采用，随后，分类、分析过程集合。通常可以注意到，许多步骤或过程中执行的低层次的任务将在在不同的过程中被重复执行很多次。因此，必须识别这些多余的任务，并且从原始功能的必要集合中排除出去。图１用一个简单的流程图演示了这一过程。从图中可知，任务Ａ是多余的，应该仅出现在原始集合中一次，通过这样类似的分析，最后得出必要的原始集合。再反复合并功能，得到如图２所示的动态结果。从业务模式的角度考虑，自底向上的分析方法存在一些问题。

图１　过程的发现和合成

1.

对于包含许多用户的庞大过程，自顶向下地分析过程工作量非常大（为了减轻工作量，一种折衷的办法是，采用过程分析和用例分析相结合的方法来提炼过程）

2.

过程的本质在于对“像-是”的情况的？

分析，只要这种分析足够清晰，它的结果就可以接受。

3.

为了确保业务模式的正确性，必须在相同的领域范围内进行反复的分析验证。在这个过程中就会发现很多实际的问题。

自底向上的分析方法的好处在于，基础分析为驱动业务模式方案奠定了基础，验证业务模式的关键在于成功地实践，一旦选好了实例，自底向上的分析方法的这些优势就会有明显体现。

自顶向下分析

图2中的功能分解依靠另外一种方法——自顶向下分析方法来进行，这种方法首先假定最上层的结构，然后逐步填充下面的层次，直到充分详细为止。

图2 业务功能分析的典型实例

很明显，有必要对分析的结果进行验证，看它是否正确地反映了现实世界。因此，自顶向下的分析方法从描述最抽象的业务问题领域开始，然后逐步分解，直到最原始层为止，以此来验证结果的正确性。这种方法能够通过一种标准方法来实现，就是用于功能建模的IDEF0，或者用于业务过程建模的扩展UML也可以。

事实上，很多前因后果决定了自顶向下的分析方法不需要详述业务过程。

自顶向下的分析方法在模式定义中的好处是行业顾问完全能做这项工作，这些顾问们往往有和许多客户在某个问题领域打交道的许多经验，因此有他们来完成这项工作将会既准确又迅速。本质上，这种分析方法一方面执行了和专家进行知识挖掘的任务，另一方面，它也减少了必须直接分析的实例数目，改变了分析员的角色——不再是以前的工作人员而是现在的浏览者。

混合分析方法

实际上，我们经常把自顶向上和自底向上的分析结合使用，在过程综合到层次结构低层次分解之间反复的变换。这样做的好处是，可以用自底向下获取的现实世界功能来验证假设的自顶向下的分解。实践证明，这是最快、最可靠的方法。

功能分解实例

以下是关于病人医疗情况的实例，使用上述方法来进行业务分析，从而演示了核心业务模式的形成过程。

首先，分析问题领域的功能性需求。以乳房癌治愈为例，得出40多个过程，参与的角色有病人、医生、系统管理者和机密保管员等。其中机密保管员这个角色会随着信息的机密性改变而改变。这些过程是用UML用例来文档化的。它们在许多用例中都有相同或者相似的子活动高度地重复。因此，我们抽取并整理了这些活动，形成以下清单：

•

病人登陆（用户检查）

•

病人注销（核查）

•

搜索申请的病人

•

管理病人详细信息

•

管理病人权利

•

查看私人区域

•

查看个人GP详情

•

管理个人一般健康数据

•

管理捐赠人明细

•

管理病人明细

•

管理家庭成员

•

查看采取的免疫措施和种痘

•

管理个人权利

•

查看病人病厉

•

查看病人私人区域

•

申请病历

•

复查病历

•

创建病人事件

•

管理病人个人事件

•

建立病人疗程

•

查看病人疗程

•

查看个人病历

•

定义普通协议

•

管理个人协议

•

维护医疗项目

•

执行医疗代码翻译

•

获取其它医疗代码

•

编制其他医疗代码

•

维护医疗路径

•

管理预约

•

改变预约

•

访问事件明细

•

访问系统索引

•

维护临床过程

•

维护角色定义

•

维护组/队结构

•

维护组/队成员

•

维护许可证授权

•

维护医生注册

•

医生登陆（身份鉴定）

•

医生注销（核查）

•

查看医生许可

•

维护具体许可

•

定义普通许可

图3 医疗实例—功能分解

图三表达了医疗实例功能分解过程。利用主题和功能的相似性把各个分散的功能归纳到更高的层次上去。

返回页首

数据模型

医疗实例有综合的数据模型。经过对同一个问题领域的数据进行分析，共定义了31个主要的实体，如病人、医生、病人事件、医疗路线等等。数据模型需要识别实体的候选码和它们的主要属性，描述实体之间的相互关系，分解所有的多对多的关系。并且这些操作就是在功能分析时并行地得到的。

据我们所知，数据模型应该支持所有已识别的功能需求，反之亦然。在实体之间的相互关系和聚合的基础上，上述31个实体已经分配给8个数据项。这些项分别是：

•

病人

•

病人协议

•

医疗路线

•

医疗项目

•

临床过程

•

角色、团队和组织

•

医生和许可

•

本地系统

这些数据项是目标数据库和动态内容定义的第一步。图4显示病人数据项的全部内容，采用传统的E-R图描述了数据实体以及实体间的关系，并且标出了每个实体的主键。框外的实体是属于其它数据项的，但是与框内的实体有着紧密的联系。

图4 病人数据项的实例模型

映射关系

功能分解的层次结构定义了需求功能，关系数据模型定义了需求数据。此后，我们通过比较功能和数据二者之间的关系，能够得出一个初步的构件体系结构。具体的做法是建立一个矩阵，行表示功能，列表示识别的实体，行列交叉处的值有C、R、U、D四种：

•

C代表“创建”数据实体实例的功能

•

R代表“读取”数据实体实例的功能

•

U代表“修改”数据实体实例的功能

•

Ｄ代表“删除”数据实体实力的功能

得出的结果如下图5所示：

图5 功能和数据的CRUD的矩阵

矩阵簇群

我们确保矩阵中每一列（数据实体）至少有一个创建操作，每一行（功能）都有少许活动。请注意矩阵中的操作并不是绝对正确的，特别是读取操作。同时表中没有制定删除操作。现在用归类和聚合的方法来分析矩阵，以获取那些共享创建和修改操作的功能组和实体组。对于数据模型中内部实体动静态关系，我们采用高内聚、低耦合的原则进行功能分解。然后调整矩阵，合并关系紧密的功能和实体，最后得到的就是候选业务构件。具体的算法描述（"North West"算法）超出了本文的范围。图6所示。

图6 矩阵簇群

业务构件的来由

首先应该说明业务构件是用来做什么的。一个业务功能创建、读取、修改和删除数据。分组聚合相同数据实体的创建和修改功能，用诸如相互的分簇技术定义一个必要的构造块，就形成了业务构件，用它来构造模式、系统或应用，以便支持特定的业务过程。业务构件是一个驱动领域的实例——它是从其它2个领域的相互关系中推导出来的。这是一个强大的技术，可以获取企业体系结构中隐藏的特性。通过封装功能和数据到一个构件中，软件重用和重构才能切实可行。更进一步说，业务构件提供了一些服务，使得它们能够和其它业务构件提供的服务相结合一起协调的工作，完成一个具体的应用。

业务构件来源于对服务和接口的簇群分析，业务实体构件、数据访问构件和某些服务代理这些制品共同构成了.Net体系结构，业务构件并不包含敏捷的元素如UI构件和UI过程构件、业务工作流或其他元素，如安全、运作管理和交互。这些初步的定义是十分有用的。它提供了一个全部体系结构方案的稳定部分。然后结合一些敏捷元素，像UI、UI过程、业务工作流，就能提供一个以稳定模式为基础的敏捷方案。

通过对业务功能和数据之间的整合分析，能够得出初步的业务构件和服务。从而生成CRUD矩阵，来定义构件与数据之间的关系

图7业务构件样例

在SAM中，业务构件也是一个层次，因此业务构件能够被分解成更为具体的服务、业务实体、数据访问子构件层，并且包含想要业务服务。对这些服务进行明确的定义是非常有用的，这样才能够搞清楚哪些是internal服务，哪些是web服务

构件和服务

构件清单如下图：

•

病人构件

•

病人事件构件

•

病人协议书构件

•

医疗项构件

•

预约构件

•

疗程构件

•

GP&医院系统访问组建

•

临床过程构件

•

组/队构件

•

医生构件

•

许可证构件

图8 PRM的体系结构视图和设计视图

上述构件显示了业务模式定义的本质，其中的病人构件如下图7所示，它描述了整个构件的功能、管理的数据和服务、特征。

业务模式对软件工程有什么作用？

现在我们将来讨论本文的关注点——怎样利用上述业务模式来建造其它模式或实际的软件系统。图8的PRM的五个层次说明了这个问题。注意到PRM区分了系统结构视图（一个更高的视图，如项目规划）和系统设计视图（如项目或主题设计）。图8介绍了适合这些视图的不同技术和标记，帮助建立一个正确的软件系统。值得注意的是，PRM辨别简单的元素时，要依靠实践而不是假定或者臆断。在业务模式定义后，就可以随心所欲地开展工作了。

在对业务模式进行仔细分析时，首先需要认清体系结构和设计之间抽象水平本质的不同。

业务模式用在哪些地方比较适合？

图9显示了业务模式的优势，图中定义了业务、业务功能、数据和业务构件这些稳定元素。这种方法可以用来指导大型项目开发，保证了项目之间的一致性，节约了项目开发成本。

图9PRM中业务模式的优势

业务模式和面向服务的体系结构（ＳＯＡ）

对于那些想要提供其它ＩＴ模式或者更进一步地提供业务问题的ＩＴ方案的人士来说，业务模式能够用ＳＯＡ原理更深入地来定义，ＳＯＡ虽然不是必须的，但确实最优秀的。利用ＳＯＡ来定义业务模式，我们所需要做的事就是将体系结构中的详细内容转化为ＩＴ方案。那么首先需要提供给业务敏捷一个机会，如图１０所示，将下一层描述的业务细节包含到模式中来，图中新加的这两套原理将把业务模式改变成业务方案模式，另外，业务可以为业务模式构造一个具体的业务方案体系结构。下面我们就来讨论这个问题。注意，此时各个阶段的工作仍然是独立的技术产品

图１０　在业务模式中附加ＩＴ体系结构

业务模式、SOA、(Microsoft)产品细节

最后，图11清楚地描述了更深层次的产品和实践，成功地实施了微软技术方案

图11 附加微软技术元素

到目前为止，我们已经讲述了业务模式、面向服务的应用体系结构和微软的一套实施模式，接下来将利用相关的模式或IT方案来解决体系结构层次的共同问题。但是仍然需要更加详细的信息，它就是设计视图。

返回页首

业务模式和行业方案

上面已经讨论了体系结构的建立过程，并且这个过程保证了IT项目的管理和价值。如果想要提供一个具体的方案，那么就需要对体系结构的设计层次更详细的研究。将一个方案应用到几个项目上是有可能的，并且体系结构保证了这些项目之间的一致性。

图12 精化设计方案

图12显示了设计方案的精化过程，并告知用UML这个标准的方法来进行系统设计。

这是精化体系结构的一个普遍的方法，设计结果可以直接用来实现。

在精化体系结构的时候，还能产生一个模式，即IT设计模式。今天大多数软件模式的描述也是采用上述这种方法。包括Microsoft公司的企业方案模式—Microsoft .NET6和Martin Fowler的企业应用体系结构模式。

当然，并不是仅仅依靠设计模式就能创建一个实际的解决方案的，找出模式之间的关联性这一步也是相当关键的。这些模式涉及到Gang of Four8或面向模式的软件体系结构集，以及上面提到的Microsoft和Martin Fowler的模式等。

返回页首

结论：设计模式和行业方案的框架和方法

本文描述了创建业务模式的框架和方法，然后使用业务模式来实现指定的体系结构，这种体系结构可以用来定位、核算、管理IT项目。并且提供了一种方案，来更进一步地指导该体系结构的设计和实施

Microsoft技术模式的实例可以在此处获得，http://www.microsoft.com/resources/practices/

尾注：

1.

本文对模式的定义遵循由Christopher Alexander在《创建永恒的构造方法》（牛津大学，1979）一文中建立的模式标准。描述模式时采用一种Coplien-style的标记。

2.

对于SAM更详细的信息，请查看《企业体系结构—对Bigger Picture的理解》，Bob Jarvis，牛津大学计算机中心，UK, 2003年5月，或者查看http://www.systems-advisers.com

3.

模型问题精化—查看本刊2出版的第一部分

4.

NIST中 FIPS 的IDEF 成员标准，查看此处文章183页http://www.itl.nist.gov/fipspubs/by-num.htm

5.

.Net的应用体系结构：设计应用、服务模式和实践指南—Microsoft 公司 2002

6.

查看http://www.microsoft.com/resources/practices/ or 或者Amazon

7.

http://www.martinfowler.com/books.html#eaa

8.

《可重用的面向对象软件设计模式原理》，Erich Gamma, Richard Helm, Ralph Johnson, 和John Vlissides. http://hillside.net/patterns/DPBook/DPBook.html

慎重声明：

未经本文作者所在公司授权，任何其他公司都不得擅自采纳文章中的思想和理念。

作者介绍：

Philip Teale是一位伙伴策略咨询师，之前供职于英国微软的Enterprise & Partner集团，现就职于微软Prescriptive Architecture 集团，之前为微软提供咨询服务，有29年的IT从业经验，其中有4年供职于微软，16年供职于IBM，均承担软件开发业务。他的国际性经验包括了9年在美国工作，3年在加拿大，17年在英国。Philip Teale的背景是架构师、设计师和能构建大型复杂分布的商业系统。他最近的对领导思想产业的贡献将推动微软在企业系统模型创建上的发展，他是RSA会员。可以通过E-mail与他取得联系：pteale@microsoft.com.

Robert Jarvis是系统顾问有限公司的总监，这是一家英国的顾问公司，专业从事为国际性大型企业开发战略系统建设的业务。他也是一位微软的建筑咨询合作人，Robert Jarvis在国际性系统咨询方面具有超过30年的工作经验，在英国、欧洲大陆和美洲为商业和政府组织提供咨询。他特别擅长企业系统机构的构建，特别是业务/技术交叉点上。他是企业构建的创造者——对大型图纸的理解，一篇很好的应用指南，于2003年，由英国国家计算中心出版。E-mail：v-rjarvi@microsoft.com

转到原英文页面

 

源文档 <http://www.microsoft.com/china/MSDN/library/architecture/BP2.mspx>

 

 

软件工程中业务模式的使用（第一部分）

发布日期： 2005-10-22 | 更新日期： 2005-10-22

Philip Teale

Microsoft Corporation

Robert Jarvis

Systems Advisers Limited

对于软件开发者来说，采取一种方式定义业务模式，并通过战略架构模型（SAM）来开发一个商业模型框架，是有益的。

本页内容

简介

业务模式的应用接口

如何识别并文档化业务模式

相关域的定义

结论

简介

这是一个系列文章中的第一部分，这系列文章分为两部分。这系列文章探讨了是否业务模式能够被通过结构化的方式定义，如果能的话，这些业务模式对于那些搭建商业软件系统的软件工程师是否有价值。

第一部分探讨了如何通过一种方式定义业务模式，以使得业务模式对软件工程师来说有益处。

第二部分探讨了如何通过这些业务模式开发系统。在这些文章中“模式”这个词来自于Christopher Alexander给出的标准定义，这个定义确定了一个模式的三个关键元素。

一个模式是在已定义语境下描述一个连续问题的通用解决方案。在模式定义中有三个关键部分：

•

通用解决方案 这意味着一个模式不会定义一个特定解决方案。甚至，以一些显著的现象为基础，它定义问题“类”和问题如何通过一种特定的方法得到解决。它的作用来自于一个事实，就是它只是一个抽象，并可以在一些情况下被调节。

•

连续问题 这意味着问题不唯一时，模式是有益的，尤其在出现很多问题的时候。

•

已定义语境 这意味着你不得不限制通用解决方案，因为没有绝对普遍的真理（在任何有效水平）。因此你必须了解通用解决方案有效的情况，还有如何详细说明它来创建你自己的特别的设计。

摘要

什么是业务模式？一个业务模式描述了一个可重用方法来解决一个特别的商业问题，这个商业问题通常是在商业过程范围内。它提供了一个解决方案，这个方案以前面定义的针对同样的，或相似的，商业问题的方案为基础。一个业务模式可以被形容为一个“商业方案的架构模型”。

这篇文章回答了下面几个问题：

1.

我们能够为业务模式的创建开发一个框架么？

2.

我们能够定义一个稳定方法来创建业务模式么?

3.

我们能够改善框架和方法工作么?

4.

这些业务模式可以用来驱动其他软件设计和应用模式，或者实际方案么?

在这篇预言性的和可行性的文章中，我们断言所有这些问题的答案都为是。

1.

我们确定完整描述业务模式所需要的架构元素集。我们给它们分类并且着重在描述商业最稳定部分的元素上，它们非常适合“模式化”这个词语。

2.

以实验过的并可相信的方法为基础，我们已经定义了一个正确的方法。

在第二部分，我们提供一个来自医疗产业的例子，这个例子以联合国的真实雇用为基础。

这篇文章没有努力让你认为你可以创建业务模式，也没有提供一个关于这个活动的成本/效益例子。它描述了使用业务模式得到的一些好处，但是它并不广泛。我们的目的是促进这个对概念的兴趣并给出一些想法，因为我们相信这将带领我们到一个更加工程化的软件系统时代。

方法一致性的益处

软件工程上有一个框架的益处以惊众所周知所以我们不再讨论。然而，方法一致性的益处还值得讨论一下。依作者的观点看来，因为一下这些原因，我们必须用一种一致的、结构化的方法记录下业务模式：

•

这个方法允许业务模式和业务模式方案的逐步介绍。它使得一个系统方案应用业务模式成为可能。这也是必要的，因为企业通常只对投资它们产业中某部分这件事在任何时候都感兴趣。

•

因此我们需要逐步的解释业务模式，针对企业的利益。我们需要一个一致性方法，这个方法允许通过无缝增加现存事物的方式来扩展模式范围。

•

我们还认为这种方法可以跨产业领域被使用，因此如果某产业领域的某企业需要另一个产业的企业（举例说，一家银行需要一家保险公司），他们可以选择在业务模式层次的简单集成。

返回页首

业务模式的应用接口

我们认为成功的关键在于，通过给出一个服务于所有业务模式的一致性接口，业务模式要增强IT系统的开发和维护。我们推荐接口采取组件与服务共同定义的模式，这些组件和服务将在可描述商业数据上执行已定义的商业功能。

使用的模式

我们需要两个模型--一个用来说明如何定义业务模式，另一个用来说明如何设计基于业务模式的系统，这些系统可能在过程中使用其它模式。我们选择了以前用过的两种模式，但是，再次着重重申一次，你不是必须使用这些模式。我们的确感到，如果产业使用一致性方法来定义业务模式会更好一些；但是，接下来将使用很多方法来开发应用它们的系统。我们使用的这些模型已经被微软公司的内部与外部顾问使用过，用来为创建客户和合作伙伴提供意见。这些方法和技术已经在实践中被证明。

模型1：一个企业结构框架—SAM

在第一部分我们开发一个业务模式框架，通过使用SAM—企业结构框架。SAM为企业架构和相关问题领域提供了一个非常好的分析方法和文件结构。

SAM使用“兴趣域”这个概念来说明一些企业和“关系”事例的集合，将这些事例关联为一些组，这些组提供对企业架构与操作的观察。SAM已经被Systems Advisers Ltd，一名曾在微软公司架构领域工作过的联合国顾问，发展起来。在这篇文章中，我们使用SAM来定义关键业务模式主题。

SAM可以被认为是一个Zachman框架的扩展子集，它通过提供一个架构定义与机制的通用架构进行扩展，这些定义和机制用来组织、关联，和分析架构信息。

SAM对架构开发采用一种反复的方法，通过从上到下或从下到上的方式，或者这两种方式的混合来进行操作，形成自己的意见。一个SAM“兴趣域”包括一个特定主题的所有相关信息，比如组织结构或商业过程，通过简单方式提出并组织。通过详细收集所有相关信息和逐步概括为更抽象的组，一个域可以“从下到上”的组装，或者通过定义假定的高层次组和详细分解它们直到“自动”层次，一个域也可以“从上到下”的组装。在实践中，这些方法经常一起使用来搭建可扩展的与有弹性的架构模型，最重要的是用来在分析中验证完整性。

已经足够仔细的搭建和组装了一对域，这些域的成员可以被连接起来表示现实世界的关系，这些关系驱动和支撑了企业的操作。这些关系的分析和改进可以改善和优化商业。

在IT业务模式的环境中，SAM提供了模式化商业功能和数据，以及它们之间关系的方法，来派生组件和服务，这些组件和服务支持一个已定义商业域。

模型2：一个问题改进模型（PRM）

一个通用PRM有以下这些步骤：

1.

问题

2.

概念方案

3.

逻辑服务

4.

物理服务

5.

执行

举例，我们可以按步骤应用PRM来搭建一个家。

•

问题：在一个适合的建筑里保护一个家庭。

•

概念方案：位置模型内的属性要可视化，并以和未来使用者相关联的方式被描述。

•

逻辑服务：概念方案更进一步的优化，需要这个优化的标准；在这个优化中，比如房屋，窗户，以及屋顶类型，都为建筑选择出来。

•

物理服务：着重基础需要的优化；比如地基，水管，绝缘材料等。

•

执行：最终优化将逻辑与物理服务一起展示出一个蓝图，这个蓝图说明这个房子如何被构造。这是架构师/设计者的最后工作，设计即将被实现。对IT架构和IT项目设计者来说，这是类似的。

在第二部分我们用一个PRM（问题优化模型）来说明如何将一个商业问题转化为技术实现。通用的PRM可以被用来反复优化任何问题，从最初定义到最终方案。我们的经验已经证明，这种方法对方案搭建与设计非常有效，因此我们所说的PRM已经适应了这些问题的要求。我们还可以说明如何使用PRM来将商业问题（在我们这里以业务模式表示）转化为IT解决方案。

我们还使用PRM识别常见的需求，来从项目设计者的角度切分企业架构，并使用不同的技术来与客户交流。它为每一个客户在一个五层结构的视图中说明不同的优化技术和不同层之间的转换。这五层结构如图1所示。

图1.一个问题优化的五层结构视图

结构分为五层的原因是，从实践中看来，应该提供一些优化步骤：

1.

商业问题（也被表达为业务模式）对被执行的商业功能和需要的数据来说是明确的。

2.

概念方案的元素可能对其它业务模式有效。

3.

逻辑服务可能对其它方案有效。

4.

物理服务面向节点和功能/数据放置，这些节点和功能是在独立于产品出售的。

5.

特别出售问题与应用层有关。举例说，这里我们可以提供非常详细的微软产品使用指南，在整个环境中。

使用优化模型的一个重要价值就是你可以维持对系统方案可追踪性。这样你就可以查看执行细节并且一层层的追踪来清除了解哪一个执行驱动对商业问题是恰当的。

应用企业架构模型时，我们特意使用了归档技术，这项技术对于一个应用项目编程人员的长期指导是合适的。当项目设计者使用它时，我们使用像UML这样通用的“语言”来分析和设计项目。（编程人员的差别所导致的项目需求的差别是技术优化的关键点，而不是责任差别）

返回页首

如何识别并文档化业务模式

使用SAM域来识别真实世界

我们通过考虑SAM域来解决这个问题。这些表明了一个Zachman框架的扩展子集。我们来自于搭建真实企业架构的经验表明，图2所示的这些域清楚表明了重要的兴趣域。

图2.典型兴趣域

这些兴趣域需要进行一些说明。特别是应该着重指出，从一个企业到另一个企业，这些定义可能是不同的。重要的是，概念被识别并组合为整体架构设计。

在域中，我们储存特定主题的信息--按照尽可能简单维护和修复的原则结构化。通常这将导致对一个或更多层次结构，分析档案橱柜的思考。每一项信息都被认为是一个“成员”。因此，一个成员就是一个兴趣域内信息的一个离散片。一个关于“场所”的域可能会包括以下这些成员“总公司”，“伦敦销售店”，“伯明翰工厂”，等等。更进一步的成员例子包括：

•

一个明确的组织单位，例如“组织”域内的“销售部”。

•

一个明确的商业过程，例如“商业过程”域内的“接受订购”。

•

一个特定数据实体，例如“数据”域内的“客户”。

返回页首

相关域的定义

目标是完成任务，这里的目标是指企业在战略和战术上的。他们可能在较高层次，比如“改善客户服务”，或者着重在“将等待时间压缩在30秒之内”。目标会影响商业过程，并为了完成而被分配为组织单位。

组织与企业的组织结构相关，企业组织结构--小组，部门，部分--以及这些组织单位间的关系

基础结构与企业的固定资产相关，企业固定资产--场所，建筑，设备（包括IT设备），网络，运输工具，等等，还有他们间的关系。

商业过程在这里被定义为企业执行的过程和活动。商业过程还经常被表示为一系列工作活动。这些活动由不同的并行工作的组织单位执行。例子可以是“处理客户命令”，“雇佣职员”，或“准备设备文档”。

商业功能就是一个企业所做的事情，比如市场，销售，产品设计，制作，财务管理，人力资源管理，等等。这些不能被从事这些的“部门”搞混。一个功能可以被多个部门或组织单位执行。功能可以被标准定义为一个不会冗余的层次结构。一个功能分解可以按照减少外部关联与增加内部耦合的思想来结构化，模块化的思想对于软件工程师来说是非常熟悉的。

数据是信息的基本片断，这些信息由企业创建和使用。显然，这些片断在一个数据实体的层次被表示，这个数据实体可以使“雇员”或“产品”或“客户”。

商业组件由商业功能和数据打包而成。一个商业功能创建，读取，修改，和删除数据。通过使用一些技术，比如可交换组，定义不会冗余的“建筑块”—用来搭建支持特定商业过程的系统或应用的组件，来给所有的功能分组，可以创建和修改相同的数据实体。通过概括功能和数据，软件的可重用性和易替代性更加接近实际。甚至，组件还提供可以在其它组件提供的服务关联中使用的服务，来示例一个SOA。明显使用网络技术的服务被称为“网络服务”--微软公司.NET技术的一个重要方面。

应用是企业现有的计算机或其他系统。包括所有的位于开发层次下的操作系统，以及计划中的系统。它们可能以组件为基础，或者是按照旧方法搭建起来的。

技术描述了用来搭建和操作应用的硬件、软件，以及交互环境，和工具。

项目是工作的可控片断，工作指实现一个应用或应用集合。项目按照目标顺序排列。

使用SAM域来搭建商业模型

我们认为上面的域子集和它们之间的关系可以用来定义一个完整商业模型。因此，这就是我们描述业务模式的方法么？我们可以通过文档化所有域和所有关系来做到这一点么？

一般说来，答案就是“是的”，但是这还远远不能让人满意，因为不同的域随着稳定程度的不同而不同：从高稳定的到动态的。我们希望我们的业务模式以企业的稳定元素集为基础，并以此为基础创建处弹性的，灵活的方案。

我们假定域的集合分为三类，如图3所示。

图3.稳定，灵活，动态的兴趣域

集合1=稳定的

这些域描述了商业的稳定元素，并说明了基础结构--商业功能，数据，商业组件和基础组织--必须被表示来在一个已定义商业域内操作。

集合2=灵活的

这些灵活的域描述了商业做的事情，或者能做的事情，来清楚的将它与竞争者区分开来。它如何来做将确定他是否是灵活的。这些灵活的域--组织，商业过程，应用和技术--就是一个企业根据市场和经济情况可以迅速改变，甚至持续改变的事情。

集合3=动态的

这些动态的域与商业方向，工作计划，和变更安排相关--主要是“与这相关的都是什么”。通过一系列相关项目，它们描述了朝着商业目标集的方向所做的努力。

表格1

域集合

这可以被称为业务模式?

它们对软件工程有用么?

稳定的

是的，这些模式将对软件公司（ISVs）的商业顾问和AND集成者非常有益，这些人可以证明他们的方案可以快速提供大量，稳定，可维护的功能。

是的，它就是我们需要的东西。因此他就是我们应该要做的，就从这里开始！

灵活的

是的，这些模式将对商业顾问和较低层次的集成者非常有益，这些人可以用它们来在客户商业那里引发改变。然而，环境和驱动力带来的大量不同模式将是不稳定的和数量众多的。

不是马上

动态的

是的，这些模式将对商业顾问和系统集成者非常有益，这些人可以在程序实现和变更管理上深入研究。他们可以使用这些模式来配置项目，项目的编程人员也可以根据前面的成功方法改善这些模式。

不是马上

表格1回答了这些问题：

•

这些域集合的哪些部分可以被表示为业务模式？

•

对于软件工程师来说哪些是有益的？

返回页首

结论

我们得出结论，一个业务模式可以描述：

•

被支持的商业功能。

•

要求数据来支持所描述的功能。

•

商业组件就是商业所需要的数据和功能的IT表述。

•

任意的，需要基础组织结构来支持功能，数据，以及组件。这对一个高度分布的企业来说是必须的，对那些由不同的技术和操作环境支持的部分或单位来说也是必须的。

另外，业务模式还描述这些元素之间的重要关系。所有的SAM域都与所有其他域相关。然而，我们需要着重在一定量的核心关系上，这些关系是形成业务模式的基础。

这些核心关系被这样定义：

稳定关系

•

商业功能在商业数据上执行事务（典型的，创建，读取，修改，和删除）。

•

商业功能被包括在商业组件中。

•

数据被包括在商业组件中。

下面，这些稳定域关联到灵活域：

关联关系（稳定域>灵活域）

•

商业功能被按照商业过程执行。

•

商业过程使用商业组件提供的服务。

•

商业组件在应用系统中被执行。

下面这些灵活域中的关系是有效的：

灵活关系

•

应用系统支持商业过程。

•

用技术操作应用系统。

图4.业务模式定义的最小化基本模型

这可以在图4中看到。另外，在基础组织结构与组织（灰色）之间存在着关系，这些组织依赖于企业和已定义商业域的属性。

然而，我们发出一句警告。在有效的成果出现之前，尽管还不用必须组装这些域，但是，在关于业务模式可实现的范围和约束的重要结论出现之前，却应该必须完成一个紧急的相互关联的稳定结构的集合。

方案vs.模式

业务模式仅通过稳定域和稳定域之间关系来定义。业务模式与潜在方案的关联被域之间关系提供出来。甚至，通过改善和优化灵活关系，灵活性也可以达到。

在一个完整方案开发中，我们至少可以解决相关稳定域与灵活域，以及它们之间关系。

因此对一个业务模式而言，我们需要仅仅三种稳定域以及它们之间关系被归档。这给了模式应用中的灵活性以最坚固的基础。所需的三个稳定域在图4中被突出显示。灰色的关系和域表示在一个方案中从稳定域到灵活域的关系。如果业务模式为某个主题存在，那么方案就搭建在模式上。

 

  After completing a process model by Modeler, Business analyst will simulate the process.
  The tool adds a simulation snapshot as a child element of the process in the project tree.
  A simulation saapshot is a record of the complete process model at the moment when you
  simulated the process. This record contains a copy of all the elements of your project
  Within the simulation snapshot, the tool also cretes two folders:
  Default-----Containing a set of local preferences for simulation attributes.
  Profile-----Each simulation snapshot contains an initial simulation profile which
  contains a copy of the process model at the time that you creted the simulation snapshot.
  You can customize process contained in this simulation profile, and you can create
  additional simulation profiles within the same simulation snapshot.
 
  Today, I follow these steps to complete the simulation of the process. There is a problem.
  For a local task, the flow is ok. The tool simulates the process correctly. But when the
  process includes a local process, the problem comes out. The flow is "stop in the local process".
  There is not outcome and the following task won't be carried out. I try the example which
  also includes a local process on the book. The result is suprising. Most of the flows is "stop
  in the local process". But when performing many times, some flow can go through the process.
 
  What lead the problem? 

-------------------------------------------------------------------------------------------------------------------

Davis Xu 

这两天都在考虑一个问题，就是业务流程中怎样加入需要人来完成的操作，这样的场景应该怎样来设计和实现？

今天查了半天资料，终于找到了一条解决之道，那就是Websphere Process Server的Human Task Manager