Following the opening keynote at Building Business Capability, I attended the session about Elevations Credit Union’s journey to process excellence. Rather than a formal presentation, this was done as a sit-down discussion with Carla Wolfe, senior business analyst at Elevations CU being interviewed by Mihnea Galateanu, Chief Storyteller for Blueworks Live at IBM. Elevations obviously has a pretty interesting culture, because they publicly state – on their Facebook page, no less – that achieving the Malcolm Baldrige National Quality Award is their big hairy audacious goal (BHAG). To get there, they first had to get their process house in order.

They had a lot of confusion about what business processes even are, and how to discover the business processes that they had and wanted to improve. They used the AQPC framework as a starting point, and went out to all of their business areas to see who “Got Process?”. As they found out, about 80% didn’t have any idea of their business processes, and certainly didn’t have them documented or managed in any coherent manner. As they went through process discovery, they pushed towards “enterprise process maps”: namely, their end-to-end processes, or value streams.

Elevations is a relatively small company, only 260 employees; they went from having 60 people involved in process management (which is an amazingly high percentage to begin with) to a “much higher” number now. By publicly stating the Baldridge award – which is essentially about business process quality – as a BHAG, they couldn’t back away from this; this was a key motivator that kept people involved in the process improvement efforts. As they started to look at how processes needed to work, there was a lot of pain, particularly as they looked as some of the seriously broken processes (like when the marketing department created a promotion using a coupon to bring in new customers, but didn’t inform operations about the expected bump of new business, nor tell the front line tellers how to redeem the coupons). Even processes that are perceived as being dead simple – such as cashing a $100 bill at a branch – ended up involving many more steps and people that anyone had anticipated.

What I found particularly interesting about their experience was how they really made this about business processes (using value stream terminology, but processes nonetheless), so that everything that they looked at had to relate to a value stream. “Processes are the keys to the kingdom”, said Wolfe, when asked why they focused on process rather than, for example, customers. As she pointed out, if you get your processes in order, everything else falls into place. Awesome.

It was a major shift in thinking for people to see how they fit into these processes, and how they supported the overall value stream. Since most people (not just those at Elevations) just think about their own silo, and don’t think beyond their immediate process neighbors. Now, they think about process first, transforming the entire organization into process thinking mode. As they document their processes (using, in part, a Six Sigma SIPOC movel), they add a picture of the process owner to each of the processes or major subprocesses, which really drives home the concept of process ownerships. I should point out that most of the pictures that she showed of this was of paper flow diagrams pasted on walls; although they are a Blueworks Live customer, the focus here was really on their process discovery and management. She did, however, talk about the limitations of paper-based process maps (repository management, collaboration, ease of use), and how they used Blueworks Live once they had stabilized their enterprise process maps in order to allow better collaboration around the process details. By developing the SIPOCs of the end-to-end processes first on paper, they then recreated those in Blueworks Live to serve as a framework for collaboration, and anyone creating a new process had to link it to one of those existing value streams.

It’s important to realize that this was about documenting and managing manual processes, not implementing them in an automated fashion using a BPMS execution engine. Process improvement isn’t (necessarily) about technology, as they have proved, although the the process discovery uses a technology tool, and the processes include steps that interact with their core enterprise systems. Fundamentally, these are manual processes that include system interaction. Which means, of course, that there may be a whole new level of improvement that they could consider by adding some process automation to link together their systems and possibly automate some manual steps, plus automate some of the metrics and controls.

So where are they in achieving their BHAG? One year after launching their process improvement initiative, they won the Timberline level of the Colorado Performance Excellence (CPEx) Award, and continue to have their sights set on the Baldridge in the long term. Big, hairy and audacious, indeed.

Mark Cotgrove and Clark Swain from Nimbus Partners presented in a breakout session on Nimbus and how it fits into the bigger TIBCO picture, as an expansion of the short presentation we saw from Cotgrove at the analyst session yesterday. To sum up the message from yesterday, Nimbus Control provides an essential bit of business-driven process discovery functionality that isn’t really covered in TIBCO’s AMX/BPM offering, but more importantly, the ability to create intelligent operations manuals that can then interact with AMX/BPM in a variety of ways.

Nimbus Control doesn’t do process automation: they do process and procedural documentation that can also be linked to supporting documentation and other content required to perform a manual process. Some of the manual steps may be to interact with systems in specific ways, such as entering an order on an ERP system; others may be to perform purely manual tasks such as having a customer sign a paper document. There are a few competitors in this space, such as BusinessGenetics and Business Optix (formerly ProcessMaster), and there is some overlap with BPA tools such as ARIS and Blueprint in terms of the process discovery side, but not the end-user procedural help.

Swain started on a demo, but due to the late session start (apparently the keynote went way overtime), I had to leave for another meeting, and will have to see a more detailed demo some other time.

Tom Laffey, EVP of products and technology, moderated a session highlighting three of TIBCO’s recent acquisitions: OpenSpirit, Loyalty Lab and Nimbus.

Clay Harter, CTO of OpenSpirit (which was acquired by TIBCO a year ago), discussed their focus on delivering data and integration applications to the oil and gas industry. Their runtime framework provided a canonical data model over a heterogeneous set of data stores, and their desktop applications integrated with spatial data products such as ESRI’s ArcGIS and Schlumberger’s remote sensing. Due to their knowledge of the specialized data sources, they have a huge penetration into 330+ oil companies and relationships into industry-specific ISVs. In October, they will release a BusinessWorks plugin for OpenSpirit to make oil and gas technical data available through the TIBCO ESB. They are also prototyping a Spotfire extension for OpenSpirit for visualizing and analyzing this data, which is pretty cool – I worked as a field engineer in oil and gas in the early 80’s, and the sensing and visualization of data was a whole different ball game then, mostly black magic. OpenSpirit’s focus is on reducing exploration costs and increasing safely through better analysis of the petrotechnical data, particularly through interdisciplinary collaboration. From TIBCO’s standpoint, they were building their energy vertical, and the acquisition of OpenSpirit brings them expertise and credibility in that domain.

Keith Rose, formerly president of Loyalty Lab and now leading the sales efforts in that area since their acquisition by TIBCO, presented on their event-driven view of managing customer loyalty, particularly loyalty programs such as those used by airlines and retailers. They have a suite of products that support marketers in terms of visualizing and analyzing loyalty-related data, and building loyalty programs that can leverage that information. Their focus on events – the core of real-time and one-to-one loyalty marketing programs – was likely the big reason for the TIBCO acquisition, since TIBCO’s event and messaging infrastructure seems like a natural fit to feed into Loyalty Lab’s analysis and programs. Spotfire for visualization and analysis of data also makes a lot of sense here, if they can work out how to integrate that with their existing offerings. With 99% of their customers on a hosted cloud solution, they may also want to consider how a move to TIBCO’s cloud platform can benefit them and integrate with other initiatives that their customers may have.

Less than a month ago, Nimbus was acquired by TIBCO, and Mark Cotgrove, a founder and EVP, gave us a briefing on their product and why it made sense for TIBCO to acquire them. Nimbus provides tools for process discovery and analysis, including the 80% (or so) of an organization’s activities that are manual and are likely to remain manual. Currently, the automated activities are handled with enterprise applications and automated BPM (such as AMX/BPM), but the manual ones are managed with a mix of office productivity software (Word, PowerPoint, Visio) and business process analysis tools. Furthermore, end-to-end processes range back and forth between manual and automated activities as they progress through their lifecycle, such that often a single process instance ends up being managed by a variety of different tools. Nimbus provides what are essentially storyboards or guided walkthroughs for business processes: like procedures manuals, but more interactive. These “intelligent operations manuals” can include steps that will instruct the user to interact with a system of some sort – for example, an ERP system, or a BPMS such as AMX/BPM – but documents all of the steps including paper handling and other manual activities. Just as a BPMS can be an orchestration of multiple integrated systems, Nimbus Control can be an orchestration of human activities, including manual steps and interaction with systems. There are a few potential integration points between Nimbus and a few different TIBCO products: metrics in the context of a process using Spotfire; exporting discovered processes from Nimbus to BusinessStudio; instantiating an AMX/BPM process from Nimbus; worker accessing a Nimbus operations manual for instructions at the step in an AMX/BPM process; collaborative process discovery using tibbr; and tibbr collaboration as part of a manual process execution. Some or all of these may not happen exactly like this, but there is some interesting potential here. There’s also potential within an organization for finding opportunities for AMX/BPM implementation through process discovery using Nimbus.

An interesting view of three different acquisitions, based on three very different rationales: industry vertical; horizontal application platform; and expansion of core product functionality. TIBCO is definitely moving from their pure technology focus to one that includes verticals and business applications.

Back in May, I wrote about a cool new cloud-based service called RAVEN Cloud, which translated natural language text into process maps. As I wrote then:

You start out either with one of the standard text examples or by entering your own text to describe the process; you can use some basic text formatting to help clarify, such as lists, indenting and fonts. Then, you click the big red button, wait a few seconds, and voilà: you have a process map. Seriously.

They’re releasing RAVEN Cloud for general availability today (the beta sticker is still on the site as of the time of this writing), and I had an update demo with Dave Ruiz a couple of days ago. There are two major updates: UI enhancements, particularly the Business Process Explorer for process organization and categorization, and exporting to something other than JPEG.

The Business Process Explorer, in the left sidebar, looks like a set of folders containing processes although the “folders” are actually categories/tags, like in Google Docs: a process can be in more than one of these folders simultaneously if it relates to multiple categories, and the categories become metadata on the processes “contained” within them. This become more obvious when you look at the attributes for a process, where the Process Category drop-down list allows multiple selections. There is context menu support in the explorer to take actions on a selected process (open, rename, delete, move, save as), and the Process Explorer can be collapsed to provide more screen real estate for the process itself.

The Process Explorer contains a few standard categories, including process examples and tutorials; there is a separate administration panel for managing the process examples, which can then be used by any user as templates for creating  a new process. The tutorials highlight topics such as writing nested conditionals, and can be used in conjunction with the writing guide and their YouTube videos. I liked this one on correcting errors; I saw a bit of this in the demo when Dave accidentally misspelled a role name, resulting in an unwanted break in the flow, and didn’t specify the “else” clause of an “if” statement, resulting in an incomplete conditional:

Another feature that I saw in this version, which also brings them closer to BPMN compliance, is the inclusion of explicit start and end nodes in a process model. There can be multiple end nodes, but not multiple start nodes.

In addition to exporting as a JPEG image – useful for documentation but not for importing to another tool for analysis or execution – RAVEN Cloud now supports export to Visio or a choice of three XML formats: XMI 2.1, XPDL 2.0 and XPDL 2.1. The process model imported to Visio looked great, and the metadata at the process and shape level were preserved. Importing the XPDL into the BizAgi Process Modeler didn’t create quite as pretty a result: the process model was topographically correct, but the formatting needed some manual cleanup. In either case, this demonstrates the ability to have a business analyst without process modeling skills create a first version of a model, which can then be imported into another tool for further analysis and/or execution.

This still creates only simple process models: it supports unadorned activities, simple start and end events, sequence flows, OR gateways and swimlanes. It also isn’t BPMN compliant, although it’s close. They’re planning to add link events (off-page connectors) and AND gateways, although it’s not clear what natural language constructs would support those, and they may have to use keywords instead, which weakens the natural language argument.

There will still be a free version, which does not support user-created categories or Visio/XPDL exports, and the paid version will be available for subscription for $25/user/month with volume discounts plus a 10% discount for an annual versus monthly subscription. An account can be either single-user or multi-user; by default, all models created within an account are visible for read-only access to all other users in that account, although access can be restricted further if required. A future version will include process model versioning and more access control options, since you can’t really have multi-user editing of a single process model unless you’re keeping some past versions. I think there’s also an opportunity for hybrid pricing similar to Blueworks Live, where a lower-cost user could have read-only permissions on models that were created by others, possibly with some commenting capabilities for feedback. It’s all self-provisioned: you just set up your account, enter your credit card details if you’re going for the paid version, and add users by their name and email address; they’ll receive an email invitation to create their account login and profile. I didn’t ask if one RAVEN Cloud login/profile can be shared across multiple accounts; that would be interesting for people like me, who work with multiple organizations on their process models, and I’ve seen something like this in Freshbooks, an online time tracking and invoicing applications, so that Freshbooks customers can easily interact since a single login (authentication) can have access to multiple accounts (authorization).

They’re also working on hosting RAVEN Cloud in a private cloud environment, so keep watching for that.

My verdict: still cool, but they need to re-work their subscription model a bit, and bring their notation in line with BPMN. They also have some challenges ahead in defining the language for new element types, but I’m sure that they’re up to it.

The last speaker at the CASCON workshop is Sebastian Carbajales of the IBM Toronto Software Lab (on the WebSphere BPM team), on the interaction between a technical business analyst using WebSphere Business Modeler and an IT developer using WebSphere Integration Developer, particularly how changes made to the business-level model in WBM are reflected in WID. The business view is quite different from the IT view, and doesn’t necessarily directly represent the IT view; this is a common theme at this conference, and in general for vendors who don’t use a shared model approach but rely on some sort of model transformation. Given that there are two different models, then, how do business and IT collaborate in order to keep the models in sync?

They first looked at maintaining a separation of concerns between business and IT that would to minimize the need for changes by IT in response to a business change. This comes down to separating the business logic and rules from the implementation, and the separation of artifacts with well-defined logic from those with undefined logic. I’m not sure that I really get the distinction between the well-defined and undefined logic artifacts, or the benefits of separating them, although my instinct would be to externalize much of the business logic into a rules environment that the business analyst and/or business manager could manipulate directly.

They also looked at tool-assisted model merging to allow models to be compared in the specific user’s domain, then selectively apply and merge the changes into existing models. This would speed development as well as improve the model quality by reducing translation errors. There are some very similar concepts to those discussed in the previous paper on model change management, although with the added complexity of multiple modeling environments. A key goal is to improve the accuracy of model change detection, both to identify the objects in each model type as well as the relationships across the business-IT model transformation, and they used a traceability mechanism to do this. They generate a traceability map when the business to IT model transformation is originally done, capturing the identify of and the relationship between each object in the models, which allows traceability of changes on either model type.

He walked through a typical scenario, where the BA creates a process model in WBM, then exports/publishes it, where it is then imported by IT into WID and enhanced with implementation artifacts. When a change is made by the BA to the original model, and re-exported, that modified model is compared to enhanced WID model to create a new, merged WID model. Then, the change report is exported from WID, and any business-level changes are compared and merged back into the WBM model. Yikes.

Having a traceability map allows an IT developer to filter changes based on the business or IT artifacts, do visual comparisons and selective merging of the models. On the return trip, the BA can view updates to the process model, business services and business service objects that might impact the business logic, and select to apply them to the business-level models. The traceability is the key to model governance when multiple model types undergo transformations as part of the modeling and implementation lifecycle.

Following Carbajales’ presentation, we had a round-table discussion on the two process modeling themes of collaboration and consistency management to finish up the workshop. Some good ideas on the reality of business-IT collaboration in process modeling.

Jochen Küster of the IBM Research Zurich lab (where they do a lot of BPM research), was first after the morning break at our CASCON workshop on collaboration and consistency management in BPM, presenting on process model change management. This was more of a technical talk about the tools required. As motivation, process models are a key part of model-driven development, and become input to the IT process modeling efforts for SOA implementations. Multiple models of different types will be created at different points in the modeling lifecycle, but individual models will also go through multiple revisions that need to be compared and merged. This sort of version management – that allows models to be compared with differences highlighted, then selectively merged – doesn’t exist in most process modeling tools, and didn’t exist at all in the IBM process modeling tools when their research started. This is different from just keeping a copy of all revised process models, where any one can be selected and used.

In order to do this sort of comparison and selective merging, it’s necessary to generate a change log that can be used for this purpose, logging not only atomic activities, but have those rolled up to compound operations to denote an entire process fragment. Furthermore, the merged model generated by the selective application of the changes must still be valid, and must be checked for correctness: a resolution of the changes following a detection of the changes.

The solution starts with a tree-like decomposition of the process model into fragments, with correspondences being determined between model elements and fragments; this was the subject of research by the Zurich lab that I saw presented at BPM 2008 in Milan on parsing using a refined process structure tree (PST). A key part of this is to identify the compound operations that denote the insertion, movement or deletion of a process fragment. The current research is focused on computing a joint PST (J-PST) for the merged process, which is the combination of two PSTs determined by the earlier decomposition, based on the correspondences found between the two models. The dependencies are also computed, that is, which process fragments and activities need to be inserted, moved or deleted before others can be handled.

The results of this research has been integrated into WebSphere Business Modeler v7.0, although not clear if this is part of production code, or a prototype integration. In the future, they’re looking at improving usability particularly around model difference resolution, then integrate and extend these concepts of change management and consistency checking to other artifacts such as use cases and SCA component diagrams.

Janette Wong, a long-time IBMer who is now an independent consultant working as a solutions architect, discussed the use of workflow patterns in modeling business requirements and turning these into executable processes.

She used an example of an “authorization” business requirement, where manager can create confidential requests, and transfer those confidential requests to others. This can be matched to the standard role-based distribution pattern, which is fine for modeling, but then needs to be mapped to an implementation platform: in this case, some combination of WebSphere Process Server (WPS), LDAP or other directory service for user authentication and authorization, a workflow client application for human task management, and any other data sources that include user/role information. This multi-system implementation requires not only a conceptual mapping of the process and roles, but also actual integration between the systems that house the information. WPS provides instance-based authorization roles, then needs to bind that to the other sources at runtime in order to populate those roles; it doesn’t automate the solution, and in fact only provides a small amount of assistance in getting to that mapping. This is complicated further by role and authorization information that is spread out over multiple systems, particularly existing legacy systems; the business may think of the roles as being encapsulated in one of these other systems, which then needs to be mapped into the executing process.

She also discussed the requirement of a multi-item Inquiry, where multiple sub-inquiries will be created from the main inquiry (such as fraud investigations), and the exact number is not know at design time. This matches to the multiple instances without a priori runtime knowledge pattern, where you have multiple parallel sub-tasks that start and end independently, although the master activity has to wait for all children to complete before proceeding. This is similar to what we are seeing emerging in many case management implementations, where the parent activity is really the case itself, and the child tasks are those activities that the case workers initiates in order to move towards case resolution.

Wong observes that in spite of the length of time that BPM systems have been around, the larger patterns are not well supported by many of the systems although they are prevalent in real-world situations. She talked about the need for better design in process modeling tools, so that it is more obvious how to use the tools to implement these common, but complex, workflow patterns.

Next in the workshop was Moises Branco from University of Waterloo; he previously worked with the Bank of Northeast of Brazil (BNB) and discussed his work there as well as his current research that resulted from some of the challenges identified there. Their motivation for BPM came from a revision of their IT processes in 2004 that exposed the inflexibility in the heterogeneous environment; they saw BPM as being important for modeling and optimization, but also for process execution. They graded all of their existing systems on scales of technical quality and functional quality, mapped onto four quadrants of substitute (both low), improve functionality (low functional, high technical), improve architecture (high functional, low technical) and maintain (both high), with a drive to move systems in the two “improve” quadrants into the “maintain” quadrant.

He showed their strategy for execution, which included a business specification in the form of a process model, then an executable process that was a transformation/refinement of that model, and used an ESB to call services layered over their legacy systems. Since they took an enterprise architecture approach, they considered the multiple interrelated artifacts produced, including process models at various levels, use cases, business rules and entity-relationship diagrams. With multiple artifacts, the concerns became traceability, consistency and impact analysis between the models. To complicate things further, some of the development was outsourced, meaning that the collaboration between business and IT that should occur during any model-driven development had to extends beyond the enterprise.

Unfortunately, just as we heard from BofA, much of the model translation and consistency management was manual, as well as the collaboration in terms of version management. They were able to semi-automate the establishment of traceability links and perform basic model consistency checking.

Their current research is on model consistency: defining it via traceability, and automating some of the traceability between models (e.g., business-level and executable) and consistency checking.

In a break from the usual lineup of academics and researches, Peter Braun of Bank of America was up next in the collaboration and consistency management workshop to present on maintaining consistency across BPM initiatives’ content. They use IBM’s WebSphere Business Modeler (WBM), Information Framework (IFW, effectively a set of reference models in an enterprise architecture framework) and m1 (the modeling tool on which IFW sits), but have many other tools that have been implemented independently – mostly due to acquisitions – and need to be unified in a consistent environment as part of their latest transformation initiative. He gave some background on model-driven development, business process modeling (what I would consider BPA, although he called it BPMo) and IFW.

Braun comes from the business side, and he has a keen focus on the adoption of collaborative model-driven development: they use an agile approach that greatly reduces the need for written requirements through the involvement of the subject matter experts at all phases of process modeling. I’ve worked at introducing this in several of my financial services clients, and the culture shift is significant, since business analysts (and their managers) find it hard to imagine a project without a 100+ page text-only requirements document containing disconnected lists of desired features and actual requirements. Also, the expectation of ongoing involvement, not just the up-front requirements development that is thrown over the wall to the development, then forgotten until delivery.

They also have to deal with model governance to keep the WBM and IFW models in sync: each are used for different types of models at different points in the modeling lifecycle, and have specific strengths such that they want to continue using both tools. Because there are multiple non-integrated tools, they need to do model management to consider the interactions between model types, and there is a great deal of manual work to be done when a model is exported between the two environments. After the initial export/import, any changes in a model in one environment have to be manually made to match in the other modeling environment. They have issues with version management, since there is no proper repository being used for the models, and the modelers can end up overwriting each other’s efforts in a shared area on a server. They’ve also looked at ILOG, and have further issues with managing consistency between the rules designed in WBM – which map to the process server – and when those rules are rewritten in ILOG in order to externalize them.

Their biggest challenges include consistent adoption by all stakeholders, and what he refers to as tool/data integration, but is mostly about model governance and using “smarter tools”. It’s just not clear to me that their current combination of Visio, WBM and IFW is going to get very much smarter.

Krzysztof Czarnecki of the University of Waterloo introduced this morning’s workshop on Effective Collaboration and Consistency Management in Business Process Modeling, starting with a discussion of consistency management in modeling: within versions of the same model type, but also between models of different types, such as sequence diagrams and state charts, where there may be overlap of information representation. This theme of model interrelationship and translation has come up a couple of times this week at CASCON, and the need to manage the consistency between these artifacts through understanding the relationships and usages. He discussed some of the techniques for determining model overlap/relationship and checking consistency, including overlap and merging, and how these might differ depending on whether there is a 1:1, 1:many or many:many mapping between the different models. He also introduced modeling collaboration concepts, including methods of communication, terminology and awareness, in order to set the stage for the remainder of the workshop.

I’m going to break this post by the individual speakers since these are really independent presentations, and it will get way too long otherwise.