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.