IFML 1.0: Interaction Flow Modeling Language approved by the OMG

After three years of work, IFML 1.0 is finally approved by the OMG!
The Interaction Flow Modeling Language was actually adopted one year ago, in March 2013, as Beta specification by the Object Management Group (OMG). Since then, the IFML Finalization Task Force worked hard to bring the specification to perfection.

The Object Management Group (OMG) Architecture Board approves the new IFML 1.0 standard on March 2014 in Reston, VA
The OMG Architecture Board gathered for approval of IFML. Among others, you can see Andrew Watson (OMG), Juergen Boldt (OMG), and representatives of IBM, 88Solutions, Adaptive, Fujitsu,  PrismTech and others.

Along the path, we got valuable feedback from implementors of the standard, spanning DSL tool vendors implementing the notation, UML tool vendors implementing the UML profile, and our own developers at WebRatio implementing the commercial industry-strenght modeling tool and code generators, as well as a bunch of opensource IFML editors. We also got feedback from WebRatio customers, which contributed to improve the language notation too.

All this summed up to 77 issues formally submitted to the OMG and subsequently addressed by the task force. The specification document, as well as the machine readable files (XMIs) have been cleaned up and prepared for final publication.
As a last step, the finalized version of the standard has been presented at the ADTF and at the Architecture Board of the OMG during the March technical meeting in Reston, VA, USA.
Version 1.0 is now officially adopted by the OMG. It’s just a matter of a few weeks before the final, copyedited version of the specification will be officially available on the OMG servers.
For documentation purposes, here is a snapshot of the program
Meanwhile, you can have a look at the sneak preview of the final version of IFML. Further details are available on the official site.

As Stefano Butti, CEO of WebRatio said, IFML is one of the three biggest leaps in WebRatio history (together with the move to the US and the selection of WebRatio as Gartner Cool Vendor). Other vendors have already declared interest and/or started developing some modeling solution based on IFML. We look forward to wide adoption of this new standard, thanks also to the integration with other modeling aspects such as business modeling (with BPMN) and system modeling (with UML, SoaML, SysML, …)!

At the Reston event we also gave away the first copies ever of the very nice IFML Cheat Sheet (or Quick Reference Guide) prepared by WebRatio based on the official specification document.
The cheat sheet is available for free on the learning portal of WebRatio.

IFML CheatSheet - Quick Reference Guide and examples
The IFML cheat sheet: Quick Reference Guide and Examples (on the back side, not shown here).

Here is a small photo gallery of the event location, the WebRatio booth and the program of the AB plenary where IFML was adopted.

WebRatio boothOMG AB agenda for March 2014


To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Daniel Moody on "Designing diagramming notations that work": the physics of notations

Daniel L. Moody from University of Twente gave a talk (and a full fledged tutorial) at OMG technical meeting in Reston, VA, on the principles for designing effective diagramming notations. His talk had this overall design:

(click to enlarge)

Daniel Moody wrote a famous paper on IEEE Transactions of Software Engineering titled:

IEEE TSE. November/December 2009 (vol. 35 no. 6). pp. 756-779

Program flow charts have been invented long time ago, in 1947.
Visual notations are effective communication tools because they rely on the highly parallel way of reasoning an processing signals of the human brain.
Therefore, they should be optimized for human mind processing. It’s not something that can be designed based on opinions. There are ways of measuring and proving results.
The measure of optimization is cognitive effectiveness. Effectiveness of existing notations is hampered by:

  • unclear goal of the notation
  • low attention to this aspect
  • lack of accepted design principles
Notations like ER diagrams expose significant flaws, but is accepted and preserved with no questions. UML has the same problem. In general, another point is that in current notations there is no motivation on why one choose one symbol or another for model elements. In other words, there is no rationale for design of notations. Basically, we are still in unselfconscious design culture (more or less the same as the way huts are built by primitive people: there are no architecture principles or books, the just build huts).
The same symbols are used again and again within the same language and across languages (e.g., think about the rectangle symbol).
There is lack of testing and principles. That’s why Moody proposes a set of objective principles based on scientific observation.
Out of that, he proposes a clear manifesto for design notations:
  1. At least equal effort and attention for notation and content
  2. Have a design rationale
  3. Decision must be based on evidence
  4. Design must be based on objective principles
  5. There must be explicit testing of the notations (user studies)

The purpose is to move diagramming from art to science.

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Model interoperabilty in MDE: a lost battle?

If you have been extensively using software modeling tools, you have probably experienced the awful situation where you want to move models from one tool to the other, but this ends up not being possible.
Why? Because you are using different languages? Not at all: even just moving a “standard” model from a modeler to another is a pain.
Concretely, each tool stores and manages the models with its own internal format or its own “dialect”, even if a standard format is adopted.

This is a major concern for developers, who need to check every time the actual possibility of exchanging the same kinds of models between editors, and often still need to struggle finding the mappings and defining the bridges between the formats by themselves. This hampers the possibility of effectively exploiting different tools in the development process. This is is definitely a minus for the developers, since having several tools at hand to be used upon the same model could allow to use the different features provided by the different vendors, based on availability but also taste of the developer himself. For instance, in an ideal world a developer could design the models with a modeling tool MT1 (e.g., because the editor of MT1 is more usable and allows higher productivity) and then immediately move to another tool MT2 for the verification phase (e.g., because MT2 provides more precise or extensive rules), and to tool MT3 for model execution (code generation or model interpretation, e.g., because it’s not provided by other tools).
Even in the case of well established standards like UML or BPMN, their abstract definition is still not enough for leading modeling tools from different vendors to share their models in a seamless way.

Interoperability is addressed also by standardization bodies. They are well aware that the supposed role of facilitating communication and information interchange that (standard) models should cover, is not a reality yet.
To improve interoperability between modeling tools, standardization bodies have defined specific model interchange languages. Examples of these languages can be found both for GPLs and for DSLs.
The most known model interchange language is XMI (XML Metadata Interchange), a standard proposed by OMG for serializing and exchanging UML models. Unfortunately, even if this has been devised as an interchange format, different tools still adopt it with different flavors. Therefore, the need arises of constraining the language even more. That’s why OMG is now running an activity for defining a canonical version of XMI (Canonical XMI), which is a strict subset of XMI and forces the adopters to follow stricter constraints.
A similar situation can be found in the most popular DSLs too. For instance, BPMN has an interchange counterpart in the XPDL language (XML Process Definition Language). In turn, this interchange language suffers of the same problems of XMI. Indeed, it is very difficult to actually move BPMN projects from a modeling environment to another.

This leads to my initial question:

  • Is modeling interoperability a moving target that will never be reached? 
  • Is it doomed to fail anyway and anyhow?

To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

Bruce Silver’s keynote speech at BPMN 2011 workshop: interoperability and other issues in BPMN and UML

Today at the BPMN 2011 workshop in Luzern, Bruce Silver gave an interesting talk on the status of BPMN 2.0, its adoption, and his proposal for improving its general usage.
I really appreciated the talk because:

  • it focused on the ambiguities of the BPMN notation, even in the so acclaimed 2.0 version
  • it highlighted how users tend to be confused once the notation is so complex.

Bruce presented his well-known approach, with the caveat that probably method and style is too weak as a position, so he proposes to move to the rules term, so that people feel somehow more obliged to comply 🙂 .

    The first issue I take away is the problem of interoperability.
    I would also identify a trend on what I heard here, through a parallel to what is happening in OMG within the Canonical XMI initiative (read something here), performed by the Canonical XMI Finalization Task Force: given a modeling language (or an exchange format like XMI) which is under-specified, too general, or too open for dialects generation, the need arises for putting some stricter limitations to the designers, for making the tools more interoperable and for improving the quality of the models. Interoperability is the explicit aim of XMI, but, since it failed to an extent. Probably the same would apply to XPDL itself: it was designed as an interchange format for business process models, but then ended up being prone to several dialects and interpretations as well. For XMI, the improved interoperability aim is now in charge of Canonical XMI (while no action is being taken on XPDL).  The same purpose is addressed by the BPMN-I initiative by Bruce Silver.

    A similar problem that has been addressed is executability:
    Also on this, I see strong parallelism with the UML world. There is definitely a push towards executability of models: just think about the executable UML fUML and Alf initiatives (you can find a nice overview on both on Jordi’s blog here), at OMG or also some new activities like MiUML, an open-source executable UML project.
    On the other side, also BPMN 2.0 is addressing executability and within WebRatio we are also providing somehow a pragmatic approach to BPMN executability, by generating running Web applications. The question is: are customers asking for that? The claim by Bruce is that they are not for BPMN. Most people only want to model, not to execute. Probably, if you look at the share of interested people, for UML it’s the same. However, I think executability is an interesting property that should be granted to give a general grounding to reality to models (although I acknowledge that some models may not need/allow that).

    A final take from the day is related to choreography.
    Interestingly enough, again people are not using it: neither in the BPMN world nor in the UML one. I don’t have stats on the usage of the different kinds of UML models, but I’m pretty sure people only use class diagrams basically. Some will use activity diagrams, and few sequence diagrams. Anything else?

    Bruce Silver, with Bruce Silver Associates,
    presenting his keynote at the BPMN 2011 workshop.

    To keep updated on my activities you can subscribe to the RSS feed of my blog or follow my twitter account (@MarcoBrambi).

    Applying design patterns in BPM?

    In response to the really sensible question posted on eBizQ: What key methods do you use for applying design patterns in BPM? here is my viewpoint:
    I’ve been working both on software engineering (where design patterns have basically redefined the entire discipline) and in web and BP design.

    I think to pattern as reusable design solutions to known problems. The concept is a very abstract one.. actually, as you may know they have been first used in architecture (meaning bricks and concrete, not software 🙂 See: ).
    I agree with Scott on the purposes of patterns and on the fact that they don’t really induce a fixed implementation
    [As a side note: the Hashmap example, while it gives a good idea of the point, is already too detailed to be called a sw pattern, that’s already a design solution.]
    However, while in software engineering I see patterns as usable in every setting, I agree with Andrew that in BPM they can be useful for composition of rather standard processes only. This is not so bad, since I would say that a large percentage of processes may fall in this category. Anyway, for sure ACM is not a field where a see an easy application of patterns, since ACM addresses a set of problems that are inherently not codifiable a priori.

    In the academia van der Aalst and others have codified a fairly complete set of workflow patterns (, which are a useful tool for some purposes (e.g., comparing the expressive power of different workflow languages), but I’m not sure they are nearly as useful for actual BP design within industrial scenarios (honestly, I haven’t seen anybody using them in this way; have you?).
    Also, I recently discovered a set of more practical patterns here: .

    As a concluding remark, I’m not really sure about what is the real difference between a pattern and a template. Here is my (possibly simplistic) interpretation (opinions and criticisms are welcome): a pattern is a simple solution to a small problem, that composed together with others can contribute to a solution of a complex problem; a template is a complete solution which is completely configurable for being adapted to different context and therefore address similar situations.