Goede koppelvlakken bieden onafhankelijkheid, keuzevrijheid en besparen geld

Veel gemeenten zijn gegijzeld door de softwareboer, zo stelt het NRC in een artikel afgelopen weekend. Wekelijks bezoek ik meerdere gemeenten die met dit artikel bedoeld worden, maar die bezoek ik met een andere insteek.  Zij willen in 2017 burgers en bedrijven een Digitaal Loket bieden en met snel veranderende wetgeving leidt dit tot een zeer dynamische werkomgeving en complexe IT-projecten. Deze gemeenten volgen een nieuw pad, ze kiezen voor onafhankelijkheid, keuzevrijheid en flexibiliteit.

Het Digitaal Loket wordt ingevuld door frontoffice-applicaties en de medewerkers van de gemeenten werken vanuit mid- en backoffice applicaties. Die applicaties moeten goed op elkaar aansluiten. Van ingevulde formulieren moet een zaak worden aangemaakt, bijlagen worden opgeslagen en informatie over de aanvrager moet bijvoorbeeld wel up-to-date zijn. Hiervoor zijn goede koppelingen nodig en een duidelijke visie en strategie op het gebied van koppelvlakken als het gaat om realisatie, herbruikbaarheid, beheer, onderhoud en uitwisselbaarheid.

 

Kwalitatief goede diensten door een servicebus

Zomaar alles aan elkaar knopen heeft geen zin, omdat dit vaak resulteert in maatwerkkoppelingen en alleen degene die ze bouwt nog weet hoe het koppelvlak eruit ziet en hoe het werkt. Met mijn klanten werk ik toe naar een situatie waarin alle softwareleveranciers met hun applicaties kunnen aansluiten op elkaar, en op een beheersbare manier. Ook Centric en PinkRoccade, die deze week live zijn gegaan met diverse koppelingen. Dit doen we door gebruik te maken van standaarden en waar geen standaard toegepast kan worden, wordt dit gedocumenteerd en overgedragen aan mijn klant die hier later op terug kan vallen. Soms wordt er zelfs een extra ‘stekker’ gemaakt die voorbereidt op het toepassen van standaarden. De standaard wordt alvast op de servicebus geïmplementeerd, maar nog niet in gebruik genomen.

Een servicebus? Dat is een centrale, technische voorziening waarmee de genoemde voordelen te behalen zijn. Het is een middel en geen doel op zich. Je kunt hierin de standaarden implementeren, applicaties aan elkaar koppelen en zorgen dat als een onderdeel van de gemeente wil gaan werken met een andere applicatie dat deze in no-time gekoppeld kan worden aan de andere applicaties. Het maakt de gemeenten onafhankelijk en flexibel. Ze zijn vrij in de keuze van leveranciers en kiezen voor de applicaties die het beste aansluiten op hun primaire behoefte: het bieden van kwalitatief goede dienstverlening aan burgers en bedrijven.

Bij één van mijn klanten werd een nieuw zaaksysteem geïmplementeerd dat met koppelvlakken op basis van standaarden ontsloten kon worden naar andere applicaties. Vanaf dag 1 was duidelijk dat de koppelvlakken toch net even anders werkten, omdat het technisch een interpretatie van de standaarden bleek te zijn die door de andere partij toch anders was ingevuld. We hebben toen de informatiebehoefte van de klant vastgelegd, de beschikbare koppelvlakken hier tegenaan gehouden en bekeken wat er technisch anders moest. Dit hebben we vervolgens zo voor die klant gebouwd en na een paar maanden hadden we het zaaksysteem volledig in de lucht. De klant was natuurlijk niet blij met de constatering dat het niet ‘plug-and-play’ was, maar technisch was dit een mooie uitdaging.

 

Schoenmaker blijf bij je leest

Verschillende leveranciers leveren in hun applicatie servicebus-achtige functionaliteit mee, maar dit moet gezien worden als een integratielaag met die applicaties. Vanuit dit oogpunt komt het voor dat er dubbele functionaliteit in huis is en van dingen dubbel doen, houd ik ook niet. Wat wel in gedachten moet blijven, is dat het gebruik van deze functionaliteit weldegelijk anders is. Met een goede integratielaag krijg je het standaard koppelvlak en de intelligentie naar de (vaak verouderde) applicaties. Deze integratielaag is dus de sleutel tot een succesvolle koppeling. Als je die gaat inzetten als (onderdeel van de) servicebus, krijg je alsnog een maatwerkkoppeling en blijf je afhankelijk van die leverancier. Houdt die rolverdeling scherp, is daarom ook mijn advies.

 

Onderweg naar goede koppelingen

Bij het koppelen van verschillende applicaties komt veel kijken. Om tot een goed stappenplan te komen voor het realiseren van een koppeling, bepaal ik samen met mijn klanten:

  • hoe zij werken;
  • wat hun informatiebehoefte is;
  • welke applicaties gebruikt worden;
  • welke koppelvlakken hierop beschikbaar zijn;
  • welke techniek hiervoor gebruikt wordt en ga zo nog maar even door…

Dat is complexe materie, maar met een gestructureerde aanpak en een duidelijke visie heel goed voor elkaar te krijgen. Een goede samenwerking met verschillende stake-holders is essentieel voor het verloop van koppeltrajecten. Als iedereen weet wat er van wie verwacht wordt en wanneer zijn we al een heel eind. Hé, waar kwamen we dat ook alweer nog meer tegen…

Afgelopen week zei één van mijn klanten nog dat hij niet wil betalen voor een applicatie waarvan zijn organisatie maar een klein deel gebruikt en voor veel minder geld hij een alternatieve oplossing kan inkopen die precies datgene doet waar zijn organisatie behoefte aan heeft (hij noemde bedragen, maar het gaat om 12,5% !!!). Juist in dit geval is het goed kunnen koppelen van die applicatie belangrijk, omdat het flexibel maakt en onafhankelijk. Ze kunnen kosten besparen en bouwen aan een vrije keuze met wie ze samenwerken. Wie de beste prijs-kwaliteit verhouding kan leveren, is spekkoper.

Frank Arts, CEO van Enable-U waar ik werk reageerde ook op het artikel van het NRC.nl met ‘Arme, arme gemeenten‘.

Performance problemen? Niet blijven wijzen!

Finger-PointingWelke IT-er kent het niet… applicaties die traag reageren en als je op zoek gaat naar de oorzaak, beland je in een situatie waarin iedereen naar elkaar wijst en zijn eigen straatje schoonveegt. Onder het motto ‘mijn applicatie was het niet, maar misschien kun je daar of daar eens kijken, want…’ wordt het gesprek vaak beëindigd en kun je weer verder zoeken. Soms wetende dat de oorzaak weldegelijk bij de applicatie lag waar je net de beheerder of leverancier van gesproken hebt, maar de vinger niet op de zere plek hebt kunnen leggen. Hoogst irritant en het kost veel tijd en geld…

De oplossing? Application performance monitoring! Bij uitstek de manier waarop goed beheer van applicaties gedaan kan worden als het gaat om hun performance. Vooral in een productie-omgeving kan het in de papieren gaan lopen als er ergens een probleem ontstaat en niet direct duidelijk is waar het euvel zich bevindt. Het onderzoeken is één, maar het daarna goed weten op te lossen is twee. Hoe sneller je bij de oorzaak bent, hoe sneller je dus ook met oplossen kan beginnen.

Klanten lopen weg, medewerkers worden ontevreden en managers raken in de stress als hun systemen niet goed draaien en omzet wordt misgelopen. Zomaar een paar gevolgen, en dat is natuurlijk niet de bedoeling. Een dergelijke situatie kost veel geld en dat kan soms direct meetbaar gemaakt worden door omzetverlies op een website, maar door verbetering van systemen kan ook extra omzet gegenereerd worden. Het sneller oplossen van optredende issues leidt onherroepelijk tot lagere beheerkosten, de MTTR wordt lager. Minder meetbaar, maar zeker noemenswaardig, is het vingerwijzen en de tijd die daarmee verloren gaat door tijd die daarmee verloren gaat en een verminderde sfeer heeft natuurlijk ook zijn impact op de productiviteit.

Het meetbaar maken van de business impact met een APM-tool als AppDynamics biedt veel voordelen. Het draagt direct bij aan de omzetcijfers, beheer- en projectkosten, inzicht en controle op de gehele IT-infrastructuur. Door vast te stellen welke business transacties cruciaal zijn en deze te monitoren, kan binnen een dag al een beeld verkregen worden waar de verbeterpunten zitten en stopt het vingerwijzen.

“Simon en Sting, da’s toch geen combinatie!”

Zondagavond speelden Sting en Paul Simon in de Ziggo Dome en dat was boven verwachting goed! Nu zijn het natuurlijk grootheden in de muziekwereld, maar of dat samen gaat qua muziekstijl? En na North Sea Jazz vorig jaar had ik er eerlijk gezegd een hard hoofd in of Paul Simon dát kon brengen wat hij en zijn Afrikaanse drumband ooit in New York Central Park ten gehore brachten in 1990 of aan het niveau van Sting kon tippen wat hij live op het podium brengt.

Op North Sea stonden Sting en Paul Simon na elkaar op het podium en was er een wereld van verschil. Paul Simon die gewoon zijn ding deed, speelde zijn hits, maar om nu te zeggen dat er erg veel swung in zat en de zaal er warm voor liep? Nee, dat niet. Sting daarentegen gaf een goede show, muzikaal sterk en vrijwel foutloos spel. Dat was bij Paul Simon dus anders, maar gisteravond brachten zij allebei het beste in elkaar naar boven. De show, die maarliefst 3 uur duurde, was van begin tot eind boeiend en van hoog niveau.

Ze speelden hun klassiekers, samen en alleen, zongen duetten en om en om, en alles met een gemixte band van 16 man sterk. Alle muzikanten bij elkaar was een bont gezelschap van heel goede muzikanten, waarvan sommigen zelfs meerdere instrumenten bespeelden. Centraal stonden natuurlijk Sting en Paul Simon zelf, maar zij lieten hun muzikanten hun moment of fame. Die kans pakten ze met beide handen aan, want de solo’s waren goed, heel goed. De uithalen van Jo Lawry (achtergrond-zangeres) waren heel indrukwekkend tijdens Mercury Falling, maar ook de solo’s van Jamey Haddad (Simon’s percussionist) en de gitaristen en toetsenisten waren een knap staaltje muziek.

Doordat ze elkaars nummers afwisselden, maar ook sommige stukken hun eigen nummers speelden, vond ik Sting muzikaal toch sterker, creatiever en met meer gevoel. Paul Simon vond ik wat aan de zoetsappige kant en van de makkelijke, losse meezingnummers. Maar al met al zeker een geslaagd concert, want wat Paul Simon aan energie miste op het podium in North Sea Jazz afgelopen jaar, maakte hij hier ruimschoots goed. Hij nam zijn band en publiek mee in zijn enthousiasme en dat maakte veel goed. Muzikaal staat hij alleen 2-0 achter tegen het fenomeen Sting. Fragile, zo zuiver, Fields of Gold, nostalgisch, Mercury Falling, kippenvel…

Opdrachtgeverschap tot in de puntjes…

Één van de opmerkingen die ik kreeg op mijn blog over korte sprints als succesfactor bij IT-projecten was dat de business goed moet weten wat zij willen. Als dat niet het geval is en de IT-afdeling dit niet goed scherp krijgt, is dat een groot risico voor de uitvoering en goede afronding van een IT-project. Maar hoe kunnen zij dat nu goed invullen? En welke rol kan de IT-afdeling hier zelf in pakken?

Goed opdrachtGEVERschap vanuit de business en goed opdrachtNEMERschap vanuit de IT is allereerst een kwestie van met elkaar bespreken wat de opdrachtomschrijving is en welke rolverdeling er gekozen wordt. We kennen de stappen business case, globaal, functioneel en technisch ontwerp, plan van aanpak en de uitvoering waarbij beide partijen een rol spelen. Die stappen moeten in elk project opnieuw gezet worden. “Maar dat kost weer extra tijd en dat doen we altijd zo…”. Ja, cliché misschien, maar het is knap vervelend om halverwege bij te moeten sturen (in het gunstigste geval) of achteraf te concluderen dat de rolverdeling niet duidelijk was.

 

IT_Project

 

Ieder mens heeft zijn eigen belevingswereld. Zo is in bovenstaande cartoon heel duidelijk te zien wat 10 verschillende mensen voor verwachtingen kunnen hebben. Des te belangrijker is het dat de neuzen dezelfde kant op komen te staan… maar hoe?

De IT-afdeling ondersteunt de business, dat is regel één! Zij vertelt de business dus niet wat zij moeten doen, maar denkt wél mee in hoe het beter kan. Daarnaast is het voor de IT-afdeling de taak om uit te leggen hoe de software gebruikt kan worden, maar wil dit in de praktijk nog wel eens doorslaan naar het uitleggen hoe de business zijn werk moet doen. Niet doen! Dat weten zij zelf veel beter, maar toch zien we een aanzienlijk verschil tussen plaatje 1 en 10.

“Communiceren is zo dicht mogelijk langs elkaar heen praten” is mij wel eens verteld, en zo is het. Het is héél verstandig om dié personen bij elkaar te zetten die elkaar begrijpen en inhoudelijk met elkaar kunnen sparren. Als opdrachtgever is het zaak om iemand naar voren te schuiven die de IT begrijpt, de nukken kent en er mee om kan gaan dat het een spelletje van 1-en en 0-en is. Aan de andere kant, is het als opdrachtnemer van belang daar afstand van te kunnen doen. De business wil snel veranderen, alles moet mogelijk zijn, maar wees realistisch over het afgeven van een prijs, tijd en planning.

Hoe meer details vooraf bekend zijn, hoe dichter bij het gewenste resultaat gekomen kan worden. Dan zit er misschien geen profiel op de band, maar hangt deze wel netjes aan een touw aan de boom in plaats van die ruwe houten planken waar je op de splinters mag zitten…

Korte sprints: de sleutel tot succes

Elke software-ontwikkelaar krijgt er mee te maken: een veranderende omgeving waarbij aanpassingen gedaan moeten worden in het project. Aanpassingen die niet voorzien waren, aanpassingen die geld en tijd kosten en dat willen we niet.

In elk project zijn er onvoorziene acties nodig, omdat niemand een volledig beeld heeft van wat er allemaal op het project afkomt. Software is complex en ‘onder water’ gebeurt veel meer dan wat er opgeschreven staat of wat er bij de projectleden bekend is. Daarom wordt er (als het goed is) ook rekening gehouden met onvoorziene werkzaamheden. De projectleider houdt hier rekening mee en ziet er op toe dat dit het resultaat van het project niet in gevaar brengt.

Te vaak gebeurt het dat er projecten over tijd en budget heen gaan. Dat er meer onvoorzien werk is, kan voorkomen. Maar vaker gebeurt het dat er door voortschreidend inzicht wijzigingen in de oorspronkelijke projectscope gedaan moeten worden. Langer lopende projecten willen nog wel eens tegen issues aanlopen als wijzigingen in software-versies, beschikbare mensen en/of tools en wijzigende infrastructuur. Het gevolg laat zich raden: extra kosten, meer tijd en dus: “wéér een mislukt IT-project”.

Om projecten succesvol te laten verlopen, is het aan te raden om met korte sprints (deelprojecten) te werken. De organisatie stelt de business case vast en hieruit rollen vaak meerdere wijzigingen die door IT doorgevoerd moeten worden. Door deze wijzigingen te verdelen in sprints, wordt voor iedereen duidelijk wat er wanneer opgeleverd moet worden en weet iedereen waar hij/zij aan toe is. Doordat de projectomvang beperkt is, kan de business case beter uitgewerkt worden en is er een beter beeld wat er allemaal bij komt kijken.

Oh ja, de business case moest eigenlijk gisteren al af zijn en daarom staat van meet af aan het project onder druk. Hoe sneller er opgeleverd kan worden, hoe beter het is. Doe de meest complexe onderdelen of onderdelen die door meerdere partijen gebruikt kunnen worden als eerste en de IT-afdeling krijgt meer grip en meer kans op succes. Door regelmatig op te leveren, krijgen zowel de organisatie die de business case oplevert als de IT-afdeling het gevoel dat het dus wel kan! Natuurlijk zijn er tegenvallers, maar als er in korte sprints gewerkt wordt, krijgt de business niet de kans om de scope van het lopende project te wijzigen. Hiervoor zijn er wijzigingsverzoeken of worden nieuwe sprints gestart. IT-projecten worden zo een stuk beheersbaarder en de samenwerking tussen IT en business verloopt een stuk soepeler.

Lees hier meer over een praktijk case bij de gemeente Rijswijk