Bij de Raad voor de Rechtspraak ging het om het project Kwaliteit En Innovatie rechterlijke macht (KEI). Na zes jaar ontwikkelen, tweehonderd miljoen euro kosten ging vier jaar geleden de stekker er uit. De nieuwe poging, Project Digitale Toegankelijkheid (DT) loopt ook al weer en tijdje.
Het programma Areaal Informatie Rijkswaterstaat / Bouwwerk Informatie Management (Airbim) is op advies van het BIT stopgezet. De operatie Basisregistratie Personen (oBRP) werd beëindigd nadat er vele jaren aan is gewerkt en meer dan honderd miljoen euro aan is besteed. Getouwtrek tussen de waterschappen resulteerde in uiteenlopende en zelfs conflicterende eisen voor het Waterschappen Tax-I-project. Het nieuwe systeem voor het innen van belasting komt na escalaties, ingebrekestellingen, pauzes, deadline-verschuivingen, testfases, externe bemiddelingen en doorstarts uiteindelijk niet van de grond. De schade werd voor de rechter geschikt. De Omgevingswet en PGB-2.0 hebben de kenmerken van gigantisch fiasco's in wording.
Als je een aantal van deze incidenten op een rij zet, heeft het er alle schijn van dat er bij de overheid iets speciaals aan de hand is. Er spelen tal van factoren, de nalatenschap van de commissie-Elias er één is. Want die laat zien dat dit probleem verre van nieuw is.
Spraakmakende voorbeelden
Twintig jaar geleden was er een aantal spraakmakende voorbeelden van it-projecten bij de overheid die volledig misgingen. Hoger Beroep Strafrechtsysteem (28 miljoen euro), CWI’s CWIntake (35 miljoen euro), Elektronisch Patiënten Dossier (driehonderd miljoen euro). Het totale schadebedrag van falende it-projecten bij de overheid werd destijds door uiteenlopende partijen al geschat op zo’n vijf miljard euro per jaar.
In 2013-2014 voerde de commissie-Elias (VVD) een parlementair onderzoek uit naar falende it-projecten bij de overheid. Een belangrijke verdienste van de commissie was de oprichting van het tijdelijke Bureau ICT-toetsing (BIT) dat eind 2020 ophield te bestaan. Het Adviescollege ICT-toetsing is de opvolger, dat globaal uit dezelfde kleine groep mensen bestaat, maar nu in een meer permanente setting. Het BIT heeft in de voorbije jaren om verstandige redenen voor honderden miljoenen aan overheids-it-projecten tegengehouden en gaf daarbij ook adviezen. Een opsomming van BIT-adviezen van de afgelopen jaren:
- Stem projecten af op de aanwezige deskundigheid;
- Beslis zorgvuldiger over het vervangen van bestaande it-systemen;
- Wees terughoudend met de ontwikkeling van ‘generieke’ functionaliteit;
- Zet de gebruiker écht centraal;
- Verbeter het inzicht in it-kosten voor vernieuwing en instandhouding;
- Geef de cio een sterkere positie;
- Geef de it-competentie een hogere waardering;
- Zorg dat duidelijk is wat het project moet gaan opleveren;
- Houd het simpel waar dat kan;
- Zet technologie en ontwikkelmethodes weloverwogen in;
- Houd de planning realistisch;
- Maak tijdig bijsturen mogelijk;
- Plan voor de gehele levensduur.
Neutraal geformuleerd
Het zal u opvallen dat de adviezen eenvoudig zijn en geen it-jargon bevatten. Ze zijn neutraal geformuleerd zodat het moeilijk is om het er mee oneens te zijn. En dat terwijl de context waarin ze gegeven werden niet bepaald low-profile was. Het ging immers over it-projecten van miljoenen die stopgezet werden of in problemen verkeerden. Onderbemensing, de dreiging van een tijdelijk bestaan en een fragiel mandaat zullen er vermoedelijk voor gezorgd hebben dat het BIT de adviezen destijds zo neutraal heeft verwoord. Laten we, om het allemaal wat prikkelender te stellen, eens een eenvoudig gedachte-experiment doen met deze BIT-adviezen. Hieronder is een aantal geherformuleerd tot een vraag.
- Wie beslist onzorgvuldig over het vervangen van bestaande it-systemen?
- Wie zet de gebruiker niet ‘echt centraal’?
- Wie heeft onvoldoende inzicht in it-kosten voor vernieuwing en instandhouding?
- Wie geeft de cio geen sterkere positie?
- Wie accepteert onduidelijkheid over wat een project moet gaan opleveren?
- Wie vraagt niet om bijstuurmomenten?
Laten we onze aandacht nu richten op organisaties die met hun falende it-projecten en scheve systemen al jaren in het nieuws zijn. Welke functionaris zou typisch worden geraadpleegd bij het beantwoorden van bovenstaande vragen? Wie zou het overzicht moeten hebben, wie beslist er, wie geeft er goedkeuring? Bij wie komt u uit? Juist. We komen uit bij de (top)managers van deze organisaties. Zij hebben de verantwoordelijkheid om it-projecten beter te richten en ze beter te laten verlopen door er beter over te beslissen.
In 'Perfecte Driehoeksverhoudingen' (zie kader) heb ik een syndroom onderzocht dat een rol speelt in het falen van it-projecten. Daarin speelt het leiderschap een cruciale rol. Leiders staan immers opgesteld voor het (aan)brengen van: richting, begrip, vertrouwen, regie, inzicht, duidelijkheid, eerlijkheid en transparantie. Dit zijn geen willekeurig bij elkaar geharkte kreten, maar de acht fatale gebreken van slecht algemeen management die, indien vergezeld met twee andere verschijnselen tot het syndroom leiden dat it-projecten om zeep helpt.
De conclusie moet daarom de volgende zijn: we hebben beter algemeen leiderschap nodig bij deze overheden, diensten en uitvoeringsorganisaties.
Boek
'Perfecte Driehoeksverhoudingen; De beste remedie tegen scheve informatietechnologie' van drs. Nico Beenker verschijnt deze maand.
ISBN 9789081531030
Prijs: € 39,95
Reacties
Is dit een opinie of een advertorial? Kunnen we straks soortgelijke bijdragen van E-book Bertje verwachten? En vertelt Nico nu echt wat we niet weten? Want is de perfecte driehoek niet gewoon de omgekeerde pyramide van too many chiefs and not enough indians door Maarten Looijen?
Voordat Elias zich over het probleem buigde hadden anderen tenslotte al geconcludeerd dat de overheid zich graag op afstand zet want de papieren tijgers zijn makkelijker te temmen dan de realiteit. En in plaats van met de voeten in de modder van de praktijk te staan boetseert bestuurlijke top dan ook liever een model voor de sturing dan een werkend dashboard. Oja, Nico vergeet nog de windows-dressing van Rijks ICT-dashboard welke de burger vooral een bedenkelijkheid geeft over het optimisme in planningen.
Wat betreft de richting is de stip aan de horizon leuk maar als je niet weet wat het beginpunt van de reis is dan weet je ook niet de duur van de reis. En hoe vaak worden ICT-projecten niet als de Haarlemmerolie voor organisatorische problemen gebruikt?
Er wordt inderdaad (te vaak) geen rekening gehouden met de eindgebruiker, terwijl die het belangrijkste is.
Voor het gemak moeten er 2 dingen worden bepaald:
1. Wat moet de software kunnen, en
2. wat mag de software niet kunnen.
Daarnaast moet ook in de opdracht worden aangegeven, dat de opdrachtgever eigenaar is/wordt van de broncode, alleen dan is overgang naar een andere leverancier mogelijk (geen vendor-lock-in dus).
In België is het geregeld, dat software die voor een overheid ontwikkeld is, automatisch OpenSource is, dat kan een hoop geld besparen.
In Nederland zijn we een ster in het opnieuw uitvinden van het wiel, zodat veel overheden software (laten) ontwikkelen, die al bestaat.
Ook zijn de Nederlandse overheden er goed in, om specificaties te veranderen, terwijl de software nog in ontwikkeling is, omdat er verkeerd begonnen is........
Ik ben eigenlijk wel benieuwd hoe dit zich verhoudt tot het bedrijfsleven. Daar zullen ook projecten falen, maar wordt het wat minder aan de grote klok gehangen als bij de overheid.
@PA VA KE, natuurlijk komen falende / afgebroken projecten ook in het bedrijfsleven voor en niet alleen op het gebied van de ICT. Wellicht net zo vaak, maar ik ken geen recente studies op dit gebied. Falen moet bij bedrijven onder de pet blijven, want het gaat om concurrentiegevoelige informatie.
Toch komt heel veel naar buiten. Bij Big Tech zie je regelmatig dat diensten niet verder worden ontwikkeld dan de testfase, of dat nieuwe releases niet meer geleverd worden en dat bijbehorende diensten uitgefaseerd worden. Een concurrent opkopen kan vaak sneller het gewenste resultaat opleveren dan doorgaan met eigen ontwikkelingen. Bij informatie-uitwisseling tussen bedrijven loopt het ook vaak spaak. Verschuivingen in marktposities zorgen veelvuldig voor het stopzetten van projecten of diensten. Dan is er niet voldoende tijd voor ROI.
Zou Japie geen actieve herinnering meer hebben aan zijn eigen schrijfsels over Equihold? Er liggen stapels studiemateriaal van mislukte projecten in de private sector want projecten kenmerken zich als een verandering met zowel interne (organisatorische) als externe (wettelijke) risico's. Verandering moet je daarom dan ook goed als doel voor stakeholders kwantificeren want Kenneth was vooral bezig met zijn vriendjes terwijl verenigingen het idee niet zo zagen zitten. Tel erbij op dat de privacywetgeving veranderde waardoor niet de code het probleem was maar vooral de eis van privacy-by-design. VoetbalTV ging hierop ten onder hoewel de rechter een commercieel belang blijkbaar ook een rechtvaardig belang vindt als het om het schenden van de privacy gaat.
En geen woord over het toepassen van bewezen faaltechnologie.
Waardoor loopt de Omgevingswet nu weer vast?
Iets met rule engines en orkestratie?
Jack, we zijn in Nederland een ster in gevolg bestrijding, waardoor we de oorzaak niet aanpakken.........
Jack,
Gaan alle rule engines niet in de eerste plaats om de (beslis)processen?
Scheve of geheel falende IT-projecten zijn een probleem dat jaarlijks tientallen miljarden kost, en niet alleen bij de overheid. De lijst met bedrijven waarbij scheve IT-systemen een rol speelden in het faillissement groeit jaar in jaar uit. Induna badmode, Kantoorinrichter Samas, Busbedrijf Oad, De Free Record shop, het ordermanagementsysteem en de webshop van V&D: in al deze gevallen gaf een uit de hand gelopen IT-project het bedrijf het laatste zetje.
Drie opmerkingen over dit stuk:
1. De overheid is georganiseerd (Tayloriaans) en ingericht op stabiliteit. Men heeft daardoor per definitie problemen met verandering en onzekere situaties. Hierdoor komen allerlei soorten projecten in problemen of falen zelfs. Er is geen sprake van een speciale situatie als het om ICT gaat.
2. Direct gevolg van 1: Het opdrachtgeverschap bij de overheid is zeer matig ontwikkeld. Men denkt dat het met een aanbesteding en wat contractmanagement voldoende geregeld is. Dat is het niet.
3. ICT-projecten komen vrijwel altijd in de problemen. ICT is een middel en geen doel. Praat daarom over doelgerichte projecten met (hooguit) een ICT-component. ICT-projecten, voor en door ICT-ers (zeker met een ICT-er als 'opdrachtgever'), hebben geen of te weinig aandacht voor het doel of toegevoegde waarde en te veel aandacht voor techniek, het middel. Daardoor is ook communicatie ingewikkeld en gemankeerd o.a door het bizarre, vaak pretentieuze jargon van ICT-ers.
Deze punten zijn ook door Cie.Elias nauwelijks onderkend. Het voormalige BIT liep o.a.daardoor doorlopend achter de feiten aan en heeft onvoldoende toegevoegde waarde opgeleverd.
Daarom: geen BIT maar BOT (O voor Opdrachtgever. Zie: https://www.viergever.info/home-nl/blog/2019/mei/bit-crisis/
Hoi Nico, per punt
:
1. Omgaan met onzekerheid is een gegeven in IT-projecten. Mijn punt is dat hooggeplaatste overheidsbestuurders moeten kunnen omgaan met deze inherente onzekerheid en beslissingen moeten kunnen nemen op het moment dat ze nog niet over alle info beschikken.
2. Leidinggeven aan aanbestedingen en het contractmanagement is ook een belangrijke managementtaak. Als je bedoelt dat je eerder genoemde overheidsbestuurders te vaak ziet wegduiken voor hun verantwoordelijkheid, en blijk geven volstrekt niet met de inhoud of het proces bekend te zijn, dan ben ik het met je eens. De aanbestedingsregels krijgen te gemakkelijk de schuld, de concurrentie gerichte dialoog kan echt prima werken.
3. Dat er een communicatiekloof bestaat tussen business en ICT ben ik met je eens, maar deze blijkt al decennia lang van beide zijden lastig overbrugbaar. Wat daarbij niet helpt is elkaar verwijten maken. We moeten met elkaar in gesprek en zien hoe het beter kan. De BIT-adviezen van de afgelopen jaren wijzen allemaal dezelfde kant op en wij mogen zo langzamerhand best wat kritischer zijn.
Beste Nico Beenker,
Dat waren niet mijn punten.
1. Zouden met onzekerheid moeten kunnen omgaan. Maar de cultuur is er niet naar. Ongeacht ICT (Hoeveel projecten zonder ICT-component zijn er de afgelopen jaren niet mislukt,,op volstrekt vergelijkbare wijze?).
2. Opdrachtgeverschap is het probleem. Ongeacht ICT.
3. BIT (of hoe het nu mag heten) en eerder Elias hebben/hadden verkeerde focus, namelijk op ICT. Maar daar ligt het probleem niet. Daarom zien/zagen zij symptomen en geen oorzaken (opdrachtgeverschap, ongeacht ICT).
Zie dat auteur reageert alleen jammer dat een scheve schuldenlast door duur onroerend goed op het conto van de ICT geschoven wordt. Wat betreft de fysieke winkels is de ICT natuurlijk wel debet aan de inkomstenderving want wie koopt er tegenwoordig nog een boek als je een compleet ander delivery model hebt door internet?
En daarom ben ik het niet eens met Nico V. over ICT als middel omdat de facilitaire mogelijkheden van het netwerk voor veranderingen zorgen in de maatschappij. Een probleem wat al door de WRR onderkent werd voordat Elias aan zijn onderzoek begon want de overheid is nog teveel georganiseerd in de bekende loketten. En daarom eens - Jack? - met de opmerking over de Tayloriaanse organisatie als we kijken naar de beslisprocessen waar het denken uitgehaald is.
Is er ook niet wat weinig selectiedruk? Je zou als opdrachtgever binnen de overheid een project moeten indienen met begroting. De nuttigste voor het minste geld krijgen goedkeuring van Bit of opvolger en voor dat budget moet je het dan gaan doen. Gebruikmaking van in andere projecten gerealiseerde functionaliteit en architectuur draagt bij tot de kans op goedkeuring. Als je denkt dat het niet gaat lukken, moet je zo vroeg mogelijk de uitgaven stelpen en mogelijkheden tot bijsturing onderzoeken. Als de opdrachtgever risico kan afwentelen op aannemers en onderaannemers strekt dat tot aanbeveling. Aannemers dienen waarschuwingsplicht te hebben inzake slecht gediende algemene randvoorwaarden zoals schaalbaarheid in performance, deployment en data-omvang, mogelijk gewenste interconnectiviteit en andere integratiemogelijkheden. Of de aannemer daarbij verzaakt door ondeskundigheid of nadelige aspecten opzettelijk verzweeg is daarbij niet van belang.
Bij een mislukt project wordt de rol van de opdrachtgever geëvalueerd. Is daarbij sprake van ondeskundigheid, lankmoedig optreden jegens uitvoerders, onachtzaamheid, ontijdig ingrijpen bij een zich aftekenend debacle e.d., zou dat consequenties moeten hebben (zoals verhaal op het algemene budget van de betreffende overheidsinstelling, achterstelling bij nieuwe aanvragen e.d.).
Tenslotte zou in de aanvraag nog inzichtelijk moeten worden gemaakt dat de revenuen daadwerkelijk zullen worden gehaald. Een leidinggevende van een opdrachtgever die bij voorbaat al weet dat een bepaalde dienst of afdeling niet zal worden ontmanteld (omdat handhaven goedkoper is en minder risico's oplevert) of bijvoorbeeld een applicatie die 'disruptive' zal gaan werken op bestaande verdienmodellen (waarvan de begunstigde personen cruciaal zijn voor het welslagen van het project), kan van duidelijk zijn dat de achterliggende doelstellingen van het project helemaal niet gehaald zullen (kunnen) worden. Dat zijn juist de projecten van het slag dat heul veul tegenslag ondervindt.
@Koelmans zou allemaal moeten. Gebeurt niet.
Zelfs evaluatie van beleid gebeurt niet. Aantal jaren terug aangekaart door Algemene Rekenkamer. Volgens toenmalig MinFin Dijsselbloem niet nodig en onhaalbaar. Deze mening werd ondersteunend door de "huiseconoom" van Nieuwsuur.
Het punt: als het op dit niveau al zo misgaat, hoef je op het niveau van projecten ook niet veel te verwachten.
'Culture eats strategy for breakfast'
Hoi Nico,
Nog even terug komend op jouw opmerking “dat zijn mijn punten niet” van eergisteren. Als ik niet de intentie had gehad om serieus op je punten in te gaan zou het niet best zijn. Die intentie heb ik wel, dus bij deze nog een keertje in de herkansing.
Ad 1: Of het nu een Tayloriaans of een cultuurprobleem is zoals je aangeeft, kunnen we volgens mij in het midden laten. Feit is dat het publieke leiderschap inadequaat omgaat met de ingebakken onzekerheid die IT-projecten nu eenmaal hebben, vooral door er ongelukkige beslissingen over te nemen. De BIT-adviezen van de afgelopen jaren slaan daar op, ik heb ze voor de grap gewoon eens onder elkaar gezet. Ze wijzen allemaal naar deze zelfde groep hooggeplaatste bestuurders. Ik vind dat een kwalijke zaak.
Ad 2: Het punt van slecht opdrachtgeverschap dat je aansneed. Of ze op andere managementgebieden ook slecht opdrachtgeverschap vertonen kan ik minder goed beoordelen. Het zou me niet heel erg verbazen, maar ik kan die conclusie niet voor mijn rekening nemen. Leidinggeven aan IT-aanbestedingen en het IT-contractmanagement is hoe dan ook in iedere grote organisatie een belangrijke managementtaak, en het valt bij de overheid(en) op dat ze dat in heel veel gevallen niet goed doen. En dat is dus niet goed.
Ad 3: Het is niet correct dat de commissie Elias in haar aanbevelingen destijds het probleem van slecht opdrachtgeverschap niet heeft aangekaart, integendeel. Er stonden daarover hele concrete aanbevelingen in het eindrapport. En daarbij, de commissie Elias is langs democratische wegen tot stand gekomen. Hun focus, hun opdracht en hun mandaat was door de Tweede Kamer vastgesteld. Ik vond het destijds goed dat het gebeurde en ook de oprichting van het BIT (nu Adviescollege ICT-toetsing) was verstandig. Het is jammer dat er de afgelopen 15 jaar niet is doorgepakt, maar dat is een ander gespreksonderwerp.
Groet,
Nico
Beste Nico,
Ik verschil vaak van mening met ICT-ers. Ook in dit geval.
Terugkomend op "dat zijn mijn punten niet": ik zie vrijwel structureel dat ICT-ers niet reageren op wat iemand van buiten de sector zegt, maar zij gaan in op hun mijlenver verwijderde perceptie. Dat zag ik in jouw reactie ook.
Wat Elias betreft: dan hebben wij erg verschillende definities van goed opdrachtgeverschap.
Stuurlui aan de wal die het hebben over mijlenver verwijderde perceptie moeten wel wat nauwkeuriger zijn want gaat het hier om de zee- of landmijlen? Definities blijven tenslotte lastig als deze de basis vormen van de stip aan de horizon als we kijken naar het oordeel van de Commissie Elias over de inhuur van externe consultants. Want hoe langer de reis duurt hoe profijtelijker deze wordt en letterlijk stond in het rapport dan ook iets over de vos die op de kippen moet passen als het om een volwaardige gesprekspartner met ICT-marktpartijen gaat.
Dat klopt. Alleen had Elias op geen enkele wijze in de gaten dat de "tamme" vos, de CIO, veel gevaarlijker is en was dan zijn commerciële, wilde variant. Meestal wordt over het hoofd gezien dat een interne leverancier ook eigen belangen heeft en dat de interne leverancier daardoor ongeschikt is om als opdrachtgever op te treden.
Elias gaf geen moment teken van begrip toen de toenmalige directeur Public Sector van LogicaCMG, een goede kennis van mij, werd bevraagd. Ook hij klaagde over gebrekkig, vrijwel afwezig opdrachtgeverschap, tot ergernis van Elias.
Wat dat alsmaar terugkerende cliché van stuurlui en wal betreft: dat zou in deze context zeer goed waar kunnen zijn. De stuurlui aan het roer doen het immers niet best.
Maar met het perspectief van een verdeel-en-heers strategie:
Misschien doen de stuurlui het juist erg goed? En is de twijfel rondom zee- of landmijnen daarin juist helpend?
@Nico, de tamme CIO neemt wellicht niet altijd zijn verantwoordelijkheden en de interne leverancier kan te klein zijn om als uitvoerend opdrachtgever op te treden. Maar dit geldt net zo goed voor het bedrijfsleven. De opdrachtgever (overheidsinstelling, bedrijf) wil enerzijds meer automatiseren / moet regelmatig de systemen technisch vernieuwen, maar wil of moet tegelijkertijd ook innoveren. En accountmanagers beloven te vaak te veel bij grootschalige projecten die ze zelf niet kunnen overzien. Een tehuis runnen voor honderd kinderen is heel wat anders dan 100 kinderen laten verzorgen door 50 gezinnen met 2 kinderen. Maar de toezegging dat het kan (met disclaimer) is precies wat de opdrachtgever wil horen. Daarbij is er vaak sprake van een onvoldoende concrete opdracht, te weinig commitment, te weinig geld, te weinig tijd, enz. Een goede CIO ziet de valkuilen die door de betrokkenen zelf gegraven worden, omdat leiders falen. Maar als de CIO en CEO faalt, dan wordt het Yes we can not.
Ik kan niet oordelen over enig teken van begrip vanuit Elias in een gesprek of ergenissen daarin aangezien dat nogal subjectief is. Wat betreft een terugkerend cliché van de stuurlui aan de wal in het verwachtingsmanagement lijkt het me wel beter om mijlenver van de onderbuik gevoelens te blijven. Oja, de opmerking van Japie over schaalbaarheid in het Tayloriaanse denken betreft niet zo zeer de uitvoer maar de governance waarbij ik een gebrek aan kennis in sturing vermoed. En binnen de overheid staan de letters CIO voor Carriére Is Over omdat het een functie zonder betekenis is, een vanuit Amerika overgewaaide rol die eigenlijk niet goed past in de organisatiestructuur van de overheid.
Ton Elias, was dat niet degene die niet wist wat een IP adres is? :-)
@Jaap: oneens met jouw mening over de CIO. Een CIO is een interne dienstverlener/ interne leverancier en kan alleen optreden als opdrachtgever voor de harde ICT-kant, zaken die te maken hebben met de infra.
Helaas zetten veel organisaties (daar heb je gelijk in), ook de overheid, deze rol ook in bij opdrachtgeverschap voor b.v. applicatieontwikkeling. In die gevallen is er vrijwel zeker sprake van ineffectief opdrachtgeverschap, vaak zelfs nog gevaarlijker dan wanneer je de klus commercieel volledig uitbesteedt.
Op min site schreef ik daarover over diverse voorbeelden, zoals SPEER (MinDef) en Aldi.
Daarom zit daar ook de probleem van het BIT; onder de CIO.
@Nico, de Chief Information Officer is dus voor jou een Chief Infrastructure Officer (al la Capgemini)? Dit is in mijn ogen meer een CTO. Anderen zien de CIO meer als Chief Innovation Officer. Wat je allemaal met drie dezelfde letter kan (vooral in de ICT). Elke CxO moet aangeven waar niet alleen de letters voor staan, maar vooral ook wat de functie inhoudt. Anders worden mensen opgezadeld met de verantwoordelijkheid van een ander of erger er kan een verantwoordelijkheid nergens belegd zijn. Die ligt ergens achter een schutting, zoals de programma- en projectmanagers snel zullen merken.
Normaal is de CIO verantwoordelijk voor de inkoop van ICT (en niet meer de CFO) en soms ook voor zaken als GDPR. Het zou niet moeten uitmaken of er extern of intern wordt ingekocht en of dat intern deels weer wordt uitbesteed. De CIO moet geen conflicterende petten accepteren en bijvoorbeeld verantwoordelijkheid nemen om systemen te ontwikkelen. Dan moet de CIO eigen vlees gaan keuren. De interne ontwikkelorganisatie is uiteindelijk een profit center die moet kunnen concurreren. De CIO is er voor het bedrijfsbelang en kan opdrachtgever zijn voor b.v. applicatieontwikkeling. Bij grote gedifferentieerde organisaties, is het beter dat de baas van de gebruikersorganisatie opdrachtgever van applicatieontwikkeling wordt. Maar mij lijkt het vooral belangrijk dat de taken, verantwoordelijkheden, bevoegdheden (dus ook mandateren) logisch belegd zijn en behapbaar.
Voordat ik überhaupt iets gedaan krijg bij een overheids organisatie, bijvoorbeeld een simpele POC, ben ik al een jaar verder voordat ik alle 26 afdelingen en 200 chefs heb gesproken die allemaal uiteraard iets te zeggen moeten hebben, vooral voor eigen functie-behoud. En dan mogen we aan de hand van 2 miljoen requierments, die vaak haaks op elkaar staan, een oplossing bedenken voor het e.e.a. En of dat nu over software of hardware gaat, maakt niet uit. En dan maar klagen dat het aan de IT ligt.
Niels, dat is het nadeel, wanneer iedere overheid en/of instantie zelf het wiel wil uitvinden.
Gebruik maken van ervaring van anderen is blijkbaar moeilijk.
@Niels, ik was vrijwel altijd in de gelukkige omstandigheid dat ik ze dan veel succes kon wensen en eruit kon stappen. Het heeft geen enkele zin om te gaan pappen en nathouden behalve misshien dat je je hypotheek ermee kunt betalen. Je pleegt door te blijven een enorme aanslag op je kennisniveau op langere termijn want dat soort gekkengestichten vormt dan op een gegeven moment nog je enige referentiekader.
Pragmatische sales jongens zoals Niels willen graag een PoC maar vaak is dat één van de vele puntoplossingen die voor een silo zorgt waardoor ik de anderen alweer hoor klagen dat er niet onder architectuur gewerkt wordt. En met onder architectuur werken bedoel ik grip krijgen op zoiets als de informatievoorziening want specificaties hebben veelal tot doel om tot een open standaard te komen. De gegevensuitwisselingen tussen systemen mogen bijvoorbeeld niet op hindernissen stuiten zoals leveranciersafhankelijke intellectuele eigendommen. Kortom, verkopen van licenties middels een PoC is dan ook geen oplossing voor de problematiek als we kijken naar de miljarden die de overheid jaarlijks moet betalen voor het gebruik van software.
Het probleem is en blijft de Tayloriaanse, gefragmenteerde, silo-organisatie van de overheid die het laatste decennium alleen maar erger is geworden. Met daar direct aan gekoppeld zeer gebrekkig opdrachtgeverschap.
Daar komen projecten van allerlei aard doorlopend ernstig door in de problemen. Vooral wanneer de focus ligt op het middel (b.v. ICT) en niet op het doel. De focus op middel i.p.v. doel is trouwens ook een vrijwel onvermijdelijk gevolg van de silo-organisatie; elke silo wil wat het beste is voor hun deel. Een hoger doel wordt daarbij uit het oog verloren.
Jaren geleden ben ik als adviseur van een parlementariër betrokken geweest bij de analyse van misschien wel de grootste ICT-faal van de overheid ooit, tekenend voor de overheid: SPEER van Defensie. Ik heb daarover verschillende analyses geschreven.
Voor de geïnteresseerde: In deze blog een beschrijving van de problemen en in het vervolg een alternatieve aanpak.
https://www.viergever.info/home-nl/blog/2016/augustus/speer-organisatiecultuur/
Allerlei secundaire voorwaarden zoals schaalbaarheid, integreerbaarheid, optimale levensduur, kortom dingen die in de afgelopen twintig jaar honderdmaal eenvoudiger zijn te waarborgen door de-facto standaards en breed ontwikkelde 'best practices' (vanzelf zijn gewaarborgd zelfs) zijn bij de overheid duizendmaal zo moeilijk gemaakt. Deels door ondeskundigheid op detailniveau, deels omdat er politiek mee wordt bedreven. Dingen die in de afgelopen decennia honderd maal goedkoper zijn geworden, zijn bij de overheid tienduizend maal duurder geworden. Echt duizelingwekkende budgetten voor dingen die je kwalitatief perfect op iedere straathoek kunt kopen of krijgen, worden 'from scratch' ontwikkeld met code-generatoren e.d. met gegarandeerde troep als resultaat. Gebrekkig opdrachtgeverschap van de overheid is de understatement van de eeuw. Ik bekeek twee of drie jaar geleden een keer een project dat een minister op Github had laten zitten nadat het was afgeblazen en een paar honderd miljoen of zo had gekost. Alleen maar een paar honderd meg uit XML gegenereerde rotzooi.
Adviseur van een parlementariër lijkt me wat anders dan een parlementaire commissie want ik kan ook uit eigen werk citeren aangaande onderzoeken van overheidsprojecten. En ja, de overheid is geen (worsten)fabriek terwijl Tayloriaanse organisatiestructuren zich toch vooral kenmerken door het idee van efficiëntie verbetering op basis van processen welke veel overeenkomsten hebben met een lopende band. Nu valt er ook iets positief te zeggen over een overheid die probeert verrassingen te voorkomen middels procesmatig werken want Donner was in 2013 abuis toen hij stelde dat worst lekker is maar dat je niet wilt weten hoe deze gemaakt wordt. Juist in de nieuwe bestuurscultuur van 2022 willen we weten hoe de worsten gemaakt worden omdat de worst er niet lekkerder op is geworden maar wel duurder door een vleestax.
Understatement van de eeuw komt van ouwe verkoper Robbie K. omdat open standaarden zonder intellectuele eigendommen veelal goedkoper schalen, een oplossing op basis van gemeten verbruik is tenslotte als het verdienmodel van de Hypotheker als verkopers jaarlijks provisie krijgen. Ik wil niet het eigen nest bevuilen maar de verkoop van software is uiteindelijk iets heel anders dan de ontwikkeling ervan.
Ja, Oud-lid.
De overheid is geen worstenfabriek maar wel een machinebureaucratie; het bureaucratische vervolg op Taylor. Dat heeft heel veel overeenkomsten: gericht op standaardisatie en efficiëntie. Maar een machinebureaucratie is door typisch Tayloriaanse silo's resulterend in versnippering en fragmentatie en daardoor schijnefficiënt en ernstig leidend tot suboptimalisatie. Daardoor uiteindelijk ineffectief, zeker wanneer het gaat om uitzonderingen, crisismanagement en verandering (projecten).
Het boek The Goal van Goldratt zou over de overheid kunnen gaan waar het verhaal gaat over een manager op het hoofdkantoor die zich druk maakt over efficiëntie en standaardisatie en zich totaal niet druk maakt over de ineffectiviteit die hij daarmee veroorzaakt en zelfs aanjaagt.
@Nico, helemaal eens.
@Oudlid, je kunt het weer mooi verklarenn. Het ligt allemaal niet aan de overheid maar aan mij als incapabel observeerder. Maar de trackrecord van de overheid liegt niet. Misschien moeten de it-media eens naar een paar succesverhalen op zoek bij de overheid. Daar zouden er op zijn minst toch wel een paar van moeten zijn.
Grote dienstverlenende organisaties zoals de overheid kennen vaak een machinebureaucratie als organisatiestructuur omdat processen uiteindelijk door allerlei wet- en regelgeving bepaald worden waardoor we een grote regeldruk hebben. En oud rapport (2006) noemt de modificatie als probleem hierin omdat de 'regelfabriek' dus steeds vaker maatschappelijke veranderingen probeert te bewerkstelligen middels wetgeving vanuit een digitaal optimisme aangaande de codificatie. Recentelijk voorbeeld hiervan is de pandemie waardoor er uiteindelijk meer geld naar een symptoombestrijding (QR-code?) ging dan naar genezing.
Wat betreft de 'Hugonoten' van Donner laat de huidige kwaliteit van wetgeving dan ook nogal te wensen over als we kijken naar de systeemeffecten op z'n Amerikaans als het om de accountabilitity & opportunity costs gaat. Leuke hierin zijn dus de vragen zoals: ‘Kan ik mijn keuze publiekelijk verantwoorden?’ of ‘In wiens belang is dit?' want de concurrentiebelemmerende afspraken zijn een slecht werkend instrumentarium in de modificatie van de markt. Oja, Robbie moet nog maar eens mijn reactie lezen van 6 april 23:37 want een codificatie van integriteit in regels zorgt ervoor dat je de dialoog met de markt dichtmetselt waardoor sommigen de achterdeurtjes zoeken met een PoC.
Oja, ik ben een groot voorstander van de ToC omdat het investeren in een niet-knelpunt uiteindelijk een verlies is als je inspanning maar weinig rendement geeft. En zoals gezegd zijn de accountabilitity & opportunity costs hierin meerzeggend dan de directe kosten want uiteindelijk is een miljard aan ontwikkelkosten geen verlies als dat een miljard aan uitkeringen scheelt;-)
@Oudlid, klinkt voortdurend allemaal heel indrukwekkend. Benieuwd naar eventuele wapenfeiten.
https://www.youtube.com/watch?v=2V8sFfQo6SA vroeger was alles beter, maar calling names blijft leuk, nietwaar eddy baby ;-)
Oudlid: een machinebureaucratie heeft niet noodzakelijk te maken met wet- en regelgeving. Het is een keuze van grote bureaucratische organisaties die, omdat er geen of beperkte concurrentie is, zich niet hoeven te focussen op effectiviteit en verbetering. Daarom ligt de focus op het zo efficiënt mogelijk maken. Daarmee helpt de organisatie de effectiviteit langzaam maar zeker om zeep.
Met dit verschijnsel had Henry Ford, als volger van Fred.Taylor te maken. Hij moest aanpassen of failliet gaan. Ook financiële instellingen en b.v. telecom hebben hiermee te maken. Zodra een zich anders gedragende concurrent op de markt komt, is er een probleem. Maar de overheid heeft per definitie geen concurrentie en kan, gestuurd door politici die op een domme manier een kleinere en meer efficiënte overheid nastreven, doorgaan met steeds meer "efficiënt" gefragmenteerd en in silos organiseren. Niet alleen wordt de overheid daardoor minder effectief en groter/duurder (Goldratt heeft gelijk), ook is het steeds minder mogelijk om iemand aan te spreken; iedere betrokkene kan naar een ander wijzen.
Je schrijft een voorstander van ToC te zijn. Het bovenstaande is het hart van ToC; focus op efficientie leidt tot ineffectiviteit. Focus op effectiviteit leidt tot efficiëntie als bijproduct. Dat heeft de Japanse industrie al veel eerder en veel beter door dan Goldratt.
@Nico, je hebt voortdurend helemaal gelijk maar - meegaan in dit soort kuldiscussies - heeft geen enkele zin als eerst iedere vorm van zelfontplooiing en zelflerend vermogen van een organisatie is doodgeslagen.
Je begeeft je dan op het terrein waar mensen die zelf helemaal niets kunnen (zoals vermoedelijk Oudlid) zich het liefst op manifesteren (daar kun je namelijk allerlei badinerende praatjes hanteren over allerlei rand- en nevenvoorwaarden waarvan de gesprekspartners verondersteld worden niets te weten).
Het belangrijkste is het inzicht dat hierdoor projecten zeer risicovol en extreem moeilijk worden.
SPEER was in de toenmalige opzet kansloos, want in een extreme silo-organisatie aangestuurd door een manager van een stafafdeling (CIO) gericht op het middel, niet op het doel.
Operatie Basisregistratie Personen was kansloos want in een extreem versnipperd landschap aangestuurd door iemand die zich gedroeg als een CFO; alleen oog voor tijd en geld.
Maar ook zonder ICT gaat veel mis. Denk aan Defensievoertuigen die te groot waren en politieauto's die niet voldeden.
Dit alles door versnippering en als gevolg daarvan macht bij stafmedewerkers die zich primair richten op (inkoop)procedures, budgetten en middelen, niet op doelen.
Nico V. dresseert zijn stokpaardjes maar ik denk dat Elias een hele goede reden had om zijn schouders op te halen over goed opdrachtgeverschap. Tenslotte kent goed opdrachtgeverschap geen wettelijke verplichtingen maar goed bestuur wel, net als goed werkgeverschap. Verder zijn kenmerken zoals de routinematige taken, regels, procedures en specialisatie ook van toepassing voor een vereniging in de zaterdagcompetitie. En ik had dus ook kunnen zeggen dat voetbal leuk is maar dat we niet willen weten hoe je een voetbalvereniging bestuurt want met 17 miljoen voetbalcoaches langs de lijn hebben we een enorm bestuurlijk kapitaal.
Als we naar rand- en nevenvoorwaarden waarvan de gesprekspartners verondersteld worden niets te weten kijken dan hoef ik niet te vragen wat de wapenfeiten van Robbie Konijn zijn. Ik reageer gekscherend met enigszins cryptische reacties maar ik kan een aardig potje schaken als het om regels gaat want de kuldiscussie gaat namelijk om de bestuurlijke kant van de ICT. En adoptie van Amerikaanse managementparadigma's is leuk maar een vertaling naar de Nederlandse (statutaire) realiteit leert dat je indrukwekkende titels op je visitekaartje kunt zetten maar dat dit nog niks zegt over je bevoegdheid.
Zalig zijn de onwetenden want de Anglo-Amerikaanse managementparadigma's zijn leuk maar in de vertaling gaat nog veel mis want Theory of Constraints (TOC) gaat volgens mij om de optimalisatie van een BEHEERSBAAR systeem door een klein aantal beperkingen weg te nemen. En volgens mij gaat beheersbaar om CONTROLE terwijl beheerbaar meer om het ONDERHOUD gaat. Niks nieuws voor mijn antogonisten want één van de redenen voor RACI-matrix is dat gesprekspartners verondersteld worden te weten van rand- en nevenvoorwaarden waarvoor ze de verantwoordelijkheid dragen. En klein puntje van aandacht is dat de WBTR een wettelijke verplichting tot professionalisering van het bestuur is met voor vele amateurclubs dus niet alleen een onderhoud aan de statuten want de GOTO van de spaghetti-codificatie in de verwijzingen naar reglementen doen me denken aan Kafka.
Oja, de overheid schuift graag taken naar maatschappelijke organisaties als ik kijk naar 'bezuinigingen' in het sociale domein waarin ik met belangstelling de financiële kant volg. Tenslotte zijn sommige privatisering nogal bedenkelijk als we naar de bestuurlijke verstrengelingen van belangen kijken, domme politici besturen namelijk niet dit land.
Hier gekscherend en cryptisch maar in 't echt bennik kei-goed.
als antwoord op "wat heb je nou eigenlijk ooit gedaan ?"
die over focus was ook een topper. op effectiviteit en efficiëntie als bijproduct enzo.
heerlijk he, dat vrijblijvend ouwehoeren.
Jullie passen prima in een ic-project-bij-de-overheid.
IT-projecten bij de overheid (maar ook elders) falen vooral door het uitblijven van een adequate 5GL.
Wel graag in combinatie met een 4GL (SQL) naar keuze:
https://dmcommunity.org/2021/09/02/is-sql-for-business-or-it/
Overigens is deze visie al eerder geopperd, maar kwam destijds niet van de grond:
https://www.computable.nl/artikel/opinie/development/1855254/1509029/5gl-springlevend.html
https://www.computable.nl/artikel/opinie/development/1880473/1509029/5gl-springlevend.html
Maar die aanpak was dan ook een voorloper van de huidige lowcode/nocode:
“… een combinatie van wat in de markt wordt aangeduid als business process management (bpm) en business rules management (brm).”
Zoals het ook tegenwoordig nog steeds mis gaat:
https://methodandstyle.com/stateful-decision-models/
@Jack, ben ik helemaal met je eens. Allerlei onderdelen van wat overheden een it-project noemen vergen totaal verschillende vaardigigheden, worden op totaal verschillende maneren geïntegreerd gebruikt, zijn qua onderhoud van totaal verschillende factoren afhankelijk enzovoort. Met Everest e.d. geen ervaring. Wij ontsluiten bestaande en te bouwen stored procedures met behul van on-the-fly aangemaakte scripts, o.a. in Flow/PowerAutomate. Werkelijk fantastisch wat je daarmee aan robuuste, perfect schaalbare functionaliteit kunt bouwen (met een architectuur die niets meer te wensen overlaat). Je moet alleen de creatie en interpretatie van XML/JSON wel aan de database overlaten. Anders wordt het al snel complex. Duizenden en duizenden transacties per minuut voor een habbekrats.
Kijk Robbie Konijn komt uit zijn holletje met verkooppraatjes alleen jammer dat het al snel om tienduizenden transactionele bevragingen per seconde (IOPS) gaat in de SOA-loketten omdat achterliggende I/O latency in zo'n gelaagde architectuur enorm is. Wat betreft een habbekrats is een pen een kleinigheidje wat niet veel voorstelt alleen is deze essentieel als je gevraagd wordt om een handtekening te zetten. Punt is namelijk dat de SOA architectuur uit de jaren 90 die in leven gehouden wordt door Internet niet de innovatie is waar de overheid op zit te wachten, het loket dat voor de logge Systems of Record zit is achterhaald door de Systems of Collaboration waarbij de moderne datasynthese vooral ongestructureerde data verwerkt. Want vaak is er niet één bron van waarheid maar zijn er meerdere waardoor de waarheidsvinding een soort van weging van feitelijkheden in een bepaalde context wordt. Ook Jack zoekt spijkers op laag water omdat hij alleen maar een hamer heeft want als een visie na 15 jaar nog niet van de grond is gekomen dan is er blijkbaar wat mis met die visie.
Ach ja, verkooppraatjes. Schiet me ineens wat te binnen. Mijnheer Ewout Dekkinga van de zo integere firma F. lijkt helemaal van aardbodem verdwenen op Compatable. Verkooppraatjes in de vorm van pretentieus gebluf dat willicht niet langer werd toegestaan door C.
Voordat Robert Wilhelmus Koelmans een 'Sanderinkje' doet met pretentieuze insinuaties moet hij eerst in de spiegel kijken want zijn reactie zegt veel over zijn integriteit. Maar ja, als de wijn is in de man dan zit de wijsheid in de kan want verkooppraatje als 'wij leveren voor een habbekrats' lijkt mij gebral als je niet eens weet wat de vraag is. Maar vooral grappig is de taal want de business eigenaar weet niet wat een stored procedure is;-)
Probeer je het nou een beetje te herstellen door over stored procedures te beginnen? Nou ja, als je zogenaamd principal architect bij het vallen van het woord transacties een beetje gaat lopen schermen met tineduizenden iops houdt het op wat mij betreft. Dan ben je duidelijk iemand die overal over meepraat maar nergens verstand van heeft.
Robbie durft want titels zijn - zoals ik 12 april al zei - mooi voor het visitekaartje want de uiteindelijk vraag gaat om met welke autoriteit gesproken wordt
omdat het bonnetje opmerkelijk vaak wat anders laat zien dan wat gezegd wordt. Want de one-trick ponyshow van Robbie met Access vergeet bijvoorbeeld dat één gebruiker die 1.000 transacties per minuut kan doen niet wil zeggen dat 10 gebruikers ook gelijktijdig 1.000 transacties per minuut kunnen doen of dat 1.000 gebruikers dat kunnen.
Behalve dat 1.000 x 1.000 transacties per minuut niet alleen veel I/O is zal zo'n systeem ook kritischer zijn dan de PC die Robbie levert, robuustheid kent dan ook wat randvoorwaarden want de jaarrekening van kleine debiteuren laat afschrijvingen op de bedrijfsmiddelen zien die voorbij de garantievoorwaarden van het bonnetje gaan. Uiteraard kun je de schuld van een verkeerde zuinigheid op onderhoud en garantie bij de leverancier leggen maar wat betreft het bonnetje is een uitsluiting van de kleine debiteur op grond van het ontbreken van een financiële verklaring niet de schuld van de opdrachtgever.
Dus als Robbie over integriteit begint dan moet hij eerst zelf in spiegel kijken, tenslotte is herstel vaak niet mogelijk omdat de back-up ook zo'n sluitpost op de begroting is. Veel kleine debiteuren brullen namelijk als een leeuw maar zijn organisatorisch een muis omdat deze 'micro-enterprises' namelijk de kennis over randvoorwaarden missen. Cherrypicking van on-the-fly klinkt bijvoorbeeld niet als 'privacy-by-desing' als we kijken naar beveiligingsmodellen want je kunt met 1.000 x 1.000 transacties per minuut de cloud voldruppelen via de microservice van een serverless model aan de voorkant. De vraag is echter want je met de analytics aan de achterkant doet.
Je zit weer eens te bluffen en uit je nek te kletsen, Ewout/Oudlid. Moet je natuurlijk de hele dag al doen om die platformen van jullie nog aan de man te brengen. https://www.channelweb.nl/artikel/productnieuws/infrastructuur/7323189/6306769/einde-in-zicht-voor-mainframe-en-unix-server-fujitsu.html Suggestieve vragen stellen en onzin-aannames doen omdat iedere recente, half zo dure op Intel/AMD gebaseerde cluster rondjes draait om die uitgefaseerde productlijnen van jullie. Zullen we anders wat afspreken om een keer een paar testjes te doen?
Ik zie ze al overwegen bij de overheid : robbie, ewoutie ?
of toch maar alles bij het oude laten..
sanderinkie ?
Dank voor de link Robbie want hoewel de bedrijfslogica replatformen in dit geval inderdaad meer om de microcode van de processor gaat is een replatforming naar de cloud interessant als we kijken naar de ontwikkelingen van 64-bit RISC architecturen:
https://en.wikipedia.org/wiki/Reduced_instruction_set_computer
De 32-bit x86 emulatie voor replatforming van oude Windows bedrijfsapplicaties levert net als het virtualiseren van Windows 2003 niet de snelste oplossing maar als we kijken naar de mogelijkheden van AI in bedrijfslogica dan doet zelfs Microsoft dit niet meer zoals de replatforming naar Linux laat zien:
https://www.zdnet.com/article/microsoft-now-has-one-of-the-worlds-fastest-supercomputers-and-no-it-doesnt-run-on-windows/
2030 lijkt nog ver weg maar replatforming naar Metaverse is wat anders dan naar Metamicro als we kijken het succes van energiezuinige RISC-architecteren in de low-end mobiele oplossingen welke voor de replatforming naar apps zorgt. Als je de juiste code op het goede platform draait dan zijn 64-bit RISC architecturen niet alleen veel sneller dan AMD/NVIDIA architecturen maar ook nog eens energiezuiniger, testen bewijzen dat;-)
Dat geklets over microcode komt van jou, Ewout. Niet van mij. Was inderdaad totaal niet relevant.
Replatforming heet het. Dat is om te voorkomen dat klanten end-of-life aankondigingen van jullie onverhoopt interpreteren als mededeling dat ze hun heil beter elders kunnen zoeken? Waarschuw je je klanten al voor replatforming? Of worden ze daar straks sowieso alleen maar beter van?
Bijna Robert want een ROADMAP is heel gewoon als het om de governance van beslissingen die de verwachtingen bepalen gaat. Aankondiging van end-of-sale is dan ook niet het abrupte einde waar jij het over hebt omdat er daarna nog 5 jaar ondersteuning is zoals Europese regelgeving vereist. Vroegtijdige boodschap over de verandering gaat dus meer om het signaal dat alvast budget gereserveerd moet worden. Dat is op jouw ondernemingsniveau als winst uit de onderneming fiscaal reserveren als oudedagreserve voor de rust van morgen. Lifecycles zijn namelijk een fact of life dus vertel eens Robert waar het mis is gegaan want het is mooi dat je zo'n uitgesproken mening over mij hebt maar heb jij je zaakjes zelf wel op orde?
Oja, ik ben het niet met je eens over de strategische instructiesets want je moet je eens met je CTO gaan praten over Spectre en Meltdown en het gerucht dat er nog telkens nieuwe variaties (CVE-2022-000x) opduiken. Verder laten politieke ontwikkelingen zien dat deze strategische instructiesets als pressiemiddel worden gebruikt. Wat betreft jezelf in de voet schieten denk ik daarom dat de processormarkt er in 2030 heel anders uitziet dan nu, bijvoorbeeld door Europese 'Chips Act' als gevolg van een schreeuwende behoefte aan chips en een te grote afhankelijkheid van Amerikaans oligarchen.
Nu is een kleine debiteur die amper het hoofd boven water weet te houden in de rode zee van rehosting natuurlijk niet geïnteresseerd in de marktontwikkelingen op het fysieke vlak, de roadmaps gelden namelijk niet alleen een processorarchitectuur als ik kijk naar een PC/server van samengestelde componenten. En al die componenten kennen uiteindelijk zoiets als microcode welke op elkaar afgestemd moeten worden. Wij van WC-eend willen niet een boek of methodiek verkopen maar 'onder architectuur werken' is wat anders dan een on-the-fly aanpak als ik kijk naar compability matrixen in het configuratiemanagement.
On-topic wijs ik op een probleem aangaande het onderhoud, de governance van beslissingen die de verwachtingen bepalen gaan namelijk om het breiwerk van al het slecht passende maatwerk doordat de zorg voor de microcode bij de leverancier ligt. Eén van de reden waarom Apple strategisch een replatforming naar ARM-based oplossing heeft gedaan, de desktop als mainframe zullen we maar zeggen want het probleem van afstemming tussen software en hardware gaat om de governance. En daarin ben ik meer voorstander van één open architectuur met meerdere leveranciers dan de achter gesloten deuren oplossingen maar dat komt doordat ik van de POKE & PEEK generatie ben.
Ik heb nog nooit wat interessants van je gelezen. Alleen maar oeverloos gezwets en - ongeacht wie het schrijft - insinuaties zodra iemand iets interessants of iets van belang voor een ander schrijft. Het onderwerp maakt niet uit, Ewout leutert er wel hele verhalen onder. Permanente discussievervuiling, deels megalomanie, deels kwaadaardigheid.