Escape from standards?

Modeling or framework standards are very important for correctly describing semantics through models and thus establishing a good communication among different stakeholders. But regular everyday experience is teaching us that model and diagram interchange (MDI) with e.g. UML® models (via XMI) or BPMN™ models (via XPDL) does not always work well to receive high quality deliverables, to say the least. And please forget about round-tripping among tools. So MDI is usually a somewhat horrible exercise for architects or developers.

Exported model data are described by a data scheme format. The format of model data is described by a meta-model and the format of diagrams are described by a modeling language which extends the meta-model by a graphical notation. In general, a conversion between different model or diagram formats addresses transformations on three levels:

  • Data scheme,
  • meta-model,
  • modeling language.

For MDI there are even more dimensions adding to the complexity of such transformations: Versions, vendor-specific implementations and enhancements, and most important: client-specific customizations – they are very common and can turn conversions into nightmares.

The OMG recently started a workgroup to more precisely define the procedure of how to validate the quality of deliverables of diagram interchange (DI). This is an initiative in addition to just defining a data scheme for BPMN. (Yes, there is a specific data format for BPMN! But up to now, mostly the WfMC-defined XPDL was used to serialize BPMN diagrams). This post is about the challenge of using XPDL to interchange BPMN diagrams.

Enterprise architecture frameworks like DoDAF are using BPMN to describe operational views. But there are more viewpoints and diagram types needed to describe the application and technical views of those frameworks. Tools like ARIS® are mapping those frameworks into their own namespace of legacy modeling languages.

Most frameworks do not have a standard modeling language (well, TOGAF® and its language ArchiMate® are quite exceptional in this respect). This means however, that using TOGAF® in a third-party tool always is quite vendor-specific, more resembling a methodology and a meta-model than a formal language like ArchiMate®.  Attention to be paid that ArchiMate® defines indeed a modeling language, but there is no standard data scheme format for ArchiMate® diagram interchange available.

Also, the BPMN® notation helps describing the business or operational view but is not rich enough to express the application and technical views as well. As a consequence, there is no generic modeling language and no generic data interchange format in the market to serialize models and diagrams.

So welcome back at the starting point of the game.

To simplify the following explanations, I shall use the term “graph” as a synonym of “model” or “diagram”, because both of the latter can mathematically be expressed by a graph model. The key technology for MDI is simplification by normalizing of the graph’s data representation. Graphs can be easily stored in a highly normalized database structure representing the graph´s nodes (objects) and edges (connectors). This allows the processing of very generic object- and pattern-based transformations to convert a source into a target graph.

The first step in normalizing the model representation is the using an inbound (read input) and outbound (write output) software adapter as plugin of an enterprise service bus (ESB) that is especially designed for MDI. The adapters solely have the task to process any complex data format and the normalized graph. This technology is also known as extract-load-transform (ETL) where ETL additionally tries to transform the graph and not just the data format. This is why nasty ETL scripts have to be re-developed again and again for each specific format conversion.

The value of using adapters is

  • Complexity of the data formats, different versions and implementations are eliminated.
  • COTS: commercial of-the-shelf adapters are available to avoid custom development.
  • New tool specific adapters are created by a model-driven workbench.
  • Different adapters can be combined and flexibly be loaded at run-time from the ESB.

Once you have an adapter for a specific tool, you can connect to more tools by adding specific adapters to the ESB.

The next step of graph transformation requires a formal description of each source and target graphs. BPM-X calls this artifact a “method” which is described by a flexible meta-meta model to have a genuine open meta-model. In reality there is no a single BPMN method: there are BPMN™ 1.0, 1.1, 2.0 standards, BPMN™ for specific BPA tools from Oracle, Software AG (ARIS®), OpenText (ProVision) etc. and BPMN™ implementation levels from a functional up to a process execution level. Those different “methods” are stored in a method dictionary which acts as like a template library.

And individual source and target methods can be built by

  • using a predefined method from method dictionary as a starting point to customize the specific source or target method;
  • running a BPM-X import filter to read available method descriptions directly from the source or target data;
  • running a BPM-X re-engineering tool to generate a method from its instance data (e.g. exported XML data);
  • or creating a method from scratch.

Now we are at the point to have our the adapters available, the source data loaded as a normalized graph into the database and the graphs describing source and target method are available, also.

The missing last step is the definition of transformation rules to convert the source into the target graph. The transformation (T) uniquely describes the relationship between source (Gs) and target graphs (Gt) through a simple formula: Gt=T(Gs). Once the transformation rules are defined they can be stored for later re-use if the source and target methods are identical.

The benefits of this very methodical approach are:

  • Architects work on graphs instead of nasty data formats,
  • concentrating on content instead of technical formats,
  • supported by tools and templates to accelerate their tasks,
  • having extendable and maintainable rule sets available.

At the bottom line, this approach solves the dilemma of MDI among large organizations, teams and partners. No matter of frameworks, modeling languages, tools or data formats they use for their implementation of enterprise architecture or business process analysis.

Latest Comments

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Join other 25 subscribers


© 2017 TransWare AG is a registered trademark.