The Process Cycle Layer
流程周期层
This article we'll introduces The Process Cycle Layer as a new BPM concept that puts BPM Systems into a completely new perspective. The proposed concept and strategy that we present here fits much better with how people work in practice. And it will result in a much broader applicability of BPM technology. The Process Cycle Layer identifies the layer on which business stakeholders, developers and IT operations people collaborate. As part of this article, we'll sketch the initial direction of a concrete tool that supports The Process Cycle Layer.
本文将介绍流程周期层，它将作为一个新的BPM概念，将BPM系统纳入一个全新的视点里面。提议的概念和策略，非常适合在实践上人们是如何工作的。并且它将导致广泛的BPM技术应用能力。流程周期层识别业务干系人，开发者和IT运营人员在哪个层次上协作。作为这篇文章的一部分，我们将勾画出一个具体的工具，支持这一流程周期层的初始方向
BPM Overlaps With Software Development
BPM与软件开发的重叠
One of the most common goals of BPM is to end up with software that supports those core business processes. The scope of managing business processes is of course larger then just building software. It also involves identifying core business processes in an organisation, filtering out activities that don’t contribute to core business, documenting how people collaborate today, business process reengineering and managing the organisational changes after reorganisations. Those aspects can all be done without building new software.
BPM最公共的目标之一是终止那些只支持核心业务流程的软件。管理业务流程的范围当然比只是构建软件要大得多。它也包括确定组织中的核心业务流程，筛选出无助于核心业务的活动，记录今天人们如何协作的，业务流程再造和管理重组后的组织变化。这些方面都可以做到而不用构建新的软件。
But still a big aspect of BPM is creating software support for business processes. And BPM suites typically focus on simplifying the translation from analysis process models to executable process models. That part of building executable processes is actually software development. At Activiti, dealing with business processes in the context of software development is not an afterthought.
但BPM一个大的方面仍然是创建支持业务流程的软件。BPM套件通常侧重于简化从分析过程模型到可执行流程模型的翻译。构建可执行流程那个部分实际上是软件开发。在Activiti，在软件开发环境下处理业务流程不是可有可无的事情。
Looking at the software development aspect of BPM, executable processes (and rules for that matter) cannot be looked at in isolation. They are authored preferably in the developers Integrated Development Environment (IDE). And typical executable business processes are close related to other software artifacts like java classes for the domain model or java based services, web applications, message queues, services and so on. An application can be composed of many of those components. Or the other way round: executable business processes are only one aspect of an application.
纵观BPM的软件开发方面，不能以孤立的方式看待可执行流程（和这个问题的规则）。最好在开发人员的集成开发环境（IDE）里创作它们。并且典型的可执行业务流程和其它软件工件密切相关，比如领域模型的Java类，或者基于Java的服务，Web应用程序，消息队列，服务等等。一个应用程序能够由许多那样的组件组成。或者反过来说，可执行业务流程只是应用程序的一个方面。
In practice, both BPM as a management discipline and BPM as software engineering both require dedicated solutions. Our conclusion is that round-tripping only works in very particular niche cases. In general --and that is the market we target-- business process modelers and developers should both work in their own world and the BPM solution must facilitate the interaction links to get a good collaboration.
实践上，作为管理学科的BPM和作为软件工程的BPM，都需要专门的解决方案。我们的结论是，双向工程只适用在非常特殊的好的场景。一般情况下 - 这是我们的目标市场 - 业务流程建模和开发人员都应该工作在自己的世界。BPM解决方案必须提供便利的互动连结来取得了良好的合作。
Problems With Traditional Approaches
传统方法的问题
Traditional pure-play BPM vendors have 2 major problems:
传统的纯BPM供应商有2个主要问题：
· 1) Traditional BPM systems are focussed solely on the non tech business users. Less or even no focus is given to IT development teams. And yet most the software support that is being build to support business process is part of a larger software application. So despite the ambition of some BPM leaders to bypass technical developers, in practice that approach turns out to fail. The only viable path is to facilitate a proper collaboration between non tech business people and IT development teams. So BPM should not be looked at in isolation from a process only perspective. For IT teams, BPM should actually be a part of their normal software development work. Traditional vendors don’t focus enough on embedding BPM as part of the normal software development work.
· 传统的BPM系统是完全集中在非科技企业用户。较少甚至没有关注开发团队。但大多数正在建设以支持业务流程的软件是一个更大的软件应用程序的一部分。因此，尽管一些BPM的领导厂商的野心企图绕过技术开发人员，这种做法在实践中失败。唯一可行的道路是促使非技术业务人员和IT开发团队之间的合作。因此，不应当孤立看待BPM只是流程的观点。对于IT团队，BPM实际上应该是一个正常的软件开发工作的一部分。传统的供应商不注重能够嵌入BPM的能力作为正常开发工作的一部分。
· 2) All BPM vendors focus start with a focus on the non tech business users. But then they end up with self-contained, monolithic systems on which those business processes have to run. To interact with other systems, they then build communication capabilities. In that context, BPEL found it's origin as it is assumed that any other system is addressable via a web service. The capability of just having communication between BPMS and other applications is just too limited. BPM Systems must be able to run *inside* applications. It should be easy to combine application updates and BPM updates into a single transaction. From the application data, it should be easy to access the process instance and also the other way round. The capability to run business processes as part of an application greatly reduces the threshold to start using BPM technology.
· 所有的BPM供应商一开始，都把重点集中在非高科技企业用户。不过，他们终止于那些业务流程必须运行在自包含的，单一系统上。为了和其它系统交互，然后他们构建了通信能力。在这种情况下，BPEL能够发现它的起源，因为它是假定，任何其他系统通过网络服务寻址。在仅仅具有BPMS和其他应用程序之间的通信能力实在是太有限。BPM系统必须能够在应用程序*里面*运行。它应该很容易将业务流程的更新和应用程序更新结合到一个单一事务里面。从应用程序的数据的角度，它应该可以简单地访问流程实例，反之亦然。作为应用程序的一部分的运行业务流程能力大大降低了开始使用BPM技术门槛。
In summary the traditional BPM approach focusses on forward engineering from the Analysis phase. In those solutions, development and deployment are typically limited to a process-only world and limited to the self-contained tooling from the BPM vendor itself.
总之，传统的BPM方法集中在从分析阶段的前向工程。在那些解决方案里，开发和部署典型地限制在只有流程的世界，并且限制在从BPM供应商自身提供的自包含工具。
The Process Cycle Layer
流程周期层
We took the starting point that business processes are part of your applications and we looked at how people work in practice today. That gives a completely new and interesting perspective. As you are probably aware, it can be time consuming to sync business people with the IT team. A lot of meetings typically take place and the result is most likely a set of text documents. Keeping those text documents and abstract process models in sync with the actual developed software is a challenge.
我们把业务流程是应用程序的一部分当作是出发点，我们看到今天人们在实践上是如何工作的。这给了一个全新的，有趣的观点。正如你可能知道，它可以是同步业务人员和IT团队所耗费的时间。通常召开很多会议，其结果很可能是一个文本文件集。保持与实际开发的软件同步的文本文档和模型的抽象过程是一个挑战。
From our practical experience, we know that trying to automate the updating of analysis documents, processes and software in all directions just doesn't work. Some try to achieve this with round-tripping solutions. We've concluded that can only work for very specific cases and hence it doesn't fit the ubiquity that we're after. So we conclude that we have to live with distinct sets of documents. Business documents are owned by the business people, software artifacts are managed by the development team and deployed software applications are managed by the IT operations people.
从我们的实践经验来看，我们知道尝试在所有目录下自动化更新分析文档，流程和软件是行不通的。有些人用双向工程的解决方案来完成这项工作。我们已经得出结论，只有那些非常特殊的案例才能工作，所以它并不适合我们后面无处不在的案例。因此，我们得出结论，我们不得不忍受不同的文件集。业务文档由业务人员所有，软件工件由开发团队管理，已部署的软件应用程序由IT运营人员所管理。
As an indicative example to give you a more concrete feel about the actual artifacts, imagine a manager maintaining a text document with the requirements and a visio diagram of the process flow. The developer managing an executable process and a bunch of Java source files. And the IT operator to managed the .war files on a Tomcat installation and set of deployed processes in an Activiti DB.
作为一个例子来指示给你一个更具体的实际感受工件，想象一个经理保持文本文件的需求和对流程的Visio图表。开发者管理可执行流程和一大推Java源代码文件。而IT操作人员管理在Tomcat安装之上的.war文件和在Activiti数据库里的一系列已部署流程。
Instead of trying to automate artifact synchronization over team boundaries, we'll facilitate collaboration by enabling link, discussions and notifications on all artifacts managed by the different groups.
代替在团队边界上自动化工件同步，我们将通过使用链接，讨论和由不同组管理的所有工件上通知来提供协作。
Taking a step back, you can see that we'll basically apply the social web to the BPM lifecycle. The social networking features provide a more structured and persistent replacement for those volatile and closed meetings. In that whole social web experience, colleagues are all peers. On the one hand, that encourages newcomers to get involved. And on the other hand it keeps established co workers on their toes and active as they will be challenged.
退后一步，你能看见我们基本上将社交web应用到了BPM的生命周期。社交网络提供更多结构化和持久化特性替换那些易变的和封闭的会议。整个web体验，同事都是对等的。另外方面，鼓励新来人参与进来。而在另一方面，从下到上，它保持建立合作工人的联系，并当它们遭遇挑战时激活。
A tool proposal: Activiti Cycle
提议的工具：Activiti Cycle
Activiti Cycle is a web application that improves collaboration between business people and developers by linking artifacts in analysis, development and deployment of software applications. Having a link between an analysis process model in a model repository and the executable process model in the development SVN repository is crucial. And still it's possible to include helper tools for forward engineering and reverse engineering might be supplied. But it's very important that those are optional. This way Activiti Cycle facilitates the way people collaborate and it doesn't have a hard dependency on full the round trip like typical BPM products have. That is in a nutshell the core vision behind the innovative Activiti Cycle.
Activiti Cycle是一个Web应用程序，在软件应用程序的分析，开发和部署里面通过连接的工件，提高了业务人员和开发人员之间的协作。具有在模型仓库里面业务流程模型和开发SVN仓库的可执行业务流程模型是至关重要的。并且仍有可能包括也许提供的前向工程和反向工程的帮助工具。但是非常重要的是那些事可选的。这种方法Activiti Cycle给人员协作提供便利。它并没有像典型的BPM产品具有的全部双向工程的硬性依赖的缺点。简而言之，这是创新的Activiti Cycle幕后的核心愿景。
The main layout of the web application looks like this:
Web应用程序的主要布局看起来像这样：
Artifacts are stored in repositories. The artifact browser can show a range of repositories. Examples:
工件保存在仓库里。工件浏览器能够显示仓库的范围。例如：
· a network drive containing artifacts like Visio diagrams, images, word documents, spreadsheets
· 网络驱动器包含像Visio图表，图像，Word文档，电子表格之类的工件
· a business model repository like Signavio containing abstract BPMN process models
· 像Signavio那样的业务模型仓库包含抽象的BPMN流程模型
· an SVN repository containing Java source files and executable BPMN processes
· 一个SVN仓库包含Java源代码和可执行的BPMN流程
· a maven repository containing business archives
· Maven仓库包含业务档案
· Activiti instances containing a set of deployed business archive versions as artifacts
· Activiti实例包含一个作为工件的已部署的业务档案集
The application will allow to link, watch, get people involved and discuss those artifacts. Those base capabilities are provided across all repositories and all artifact types. Business analysts, developers and operators can now keep working in their own world with their own tools and organise their collaboration through Activiti Cycle.
应用程序将允许连接，观看，让人们介入并讨论那些工件。它提供跨越所有仓库和所有工件类型的基本能力。业务分析师，开发者和操作者现在能够在他们自己拥有的世界里保持工作。在这个世界里，通过Activiti Cycle，拥有自己的工具和组织他们的协作。
Activiti Cycle Example Use Case
Activiti Cycle 示例用例
In this section we'll take you through a scenario that describes how the Activiti Cycle features support the Process Cycle Layer.
本节我们将带您经历一个如何支持流程周期层的场景（Process Cycle Layer）的Activiti Cycle特性。
Business Manager John Doe starts a new initiative to create a new product: an insurance for supercars. First, a meeting takes place with management around the new product. The whiteboard picture of the meeting is stored in a network drive, along with the competitive analysis and a description of how the claims will be handled. This network drive is available in the plain OS of every employee.
业务经理John Doe启动一个新措施来建立新产品：为超级跑车保险。首先，召开了一个围绕新产品的管理会议。这次会议的白板图片存储在网络驱动器，伴有竞争分析和如何处理索赔的描述。该网络驱动器从每个员工的普通OS上获取。
In Activiti Cycle, the artifacts are now visible in the ‘Shared Files’ repository under directory /Shared Files/Products/SuperCar Insurance
在Activiti Cycle里，从目录/Shared Files/Products/SuperCar Insurance下的‘共享文件’仓库里，可以看见这些工件。
Business manager John Doe can now start to involve people. Each artifact and directory can have people associated to it. John Doe adds the business analyst Joe Smoe as a person linked to the directory. This will enable easy traceability. And if afterwards new people get involved, they will be able to read up on the whole story that will give them the necessary context and background.
现在业务经理John Doe能启动参加的人员。每个工件和目录能让人们和他关联。John Doe增加业务分析师Joe Some作为连接到目录的人。这将可轻松跟踪。如果以后新的人参与进来，他们将能够阅读整个故事，这将为他们提供必要的环境和背景了。
Business analyst Joe Smoe will then produce an abstract BPMN 2.0 process model with Activiti Modeler and it's saved in the model repository. Also the model repository is available in Activiti Cycle so Joe Smoe can then link the new process model with the directory /Shared Files/Products/SuperCar
业务分析师Joe Some然后会用Activiti建模器创建一个抽象的BPMN 2.0 流程模型并将它保存在模型仓库里面。在Activiti Cycle里面也有模型仓库，所以Joe Some然后能把新的流程模型和目录/Shared Files/Products/SuperCar连接起来。
Here's a mockup of what the tool could actually look like:
这里是工具实际上看起来像的样品：
In order to keep up to date, the business manager now decides to watch the /Shared Files/Products/SuperCar directory and the process diagram. That way, he’ll be notified of all actions and changes to those artifacts.
为了保持更新，业务经理现在决定观察/Shared Files/Products/SuperCar目录和流程图。这样，那些工件的所有动作和变化都要通知他。
Next, the developers get involved. They create a new software project in their svn repository. That repository is also mapped in Activiti Cycle. That way, the abstract business process can be linked with the executable process model. Developers can also easily trace back to the people behind the requirements. They can see the full context of the initial discussions. Eventually, when the software project is released, it becomes available in a maven repository. The application is composed of 2 parts: a web application archive (/Software Components/supercar-webapp/1.0/SuperCar.war) and a business archive (/Software Components/supercar-process/1.0/SuperCar.bar)
接下来，开发者参与进来。他们在SVN仓库里建立一个新的软件项目。那个仓库也和Activiti Cycle映射。这样，抽象的业务流程能够和可执行的业务流程相连接。开发者也能够轻松地追溯需求背后的人物。他们能够查看到初始讨论的所有上下文。最后，当软件项目发布时，它在maven仓库中变得可见。应用程序包含2部分：一个web应用程序的档案（Components/supercar-webapp/1.0/SuperCar.war）和业务档案（/Software Components/supercar-process/1.0/SuperCar.bar）。
Next, The IT operations admin can take the deployable artifacts from Activiti Cycle and deploy them to the Activiti instance and the Tomcat instance respectively. This completes the cycle because now there is traceability from the deployed artifacts in production, all the way down to the original requirements documents. And all that with links to the people involved.
接下来，IT操作管理员能够从Activiti Cycle里取出可部署的工件并将它们分别部署到Activiti实例和Tomcat实例里。因为现在产品环境下存在已部署工件的可追溯性，所以这就完成了整个周期。所有的方法下载到原始的需求文档里。并且所有那些和参与的人们相连接。
Goals
目标
Non intrusive
非侵入式
Activiti Cycle lets people work the way they work now. The tool can be introduced gradually without a big investment upfront.
Activiti Cycle让人们以现在工作的方式进行工作。工具能够被逐渐引入，而不需要预先投入巨大的投资。
Context
上下文
People that get involved into an initiative later in the game can get full context immediately without people having to explain everything in endless emails. This extra context information will turn employees into knowledge workers and let them work more effectively.
人们不必用没完没了的电子邮件来解释所有的事情，参与到游戏里面的人物立即能够得到全部的上下文。这个额外的上下文信息将员工转变为知识工人并让他们工作更加有效。
Governance
治理
Since all artifacts from business documents over analysis to production deployment are linked, a very high level of traceability is obtained. Which process is deployed on which system? Who was involved in the requirements for that process? and so on.
因为所有来自于产品部署的分析的业务文档的工件是连接的，所以可以获取一个非常高级的可追溯性。那个流程部署到哪个系统？谁参与那个流程的需求？等等。
Social BPM
社交BPM
Create communities around company initiatives. Social BPM ensures that everyone remains engaged. Building communities requires that people expose themselves vulnerable. It's normal that people make mistakes. That can be a challenge to accept for people that have since long been used to their ivory tower. Inside an organization, the social aspect of Activiti Cycle will encourage both established and new members to share knowledge and work more effectively.
建立围绕公司倡议的社区。社交BPM确保每个人都能参与。构建社区需要人们暴露他们自己的脆弱。每个人都会犯错误，这很正常。接收那些长期习惯于象牙塔的人们是一个挑战。在一个组织里面，Activiti Cycle的社交方面将鼓励已有联系的人员和新成员共享知识并且更加有效地工作。
Realistic BPM
现实BPM
Traditional solutions focus on the business users and then try to avoid relying on IT with automagical transformations. Instead Activiti Cycle facilitates the collaboration between business people and IT in a way that fits with how they work in practice.
传统的解决方案侧重业务用户，而尝试采用automagical变换避免依赖IT。相反，Activiti Cycle以一个实践上适合他们工作的方式加强了业务人员和IT人员的合作。
Broad coverage
覆盖面广
Activiti Cycle is an overview tool. It doesn’t allow detailed operations on all artifacts. Instead if focuses on the overall picture. This means that all aspects of business related content, software development and software deployment need to be taken into account.
Activiti Cycle 是一个概观工具。它并不允许对所有的工件进行详细操作。相反它着眼于大局。这意味着所有与内容相关的业务方面，需要考虑软件开发和软件部署。