We finished the camunda community day with an update from camunda on features coming in 7.2 next month, and the future roadmap. camunda releases the community edition in advance of the commercial edition; this is the way that open source should work, but some commercial open source vendors switch that around so that the community version lags by as much as a full version.
The highlights of the 7.2 release are as follows:
CMMN-based case management engine, which includes the core activities (stages, human tasks, process tasks, case tasks, milestones and sentries), the base case instance and plan item lifecycle, and a CMMN model API and REST API on a common process engine. They demonstrated a basic case manager UI that can manage cases and the related tasks; I assume that this is really just a demo of what can be done rather than intended as production code. They also don’t have case modeling in their modeler yet, so it’s early times.
New tasklist, updating the tasklist UI that they released just before announcing camunda as an open source project. It allows filters to be defined, including specifying who can see the results of a filter in addition to the search criteria; that filter then appears as a tab on the task list, in the color defined by the filter author. The sort order can’t currently be defined as part of the filter, but can be set on the general tasklist interface. This adds a third (left) column to the tasklist UI, which also shows the list of tasks and the form for the selected task. Still work to be done, but the new filters capability is a big step up, providing a conceptually similar (but much different graphically) functionality to the Brazos portal filters.
There were a list of other smaller enhancements and fixes, from platform support to performance improvements to new functions.
Another lab project is the camunda BPM workbench, a debugging tool that allows inspection of the runtime state of processes alongside the process model, allowing breakpoints to be set in the process model (rather than in code). A console interface allows for interrogation and updating of the process variables as the developer steps through the process. The process model is displayed using the bpmn.io viewer.
At the end of all the roadmap sessions, the audience had a chance to say what was most important for them in terms of what will be implemented when; there were questions about case management, centralized model repositories, bulk runtime operations and other features.
A great half-day; this is the first time that I’ve attended an open source code community day, and it’s quite a different environment from a typical vendor conference. We’re about to enter the beer-drinking portion of the day so I will sign off for today; I’m giving the keynote at the main camunda user conference tomorrow morning, and not sure how much blogging that I’ll do during after that.
Disclaimer: camunda paid my travel expenses to be here today and tomorrow, and is providing a speaking fee for tomorrow’s keynote. I was not compensated for blogging, and the opinions here (and in my keynote) are my own.
The second customer speaker at camunda’s community day was Peter Hachenberger from 1&1 Internet, describing how they use Signavio and camunda BPM to create their Process Platform, which is in turn used by their clients’ developers for building and executing automated processes. His presentation was primarily about the details of their technical implementation of the platform; they have built some fairly comprehensive tools for monitoring and managing executing processes, many of which are facilitated by changes that they made to the core process engine, including retry behavior, process ID generator, multiple business keys, an asynchronous process starter API, an extended REST API and a few new commands. Since camunda BPM is open source, any customer such as 1&1 can take a copy of the code and make changes to it, optionally returning them to the community if they are valuable to others. There’s a bit of danger in this, in that if you make changes to core functionality (such as the engine) rather than create an extension or plug-in, and those changes do not end up back in the community version, you’re not only on your own for future development on those components but may not be able to upgrade to future versions.
We had a number of short (10 minute) presentations from community members to discuss extensions that they are working on:
Grails plugin to add camunda functionality to Grails applications
OSGi module extension for greater flexibility and configurability at runtime, including sharing process engines as services
Elasticsearch extension to write camunda BPM history data to an elasticsearch cluster to allow full-text searching, enabling more comprehensive analytics
camunda mocking extensions for process testing with mockito
Cockpit plugin to add interactive graphs and some statistical calculations (e.g., aggregation, regression, min/max) for process monitoring directly on the camunda history database
Some of these extension projects were done by camunda employees, but great to see the external community contributions as well.
I am giving the keynote at camunda’s BPMcon conference tomorrow, and since I arrived in Berlin a couple of days early, camunda invited me to attend their community day today, which is the open source community meeting. Nice to see such a great turnout — 70 or 80 people? — and I definitely wasn’t the one to travel the furthest to get here, since today’s opening presentation is from Rob Parker of Australia Post. Australia has a lot of the same issues as Canada when it comes to nation-wide services such as post, since we both have a lot of geography and not a lot of population: this means that a lot of services have to be delivered at a fiscal loss to sparsely-populated areas, with specific rules about what percentage of the population has to be within a certain distance of a postal outlet.
Post offices in particular are hard-hit by digital disruption; Australia Post has seen their letter delivery service decline by 1 billion articles (and the related revenue), even though the number of addresses to cover has increased. However, they have seen their parcel delivery business increase, even though this is a competitive business with courier companies. They’re also offering a number of other products, such as electronic bill payment, digital mail delivery and even passport interviews, which has driven them to create a more integrated multi-channel/multi-product architecture to be able to quickly bring new products to market. They’re using camunda BPM for their order management processses, both for customer orders and service fulfillment orders. Customer order processes support the various customer channels, then drive out one or more service order processes to fulfill a customer order.
They decided to use BPM in order to externalize processes from applications, making for more agile development and better reusability. They picked camunda because they wanted “just enough technology”: that is, they wanted to add process management to their existing Java application development environment, not rewrite all of their apps in a proprietary, monolithic BPMS app dev environment. camunda BPM is used to implement the multiple service order processes that might be kicked off by any given customer order, with their overall architecture handling the communication between the two order management layers: the customer order layer as a consumer for the service order layer producer.
Parker went into a lot of detail of how they have implemented this architecture, putting their BPM usage into the context of their overall technical architecture, and walked through the general process model for their service order that instantiates a dispatcher process for each customer order, which in turn instantiates a subprocess for each line item in the order. They really want to implement all of this in camunda, but are still using TIBCO for the dispatching process while they work out some of the sticky bits such as how subprocess cancelations are propagated to the parent process. They are also having some challenges with handling process versions, considering that they run 7×24: they need a mapping table that takes these temporal anomalies into consideration, so that the process version in use may be tied to the order date for longer-running order processes. They also created a business dashboard by modifying Cockpit, the camunda IT operations dashboard, to remove all of the “dangerous” operations while exposing the work in progress, and adding some additional functions such as searching by a business key.
Parker ended up with their outcomes, some expected, some less so: basically, BPMN 2.0 is really working for them both for business-IT collaboration and model-driven development; this level of business-IT alignment means that error handling can be shared, with business handling business errors, and IT handling IT errors. They found that developers became productive very quickly since they were just adding some tools to their existing familiar Java application development environment, although some had to be gently reminded to use the BPM capabilities instead of writing code.
It was great to see the reactions and interactions of the camunda team during the presentation: Australia Post is a “do-it-themselves” open source user of camunda, and as Parker discussed some of the shortcomings, they were obviously taking some notes for future work. The presentation finished with him being presented as an award for the non-camunda person who contributed most to the community forum discussions, suggesting that you get out of open source what you put into it.
James Taylor of Decision Management Solutions and I are doing some research into the use and integration of BPM (business process management) and DM (decision management) technology into mobile applications, as background for co-authoring a white paper. For this study we are focused on the mobile applications that you use to interact with businesses (as a consumer), government (as a constituent) or your employer (as an employee), NOT games or personal productivity tools.
As part of this research, we are doing a short survey on the use, development and support of mobile applications; please help us out by taking the survey:
The first few questions are about your own use of mobile applications. If you are involved with the development of mobile applications, there are a few additional questions. It should take no more than 5-10 minutes to complete.
Last week BP3 announced the latest addition to their Brazos line of UI tooling for IBM BPM: Brazos Portal. Scott Francis gave me a briefing a few days before the announcement, and he had Ivan Kornienko, their director of UI/UX, along to give a demo.
As a recap, BP3 is a boutique-sized IBM BPM services and ISV partner, made of up a large contingent of ex-Lombardians (Lombardiites?) who know the IBM BPM product as well or better than any other partner out there. In addition to implementation services, they offer a free UI toolkit that allows you to easily build responsible HTML interfaces for IBM BPM applications that can support both mobile and desktop browsers. They sell the services and support around the Brazos UI Toolkit, but give it away to encourage adoption. This seems to be working: as of the end of May, they had more than 400 registered developers who had downloaded the toolkit and about 40 production deployments.
However, like that tendency to start redecorating your whole house once those new curtains make you realize how outdated everything else is, customers using applications built with the Brazos UI Toolkit wanted a more responsive and modern portal interface than the out-of-the-box IBM portal. After all, the portal is where many BPM users start and organize their day, only launching the applications once they’ve identified a specific item that they want to work on. According to BP3, the IBM BPM portal, in addition to not being optimized for modern browsers or mobile devices, has some performance issues due to server-side searching, sorting and filtering; it’s also difficult to customize and can be brittle once customized.
BP3’s answer to this is the Brazos Portal: responsive and mobile-ready, customizable, and with local search, sort, filter and task display for optimal performance. Although Brazos Portal is being positioned as a mobile portal – I suspect that BP3 doesn’t want to explicitly position against IBM’s own desktop portal – it appeared to be completely usable as a desktop portal as well, with the added benefit of a unified experience across all platforms. However, the two portals can coexist peacefully on the same process data, allowing for only certain users or devices to be on Brazos while the others are on IBM.
I’m getting to the part about the ring, really.
We started the demo with a sleek-looking but fairly standard view of an unfiltered user task list, showing a few metadata columns (task name, class, due date), with displays at the top showing aggregate information for work in progress, complete and due/overdue tasks. Clicking on an item in the task list opens the task application screen for processing the task (a Coach, in the IBM BPM terminology); in the demo, this opened an application written using the Brazos UI Toolkit although I’m not sure that’s a requirement [Scott, feel free to chime in here]. Clicking on a column in the task list sorts by that column, as expected; this is fast since it is done locally rather than requiring a re-query of the BPM server as (I think) the IBM portal does. It’s all in monochromatic greys and black, except for thin bars of color on the left of each item in the task list.
It’s also responsive: we were viewing it in a desktop browser, and when the browser was resized to the size of a tablet or mobile phone, the portal responded appropriately.
Then there’s the ring.
At the top right of the portal is a circular graphical element, with the BP3 logo in the center, that I initially just gloss over as window dressing. However, in the same block, there are some small controls to the right of it, a count of the cases and tasks in the current list, and a search field. This ring interface, or “Task Drive”, is actually a metadata filter control, positioned at the top right so that it’s right under where your right thumb would be on a touch-enabled screen, and the search field combines with the filtering selected on the ring. The appearance of the Task Drive changes as you interact with the portal to show you information about what is currently displayed, and how it breaks down by metadata. In our unfiltered list, for example, we had 44 cases and tasks, but hovering over one of the sectors in the ring showed us the corresponding metadata field that would be filtered and the resulting number of cases and tasks. Selecting a segment of the ring filtered the list to just those in the class “Client On-Boarding”, which had 14 cases and tasks. There are actually concentric rings in the Task Drive control, giving us a visual indicator of the potential filters; we had initially filtered based on the work class, and could then filter further by task name. We could also filter via a free-form search on any task metadata by entering text in the search field beside the ring.
Things start to get colorful with groups, which are pre-defined filters: you define a view of up to three columns with filter criteria, using any metadata including custom fields defined on a work class as well as standard fields like due date and priority. This creates a new group in the task list, which is assigned a unique color, showing those tasks that meet the filtering criteria. Those that don’t meet the filter criteria are still in the black and grey “Unfiltered” list. Presumably, items can appear in more than one group if they meet the criteria, so the counts of the items in each group may be more than the overall count; only those that do not meet any of the groups’ criteria remain in the Unfiltered list.
Once you define groups, the Task Drive becomes equally colorful: the ring is now in sectors by color, with concentric rings indicating the metadata filtering/drilldowns for each group. We looked at an example that had four groups defined: High Priority Claims, Client On-Boarding, Other Claims, and New Coverage Branch, appearing as orange, red, green and purple (actually more like lavender). Each group’s list could be collapsed into a single title bar showing only the group name and item count, or expanded to show all items within it. Hovering over the green ring segment showed us that that corresponded to Other Claims, and had 6 cases and tasks. Clicking on the purple segment drilled into the New Coverage Branch group directly, then hovering over segments of the now-purple ring showed us the breakdown of items by task name.
The graph displays in the upper left of the portal actually contain live controls as well: the center one is a date control that cycles between today, days, weeks and months for filtering the other content in this navigation header including the Task Drive. Checking the “show complete” control to the right of the Task Drive also makes the Complete graph at the top left interactive.
After the briefing with a live demo, I played around with the online demo version; one interesting feature (bug?) is that on my touch-screen Lenovo Yoga Windows 8 laptop, I could only get the ring to respond to the touch screen, not to the mouse control, although everything else worked fine with either.
The ring – sorry, Task Drive – is an extremely clever and beautiful piece of UI. However, I’m concerned about its usability by more traditional users, since it may not be as intuitive as the designers hope. Having the ability to pre-define groups for users (which is planned for the paid versions) will help sort out some of the confusion for users, but many may ignore the ring as if it were a graphical element, and just scroll through the lists in the groups rather than using the metadata filtering. BP3 reported that they had had very good reception of this as a filtering control, but their test group is likely skewed towards mobile users and the inherent selection bias; if they expect this to be used on the desktop as well, or by more traditional remote workers whose paper clipboard is replaced with a tablet, then they need to understand the learning curve behind that control.
Brazos Portal supports IBM BPM 8.0.1 and forward. It does not yet expose the new case management features in the 8.5 release, but that will probably show up in a future release. They have a fairly ambitious list of potential future features, and will likely develop these according to demand, so if you try out Brazos Portal and find something missing, be sure to give your feedback to BP3.
Brazos Portal is available in both free and paid versions, with the free version having launched last week. The free version has no active support, but BP3 will likely help out if they can in order to spur adoption, and would probably be happy to sell you some services to get you up and running. The premium version will include standard support and SLAs, plus features for pre-defined/shared user groups, custom branding and API incorporation; the enterprise version will include a support agreement customized to the organization, plus custom integration and cross-platform federation to allow multiple BPM servers to be integrated into a single portal.
I recently wrote a paper on BPM in healthcare for Siemens Medical Systems: it was interesting to see the uses of both structured processes and case management in this context. You can download it from their website (registration required) here.
I gave a webinar today sponsored by camunda on developer-friendly BPM, discussing the myth of zero-code BPM. I covered the different paradigms of BPM development, that is, fully model-driven versus process models and code, with some pointers for how to evaluate the different approaches within your organization – it’s not a simple one-size-fits-all decision for most large companies with complex application development needs.
I also wrote a white paper on the topic, it will be posted on the camunda site soon, as well as a link to a replay of the webinar.
Update: the webinar replay is here and the white paper is here. Registration on the camunda site required for both.
The day 2 keynotes at PegaWORLD 2014 wrapped up with Vik Sohoni of McKinsey, who talked about becoming a digital enterprise, and the seven habits that they observe in successful digital enterprises:
Be unreasonably aspirational
Acquire new capabilities
Ring fence and cultivate talent
Be quick & data driven
Follow the money
Be obsessed with the customer
Some good points, but what is also interesting is the presence of McKinsey on the stage at all: Pega is increasingly attempting to align themselves with management consulting firms further up the customer food chain rather than just technical implementation. Pega’s role is becoming more of a consultant than an implementation partner to customers, leaving implementation to the partner network so as to not limit their growth. However, my sense from what I’ve seen and conversations that I’ve had with partners and customers here is that Pega implementations are still non-trivial technical efforts, and the partner channel has a wide variability in capabilities, meaning that Pega is unlikely to step completely out of implementation consulting if they want to guarantee success.
Jeffrey Kuhn, EVP of client service delivery at BNY Mellon, spoke in the morning keynote at PegaWORLD about the journey over the 230-year history of the bank towards improved customer focus. They’ve done this through a Lean/Six Sigma type of continuous process improvement (CPI) initiative: improving their processes to impact quality and efficiency, while reducing risk and improving the customer experience. But they didn’t want to just take orders and process orders faster: instead, they automate the routine work, and enable their workers to manage exceptions effectively. They’re not a retail bank, so their customers are not consumers: the customers are institutional and government investors, meaning that each customer is very high-value.
BNY Mellon has weathered recessions, depressions and financial melt-downs over the decades, but Kuhn sees the current climate as being particularly difficult: low interest rates, higher regulatory complexity and costs, and foreign investment markets that have not rebounded as much as expected. He doesn’t see this as a temporary state, however, but the new normal; they have been working to lower costs by consolidating, streamlining and automating operations in order to remain competitive, and are using Pega for much of that continuous process improvement.
Automating the routine work is only part of it, however: they also need to deal with the exceptions and the inbound customer inquiries that can’t be automated, but can be made more digital so that they can be tracked and shared. They are implementing a single inquiry platform with the goal of improving service levels, service quality and client satisfaction, which requires capturing all of the inquiries as they arrive — by paper, email and other forms — and routing them to the right team for resolution. There’s certainly a strong element of old-school imaging and workflow in this solution (begging the question why they haven’t done this decades ago), but appears to also have more modern elements of user experience, decisioning and analytics.
At the heart of this, it’s not an amazing technology story — they’ve automated straight-through processes, then implemented the less predictable processes in a BPM/case management environment — but it’s a good process improvement and change management story for how a very old organization can transform itself by embracing continuous process improvement and developing best practices. They have a two-tier model for their CPI teams that allow the best practices to flow through a centralized team to more distributed teams, allowing the distributed teams to adapt the best practices for their particular areas. More importantly, they have a company-wide shift in focus to continuous improvement: in Kuhn’s words, delighting their customers by doing what they’re good at.