Steeds meer organisaties zien het belang van een gedegen referentiearchitectuur. In een referentiearchitectuur staan de spelregels gedefinieerd voor het ontwerpen en bouwen van informatiesystemen. Het is altijd al belangrijk geweest er een te hebben, omdat we hiermee kunnen zorgen dat iedereen volgens dezelfde bouwprincipes systemen in elkaar zet.
Maar nog niet iedereen heeft een referentiearchitectuur. Let wel, op het moment dat er een soa (service oriented architectuur) ontwikkeld moet worden, is er geen ontkomen meer aan. Een soa zonder een referentiearchitectuur is gedoemd te mislukken. Een soa zal uiteindelijk een netwerk van services vormen die samen het gehele informatiesysteem omvatten. In deze bewering neemt het woord samen een belangrijke plaats in. Om te garanderen dat al die services uiteindelijk kunnen en zullen samenwerken, moeten er eerst spelregels opgesteld worden. Zonder deze spelregels zijn we echt wel in staat om services te ontwikkelen, maar het zal een net zo lastig te integreren geheel zijn als nu onze legacy systemen. Voor die legacy systemen hebben we echter wel een excuus: initieel waren ze niet ontworpen om samen te werken. de services van een SOA moeten samenwerken.
In de referentiearchitectuur voor de SOA dienen we diverse zaken te definiëren. We geven enkele voorbeelden. Ten eerste moet er in opgenomen worden welke standaarden er voor gegevensuitwisseling voor de organisatie bestaan. Als er bijvoorbeeld adresgegevens tussen twee services uitgewisseld worden, wat is dan de exacte definitie van een adres en hoe zien deze gegevens er in XML uit? Hetzelfde geldt voor alle gegevens die tussen de services uitgewisseld worden. Denk hierbij aan klantgegevens, een factuur, een aanvraag voor een uitkering en een bestelling. We zullen hierbij moeten gaan praten met de afdeling Enterprise Data Models.
Ten tweede dienen afspraken gemaakt te worden over wie nieuwe binnenkomende gegevens controleert op correctheid. Doen de user interfaces dat zelf, of gaan we hier aparte services voor ontwikkelen? Of laten we dat aan de business process services over? Wat er ook gekozen wordt, iedereen dient dezelfde aanpak te volgen, en daarvoor dienen we dit in de referentiearchitectuur op te schrijven.
Ten derde, wat doen we met compositie? Als we echt voor elke component, transactie, interface en object een aparte basic service creëren, dan zullen we verdrinken in duizenden kleine services. Misschien is het dan beter om binnen de grenzen van de legacy applicaties (dus onder de soa) nieuwe componenten te maken, die de compositie naar meer documentgeoriënteerde services uitvoeren.
En ten vierde, als een service gegevens uit een bestaand systeem ophaalt, maar die gegevens zijn incorrect, wat doen we dan? Bijvoorbeeld, een postcode die niet bij een bepaald adres past? Is het dan de verantwoordelijkheid van de services die de legacy systemen benaderen om dit te corrigeren of niet? Dit kan serieuze consequenties hebben voor de hoger gelegen services, zoals de business process services.
Kortom, vele zaken dienen gedefinieerd te worden. Zorg daarom dat u vroeg in uw soa-project de referentiearchitectuur op papier hebt staan. Zorg dat over de belangrijke kwestie beslissingen zijn genomen. Doet u dit niet, dan weet u zeker dat elke ontwerper en elke ontwikkelaar zijn eigen beslissingen gaat nemen. De soa zal dan een netwerk van losstaande services worden. De kans dat de ultieme doelstelling van de soa dan gehaald gaat worden, is nihil. Vergeet niet, wie schrijft die blijft, dus zet zaken op papier.
