Activiti Cycle Roadmap 2010
With the Activiti beta1 release, we included the first version of Activiti Cycle, the tool which tries to help you in your BPM, process and/or software implementation project. I already gave a first preview in Activiti Cycle explained, for which we got quite some positive feedback. Today I want to sketch the planned roadmap of Activiti Cycle for the next months, basically till the release in December (called Activiti 5.0). I try to do this in a longer post with a couple of screen mockups, to make it as concrete as possible. This should help everybody to get the idea, in which direction we are currently heading. Feedback based on this is very welcome, since I go to vacation for two weeks on Friday, you have some time to think about it 🙂
In the first two paragraphs I want to give you the big picture of BPM projects. I think that may help you to understand the context and get a better idea which role uses Cycle in which way, which influences the features as well. If you find that boring feel free to jump to the third paragraph, where I dive into the real interesting details 🙂
BPM projects – The context for cycle
- Project Initiation: A new project is initiated, which means a project vision is formed and communicated via Power-Point slides, some project order may be written, a ROI calculation is done and often a first process is sketched. Possibly this is still on a very high level without too much details, since the goal is just to make the scope or/and the content of the project clear. At the end of this phase a decision is made, whether (and when) the project is started or if it is deferred or declined.
- Implementation and Roll out: The process is now really implemented. We currently look at BPM projects involving process automation and software development. In this phase a detailed BPMN model is done, an executable version is derived, all technical details are added, maybe additional software components programmed. Despite the synchronization of the different process models this phase requires Requirements engineering and project status tracking. When the process is implemented, tested and approved, it will be rolled out into production use.
- Operation: When the process is running in production, somebody has to monitor it, recognize problems, solve problems, analyze reports, find weaknesses and so on. This very important phase is often underestimated and forgotten by tool vendors. The results of this phase may be input for follow-up BPM projects.
In the picture you can see these phases mapped to the process life-cycle. I think every consulting company has such a process life-cycle (in the picture you see ours, done in BPMN) and it is always some kind of PDCA cycle:
- Plan (Initialization)
- Do (Implementation)
- Check (during Operations)
- Act (next project)
The people in our project – RolesThe picture on the left shows the roles we defined for typical BPM projects. Of course, this may be different in your project or some roles may be the same guy. Actually that doesn’t matter that much, it just helped us to define which group we target with cycle (at the current stage) and what features they may need.
The key roles we see in BPM projects are (surprise surprise): The process analyst (often called business analyst) and the process engineer, his counter part on the IT side. We somehow skip the architect for the moment, since we experience big difference with that role in different companies.
Why do I tell you all that? Because this leads us to the use cases and features of Activiti Cycle:
Basic Functionality of CycleThere is one aspect of Cycle, which is really important as it has a big influence on everything from now on: We don’t believe that there is ONE project approach. We think, it is different in every company, department or even project. This is why we don’t want to enforce a specific approach with Cycle, in contrast we see Cycle as basis on which you can work in the way you want.
This means, that Cycle has a lot of generic capabilities, not tied to a phase, action or even specific role. This generic basis makes Cycle a very flexible and powerful toolbox. On the other hand from these generic features the idea behind Cycle is sometimes hard to understand. I now try to show you some of the generic basics before we dive into more specific stuff.As you can see on the use case diagram, the basic features center around browsing, finding and managing folders and artifacts (we generally refer to both as nodes). But which folders and artifacts are shown? Cycle is not a repository on its own (even if it has some own database to store stuff) but combines existing repositories. Repositories may be all sources of data, like a file system for files, the Signavio or Activiti Modeler for process models, Source Control Systems for source code, JIRA for Issues, Mail Servers for Emails, Wikis for documentation and so on. Technically you can hook in everything if either a connector is already available or you build your own connector as a plugin. The screenshot on the left shows how different repositories are shown in the tree of Cycle, this was by the way already shown in Activiti Cycle explained.
Watching nodes now is a first interesting feature. As soon as you watch it, you are notified of any changes on this node. In case of a folder in the file system you can be for example notified of any new, modified or deleted files in that folder (can your network drive do this for you?). For BPMN models you may want to be notified of any change made on the model. Cool, isn’t it?
But even more interesting is linking and tagging, so let’s look at that next:Tagging is a help for you to keep the overview even in big Cycle installations with a lot of repositories and folders. Normally you don’t need the huge tree, but only a small subset corresponding to your current project or maybe task, like “show me all models for review” or even “show me all models tagged for review from me”. In the attached mockups you see what this could look like. Actually these mockups are just used for requirements specification so I made them quickly with Power-Point, so don’t blame the poor graphics 😉 A more sophisticated feature is linking of artifacts. The purpose of links is to keep track of a connection between two artifacts. You want to know for example, that a special XML file is the derived BPMN 2.0 XML from a BPMN model in Signavio. This allows to notify the process analyst watching the BPMN about changes in the linked technical model (if he likes to know that). On the right you see the mockup how links can look like.
Remember: Links can be used or anything you want, so it is up to your imagination what you use them for! Even if we have BPM projects in mind, I think you can do a lot with these features. At one customer I saw a software asset management system, where you define some responsibilities for the asset (these are additional properties for an artifact, we can save in the Cycle database as well), link the software assets to related bugs (bug tracker would be an own repository), running projects (project management tool would be a repository) and results from the continuous integration server (would be an own repository as well). Unfortunately I cannot post the screenshot here…In order to have your own views on the data we now add a plugin concept for special pages aggregating information. I would not call it reporting (which by the way is in the backlog), but simple pages showing stuff from Cycle. You can see one example on the left, where we want to show the different versions of one logical business process on one process overview page. This can be easily derived by following the links from the BPMN model.
Even if that was not too detailed, I hope you could already get an idea what we tackle with Activiti Cycle? Because somehow I get the feeling I have already written a much too long post nobody reads 😉 So I will go on with something really interesting: Linking on specific elements in a process (and not to the process as a whole artifact). I want to show you this to you with the example of JIRA-Integration.
Linking to elements in the process and JIRA Integration
JIRA is a popular issue tracking system. With Green Hopper it has a plugin which makes it really useful for agile projects as well. In BPM projects we face the situation, that most issues center somehow around the process model, so using Cycle, the BPMN modeler and JIRA together seems like a good tooling approach 🙂 One short remark: The JIRA-Plugin I will describe now is currently not part of the Cycle Open Source project, due to licensing issues. We plan to make it available like JIRA: Free for open source projects but requiring a commercial license for all the the others.One of the ideas we have in mind is to link JIRA issues to elements in the BPMN process. This could be a user story to a task/activity, some GUI requirement to a User Task or maybe even non functional requirements to the process level. The mockup shows, how we want to link a JIRA issue from within the Signavio (or Activiti) modeler. The link is stored normally in cycle an can be interpreted by Cycle, but it is hooked into the modeler nicely. The second mockup shows how we could even create issues from there, a use case we face pretty often. Once the link is created, we can use it for various purposes. First you can see the link to the process model in the JIRA issue (or maybe even other artifacts. Remember: Everything we do is generic, so as soon as we have the JIRA-Plugin to show Cycle links, we can link everything Cylce knows). We currently hook that in as own JIRA tab as you can see in the mockup. An interesting use case now becoming possible is that you can show the status of linked issues in the process model as indicated in the mockup. Isn’t that just cool? In recent projects we already had the process models printed and marked manually for this status information, now you can see that online next to your greenhopper task board or burn down chart!
I want to mention here, that we can save additional properties to artifacts or elements in Cycle as well. So even if you don’t use JIRA, you may define a property “finished”, so you can manually set the status of implementation for a task in a process model. This could be visualized in the same way as we do for the JIRA issues, so once again you have a bunch of options.And that is actually not the end of the road. As a process engineer you need to know the context of the process to understand an issue. So it is very handy to see that easily within the JIRA issue page, so you don’t have to follow a link first. The mockup shows how this can be achieved. Unfortunately due to current technical restrictions this doesn’t work in the Internet Explorer. But hey, isn’t that feature just worth changing the browser? 😉 But together with the commercial Signavio Modeler (the big brother of the Activiti Modeler) we could improve that to work with the IE as well, but we currently don’t have a customer who needs it, so it is somewhere down the backlog.
I am sure the JIRA Plugin will rock! After optimizing the JIRA and Greenhopper configuration we got very productive with this tooling and it perfectly supports agile development. And the integration I just sketched brings BPM to this world, the result is a tooling now really supporting Agile BPM!
Okay, now we had a look at the generic basics of cycle and requirements management with JIRA. But what can Cycle do for pure development? I just want to give you two concrete examples here, even if I have tons of ideas what we could hook into cycle here. And the cool thing is, everything can be plugged in! Just throw the plugin (as a jar) into the right location and it is automatically recognized, that’s it!The first example is how we can create the technical process model from the business repository. I have blogged about why we want a separate model lately (Why you may want a Mapping in your BPMN roundtrip). One of the main reasons is, that for development we need the process in the workspace of the process engineer, which is not the Process Modeler but his local Eclipse or whatever tool he uses. The model there is versioned in the source control system like SVN instead of the Signavio repository. The Engineer can add all technical details and even test it locally in his environment (at least with engines like Activiti or jBPM). While creating that technical model, we can even introduce some transformations or enrichments (like I gave an example in Activiti Cycle explained). I described the process in more detail already a couple of months ago (Making the BPMN Roundtrip real). You may have guessed it already: In the background while creating that technical model a link is added in the Cycle database, so we remember afterwards which technical process was created from which business process model in which version. The second example I want to sketch is a real life use case from a current customer. There, process execution is done with jBPM 3, a process engine which doesn’t understand BPMN but an own proprietary format. There, we do a whole transformation step from BPMN to so called jPDL (jBPM process definition language) on the fly when creating the technical process model. On the left you can see that the plugin we wrote even adds an own representation showing the jPDL source code of a process model existing in the Modeler or possible validation errors (we currently work on showing them graphically, stay tuned!). On the right you see a part of the table showing the used mapping from BPMN to jPDL.
But the really cool thing is what we do with that basic functionality: We hook in an action which creates a complete basic technical project for the developer. Sorry to get technical now, but I want to be specific on this one 🙂 So what we do is to create a Maven multi-module project with all stuff required to get that process running in the SOA platform of the company. This includes a Maven project for Java code, one for the process itself, one for an ESB service required to talk to the process and so on. Everything is wired together correctly and the resulting project is created in a specified SVN location. The developer just needs to check it out and can immediately start coding. The plan is to avoid the hazzle not knowing how to start, because we all know that the hardest is to get the initial set-up to work and how much easier it is to start out with a working examples. This solution remedies both 🙂
Dates and deadlines
So these are the things we (as camunda and core Activiti Team members) are currently working on. This blog post is named “Activiti Cycle Roadmap 2010”, and this is what it should really be. We plan to implement everything mentioned here this year! And we even have a backlog for 2011 ready 😉
The deadlines are set by the Activiti versions, that gives a release every month. The Activiti 5.0 GA is currently planned for December 1st. To be honest, that will get pretty tough on our side. With the JIRA Plugin we have at least one component decoupled from the Activiti releases, so hopefully the rest will make it into that version. If not, at least in version 5.1 on January 1st 2011. And actually that matches pretty well with the plans of our pilot customers! But maybe I better stop blogging now and get back to work to help our great team to make it happen 🙂