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 是一個概觀工具。它并不允許對所有的工件進行詳細操作。相反它著眼于大局。這意味著所有與內容相關的業務方面，需要考慮軟件開發和軟件部署。