Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

Over de hamer en de spijkers

Computable Expert

Gijs in ‘t Veld
CTO, indaField B.V.. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Infrastructuur.

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 cloudplatform-as-a-service-diensten is het gemakkelijker geworden de juiste service voor de juiste uitdaging te kiezen"

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.

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2022-02-03T14:10:00.000Z Gijs in ‘t Veld
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.