SOA draait om services. En daarom is het niet verbazingwekkend dat momenteel veel mensen bezig zijn met de vraag: hoe kom je nu tot optimale services? Recent heb ik samen met twee collega's, Linda en Jan-Willem, daarover een artikel geschreven, deel 1 is inmiddels in de Computable gepubliceerd (en ik ben benieuwd wanneer deel 2 verschijnt). Kennelijk voorziet het in een behoefte, want we hebben ontzettend veel reacties gehad. Zelfs SOA “goeroe” Thomas Erl was enthousiast: hij heeft een Engelstalige versie op een zaterdagavond nog even snel geplaatst in het decembernummer van SOA Magazine. Zelf is hij trouwens ook bezig met het verzamelen van SOA Patterns voor zijn nieuwe boek dat in maart zal verschijnen. We gaan proberen hem tegen die tijd naar Nederland te halen. Kortom: de verzameling best practices neemt nu snel toe, en dat geeft de burger moed, want het zal leiden tot meer gedetailleerde methodische aanpakken voor SOA.
Toch blijkt de speurtocht naar 'de optimale service' niet zo eenvoudig. Met stip op nummer 1 staat de methode om vanuit de compositie van bedrijfsprocessen te kijken. Echter, in een recente discussie met een fervente aanhanger van deze methode kon ik het niet laten om even te benadrukken dat we dit al 15 jaar doen (volgens mijn geheugen heb ik in 1995 een opleiding Informatie Analyse gevolgd, waar deze aanpak keurig in beschreven werd), en dat we inmiddels ook wel weten dat deze 'top down' aanpak wel gewenst is, maar niet zaligmakend. Ook al wordt deze aanpak goed gefaciliteerd door de nieuwe SOA/BPM-platformen: je teveel laten leiden door de 'vraagkant' heeft ook nadelen. Om de discussie wat te voeden, gaf ik aan gecharmeerd te zijn van de 'techno' aanpak waarin m.b.v. tools het huidige gebruik van een legacy-systeem wordt geanalyseerd. Op basis van deze 'bottom up' kennis kun je een heel aardige aanzet maken van services. Hij keek me wat twijfelend aan vroeg me vervolgens wat mijn favoriete methode was. Tsja, daar moest ik hem teleurstellen, dat is eigenlijk geen methode, maar heeft te maken met verantwoordelijkheden (het mooie woord 'governance'): wat een goede service is, moet degene die ervoor verantwoordelijk is vooral zelf bepalen. De eigenaar van het stukje informatievoorziening dat de services aanbiedt moet keuzes maken. Uiteraard kunnen methoden daarbij helpen. Maar hij/zij moet op basis van de 'marktvraag' zijn beperkte middelen en resources zo inzetten dat hij aan de vraag voldoet, volgens de eisen uit de bijbehorende SLA. Een soort vrije markt-mechanisme, maar dan wel ingebed binnen enigszins gereguleerde alignment-processen in de organisatie.
Prettige feestdagen, en laten we vooral veel best practices verzamelen in 2008!
Art Ligthart
Partner bij Ordina
Beste Art,Ik ben het helemaal met je eens dat de combinatie van ’top-down’ en ‘bottum-up’ ook bij het bepalen van services als beste werkt, waarbij het ook altijd lastig blijft om daar de juiste balans in te vinden. Zoals vaak, zijn er meerdere wegen naar Rome, en is het zelden dat één specifieke weg op voorhand altijd de voorkeur heeft. Ook onze routeplanners kennen tegenwoordigen min. 3 wegen: de snelste, de kortste en de alternatieve.Vervolgens maak je echter de stap van methode naar verantwoordelijkheden en governance. En hier maak je voor mij een grote, niet 1-2-3 te volgen stap. En om te voorkomen dat we in een academische discussie terechtkomen over verantwoordelijkheidsgebieden, taken, activiteiten, processen, procedures, heb ik de volgende vraag: Begrijp ik jouw goed dat de afbakening van een service dat is wat ‘een gek definieert’ mits die gek maar wel zelf verantwoordelijk is?’Vervolgens kader je het wel weer enigszins in, maar ik denk dat de vraag vanuit de markt is om juist methoden en gereedschappen aangereikt te krijgen met een goede gebruikershandleiding om tot een adequate services-bepaling te kunnen komen, niet? Dit is volgens mij de uitdaging waar de ICT-branche voor staat. En het pasklare antwoord is er volgens mij nog niet, wel?En hierop voortdenkend het volgende: Vroeger (nog niet eens zo heel lang geleden) ging het alleen om Functionaliteiten. En functie was dan als volgt gefinieerd: die menselijke activiteit, die geautomatiseerd door het informatiesysteem kan worden afgedaan als een logische afgerond proces, bestaande uit gedefinieerde input, bewerkingstappen en gedefinieerde output. Dit roept bij mij de vraag op: waarin onderscheidt een services zich nu wezenlijk van een functie?hèt antwoord heb ik ook nog niet…prettige jaarwisseling en service-succesvol 2008Oscar Roelofsion-ip
Beste Oscar,In het genoemde artikel, waarvan deel 2 trouwens inmiddels ook is gepubliceerd in de Computable, geven we 10 methoden. Eén daarvan is de ‘methode’ om de afbakening van verantwoordelijkheden te gebruiken voor het identificeren van services: de eigenaar bepaalt wat hij gaat leveren. Niet echt een methode, klopt. Ik zou de eigenaar dus zeker aanraden ook ‘echte’ methoden te gebruiken, als analyse-instrument ter onderbouwing van zijn keuzes. Maar zoals ik kort aangaf spelen er voor de eigenaar nog meer factoren een rol, zoals bijvoorbeeld de schaarse beschikbaarheid van human resources (“zijn er mensen beschikbaar om de idealiter benodigde analyse van bedrijfsprocessen te doen?”), of kosten (“is het uitbreiden van een bestaande service niet veel duurder dan het toevoegen van een tweede service met overlap?”) . Van de andere methoden die we noemen zijn de meeste redelijk uitgebreid als ‘gebruikershandleiding’ beschikbaar. We hebben trouwens ook één methode genoemd (methode 2) waarin ‘functies’ als uitgangspunt dienen voor het identificeren van services. Het gaat wat ver om hier te discussiëren wat een ‘functie’ dan precies is, maar de meest gangbare invullingen zijn voor zover ik kan zien bruikbaar.Groet,Art