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.
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.
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.
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.
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.
Traditional pure-play BPM vendors have 2 major problems:
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.
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.
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.
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.
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.
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.
The main layout of the web application looks like this:
Artifacts are stored in repositories. The artifact browser can show a range of repositories. Examples:
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.
In this section we'll take you through a scenario that describes how the Activiti Cycle features support the Process Cycle Layer.
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.
In Activiti Cycle, the artifacts are now visible in the ‘Shared Files’ repository under directory /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.
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
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.
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)
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.
Activiti Cycle lets people work the way they work now. The tool can be introduced gradually without a big investment upfront.
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.
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.
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.
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.
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.