Het huidige applicatielandschap zorgt voor het bekende spaghettiprobleem. Door een wildgroei aan databases, interfaces en toepassingen is een wirwar aan applicaties en databases ontstaan die zijn weerga niet kent. Met als resultaat een toename aan beheerkosten. En dat terwijl alle it-budgetten flink onder druk staan, of zelfs lager worden. Ook omdat de roep om innovatie en flexibiliteit groot is. Innovatie bijvoorbeeld op het vlak van data.
Organisaties willen meer halen uit waardevolle data die nu gevangen zit in het spaghettilandschap van applicaties. Hoe kom je daaruit? De ontwikkeling van een master data infrastructuur (mdi) is mijn antwoord. Maar hoe bouw je een mdi terwijl de applicatiewinkel voor iedereen open moet blijven?
Blik op data
Lange tijd heeft men gedacht dat de architectuurfunctie de oplossing zou zijn voor het onder controle houden van het applicatielandschap. Dat is slechts deels gelukt. Architectuur richt zich veelal op de langere termijn, terwijl de business nu wil schakelen om kansen en bedreigingen in de markt snel te lijf te gaan. Kortom, architectuur en businessdoelen verdragen elkaar slecht door de verschillende tijdshorizon. Een andere oplossing is in zicht. Bekijk het probleem vanuit de databril.
Als je een applicatielandschap op de keper beschouwt, is het te zien als een infrastructuur waarbinnen data wordt verzameld, verwerkt en toegankelijk gemaakt voor gebruikers. Veelal voldoet een subset van aanwezige datasoorten aan de meest cruciale informatiebehoeften. Dit gaat om masterdata: 20 procent van de data voldoet aan 80 procent van de informatiebehoefte. Deze tachtig-twintig regel heeft geleid tot het besef dat met masterdata de bedrijfskritische processen prima ondersteund worden.
Voor het vervullen van de laatste 20 procent van de niet kritische informatiebehoeften is de regel dat 80 procent van de tijd, budget en menscapaciteit ingezet moet worden. Kortom, minder is meer. Ga dus aan de gang met de masterdata waarmee veel problemen worden opgelost.
Aan de slag met masterdata
De masterdata is de belangrijkste data van een organisatie. Daarmee moet deze data aan de volgende eisen voldoen:
- Altijd beschikbaar zijn; data moet verzameld, beheerd en opgeslagen kunnen worden.
- Kwaliteit is op orde; niet alleen juistheid is een belangrijk kwaliteitsaspect, maar ook tijdigheid en beschikbaarheid op de juiste plaats op het juiste moment. Is cruciaal voor de flexibiliteit van een organisatie.
- Een centrale plaats in het applicatielandschap; 80 procent van de bedrijfskritische processen kan hiermee bediend worden;
- Effectief beheer van metagegevens: betrokkenen begrijpen de definities van masterdata. Dit bevordert onderlinge communicatie. Verder helpt het opstellen van een masterdata gegevensmodel voor de juiste modellering, en het verbinden van gegevens.
- Beheer in een zogenaamde mdi; dit kan een database zijn of een samenspel van databases. Hoe dan ook op een centrale plek en technisch zo ingericht dat masterdata snel en altijd toegankelijk is voor de juiste gebruikers.
Deze eisen zijn helder, of lijken zelfs logisch. Tegelijkertijd is de vraag hoe je deze eisen inwilligt terwijl de winkel open is. Oftewel, hoe realiseer je een mdi in het bestaande applicatielandschap waar informatievoorziening moet blijven werken?
Voordelen op een rij
Nog even de voordelen op een rij van een master data infrastructuur:
- Minder kosten voor ontwikkeling en beheer;
- Meer flexibiliteit om te voldoen aan bestaande en onvoorziene informatiebehoeften;
- Veel effectiever en efficiënter omgaan met de aanwezige middelen;
- Data optimaal inzetten voor organisatiedoelen;
en…
- een mogelijke oplossing voor het spaghettilandschapprobleem!
Het laatste voordeel is van groot belang. Dit maakt de flexibiliteitsbelofte waar van het ict-landschap. En schept zo voorwaarden om (nieuwe) business doelstellingen te bereiken.
Rationalisatie van applicaties
Met de tachtig-twintig regel op het vizier is het van groot belang dat masterdata beheerd wordt in een master data infrastructuur. Daarmee is er sprake van applicatierationalisatie waarbij de volgende stappen gezet moeten worden:
- Stel doelen vast voor masterdata;
- Bepaal de positie van de gegevens in architectuur: wat is masterdata en wat niet?;
- Start met het opstellen van de MDI, zowel technisch als conceptueel;
- Bepaal soort maste data management (mdm)-tooling
- Stel conceptueel en logisch gegevensmodel op voor de mdi
- Implementeer de mdi;
- Koppel applicaties aan mdi conform het satellietconcept: mdi centraal met daarom heen de applicaties;
- Ontkoppel ‘oude sets van data’ waar mogelijk bij bestaande procesondersteunende applicaties;
- Blijf groei van data in relatie tot nieuwe informatiebehoeften bewaken;
- Stel gegevensmanagementfunctie in die de mdi beheert.
Kansen en risico’s
Bij een succesvolle implementatie van de mdi ontstaan nieuwe kansen voor het optimaal benutten van de masterdata. Verder is bij nieuwe ontwikkelingen en initiatieven snel duidelijk of die al voorzien zijn in de bestaande mdi. Of anders gezegd, je voorkomt dat wielen op verschillende plekken opnieuw worden uitgevonden. Zo wordt een snelle time-to-market werkelijkheid. En alles blijft beheersbaar waarmee ook de flexibiliteit wordt gewaarborgd. Het is niet langer noodzakelijk steeds meer nieuwe interfaces aan te brengen tussen bestaande en nieuwe databases. Verder wordt het landschap veel overzichtelijker. En onderaan de streep betekent dit minder kosten en daarmee meer ruimte voor innovatie.
De complexiteit van het omzetten van het bestaande (spaghetti-)landschap naar een landschap waarin de mdi een centrale plaats vervult, is een risico. Immers, dit proces wordt uitgevoerd, terwijl alle informatievoorziening moet blijven werken. Want een greenfield scenario is voor velen een utopie.
Daarom is het advies om de mdi te ontwikkelen in een virtuele omgeving. En pas als het geheel gereed en getest is, te starten met het aankoppelen van applicaties aan het mdi. Dat stelt uiteraard hoge eisen aan data governance en de professionals die het project uitvoeren.
Tot slot
De belofte van masterdata beheer is groot. Met minder data meer bereiken. Data-intensieve organisaties moeten nagaan wat de meerwaarde is van een mdi. En hoe een dergelijk ambitieus project op te starten. Een aantal organisaties in ons land hebben deze slag gemaakt. De resultaten zijn veelbelovend. Doe er je voordeel mee. Maak een einde aan je dure en onbeheersbare spaghettilandschap van applicaties. Kies voor een mdi-aanpak, en er gaat een wereld open voor innovatie, overzicht, en kostenbeheersing.
Marc Govers, management consultant bij Sogeti
“Daarom is het advies om de mdi te ontwikkelen in een virtuele omgeving. En pas als het geheel gereed en getest is, te starten met het aankoppelen van applicaties aan het mdi. Dat stelt uiteraard hoge eisen aan data governance en de professionals die het project uitvoeren.”
Het is me niet helemaal duidelijk wat zo’n virtuele omgeving is. Bedoel je dat je apart van alles een MDI omgeving opzet en stapsgewijs applicaties laat conformeren hieraan?
Tja, het klinkt als een goed verhaal in theorie, maar ik heb sterk mijn twijfels aan de waarde in de praktijk.
Heel logisch geredeneerd: Men heeft spaghetti laten ontstaan in het verleden, het is dan wel heel naïef dat er bij een tweede poging (MDI) het wel goed zal gaan. Probleem zit hem eerder in de DNA dan in de (technische) oplossing.
Nu riekt het naar een leuk idee wat een hele bak geld gaat kosten en waarbij men er uiteindelijk achter komt dat het niet heeft opgeleverd wat er beoogt word.
Beste Marc Govers, geef me 1 echte bestaande case waarbij dit succesvol gerealiseerd is. Als je al zo’n case hebt is denk ik de succesfactor NIET de methodiek, maar de executie van een heel team wat blijkbaar de juiste eigenschappen had.
Het probleem zit namelijk niet in het hebben van een MDI of niet, ook zonder MDI kan het applicatielandschap gerationaliseerd worden.
In ieder geval is Gall’s law van toepassing: “A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: A complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a working simple system.”
Hmm, als ik het verhaal zo lees pleit Marc al dan niet bewust gewoon voor vendor lockin.
Ik had nu juist de indruk dat we inmiddels hebben ingezien dat we daar niets mee opschieten.
Gewoon voor alle technologieën open standaarden gebruiken, dan boeit het niet meer wat voor applicatie je hebt, je kunt er altijd voor zorgen dat het met de juiste standaard werkt, en dan is er van spaghetti geen sprake meer.
Overigens vrees ik dat de bevindingen van Henri een schot in de roos zijn.
Goed onderwerp. Eens met Galls law.
Wat ik veel tegenkom is dat er veel tijd en geld is gestoken in het opzetten van het data model en de rapportages maar dat er niet is nagedacht over het proces; 1) rapportages worden gedraaid voordat de juiste data in het datawarehouse is ingelezen en 2) als de rapportages worden opgestart heeft het desastreuse gevolgen voor de performance van het systeem. 3) De wens is niet elke vrijdag om 09:00 de rapportages te kunnen ophalen, maar elk moment het inzicht te krijgen in de laatste stand van zaken en verschillende doorsnedes te kunnen maken.
Een goed data model, de juiste BI infrastructuur en process automation om te zorgen dat het goed en betrouwbaar draait.
Is dit nu echt nieuw of het gevolg van een ‘data sprawl’ die ontstond toen mainframe verlaten werd?
Opmerkelijk dat het aan BI gehangen wordt terwijl er m.i meer te winnen valt door te voorkomen dat klanten telkens dezelfde informatie moeten geven of deze corrigeren. Betreffende BI kijk ook eens naar de poster uit 2005:
http://www.acis.org.co/intelinfo/wp-content/uploads/2011/05/Esquema-del-Modelo-de-Madurez-de-BI-TWDI.pdf
Het begint dus met het in kaart brengen van de informatiebehoefte vanuit – en de informatiestroom binnen de primaire processen van de organisatie. Als je dat goed doet heb je volgens mij je MDI al te pakken. Maar dat zegt nog niets over je IT.
IT heeft vooral te maken met het organiseren en faciliteren van het kunnen bewerken van informatie – van data dus. Via IT transporteer, bewerk, bewaar en verwijder je data. Niets meer en niets minder. Om dat zo slim mogelijk te doen moet je inderdaad niet alleen weten welke data cruciaal is voor het succes van je onderneming maar vooral ook welke functionaliteit IT moet leveren om die data te bewerken.
MDI is dus prima, maar IT architectuur en functionaliteit is daar onlosmakelijk mee verbonden.
Galls law zegt volgens mij niet dat ingewikkelde technische architectuur niet terug te draaien is. Als je informatiearchitectuur (MDI) simpeler maakt lijkt het mij mogelijk je IT architectuur daar bij aan te passen door deze te spiegelen (dienstbaar te maken) aan je MDI, vervolgens uit te faseren wat niet meer nodig blijkt en te verbeteren wat kan versterken. De noodzaak van een virtuele omgeving zie ik dan niet zo.