Door Tha Cleaner: De IT managers bepalen vaak niet wat er op de desktop gedraaid wordt. De business bepaald dit aan de hand van de applicaties die men nodig heeft. En dat wordt niet op een golfbaan besloten. Als men het beste kan werken met applicatie A en dat is de business applicatie van het bedrijf, dan draait het daarom. En een IT Manager kan daar vaak niet meer zoveel aan veranderen.
Er zijn ook omgevingen waar de overgrote bulk van de verwerking helemaal niet langs mensen of desktopsystemen geleid wordt. Ook daar worden pakketten aangeschaft (om bijvoorbeeld printuitvoer voor een klant uit verschillende applicaties in dezelfde envelop te laten belanden) en platformkeuzes gemaakt (ga je voor nieuwe applicaties Java of .NET gebruiken?). Reken maar dat bij dat soort keuzes dat soort beïnvloeding mogelijk is en ook plaatsvindt.
En bij andere managers dan IT-managers zal het ook voorkomen, wat de gebruiker eist kan net zo goed op de golfbaan tot stand zijn gekomen. Misschien niet als het de tekstverwerker is die sowieso ieder bedrijf gebruikt, maar wel bij meer gespecialiseerde software. Ik had misschien niet IT-managers moeten schrijven, maar dat zijn de mensen waar ik dicht genoeg bij zat om een beeld te krijgen.
Om aan te geven waarom ik nogal zeker van dit beeld ben een voorbeeld. Voor het invoeringsproject van een pakket voor gebruik in de IT-infrastructuur van een bedrijf waar ik werkte werd de projectleider door de leverancier geleverd. Dat bleek vooral een commerciële man te zijn die zo'n onstuitbare ouwehoer was dat hij ons in geuren en kleuren vertelde over de ontmoetingen die hij met ons automatiseringshoofd op de golfbaan had gehad. Hoe duidelijk wil je het hebben?
Klopt... Immers die succesvolle leveranciers weten vaak wat de klanten precies nodig hebben, en eventueel al hebben draaien. Vaak integreerd dat vrij goed in hun huidige infrastructuur, zodat alles als een geoliede machine werkt.
Vind je? Misschien weten ze vooral de klant beter aan te praten dat die iets nodig heeft. Er wordt ontzettend veel hype gegenereerd, waar "analisten" in vakbladen en -websites volop over schrijven, om vervolgens een implementatie van die hype aan grote aantallen klanten te kunnen verkopen. Denk aan hoe een aantal jaar lang in buzzwords over voordelen van "the cloud" werd geschreven voordat eindelijk eens concreet werd gemaakt hoe dat eruit ging zien. Met objectoriëntatie is ook zoiets gebeurd, van een programmeerparadigma werd dat ooit iets dat door die in vakbladen schrijvende "analisten" als een wondermiddel voor alle problemen werd gepresenteerd en opeens waren allerlei pakketten die al sinds jaar en dag bestonden "volledig objectgeoriënteerd", en ik heb folders onder ogen gehad waarin enthousiast geworden hoge managers met een markeerpen precies alle buzzwords die op dat moment gehypet werden hadden aangestreept. Onderschat niet hoe ver marketing gaat, en verwar dat niet met het belang van de klant, dat gaat over het belang van de leverancier.
Over integratie: het patroon dat ik meer dan eens zag is dat bij een pakket waar je als klant ongeveer klaar mee zou zijn na verloop van tijd toch tegen grenzen aanloopt, en dat de leverancier dan een ander pakket levert waarmee je weer verder kan komen. En dan een volgend pakket. Die "integratie" lijkt dan vooral een handig opgezet netwerk te zijn van bewuste gebreken en afhankelijkheden met pakketten die die gebreken weer aanvullen, bedoeld om na de eerste verkoop steeds meer aan een klant te kunnen slijten. Dat is niet een soort integratie waar je als klant blij mee moet zijn, dat kost je handenvol geld.
Het is in de huidige tijd misschien een verouderd voorbeeld, maar kijk hoe de goede oude e-mail werkt. Je kan alles-in-een-pakketten krijgen die SMTP, POP3, IMAP en een webinterface bieden, maar je kan ook een losse SMTP-server, een losse POP3-server, een losse IMAP-server en een losse webinterface kiezen die met de IMAP-server praat. In dat wereldje is ingezet op standaardisatie van de protocollen waarmee de verschillende componenten met elkaar communiceren, en zelfs de manieren waarop de e-mails worden opgeslagen en locking-mechanismes op die opslag zijn (in ieder geval op Unix/Linux) voldoende gestandaardiseerd of uniform ondersteund om pakketten die dezelfde mailmappen moeten benaderen dat zonder ongelukken te laten doen.
Dan heb je het over componenten die niet geïntegreerd zijn maar die goed kunnen samenwerken, en die stuk voor stuk door een drop-in-alternatief vervangen kunnen worden omdat ze de manier waarop ze met elkaar communiceren en samenwerken compatibel houden. Zo'n opzet heeft niet het effect dat je het netwerk van afhankelijkheden van een specifieke leverancier ingezogen wordt en toch werkt het.
Een leverancier die alles integreert heeft het voordeel dat hij dingen kan implementeren die niet door die standaardprotocollen worden ondersteund. Qua features en snelheid waarmee die features geïntroduceerd kunnen worden levert dat een voordeel op. Maar op termijn kleeft daar het nadeel van supplier lock-in aan. Je bent uiteindelijk in mijn ogen als klant beter af met zich ontwikkelende standaardprotocollen waar nieuwe features in verwerkt worden zodat je de vrijheid in de keuze van afzonderlijke componenten behoudt.