Very disappointed that ARIS Express does not support BPMN 2.0 XML export???

Hi Mark,

ARIS Express is not a teaser. It's purpose is to support small and medium sized companies to get started with documenting their processes. For this purpose, you don't need a BPMN 2 export, but you need exports in a powerpoint presentation (possible via clipboard or image export) and PDFs. This is supported by ARIS Express. In sum, ARIS Express is not meant for process automation and we nowhere claim that it is meant for this purpose.

I wasn't talking about process execution I was focused on process modeling and specifically model portability. You have a whole section (http://www.ariscommunity.com/aris-express/bpmn-2-free-process-modeling-tool) where you go on at length about support for BPMN 2 with examples. Yet your tool does not support import/export to the new BPMN 2.0 XML specification itself? Other free tools I've looked do, so I'm sorry but this strikes me as a deficiency. So when is ARIS going to support import/export from BPMN 2.0 XML? This is one of the major step forwards of the new 2.0 specification, i.e., standardization at the XML schema level of both the process and diagrammatic representation. BPM consumers like us are excited about the promise of widespread portability finally, so this is a big deal that BPM vendors need to demonstrate they play well with out of the blocks.

I agree with Mark.  BPMN is not about execution.  It can be used for that as well, but fundamentally it is about process modeling.  The Descriptive and Analytic conformance subclasses in BPMN 2.0 have no execution-related details, just the process logic expressed in the diagram through shapes and labels.  I have many clients who would love to see non-executable BPMN model interchange supported by ARIS.

I would add, from my current experience as consultant on ARIS paying customers, that this strategy has been a complete 'shoot on the foot': this artificial barrier hinders the internal usage in the technical teams to serve as champions for the product (which occurs well before management is aware of the tecnology candidates).



What I have seen is that when BPMN vendors are being short-listed, ARIS is striken out from the 'compatible file format' column....



Your sales team will not even be aware of this as they will not be called to present the product because they were not on the short list....

Enterprises might choose ARIS/Software AG on interely different sets of features, only to find, months after the product deployment, that it can in fact interact with another vendor's BPMN tool they have chosen before.

Just my 2¢. I hope you know what you are doing.

Hi all,

I know this issue about BPMN 2 XML export always raises a lot of heated discussions. We would invest in such an export if we see a market demand large enough to motivate the investment. So far, most projects we encounter use the XPDL export to transfer their models to an execution engine. We very seldomly see customers trying to transfer BPMN 2 models from one modelling tool to another one, because ARIS is usually introduced in a company trying to standardise on a single platform.

It is very common that people have done some modelling in low level tools like Microsoft Visio, hence we provide import functionality for that. Also, the upgrade path from ARIS Express to our professional tools is working as you can directly import an ARIS Express model (no matter if BPMN 2 or another one) into our professional tools without the need of an interchange format.

I'm pretty sure that at some point ARIS will support the BPMN 2 XML format (don't take that as an official roadmap statement). I know some of you are working in the very specific BPMN 2 consulting domain day by day and your view might be different on the need for a BPMN 2 XML export. However, please consider the fact that we have to balance our investments among a broad set of customers and only a small part is interested in BPMN 2 XML export.

Sebastian,

Does ARIS or ARIS Express export to XML with a published schema?  If so, I could probably provide mapping to BPMN 2.0.

Sure, we call it AML (ARIS markup language), which is basically a dump of a collection of models or an entire DB. However, a transformation is probably not that easy because the format basically says there is an object definition and this object occurs in a model and has a relationship to another object, etc.

An easier approach is using the built-in transformation engine. Here, a transformation can be modeled in a graphical way with full access to all ARIS information like traversing the graph of a BPMN model. A result of such a transformation could be a XML file or a new model, e.g. to transform BPMN into another language like EPC :-)

@Bruce:  "BPMN is not about execution. " What?

When you look at the spec (chapter 7) it becomes very clear that this is the only purpose/scope of BPMN. To quote the spec (highlights by me):

"Business people are very comfortable with visualizing Business Processes in a flow-chart format. There are thousands of business analysts studying the way companies work and defining Business Processes with simple flow charts. This creates a technical gap between the format of the initial design of Business Processes and the format of the languages, such as WSBPEL, that will execute these Business Processes. This gap needs to be bridged with a formal mechanism that maps the appropriate visualization of the Business Processes (a notation) to the appropriate execution format (a BPM execution language) for these Business Processes."

That chapter also lists the out-of-scope points (like org or data modeling) which are needed for proper analysis or Enterprise Architecture projects. I think we have a lot to do to improve the spec to suit the analysis requirements and remove ambiguity and other inconsistencies (e.g. the non-specification of lanes, or the inconsistent use of gateways or events).

@Roland,

Yes it is easy, when your only contact with BPMN is the spec, not to see the forest for the trees.  I have trained 1000 or more students in BPMN and only a handful are using it for executable design.  I am talking about BPMN as it is actually used in the world, not IBM-Oracle-SAP's wish about how it might be used in the future.  But even the part of the spec that you quote does not dispute what I said, which is that BPMN can be used for execution as well as business-oriented documentation, so it provides a common visual language that can be used by business and developers.  If you look at what the spec calls Process Modeling Conformance, specifically the Descriptive and Analytic subclasses, you will see that the information contained only pertains to non-executable models.  This is the part of BPMN 2.0 - the part that you can see in the diagram - that is actually used.  And I challenge you to find a BPMS that supports BPMN 2.0 execution today!  Maybe Activiti, jBPM, and BonitaSoft are halfway there.  Bottom line is when ARIS says it does not support BPMN except for executable design (e.g. with webMethods or Oracle), I think that is short-sighted... and obviously some of your customers agree with me.

@Bruce - now you are turning around the arguments ;-)

I personnally (and "we" as Software AG) have experience in non-executable BPMN projects and see which workarounds you have to do to be consistent and provide the necessary information that makes a model meaningful (e.g. mapping of lanes to role objects in matrix models, or adding KPIs and risks in assigned Function Allocation Diagrams). This is not necessarily tool-specific, but there are other notations that make it easier than BPMN.

Your bottom line conclusion is also off. We support BPMN 2.0 for executable processes for sure (e.g. within our tool stack where wM uses the ARIS BPMN model and we provide a roundtrip ARIS - wM - ARIS), but we also position the tool for non-executable processes (guess, who's currently preparing a beginner training with BPMN as the notation on the lowest level of a process hierarchy ;-).

What I just don't like is the "either - or" attitude ("pro/con"; "my way/highway" - you name it) that I see in our industry discussion that sometimes is too single-minded IMHO. The notation should be the least thing to worry about, because in the end it is important to improve the performance of an organization (with or without a system). A good example -outside of our both companies- is given by Alec Sharp and his excellent book "Workflow Modeling" (and his articles here and here). 

What I notice is that most clients who are interested in BPMN really don't know it to the depth that you and I know it - they just want to have swimlanes and sell the argument "We are using a standard" to their stakeholders. There is a lot of education to do to give them an honest and appropriate recommendation to meet their requiremtents. And even then they might decide against it and choose something that produces more work and makes things more complicated.

In regards to the spec -which should be the ultimate yard stick IMHO, even with your caveats- I think there is a lot to do and for non-executable processes this means simplification and consistency in the first place.

Roland, you are misinterpreting me, and I think maybe also misinterpreting others who suggest that it would be nice if ARIS could export to BPMN 2.0.  No one is saying BPMN is the ONLY way.  I am certainly not saying it.  I think adopting a standard has value even when a proprietary notation might have other advantages, but reasonable people might disagree.  I have no problem with that.  My interpretation of this whole thread is that someone posted they were disappointed that ARIS did not support BPMN, and Sebastian said that it does support it for executable processes, and I commented that it would be very useful for non-executable processes as well.  If you don't see the demand, that is up to you, and basically that is what Sebastian said... but the reason should not be "BPMN is only for execution"... because it's not.

Guys, nice discussion. I have the feeling, we all are not that far away from each other. Let me put my perspective on the underlying issue you are discussing.

When I was joining the BPMN 2 standardisation (at that time only Oracle, IBM and SAP were involved), I started to understand that BPMN 2 was not going to deliver what people actually expected. The big 3 were clearly focusing on making BPMN  executable. However, market demand was for better support of business process modelling and not creating executable processes. At that point in time, it was too late to change the direction, also due to limited resources on our side. Personally, I think it was good to get BPMN 2 released, but it would have been better to immediately start working on Business BPMN 3 :-)

As that didn't happen, many bright consultants like Bruce started filling the gap by providing their own frameworks. Also, tool vendors like Software AG extended their tools so that  annotations with the missing aspects like roles, data, risks, etc. could be added.

Now, even if ARIS would support the official BPMN 2 export format, I'm not sure if it would be really useful, because you could only transfer the pure process flow, but you would loose all the information you added in a proprietary way. This, of course, makes a standard pretty useless, because we are again at the point where we do proprietary modelling.

I've been following this thread with great interest as it is highly relevant to my current situation.

I'm trying to consolidate the global process modelling at my organization across 4 main regions. I have Process Architects that come from all various backgrounds with different notations and methods. The task, needless to say, is particularly challenging especially when I'm also dealing with a massive age gap - the older guys are very set in their ways and are highly resistant to BPMN (apparently it has no place in process modelling!?!).

What most of them don't realize is there are two perspectives with enterprise process modelling; the first, being getting the process objects themselves in order to understand the logical flow (e.g. using BPMN), the second, getting the process architecture objects to understand the environment in which the process is executed (e.g. EPC). What has been adopted is to have a single notation that captures both these sets of process and architecture data into one object to be modelled at the task level! To model both these perspectives at the same time, which is what is currently being proposed, seems inefficient. I may be wrong but my past experience has led me to believe that to drop all these modelling objects (risk, kpi, control, location, organization, system, role, business object - all embedded into one process/task element - coupled with events and gateways) into one notation will be messy. They don't want to use swimlanes because I have been told, via one of these guys, that the business hates the swimlane view and does not want to see it (I  have never heard a complaint from a single business user about swimlanes, ever. In fact, quite the opposite).

My question is to both Sebastian and Bruce; how does an organization conduct this type of modelling and how would Aris support it?

Hi Damian,

I posted my answer here as you also opened a new thread about this issue.

Hi Sebastian,

very interesting discussion. We have also customer demand for ARIS supporting BPMN 2.0 XML import / export. I cannot imagine that there are not more demands for it from the ARIS community. Surely you must have had a customer who allready had BPMN 2.0 diagrams created and wanted to migrate them into ARIS? What are the possibilities for BPMN 2.0 XML import at the moment.

BR,

Martijn

Self kick, still waiting for a reaction.

@Martijn: Such migrations usually only happen in large implementation projects. And in such projects, a solution is found. For example, if the customer was using MS Visio, we have the Visio import in place. If the customer has some XML format to import, an ARIS report can be implemented or reused. Sometimes, tools also allow exporting in another format like XPDL, where we got a direct import option.

We are using the standard ARIS toolchain for business process modelling for years.

However, this toolchain lacks a lightweight product, where "light" refers to costs and the learning curve to use the product.

ARIS Express would be perfect but is not because you cannot import models previously exported from ARIS Business Architect clients. Hence, as consultants we have to go elsewhere to recommend a business modelling project's toolchain that is a future proof investment, where future proof refers to the clients being able to really do something with the models we left behind after a project is finished.

Hence, I join the hookline of this thread: If a product is advertised with the buzzword of BPMN 2.0, it should support corresponding data exchange formats. At this point in time, the marketing of Software AG is comparable to the case of instant chicken soup where the image of a chicken is displayed on the cover but the soup itself contains less than 0.01% chicken. It is not illegal, it is not a straight lie, but it is not true either...

Does ARIS 9.0 completely support BPMN 2.0 now?   If not, can you please tell me which aspects are not supported?

Thanks,

Raj

Hi Sebastian,

I see that most of the comments posted here are old at least by a year.

Is there any recent development wherein BPMN 2 export becomes feasible out of ARIS Express. If yes, then please help to inform the same and the upgrade version to get this feature.

Thanks,

Jagat N. Kapoor