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

发布日期 : 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中被突出显示。灰色的关系和域表示在一个方案中从稳定域到灵活域的关系。如果业务模式为某个主题存在，那么方案就搭建在模式上。

第二部分

在JOURNAL3中，我们将说明一种开发被描述为商业功能，数据，以及商业组件的业务模式的方法。我们还将说明如何用这些模式来工程化软件系统。

弃权声明：文章中的观点来自于作者。这些观点不需被他们的公司认可，也就不意味着这些思想或概念可能这些公司被提供或出售。

关于作者

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

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