Keteininformatiemodellering op basis van Archimate

Transcriptie

1 Keteininformatiemodellering op basis van Archimate Notatie en voorbeelden versie 0.1 Bert Dingemans

2 Inhoudsopgave Inhoudsopgave... 2 Inleiding... 3 Archimate... 3 Domeininformatiemodellen... 4 Modellering... 6 Domeinmodellen... 6 Servicemodellen... 9 Interactiemodellen Procesmodellen Applicatiemodellen Viewpoints Are Tool Samenvatting Documenten

3 Inleiding Voor het ontwikkelen van keten- en domeininformatiemodellen en voor het ontwikkelen van ketenviews in het algemeen worden verschillende documenten opgesteld zoals: Aansluitvoorwaarden Berichtenboeken Domeinmodellen Ontwerpdocumenten Bij het uitwerken van deze documenten is een gezamenlijk model omtrent de objectinformatie die uitgewisseld wordt noodzakelijk. Hiervoor zijn verschillende notatievormen beschikbaar waarvan UML klassediagrammen en ER diagrammen de bekendste zijn. Het opstellen, beheren en communiceren van deze modellen is veelal een activiteit belegd bij ICT architecten. Voor enterprise- en ICT architecturen wordt veelal de modelleertaal Archimate van The Open Group gebruikt. Deze taal heeft sterke overeenkomsten met de UML notatie maar kent een groter bereik van modelleren. Dat sluit goed aan bij de behoefte bij het opstellen van informatiemodellen in een service georienteerde omgeving. Dit whitepaper gaat in op de mogelijkheden van de modelleertaal Archimate voor het opstellen van informatiemodellen. Hierbij wordt ingegaan op de notatiewijzen voor het opstellen van deze modellen. Daarnaast worden een aantal viewpoints uitgewerkt die voor een service georienteerde omgeving toegevoegde waarde hebben voor een ICT architect. Archimate Archimate is een modelleertaal gericht op het uitwerken van enterprise architecturen. De modelleertaal kenmerkt zich door een gestructureerde opzet. De taal is opgebouwd uit het weergeven van verschillende enterprise entiteiten of elementen en hun onderlinge relaties. Deze elementen en relaties kennen een typeindeling. Echter deze typeindeling is uitbreidbaar. Daarnaast kent Archimate een indeling in verschillende dimensies zoals een gelaagdheid en een dimensionering in aspecten als gedrag en statische structuren. Als laatste belangrijke aspect is de werkwijze met viewpoints kenmerkend voor Archimate. Archimate is sterk gerelaleerd aan Togaf van The Open Group. 3

4 Domeininformatiemodellen Bij het uitwerken van de architectuur voor een service georienteerde ICT implementatie zijn een aantal architectuurprincipes van belang, de belangrijkste zijn [Erl]: Herbruikbaarheid van services Gestandaardiseerde contracten Vindbaarheid van services Samenstelbaarheid van services Ontkoppeling van services Service autonomie Service abstractie of inkapseling Met name de eerste principes stellen eisen aan de interface zoals geboden wordt door een service. Hierbij is het van belang dat huidige en toekomstige gebruikers van een service een gemeenschappelijk (overeenstemmend) beeld hebben van de informatie die uitgewisseld wordt, haar structuur en betekenis. Het realiseren van een gemeenschappelijk beeld is geen sinecure, zeker niet binnen grote en complexe organisaties. Worden de genoemde services ook aangeboden aan afnemers buiten de organisatie dan worden de eisen aan de uitwerking van het gezamenlijke beeld nog belangrijker. Enkele voorbeelden van complicerende factoren zijn: Voor algemeen geldende termen binnen een domein bestaan veelal homoniemen en synoniemen. Ook treedt regelmatig verwarring op omdat gebruikersgroepen binnen elementen een andere indeling zien, bijvoorbeeld extra eigenschappen of relaties bij elementen. Het uitwerken van een gezamenlijk beeld in de vorm van een keten- of domeininformatiemodel draagt bij aan een overeenstemmend beeld bij de betrokkenen. Dit voorkomt misverstanden. Vervolgens kan dit model uitgebreid worden met servicemodellen waardoor met name het gestandaardiseerde contract en herbruikbaarheidsprincipe optimaal ondersteund wordt. Archimate is hierbij een optie voor het modelleren van deze modellen. Met name omdat ICT architecten Archimate reeds inzetten voor het modelleren van andere aspecten van een ICT systeem. Door eenvoudige uitbreidingen van deze notatie en het inperken van de in te zetten elementen en relaties ontstaat een eenduidige notatie die ook door niet ICT deskundigen goed te begrijpen is. In de volgende hoofdstukken werken we deze natatie en uitbreidingen uit op basis van een eenvoudig voorbeeld. In onderstaande afbeelding is te zien welke Archimate elementen een rol spelen bij het uitwerken van een keten- of domeininformatiemodel. 4

5 5

6 De volgende viewpoints en ondersteunende notatiewijzen worden onderkend binnen keteninformatiemodellen: Domeinmodellen Servicemodellen Interactiemodellen Procesmodellen Applicatiemodellen Hierbij zijn de domeinmodellen de kern en vormen de andere modellen een beeld vanuit een specifieke scope naar het gezamenlijke domeinmodel. In het volgende hoofdstuk worden deze verschillende modellen uitgewerkt en toegelicht. Modellering Domeinmodellen In de Archimatenotatie is een indeling in kolommen en lagen uitgewerkt. Een van de kolommen omvat de informatie-elementen zoals business objecten, data objecten artifacten. Deze elementen omvatten de informatie inhoud van entiteit binnen de organisatie. Het uitwerken van deze entiteiten in een model wordt in de literatuur vaak canonieke data modellering genoemd. Gezien de object georienteerde aanpak vind ik Canoniek Object Model een betere term. Met name de data objecten binnen de applicatielaag zijn vanuit het perspectief van domeinmodellering interessant. Data objecten zijn entiteiten die de informatie inhoud vanuit het perspectief van applicatiecomponenten en applicatieservices beschrijven. Het zijn dan ook geen fysieke entiteiten maar een applicatieve weergave. Een voorbeeld is bijvoorbeeld een factuur. Als data object is dit een clustering van informatie die een specifieke factuur beschrijft. Zo heeft het businessobject factuur veelal een factuurdatum, betaaldatum, geadresseerde en totaalbedrag. Het data object is een informatieclustering en structurering van deze gegevens. Een data object wordt in de applicatielaag van Archimate vervolgens fysiek gemaakt in de vorm van een bericht, een record in een database of een file. Een domeinmodel brengt vervolgens de omliggende elementen van een data object in kaart. Terug naar ons voorbeeld is een factuur gerelateerd aan één of meer factuurregels, een klant, eventueel meerdere adressen en via factuurregels aan bestellingen en artikelen. De Archimatenotatie biedt de mogelijkheid om data objecten te modelleren in relatie tot bijvoorbeeld services en applicatiefuncties of componenten. Voor het uitwerken van een enterprise architectuur is dit veelal voldoende. Echter voor het uitwerken van een domeininformatiemodel is dit onvoldoende. Daar staat behoefte aan een gedetailleerder vorm van modelleren. Domeininformatiemodellen stellen eisen aan het modelleren van: Data objecten Relaties tussen data objecten Eigenschappen van data objecten 6

7 In het voorbeeld is reeds het data object factuur genoemd en de relatie met bijvoorbeeld het klant data object. Dat is een goed voorbeeld van het detailleringsniveau gewenst bij domeinformatiemodellen. De relaties tussen data objecten kunnen binnen Archimate gemodelleerd worden met een standaard relatie. Echter binnen een domeininformatiemodel zullen hierdoor het aantal data objecten in een weergave snel toenemen en te gedetailleerd worden. Door het werken met twee verbijzonderde relaties wordt de notatie binnen een domeininformatiemodel eenvoudiger: Specialisatie, een verbijzondering van een data object. Zo kan zowel een client als insurant object een verbijzondering zijn van een persoon. Aggregatie, een data object is opgebouwd uit een aantal sub data objecten. Bijvoorbeeld een factuur is opgebouwd uit meerdere factuurregels. De combinatie van bovengenoemde drie relaties kunnen de elementen in een domeinmodel goed gemodelleerd worden. In onderstaande afbeelding een voorbeeld van de weergave voor domeinmodellen. In dit voorbeeld zijn client en insurant een specialisatie van person, daarnaast hebben zij een niet verbijzonderde relatie. Van een client wordt een aggregatie van contacten geregistreerd. Dit overzicht van data objecten en onderlinge relaties is een goed vertrekpunt om te komen tot een gemeenschappelijk model van de domeinentiteiten en de onderlinge relaties. Bij het uitwerken van een domein is dit een goed vertrekpunt. Op basis van deze modellen ontstaat vanzelf een discussie met betrokkenen over de bedoeling van objecten en onderlinge relaties. 7

8 Echter in deze notatie ontbreekt een detaillering, te weten de eigenschappen van een data object. In ons voorbeeld is reeds een aantal eigenschappen van bijvoorbeeld de factuur genoemd. Denk hierbij aan factuurdatum en totaalbedrag. Deze detaillering kan gewenst zijn in situaties waarbij over de eigenschappen een gemeenschappelijk beeld gevormd dient te worden of wanneer de uitwerking ingezet wordt binnen een implementatie traject. Voor Are is reeds een extensie ontwikkeld op basis van Archimate waarbij voor elementen subelementen opgenomen worden binnen de elementbeschrijving. Voor eigenschappen van data objecten willen we een zelfde werkwijze toepassen. Zie onderstaande afbeelding voor een voorbeeld. In de afbeelding is te zien welke eigenschappen horen bij een data object, wat het type is van de eigenschap en als laatste wat de cardinaliteit is van de eigenschap. Met andere woorden of de eigenschap verplicht is of niet. Voordeel van deze notatiewijze is dat de opbouw van de modellen gelijk blijft aan de notatie zonder deze mate van detaillering. De opbouw van deze notatie heeft grote overeenkomsten met de UML Klassediagrammen. Door het beperken van de relatietypen en verbijzondering van data objecten is het mogelijk om de toegepaste notatiewijze te communiceren met bijvoorbeeld implementatieprojecten waar de UML notatie veelal gebruikt wordt. In deze projecten kan deze notatie eenvoudig ingezet worden voor het genereren van bijvoorbeeld XSD bestanden voor berichtdefinities of omgezet worden naar relationele modellen voor database implementaties. 8

9 Servicemodellen In de vorige paragraaf is uitgewerkt hoe de data objecten voor de gehele omgeving aan elkaar gerelateerd zijn. Dit geeft een beeld van het complete canonieke object model. Echter men wil zich ook een beeld vormen op welke wijze services delen van dit object model ontsluiten. Door deze opzet ontstaat een ontsluiting van service contract informatie deel onderdeel uit maakt van een service register. Hierbij is met name de eenduidigheid van de notatiewijze ten opzichte van UML én Archimate een krachtig kenmerk. In onderstaande afbeelding een voorbeeld van een overzichtsmodel. De afbeelding toont voor de service clientdetail welke objecten vanuit het gehele model via deze service ontsloten worden. Via client worden de gegevens van de contacten en via overerving ook de eigenschappen van de Person klasse ontsloten. Deze notatie geeft geen informatie over de details zoals welke parameters er gebruikt worden door de service. In veel gevallen kan hiermee volstaan worden. Zeker bij herbruikbare services zal veelal gekozen worden om alle eigenschappen van de betrokken objecten op te nemen in het servicecontract. Is het mogelijk en heeft het toegevoegde waarde om de detaillering van de service parameters en resultaatset wel te modelleren en registreren dan is dat mogelijk. Hierbij kan de notatie eenvoudig uitgebreid worden op dezelfde wijze als de domeinmodellering. Hierbij is dan wel een uitbreiding van de notatie voor een eigenschap opgenomen. Deze 9

10 uitbreiding beschrijft de inkomende parameters en de uitgaande resultaatset. Vanzelfsprekend kan ook volstaan worden met een van beide kenmerken of geen van beiden. In onderstaande afbeelding een voorbeeld van de notatie inclusief de parameters en resultaatset notatie. In de afbeelding is de zoekparameter de lastname van de person klasse. Verder worden van de client alle eigenschappen in de resultaatset opgenomen, inclusief de overerfde eigenschappen uit Person. Voor de contacten wordt enkel het aantal contacten getoond. Interactiemodellen De archimate modellering kent het element interaction als uitwerking van een collaboration of samenwerking voor bijvoorbeeld applicaties. Bij het uitwerken van servicemodellen zoals beschreven in bovenstaande paragraaf kan het modelleren van een interactie van services interessant zijn. Wil je bijvoorbeeld de relatie leggen tussen een werkproces en de services dan zijn er situaties denkbaar waarbij bijvoorbeeld een task-service opgebouwd uit een combinatie van services niet volstaat. Denk bijvoorbeeld aan een opzet met gebruikersondersteuning in de vorm van widgets of mash ups. Ook volledige asynchroon uitgewerkte interacties die steeds meer toegepast worden binnen mobiele toepassingen zijn voorbeelden waarbij de inzet van service interacties een interessante uitwerking zijn. In onderstaande afbeelding een voorbeeld van een (service)interactiediagram. Interactiediagrammen kennen op dit moment geen detailuitwerking. Dit enerzijds omdat de behoefte hieraan niet onderkend wordt. Anderzijds omdat de notatie hierdoor de diagrammen mogelijk onoverzichtelijk worden. 10

11 De afbeelding toont hoe een clientmasterdetail (service)interactie gekoppeld is aan de services clientdetail, clientlist en contactlist. Procesmodellen Procesmodellen zijn in de uitwerking vergelijkbaar met de reeds bestaande notatie van Archimate. Een proces wordt gerelateerd aan één of meer services. Daarnaast kunnen processen vanzelfsprekend ook gekoppeld worden aan één of meer (service)interacties. De notatie komt daarmee overeen met de notatie voor interactiemodellen. Applicatiemodellen Bij organisaties waar de bovenstaande modellen en registratie ingezet wordt voor de inrichting van bijvoorbeeld een applicatie-, service- of koppelingen register kan het interessant zijn om de relatie tussen applicaties en services of applicaties en (service)interacties te registreren. In die situatie is een notatie waarbij de applicatie componenten en services (of de interacties) aan elkaar gerelateerd worden. In onderstaande voorbeeld een uitwerking van deze opzet. 11

12 Viewpoints In het vorige hoofdstuk zijn we ingegaan op de notatiewijzen voor het uitwerken van een domeininformatiemodel inclusief de omliggende entiteiten zoals services, interacties en applicaties. Deze notaties ondersteunen een aantal viewpoints voor zowel architecten als een beheerorganisatie. Hierbij een aantal relevante viewpoints: Gemeenschappelijk of meta data model, binnen de architectuurfunctie wordt de data architectuur en de daarbij horende entiteitmodellering steeds belangrijker. Een gezamenlijk beeld van het bedrijfs- of domeininformatiemodel en beschrijving van de entiteiten en hun eigenschappen draagt bij aan een vereenvoudiging van de ICT inrichting Service orientatie, service georienteerde architecturen zijn opgebouwd uit service implementaties en service contracten. Binnen de service contracten wordt op basis van bijvoorbeeld de XSD uitwerking een datamodel opgesteld. Een combinatie van het service- en domeinmodel is een basis inrichting van een service register of repository. Procesmodellering, binnen steeds meer organisatie wordt het uitwerken en beschrijven van de bedrijfsprocessen binnen een enterprise architectuur steeds belangrijker. Daarnaast ontstaan steeds meer toepassingen die BPM implementaties ondersteunenen. Een viewpoint waarbij een relatie blijft bestaan met de onderliggende services en (service)interacties draagt bij aan het inzichtelijk houden van de proces- en service inrichting. Applicatie portfolio, APM en beheerprocessen bijvoorbeeld ingericht op basis van ITIL of ASL bieden een uitwerking voor het in kaart brengen en beheren van een applicatielandschap. Een notatiewijze voor de relatie tussen applicaties en serviceen domein entiteiten biedt een weergave van de complexiteit van een dergelijk landschap. De notatiewijzen op basis van archimate en extensies is een weergave van de verschillende aspecten rond domeinobjecten en services. De notatiewijze sluit daarbij goed aan op het werkveld van de ICT of enterprise architect, met name omdat de Archimate notatie in die gemeenschap veel toegepast wordt. 12

13 Echter voor de beheerorganisatie of de gebruikersorganisatie kan het werken met de archimate notatie nog steeds verwarring geven. Daarom kunnen ook eenvoudiger notatiewijzen toegepast worden. Een aantal voorbeelden in onderstaande opsomming met voorbeelden: Matrices, vormen een eenvoudige en voor iedereen begrijpelijke weergave, complexiteit kan ontstaan zodra gekozen wordt voor meer dimensie of het verrijken van de notatie binnen de matrix Boomstructuren, in de ICT is veel gebaseerd op boomstructuren, denk bijvoorbeeld aan het filesysteem of verschillende verkenners. De werkwijze is niet voor iedere gebruikersgroep geschikt maar met name de beheerorganisatie kan baat hebben bij een ontsluiting op basis van bomen. 13

14 Nativatieschermen, voor een aantal gebruikersgroepen, met name beheerders en architecten willen zich snel een beeld kunnen vormen welke relaties één bepaalde entiteit heeft. Dit ongeacht of dit een service, een data object of een interactie is. Heeft men hiervan een beeld dan wil men vervolgens de relaties zien van één van de gerelateerde elementen. Are Tool Keten- of domeininformatiemodellen en servicemodellen worden al snel omvangrijk en complex. Dit stelt eisen aan het beheer van deze modellen. Al snel zal er daarom behoefte ontstaan aan geautomatiseerde tools. Dit kunnen eenvoudige tools zijn zoals excell bestanden met afspraken over het beheer tot complexe architectuurtools die een gehele enterprise architectuur kunnen omvatten. Op dit moment wordt er gewerkt aan een eenvoudige Open Source tool voor de ondersteuning van de hierboven beschreven modellen en het bijbehorende beheer. De afbeeldingen in dit artikel zijn een voorbeeld van de schermen die ontwikkeld worden in dit tool. Meer informatie over deze tool en de voortgang van de ontwikkeling is te vinden op (onder de sectie service register) 14

15 Samenvatting In dit whitepaper hebben we een extensie op archimate ten behoeve van canieke modellen en service modellen. Reden om deze extensie te ontwikkelen is om voor architecten een consistente notatie te ontwikkelen die aansluit bij de reeds aanwezige modelleertaal archimate. Een notatie op basis van Archimate heeft hierbij de kracht dat complexe structuren op een consistente manier worden weergegeven, waarbij verschillende mate van detaillering hierbij de verschillende behoeften van doelgroepen ondersteunt. Al snel zal de omvang van de entiteiten en hun onderlinge relaties groot worden en daarmee complex. Enerzijds biedt de notatie hiervoor ondersteuning. Anderzijds kunnen geautomatiseerde hulpmiddelen als repositories en wiki s hierbij ondersteuning bieden. Naast dit whiltepaper wordt gewerkt aan tooling en een uitwerking op basis van UML en veel toegepaste architectuurtools. Documenten Erl, T. Et al, SOA Principles of Service Design 15