PRET'09

Today was the Practice-driven Research on Enterprise Transformation working conference in Amsterdam, held in conjunction with the CAiSE conference. This working conference was presented as an 'industrial event' and a good attempt at bringing together academia and industry. In my opinion, we should do that more often to prevent the two world drifting apart too far.

One of the most interesting presentations was by Will vd Aalst on BPM. He presented research (with a demo) where he showed that process models can be constructed automatically by examining log-information from live information systems. This allows for similation and even TomTom like functionality (where am I in the process, what is the expected time to finish?). Good stuff.

I got several interesting new research ideas out of the conference. Stay tuned: I hope to publish them here soon.

Why archimate needs type-instance

Today I attended a very interesting archimate usergroup meeting. The topic of the meeting was ‘modeling across layers in Archimate’. This is a topic that I’ve been wondering about myself for quite some time as somethings are hard to model in Archimate to say the least.

The example problem that we tried to tackle is to model the situation where a company sells books over different channels (web, bricks ‘n mortar) to its customers. One of the things you need to realize before tackling this problem is that different stakeholders require different information and hence different views on the model. But still, as an intellectual exercise it is nice to try to represent the entire model in a single Archimate diagram. A first take results in the classic layered view of a product being offered to customers. The product (a service, in Archimate) is realized by a process which in its turn uses application functions that are realized by some ERP package. So far so good.

Considering the channels, it seems logical to model the ‘physical’ version (where a customer simply wanders into the store to order a book) as a collaboration between the customer role and the internal sales role (associated to a desk clerk). The sales role uses some graphical interface on the ERP system to do her work. Nothing too difficult.

It seems logical to model the web channel as a business interface that is assigned to the product offering (I admit that I used the 1.0 specification for inspiration here). This interface can be assigned to a role (websales) which In turn is assigned to an actor. Moving to the application layer is relatively straightforward: the websales role uses the portal function.

I don’t consider this particularly elegant, but it seems to be the best way to make the web interface explicit as well as connecting to the ‘order book process’. Also, it is more or less symmetrical with the ‘physical’ channel. Another option would have been to let the ‘order book’ service use the portal interface directly. This solution has the problem that it is harder to see the relation with the order book process.

In reviewing this simple example, I learned two things:

· Modeling things like portals where customers (in the environment) interact directly with systems (in the application layer) is tricky if you want to link to in between ‘logical’ processes. More specifically: it seems particularly tricky if you want to represent it in one view.

· The other thing is that there is a lot to be said for ‘type instance’ relationships. In my view, the ‘type’ is the product offering which uses some process which in turn uses some ERP system. The ‘instance’ is the detailed version using some specific channel. As this example shows, it is not easy to do that in archimate currently.