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.