The coolest thing I saw at Process World was definitely ARIS Process Performance Manager (PPM), specifically its ability to autogenerate the as-is model from instrumenting the backend systems that perform its activities. IDS CTO Wolfram Jost mentioned this in his keynote, and there were a number of comments about it in my Almost Live… post on Thursday. If you missed the thread, Marlon Dumas pointed me to an excellent academic paper on this technology, called “process mining,” by Wil van der Aalst and colleagues. Others commented that it couldn’t do magic, and Kiran Garimella did a strange riff on it as well. I obviously didn’t explain it very well, because at that time I hadn’t seen it. But now I have. It’s not magic at all, and still I think very cool. And something Kiran might actually want to take a second look at for webMethods.
Let’s strip away the automagical part. First of all, PPM is just about the as-is process, not the improved to-be model, which would be modeled in ARIS Business Architect. In that regard, PPM does not attempt to capture every bit of process logic in the flow, but just a diagram that provides context for KPIs. One of the essential differences between BAM from BI vendors and BAM from BPM vendors is that BPM provides a process context for the KPIs. You can drill down to see the root cause of problems: which subset of instances, which step. PPM focuses on exactly that.
Second, it requires the systems that it monitors to provide instance data in some structured form. That structure includes some instance identifier (for correlation), timestamp, and various attributes about the activity and state. The magical middleware is an “extractor” (I would call it an event adapter) that looks at events or logged instance data that the backend system already creates. ARIS provides extractors for SAP, databases, and files (must be structured, e.g. delimited, not text files… these woud require custom parsing extractors). So if an application in your process is hardcoded in COBOL and doesn’t generate events or log data, PPM isn’t going to mine it successfully. But did you really think it would?
PPM can work either with or without a predefined ARIS model for the process. Here’s how.
You start by instrumenting key events in your process, represented for example by document creation events in your SAP system. Instrumenting the event means watching it with an extractor. You don’t do this for every activity in the process, just the key milestones you are using to monitor performance, typically measured by cycle time. I suppose you could just put one at the beginning and another at the end, if you wanted to, but the idea is the capability to drill down to identify sources of problems in the KPIs. Kiran, I hope this is starting to sound familiar to you.
The extractors, which could be distributed across multiple systems, generate process instance fragments in the EPC form of event-function-event and funnel them to a “process warehouse.” If you have an ARIS process model already, I believe the names of events and functions are taken from that. If you don’t (the autogenerate case), the designer has to provide those. In the process warehouse, PPM then takes those fragments and merges them into a process chain for each single instance. This doesn’t show the logic at decision nodes because it’s just a trace of a single instance, along with the instance attributes, KPIs, and activity timestamps at each node. So far, nothing magic.
Then PPM can aggregate those instance models for any selected subset of instances - the ones with the fastest cycle times, or slowest, or the orders for blue widgets vs orders for red widgets, whatever instance data is avalable as a dimension for the KPI. This seems trickier, but again not magic. The aggregated models use some heuristic logic to generate the decision nodes based on the variety of paths taken in the aggregation.
So in operation it works like this. You instrument your current process with extractors. PPM creates a management dashboard of KPIs. It tells you which attributes of the instances correlate with the biggest variation in the KPI. You can then slice and dice the KPIs by one or two dimensions - say cycle time by activity and type of widget. Here, by “activity” I suppose I mean the time between 2 of the instrumentation points in your process - that’s as granular as you can get. This activity diagram is autogenerated by PPM. Aha! You see the overall cycle time problem stems from the QC step for the blue widgets, and you can drill down from there to the list of actual instances.
To me this is quite similar to what webMethods and Lombardi (possibly others) are trying to do with as-is performance monitoring prior to modeling, except that ARIS is taking the extra step of autogenerating a process context for the data. Not magic at all, but how long does it take? Molson-Coors supposedly got their first PPM process done in 10 days, although they are clearly one of IDS’s top customers and it sounded like the ARIS guys may have worked round the clock. But it’s not months.
PPM has been around for 3 years, but even IDS’s best customers are just beginning to try it out. Probably not the best marketing around it. I think this technology has great potential and I would expect it to take off once people understand it better, and not just from ARIS. They have some patent protection (supposedly), but Dumas and van der Aalst suggest that others will offer similar things soon. Kiran, forget about those lizards! This stuff is great.
February 10th, 2007
Air travel is God’s punishment for living in California. At 5:30 on Friday evening, when most attendees are safely home with loved ones, my journey home is just beginning, many miles before I sleep. Day 3 of Process World (”User Day”) was the best for me, since I came to find out what ARIS actually is and does, more than the corporate vision.
I went in with the preconception that BPMN is “simple” (conceptually) but “hard” (for business analysts), while ARIS is “complex” but “easy.” Oxymoronic, right? I come away with that notion reconfirmed, but now I’m starting to make sense of it. There’s process modeling and there’s process modeling. ARIS doesn’t try to do what BPMN tries to do… well, actually they’re starting to, but that’s not what existing ARIS customers are using it for. Here’s how I think I understand it.
In the ARIS world, modeling is largely business vocabulary management, with a process-centric twist. Value-added chain models (VACs) break down the enterprise into “processes”. At the VAC level, these are no more than names of end-to-end transactions: order to cash, procure to pay, make to order, etc. If you use SCOR or ITIL or eTOM or other such industry frameworks, this is familiar, since that’s mostly what those “standards” do as well. You can set up hierarchies of processes and subprocesses in this way, again mostly just names and their interrelationships, which can be seen by drilling down in the diagram.
You can attach processes to information about them - the who, what, which, and why, I think they call it. The visual metaphor is the ARIS “house”. It looks like a big rectangle (the process) surrounded by smaller rectangles on the right, left, bottom, and top (this one is peaked, like a roof… “house,” get it?) Those surrounding rectangles represent your company’s organization chart (who), functions and applications (what), data (which), and products and services (why).
Each of these surrounding elements is described by a slew of models in ARIS. The guiding philosophy seems to be the more models the better. You select the ones you want to use. And the relationships between these surrounding elements and the process are not just simple links, they carry business nuance. For example, you don’t simply link a department or position in the org chart to a particular process activity (function). You have to select between “is responsible for…”, “performs…”, “approves…”, etc. It starts to boggle the mind.
Unlike BPMN, which basically looks at processes one at a time, ARIS is BPM at the enterprise level, a cross-referenced catalog of all the processes involved in the business, and their relationships to organizational units, data, applications, and business purpose — all maintained in a common repository, so you can see the enterprise impact of changing any single element. That’s a totally different animal.
But here’s where BPMN and ARIS cross paths. Eventally, if you drill down long enough, you do model processes in terms of activity flows. ARIS calls them event-driven process chains (EPC), and they’re analogous to BPMN diagrams. ARIS calls them “event-driven”, but I don’t think they use events in quite the same way as BPMN does. What BPMN calls an activity is in EPC a sequence of an event, function, and another event. These fragments chain together by matching the output event of one function with the input event of the next function, so it seems to act more like a normal control flow than event-driven. But I really need to understand the EPC paradigm a bit better (which I plan to do).
This simple control flow aspect was what led me to ask Dr Jost yesterday if he could envision merging BPMN and EPC someday (he couldn’t). The difference seems to be not so much in the events as in all the other stuff - the who, what, which, why - hanging off of each activity in the EPC. The organizational responsibilities, the business objects, the products and services, the applications… most of that “stuff” is absent from BPMN, and most BPMN advocates would say “good” to that. That’s because BPMN is about detailed modeling of processes one at a time, simulating their performance, and possibly driving an executable implementation. Not what ARIS is trying to do at all.
Or is it? Yesterday one commenter on my post said that ARIS has no BPEL support. Not quite true. This afternoon I got the basics of ARIS SOA Architect, a new product. They’re still pitching this as a business analyst tool but it seems more IT. Here is what it does. You start with EPC (SOA Architect actually includes the functionality of Business Architect, the tool where you can build the VACs and EPCs and all the other business models, as well). Then you import WSDL from a registry into the repository. You add some more metadata to the WSDL that helps make the service discoverable for reuse. Using that metadata you can search for an appropriate service to bind to each EPC function (activity). Then you select an operation for each service and generate skeleton BPEL.
The skeleton BPEL does not include data mappings (Assign) or human tasks; for those “extensions” it just puts in placeholders in an ARIS namespace that conveys enough information that a developer can create the real BPEL in the execution platform’s native BPEL tool. It makes sense they do this for human tasks, but data mapping? I suppose in BPEL 1.1, Assigns are still really engine-dependent; with BPEL 2.0 there is no excuse for ARIS not to do the data mapping itself. Anyway, this is how ARIS is trying to bridge the worlds of business BPM with SOA. It draws the business-IT boundary well over into IT’s turf, it seems to me. But let’s see how it goes.
February 10th, 2007
