Geen tooling zonder metamodel

Door: Rob Stovers en Willem Krijgsman

In een eerdere blog zijn we ingegaan op de ontwikkeling van GEA-tooling die we binnen het kernteam GEA hebben opgepakt. De bedoeling is om te komen tot een praktisch bruikbaar instrument, gebaseerd op een theoretisch kloppende structuur.

Een onmisbaar ‘artefact’ voor de tooling is een goed metamodel. Om tooling te kunnen opzetten en implementeren is het noodzakelijk om duidelijkheid te hebben over wat je wilt kunnen vastleggen en welke ‘logica en regels’ daarbij horen. In het GEA-boek is het metamodel beperkt tot de objecttypen die we onderkennen en hun betekenis. Bijvoorbeeld: wat verstaan we onder een ‘richtinggevende uitspraak’ of een ‘perspectief’? In een objectmodel zijn de definitierelaties weergegeven, deze geven zicht op de bestaansafhankelijkheden. Dat is een goede start, maar heeft nog niet de juiste diepgang en logica om als basis voor de tooling te dienen.

Bij het (slagje dieper) uitwerken van het metamodel kijken we naar:

Een slagje dieper

  • Welke entiteiten kennen we? (dat zijn minimaal de objecttypen zoals het boek ze beschrijft, maar mogelijk meer). Oftewel: waarover willen we gegevens/eigenschappen kunnen vastleggen?
  • Welke entiteiten hebben een relatie met elkaar en wat is de betekenis daarvan?
  • Hoe zit het met de kardinaliteit van deze relaties?
  • Welke (andere) restricties en regels gelden er?

Ook moeten we kijken naar de GEA-processen voor de totstandkoming en het onderhouden van een GEA-framework, processen waarin vraagstukken behandeld worden en oplossingsrichtingen worden vertaald naar ontwikkelingen in een portfolio om enkele voorbeelden te noemen. De processen stellen ook eisen aan wat wordt vastgelegd, bijvoorbeeld:

  • datum-tijd gegevens (wanneer hadden we vastgesteld dat …, en wat was de motivatie daarvoor);
  • welke rapportages moeten we voor de werkvormen en formele verslaglegging kunnen leveren en welke gegevens zijn daarvoor nodig
  • Statussen (is een uitspraak gevalideerd)
  • De draad kunnen oppakken in een vervolgworkshop

Kortom: een goed logisch model dat kan worden geïmplementeerd in een bepaalde toolomgeving, in ons geval Sparx Enterprise Architect.

Een stukje metamodel

Het metamodel beschrijft dus de entiteiten en hun onderlinge relaties. Een (klein) stukje metamodel zie er als volgt uit:

De relatie geven we betekenis door een omschrijving van zowel de ‘heen’ als de ‘terug’ relatie. Op deze manier bouwen we het metamodel op.

Het opbouwen van het metamodel

We zijn begonnen met het inventariseren van ‘kandidaat entiteiten’. Wat zijn de dingen waar het in een GEA-traject om draait en waarover we, naar verwachting, gegevens willen vastleggen? Om te checken of dit inderdaad entiteiten zijn hebben we gebruik gemaakt van:

  • Het GEA-stappenplan. Door alle (sub)stappen te doorlopen en te bekijken welke gegevens er in een stap worden gecreëerd en over welke entiteit of relaties deze gaan bouwen we het metamodel op. Op deze manier hebben we ook direct duidelijk welk gedeelte van het metamodel in welke stap relevant is.
  • De resultaten van een real-live casus, een uitgevoerd GEA-traject. Kunnen we alles wat we destijds hebben geregistreerd, kwijt in de logica van het model? Kunnen we het proces ondersteunen?

Het opzetten van het metamodel is balanceren. We willen niet alles ‘dichttimmeren’ en de tool volstoppen met regels en verboden. Aan de andere kant willen we recht doen aan het GEA-gedachtegoed: wat we vastleggen moet wel ‘GEA zijn’. We wegen dat zorgvuldig af.

En nu de complexe zaken!

Om complexe situaties zoals meerdere besturingslagen, keten- en netwerkorganisaties, divisiestructuren en samenwerkingsverbanden te kunnen modelleren, kennen we in GEA de modelvormen recursie, projectie en multilateraal. Daarbij gaat het niet meer over één, maar over een combinatie van enterprises. In het metamodel hebben we gekeken op welke manier we, bij gebruik van deze modelvormen, de relatie moeten leggen tussen (entiteiten van) enterprises. Ons metamodel moet voor al deze variëteiten aan situaties de basis kunnen zijn. Eenvoud, eenduidigheid en een hoge mate van ‘vanzelfsprekendheid’ zijn belangrijk voor een stabiel model. Lastig, maar we zijn er uitgekomen. Het metamodel voorziet daarmee in alle binnen GEA opgenomen modelvarianten binnen en tussen enterprises.

Wat het oplevert

Het opzetten en bediscussiëren van een metamodel levert, naast de basis voor de implementatie van de methode in een tool, nog meer op. We kijken op deze manier nog eens nauwgezet naar de hele methode, het stappenplan, de workflow, de logica, de werkvormen van co-creatie en de ondersteuning met de tooling, en de beoogde resultaten. In een metamodel is geen ruimte voor ‘ongeveer’ of ‘het is maar hoe je ernaar kijkt’. Je moet dus scherp zijn, keuzes maken en duidelijkheid creëren over de logica van de methode.

In een volgende blog kijken we naar de vertaling van het metamodel naar de implementatie ervan in Sparx Enterprise Architect. Waar lopen we tegenaan? Welke keuzes hebben we gemaakt?

1 gedachte over “Geen tooling zonder metamodel”

  1. Pingback: GEA-tooling: implementeren we generalisaties of specialisaties? - Groeiplatform GEA

Reacties zijn gesloten.