Komt het op it-strategie en -architectuur aan, dan graven veel organisatie zich regelmatig in in technologie. Wat begint met een mooie architectuur, ontspoort in een Frankenstein-oplossing.
Vaak komt dit voort uit een combinatie van het gebruik van monolithische (en voor meerdere jaren aangeschafte) softwareproducten, het fenomeen ‘sunk cost’ en architecten die als gevolg daarvan als timmerman alles als een spijker (moeten) beschouwen.
Wat bedoel ik met Frankenstein-oplossingen? Een aantal voorbeelden:
- Er is maatwerk nodig om het erp-systeem geschikt te maken voor de specifieke organisatieprocessen. Er wordt gekozen om het maatwerk op zodanige manier verweven in het erp onder te brengen dat elke update van de kern leidt tot problemen. Er is niet gekozen voor loosely coupled maatwerk. Omdat daar in het it-landschap geen mogelijkheid voor was.
- De integratie-middleware biedt mogelijkheden om businesslogica te creëren en data langdurig op te slaan. Dit wordt gebruikt om tekortkomingen op bijvoorbeeld het gebied van datakwaliteit of gemis aan bepaalde benodigde data in de bronsystemen te maskeren. Daarnaast wordt vaak de fout gemaakt dat het middleware-team daar ook nog eens verantwoordelijk voor wordt.
- Er is gekozen voor een nosql-dataplatform en hiermee worden ook oplossingen gecreëerd om relationele databronnen aan te sluiten en data harmonisatie problematiek op te lossen. De oplossingen zijn niet meer te begrijpen en resulteren in autorisatie- en privacyproblemen zodra een relatie in de bron verandert.
De tools zijn in de drie voorbeelden als hamer gebruikt. Maar de oplossing is vaak niet een spijker.
Soms is er een schroef nodig, of lijm, of een click-systeem. Maar omdat we nu eenmaal een hamer in handen hebben proberen we het toch maar passend te maken. Terwijl je als kind toch al met de blokkendoos hebt geleerd dat een driehoekig blokje niet in een vierkant gat past. Tenzij je het heel creatief probeert te draaien en toch passend te maken. Of er heel hard met een hamer op slaat.
Hoe hier uit te komen?
Met de komst van cpaas (cloudplatform-as-a-service)-diensten is het gemakkelijker geworden de juiste service voor de juiste uitdaging te kiezen. Wat in het begin leek op een legodoos en waar veel afnemers bang waren voor de complexiteit die die grote set van verschillende services met zich meebrengt, blijkt dit toch een zegen te zijn. Zeker met de komst van steeds betere governance en monitoring tooling in de cloud worden de oplossingen die je ontwikkelt op basis van deze vele cpaas-diensten steeds beter beheersbaar.
Voor de architect wordt het ook makkelijker. In plaats van keuzes te moeten maken op basis van de al aangeschafte dure licenties van product x of y, is er eenvoudig te kiezen voor een nieuwe cpaas-dienst, als de betreffende uitdaging daar om vraagt. Er kan ook eenvoudiger snel gefaald worden, omdat je als het toch niet goed blijkt te werken in een proof-of-concept-situatie, je de cloudservice gewoon weer uitzet.
Het vereist wel veel kennis bij de architecten. Niet alleen op het gebied van de beschikbare clouddiensten, maar zeker ook rond de architectuurpatronen. En de gebruikskosten per dienst. Gelukkig worden de cloudleveranciers hier steeds duidelijker in. Elke leverancier heeft wel ‘opensource’ best practices en patterns waar je eenvoudig gebruik van kunt maken. En een rekenmachine om de operationele kosten beter in te kunnen schatten.
Werkplezier
Tot slot. Het is altijd moeilijk een eenmaal gekozen richting te veranderen. Zeker als er al veel geld in geïnvesteerd is. Maar denk hierbij ook na over de onderhoudskosten. En het werkplezier van degenen die het dagelijks in de lucht moeten houden. Het blijkt in de praktijk maar al te vaak dat tachtig procent van je it-budget naar onderhoud gaat, zodat er maar twintig procent overblijft voor echte innovatie. En dat it-medewerkers daardoor ontevreden vertrekken.
Zorg er als organisatie dus voor dat je architecten meer gereedschappen in hun gereedschapskist hebben dan alleen een hamer.
