11 years, 8 days ago

The 1st Belgian ArchiMate User Group Meeting

<p><span style="color: rgb(80, 80, 80); font-size: 11px; line-height: 19px;">Last week I was proud to chair the first Belgian </span><a href="http://pubs.opengroup.org/architecture/archimate2-doc/" style="font-size: 11px; line-height: 19px;">ArchiMate</a><span style="color: rgb(80, 80, 80); font-size: 11px; line-height: 19px;"> User Group meeting in Brussels, hosted by </span><a href="http://www.itworks.be/" style="font-size: 11px; line-height: 19px;">IT Works</a><span style="color: rgb(80, 80, 80); font-size: 11px; line-height: 19px;">. With three good speakers and a group of about 30 participants, the meeting was a big success. Hopefully we will have many more of such sessions in the years to come. </span></p><p>In this short blogpost I’ll present some of the highlights from the session. Rather than attempting to summarize the excellent talks by Jan Casteels (AXA, ING), Geert Cannaerts &amp; Christof Nikolay (both HP), and Pieter van Ostaeyen (de Lijn), I’ll stick to presenting some of the highlights.</p><ul><li>A common element in each of the three stories is “business-focused analyses”. Or, to put it differently: we spoke a lot about the type of analyses we can do for various (business) stakeholders as well as creating powerful visualizations to support decision making.</li> <li>The three speakers each used different tools (including <a href="http://archi.cetis.ac.uk/">Archi</a>, <a href="http://www.sparxsystems.com.au/">Sparx</a>, and <a href="http://www.bizzdesign.nl/tools/architect/">BiZZdesign Architect</a>).  The consensus seemed to be that all tools work as long as the focus is on modeling / entry of concepts and relations. A “proper” tool like Architect is needed when the focus shifts to analyses (i.e., color views, label views, generating views and cross tables, roadmapping and so on)</li> <li>There was a lot of discussion about different levels of models. <ul><li>On the one hand this refers to the difference between “architecture” and “design” (i.e., growing attentions to linking architecture models at the enterprise level to process management, business rule management, and data management at the design level).</li> <li>It also appeals to the difference between three levels of abstraction: conceptual, logical, and physical models. A crisp and clear distinction between these levels is far from easy, yet it is important to at least distinguish (and create links) between a “conceptual/logical” model and a “physical” model of the enterprise</li> </ul></li> <li>Other topics that were briefly discussed include </li> <li>The use of reference models for re-use and a head-start in creating consistent models across the enterprise.</li> <li>Starting ArchiMate modeling projects from the bottom-up. That is: rather than shooting for a top-down, enterprise-wide initiative, we see more and more organizations where the first ArchiMate models are developed in projects. This has the added advantage of adding business value early, as well as establishing good practices in modeling from the start!</li></ul><p>After a good discussions, we also found several areas where more support and guidance would be useful for the ArchiMate community at large. These boil down to the following:</p><ul><li>Easy exchange of models between tools: we see that different stakeholders and groups of professionals require different types of tools. At some point the necessity to integrate these models / to upgrade to a full-blown EA tool like Architect arises. Being able to seamlessly switch between tools is important. After all, it is about the content, not the tool.</li> <li>In line with the discussion on different levels of models, more guidance on conceptual / logical / physical modeling as well as tool support (i.e., the use of dependency relations in BiZZdesign Architect) will help the community to deal with this issue consistently and effectively</li> <li>Last but not least: in many situations it would be valuable to be able to represent the modality of relations between concepts. This goes for “cardinality” of associations, but it goes further than that. Being able to represent the fact that “a process always uses a services” versus “a process may optionally use a service” can be equally important</li></ul><p> All in all a great session with plenty of tips, real-world stories, and suggestions for taking ArchiMate initiatives to the next level.</p>