Architectuur moet systeem binden aan organisatie Automatisering Gids 21 NOVEMBER 2002 LOUIS STEVENS ACHTERGROND
Als een nieuw informatiesysteem aansluit bij de bedrijfsdoelstellingen is zijn succes verzekerd. Die afstemming is alleen lastiger dan men denkt. Louis Stevens laat zien hoe beslissend een goede softwarearchitectuur is voor het bereiken daarvan. Architecturen staan de laatste jaren sterk in de belangstelling en organisaties passen die om uiteenlopende redenen in toenemende mate toe. De gebruikelijke reden is de beheersbaarheid van de informatieverwerking te verbeteren, bijvoorbeeld door ICTprocessen in min of meer op zichzelf staande deelsystemen te verdelen. Andere redenen zijn: het gemeenschappelijk kunnen gebruiken van generieke programmatuur en het eenvoudig kunnen integreren van aan te kopen componenten. Praktijkervaringen bij verschillende organisaties die hun informatiesystemen realiseren onder architectuur, laten zien dat softwarearchitecturen een toegevoegde waarde hebben. Het toepassen van een architectuur gebeurt nog steeds met vallen en opstaan, zelden worden de mogelijkheden volledig benut. We zien bijvoorbeeld dat fraaie architecturen soms eindeloos worden bijgeschaafd, terwijl een vertaling naar realiseerbare specificaties niet van de grond komt. Regelmatig blijkt een, te zeer op technische overwegingen gebaseerde, architectuur op een aantal punten niet te voldoen aan de verwachtingen van de organisatie. Ook komt het voor dat resultaten van verschillende projecten niet goed op elkaar aansluiten en technologische beperkingen roet in het eten gooien. Wat is de toegevoegde waarde van een softwarearchitectuur? In de ICTwereld bestaan diverse definities van een architectuur. Hier volstaat een algemene en intuïtieve definitie die aansluit bij die van organisaties als het standaardisatieinstituut IEEE (Institute of Electrical and Electronics Engineers, Inc.). Met softwarearchitectuur bedoelen we de essentiële kenmerken van het geheel aan softwareproducten die, samen met de hardware, voor de korte en langere termijn de structuur van een informatiesysteem bepalen. Hoewel een architectuurontwerp een zeker abstractieniveau heeft, moet het tenminste een beeld geven van de softwareproducten waaruit het systeem bestaat, hoe deze producten samenwerken en hoe algemene eigenschappen, zoals schaalbaarheid, worden gerealiseerd. Een cruciaal uitgangspunt bij het vormgeven van een informatiesysteem zijn de eisen die een organisatie aan het systeem stelt. Een organisatie laat zich hierbij over het algemeen leiden door een complex van factoren die we kunnen omschrijven als bedrijfsdoelstellingen. Ook andere factoren, zoals technologische mogelijkheden, bepalen de vormgeving. Een succesfactor van een informatiesysteem is de mate waarin de gekozen ICToplossingen aansluiten bij de bedrijfsdoelstellingen. In de praktijk blijkt een voldoende afstemming van deze doelstellingen en oplossingen, ofwel de business & ICTalignment, vaak te ontbreken. Het gevolg hiervan is dat een informatiesysteem niet biedt wat een organisatie ervan verwacht. Een architectuur maakt het mogelijk de afstemming te vergemakkelijken. Het samenstellen van een op een organisatie toegesneden architectuurontwerp fungeert hierbij als spil in het afstemmingsproces. Brede kijk Business & ICTalignment is over het algemeen geen sinecure. Verschillende zaken maken de afstemming lastig. Ten eerste bestaat er over het algemeen geen expliciet verband tussen bedrijfsdoelstellingen en specifieke ICToplossingen. Bedrijfsdoelstellingen hebben een zeker
abstractieniveau en laten zich niet direct formuleren als specificaties voor ICToplossingen. De architectuur kan een belangrijke rol spelen bij het overbruggen van deze kloof. Zij biedt een ontwerp op hoofdlijnen en sluit als zodanig gemakkelijker aan bij het abstractieniveau van de bedrijfsdoelstellingen. Het ontwerp geeft een korte en langetermijnvisie op het gehele systeem en is daarom in staat verschillende belangen en onderwerpen vanuit diverse standpunten te belichten. Zonder de details van softwarespecificaties en door de brede kijk op het informatiesysteem is een architectuurontwerp het communicatiemiddel bij uitstek voor een vroegtijdige afstemming tussen organisatie en ICTspecialisten en alle overige betrokken partijen. Wat de business & ICTalignment verder lastig maakt, is de noodzaak niet alleen te moeten beschikken over afzonderlijke systeemonderdelen met de gewenste kwaliteit, maar ook dat het systeem als geheel de gewenste eigenschappen vertoont. De wijze waarop informatiesystemen worden ontwikkeld vormt hierbij vaak een probleem. Hedendaagse informatiesystemen bestaan meestal uit afzonderlijk ontwikkelde applicaties in combinatie met aangekochte standaardsoftwarecomponenten. In veel gevallen hebben verschillende teams op verschillende momenten deze onderdelen gebouwd en geïntegreerd met het bestaande systeem. Kenmerkend voor veel ontwikkelingstrajecten is het voor de hand liggende belang van de projectleider om op tijd en binnen budget het gewenste product op te leveren. De aandacht van het ontwikkelingsteam richt zich daarom voornamelijk op de applicatie zelf. Het succes van moderne informatiesystemen blijkt echter ook af te hangen van eigenschappen die verder gaan dan de grenzen en levensduur van de afzonderlijke systeemonderdelen. Voorbeelden van dergelijke eigenschappen zijn legio, zoals het gemak waarmee een component kan worden vervangen bij een gewijzigde bedrijfsvoering en de schaalbaarheid bij een gewijzigde systeembelasting. In feite gaat dus ook voor informatiesystemen de regel op dat het geheel meer is dan de som der delen. De architectuur overstijgt het aandachtsgebied en de levensduur van individuele applicaties en leent zich er daarom uitstekend voor om als raamwerk een informatiesysteem als geheel de gewenste structuur en eigenschappen te geven. En in het verlengde hiervan ligt de geschiktheid om ICTinitiatieven te sturen. Vragen Het derde probleem dat de business & ICTalignment parten speelt, is de toenemende complexiteit van de tegenwoordige informatiesystemen. De complexiteit ontstaat door de veelheid van en variëteit aan raakvlakken met bedrijfsprocessen, de diversiteit aan standaarden en technologieën en de integratie van uiteenlopende producten, inclusief complete systemen. Daarbij stijgen de verwachtingen ten aanzien van kwaliteit, zoals betrouwbaarheid, beschikbaarheid en beveiliging. Een architectuur biedt een raamwerk dat ingewikkelde problemen kan terugbrengen tot een aantal oplosbare problemen met onderlinge samenhang. Het raamwerk vereenvoudigt de integratie van systeemcomponenten en maakt de ontwikkeling en het beheer van informatiesystemen beheersbaar. Een architectuur is daarom zeer geschikt als middel om complexiteit te reduceren. Een eerste stap in het bepalen van een geschikte softwarearchitectuur is het verkennen van de wensen en eisen die hiervoor van belang zijn. Controlelijsten in de vorm van een aantal doelgerichte vragen zijn een krachtig hulpmiddel. Een softwarearchitectuur heeft een eigen plaats in de informatievoorziening van een organisatie. De vragen die van belang zijn voor het bepalen van een geschikte architectuur vormen daarom een speciale categorie, naast bijvoorbeeld de vragen voor het bepalen van de gewenste functionaliteit van applicaties. De onderstaande lijst toont een aantal van dergelijke vragen. De lijst geeft een beeld van het type problemen waarvoor de architectuur een oplossing kan bieden.
Aan welke bedrijfsdoelstellingen dient het informatiesysteem expliciet een bijdrage te leveren en wat houdt deze bijdrage in? Welke bedrijfsdomeinen gaan het informatiesysteem ondersteunen, wat houdt die ondersteuning in grote lijnen in en wat zijn hierbij de kritische succesfactoren? Gaat de organisatie in haar informatiebehoeften voorzien met maatwerksoftware of standaardproducten, of een combinatie van beide? Kiest de organisatie voor integrale oplossingen, zoals ERPpakketten, of is het de bedoeling oplossingen te realiseren met kleinschalige standaardpakketten? Gaat de organisatie in haar informatiebehoeften voorzien met een interne automatiseringsafdeling, door ook externe krachten in te huren, door ontwikkeling en beheer uit te besteden of door een combinatie van deze mogelijkheden? Welke nietfunctionele eisen stellen de verschillende bedrijfsprocessen aan de systemen, bijvoorbeeld eisen aan beveiliging, verwerkingscapaciteit en beschikbaarheid? Moet het nieuwe informatiesysteem ook bestaande systemen ondersteunen, bijvoorbeeld mainframeapplicaties? In hoeverre moet de architectuur een organisatiestrategie voor het uitfaseren, migreren en opwaarderen van applicaties ondersteunen? Is het de bedoeling informatie te ontsluiten via het web (internet en intranet), met clientserversessies of terminal hosting, of een combinatie van deze mogelijkheden? Wat is het beleid ten aanzien van de hardwareinfrastructuur en wat zijn de gevolgen hiervan voor de softwarearchitectuur?
Gotiek of art deco Een belangrijke keuze bij het bepalen van een geschikte architectuur is het type architectuur. Voorbeelden van typen zijn: een pipes & filtersarchitectuur, een meerlagenarchitectuur, een componentenarchitectuur en een servicegeoriënteerde architectuur. Hoewel de literatuur hier niet eenduidig in is, zouden de genoemde typen ook stijlen kunnen heten. Analoog aan bouwstijlen, zoals gotiek of art deco, bepalen kenmerkende vormgevende elementen een stijl. Een systeem met een pipes & filtersstijl, waarbij min of meer onafhankelijke processtappen (filters) door middel van voorzieningen voor berichtenverkeer (pipes) met elkaar zijn verbonden, wordt dus gemodelleerd met pipes & filters als kenmerkend vormgevend element. Hetzelfde is het geval voor de lagen in een meerlagenarchitectuur. Een verschil tussen de bouw en ICTwereld is de reden voor het toepassen van een bepaalde stijl. In de bouwwereld is dit om uitdrukking te geven aan een bepaalde levensvisie of een bepaald levensgevoel, of om esthetische redenen, terwijl in de ICTwereld stijl moet bijdragen aan praktische kwaliteiten. In de praktijk komt dit erop neer dat de gekozen stijl de essentiële kenmerken van een systeem in beeld moet kunnen brengen. Het vaststellen van de essentiële kenmerken maakt het mogelijk de meest geschikte ICToplossingen te bepalen. Als een systeem bijvoorbeeld het best beschreven kan worden als: het gegevensverkeer dat plaatsvindt tussen een aantal processen, dan komt een pipes & filtersarchitectuur in aanmerking. Als gedistribueerde verwerking een centrale rol speelt, dan valt een meerlagenarchitectuur te overwegen. Als een bedrijf systemen wil ontwikkelen en onderhouden door hergebruik, aankoop en nieuwbouw, dan is een componentenarchitectuur een mogelijkheid. En als een bedrijf via internet geautomatiseerde diensten wil afnemen op basis van afspraken met de leverancier, dan zou een servicegeoriënteerde architectuur het meest geschikt kunnen zijn. Het is gebruikelijk om verschillende stijlen te combineren. Een systeem met een
componentenarchitectuur bestaat over het algemeen uit meerdere lagen, bijvoorbeeld om de gewenste schaalbaarheid te realiseren. Servicegeoriënteerde systemen kunnen op zichzelf uit complete systemen bestaan waarvoor verschillende organisaties verantwoordelijk zijn. In het laatste geval ligt het voor de hand dat er meerdere stijlen worden toegepast. Naast het vaststellen van de essentiële kenmerken van een systeem, bijvoorbeeld aan de hand van een geschikte stijl, is het uitwerken van een architectuurontwerp een kritische succesfactor. Het ontwerpproces moet op een doelgerichte en gestructureerde wijze de afstemming met de organisatie en technologie, en de toepassing van architectuurprincipes faciliteren. Op deze wijze kunnen we voorkomen dat het bij een fraaie architectuur blijft. Voortdurende toetsing van het ontwerp aan relevante principes, zoals die van een componentenarchitectuur, spelen hierbij een prominente rol. Een component dient bijvoorbeeld maximaal samenhangende functionaliteit te vertegenwoordigen, zodat een gewijzigd bedrijfsproces hoofdzakelijk gevolgen zal hebben voor de componenten die dit proces ondersteunen. Interfaces moeten in staat zijn deze functionaliteit voor de omgeving te ontsluiten. Een component moet tot op zekere hoogte onafhankelijk van zijn omgeving kunnen functioneren, zodat een groot deel van het systeem niet vastloopt als een van de componenten faalt. En een component moet in technische zin gemakkelijk kunnen worden losgekoppeld van zijn omgeving als de component aan vervanging toe is. Verder komen bij het ontwerpproces vrijheidsgraden aan de orde, zoals de granulariteit, of korrelgrootte, van afzonderlijke componenten, en de vraag in welke mate en op welke wijze bepaalde principes dienen te worden doorgevoerd. Methoden voor architectuurontwikkeling, zoals Architecture Development Method (ADM) van OpenGroup, en technieken voor architectuurspecificatie, zoals Model Driven Architecture (MDA) van OMG en Architecture Description Markup Language (ADML) van OpenGroup en ACME, zijn hierbij van belang. Zij ondervinden een sterk toegenomen belangstelling van onder meer wetenschappers, analisten, softwareconsortia en ICTspecialisten. Grote toekomst Sinds enkele jaren verschijnen servicegeoriënteerde architecturen, of service oriented architectures (SOA), met een toenemende regelmaat in de publiciteit. Het begrip bestaat nog niet zo lang en implementaties komen nog maar sporadisch voor. Hoewel het begrip nog volop in beweging is, geven we hier een indruk aan de hand van een aantal kenmerken waarover consensus lijkt te bestaan. Deze kenmerken zijn: Geautomatiseerde diensten, zoals het verschaffen van informatie of het uitvoeren van transacties, worden verleend via interfaces waarover heldere en eenduidige afspraken zijn gemaakt. Meerdere partijen, zoals onderdelen van dezelfde organisatie of van verschillende organisaties, nemen deel aan het afnemen en verlenen van een dienst. Alleen het eindresultaat bereikt de organisatie die om de dienst vraagt, het daadwerkelijk verwerken van een verzoek onttrekt zich aan haar gezichtsveld. Omdat een partij volledig verantwoordelijk is voor het leveren van de overeengekomen diensten en meerdere partijen betrokken zijn, is de verwerking gedistribueerd en spelen uiteenlopende architectuurstijlen, implementatietechnologieën en middleware een rol (internet in het bijzonder). Het speelveld is sterk in beweging, in die zin dat er sprake kan zijn van meerdere en elkaar beconcurrerende aanbieders en dat bepaalde diensten, eventueel tijdelijk, niet beschikbaar zullen zijn.
Gartner voorziet een grote toekomst voor servicegeoriënteerde architectuur. Het analistenbureau stelt dat de benadering een revolutie kan betekenen voor de wijze waarop organisaties hun bedrijfsvoering zullen uitoefenen, en dat tegen 2007 serviceoriëntatie zich zal ontwikkelen als de belangrijkste stroming in softwarearchitectuur. De belofte houdt vooral in dat op afgesproken en gestandaardiseerde wijze partijen geautomatiseerde diensten van elkaar kunnen afnemen. Integratie van webdiensten openen hierbij geheel nieuwe mogelijkheden voor de bedrijfsvoering van bijvoorbeeld organisaties die onderdeel zijn van een supply chain (de bedrijfsactiviteiten vanaf het plaatsen van een order tot de aflevering van het bestelde product). De opkomst van serviceoriëntatie is vanuit ICTperspectief zeker geen revolutie, maar een evolutie. Principes als in grote mate onafhankelijk functionerende deelsystemen en interoperabiliteit via interfaces, treffen we ook aan bij componentoriëntatie. Vanuit technisch oogpunt zou een servicegeoriënteerde architectuur met webdiensten kunnen worden gezien als een internetgedistribueerde componentenarchitectuur. Uit bovenstaande typering blijkt dat serviceoriëntatie meer dan andere stijlen kan leiden tot buitengewoon complexe systemen. Serviceoriëntatie zal daarom een softwarearchitectuur bij uitstek de gelegenheid bieden haar toegevoegde waarde te bewijzen.
