In mijn dagelijks werk rondom het oplossen van applicatie- en infra-problemen krijg ik meestal de vraag om ook even in kaart te brengen welke applicaties er allemaal gebruikt worden, hoeveel gebruikers ze hebben en waar ze zitten, welke servers daarbij aangesproken worden, waar deze zijn aangesloten en hoe de netwerk infrastructuur eruit ziet. In dit artikel de grote lijnen van mijn aanpak in dergelijke situaties.
Aan de technische kant van de infra, zeg maar de apparatuur kant, maak ik gebruik van SNMP- & WMI-scanners. De SNMP-kant voor bijvoorbeeld netwerk apparatuur, storage apparatuur en Unix-achtige; de WMI kant voor ons aller Windows.
De betere scanners maken gebruik van de topologie informatie die is opgeslagen in de verschillende soorten netwerk-apparatuur. Denk bijvoorbeeld aan Cisco zijn CDP of diens opvolger LLDP om te bepalen wat er allemaal aan elkaar geknoopt is. In dat kader bewijst zelfs good-old spanning tree nog goede diensten doordat het precies aangeeft langs welke paden het data verkeer feitelijk wordt afgehandeld!
Het is juist deze topologie informatie die een SNMP-scanner in staat stelt een zeer gedetailleerde OSI L2 en L3 plaat op te leveren van alle aangesloten ‘apparatuur’; fysiek of virtueel.
Het gebruik van veel verschillende applicatie- & middleware-technieken heeft zo zijn voordelen bij het in kaart brengen van het applicatie landschap. Dat maakt namelijk dat packet trace en DPI-technieken efficiënt en effectief hun werk kunnen doen.
De packet trace-methode gebruik ik om inzicht te krijgen in verkeersstromen en volumes tussen gebruikers en het server park op basis van de gebruikte ip-adressen en tcp-poorten. Langs deze weg krijg ik dan ook inzicht in het soort besturingssysteem wat aan gebruikers- en server-zijde ingezet is; vaak aangevuld met versienummers. Op die manier wordt er meteen een eerste stap gezet bij het in kaart brengen van het gebruik van bijvoorbeeld byod’s en clouddiensten.
De DPI-techniek is feitelijk een aanvulling op de packet trace omdat die onderscheid kan maken tussen applicaties die over eenzelfde (server-site) tcp-poort en ip-adres lopen. Voor wat betreft de herkenning van applicaties werkt DPI ook in combinatie met ssl zonder dat de packet trace component het betreffende server certificaat aan boord heeft. Dit laatste is vooral van belang bij applicatie- en platform-diensten zoals die van Microsoft, Google en Amazone. Enerzijds omdat die over één ip-adres en één tcp-poort vaak meerdere applicaties beschikbaar stellen. Anderzijds omdat het juist niet mijn bedoeling is om mee te gluren met datgene wat een gebruiker allemaal aan het doen is.
Bij elkaar levert de combinatie packet trace en DPI dan ook in een zeer gedetailleerde plaat van de applicaties, de gebruikersgroepen en de servers.
Blinde vlekken
Zelfs met de inzet van meerdere ESX-hosts, honderden vm’s, firewalls, caching/proxy servers, nat-ing en wat-dies-meer-zij blijft deze aanpak overeind! De inzet van dit soort technieken brengt namelijk een bepaald verkeerspatroon van applicaties met zich mee. De kunst bestaat erin om die verkeerspatronen te herkennen om van daaruit dat deel van het it-landschap verder af te pellen en in kaart te brengen.
Om het succes van deze herkenning te maximaliseren maak ik gebruik van de combinatie L2/L3-topologie en de applicatie-topologie. Door die twee over elkaar heen te leggen ontdek ik de blinde vlekken.
De essentie van deze herkenning bestaat eruit dat de applicatiekant verkeersstromen laat zien van en naar bepaalde ip-adressen over bepaalde tcp-poorten (eventueel uitgesplitst naar meerdere applicaties door de DPI-techniek). Terwijl de L2/L3-plaat geen verdere informatie heeft over deze ip-adressen en het erachter liggende netwerk.
Samen zijn ze dan ‘het bewijs’ dat er iets is wat het betreffende netwerkdeel afschermt. Soms stopt het hier. Andere keren helpt een goed gesprek met het beherende team over het nut en noodzaak voor het verder afpellen van deze blinde vlekken.
100 procent volledig
Ik durf de stelling aan dat het systematisch toepassen van deze aanpak een 100 procent volledig beeld oplevert! Beide methodes samen bieden namelijk inzicht in de bekende en minder bekende onderdelen van een it-landschap. Wat al een hele vooruitgang is ten opzichte van een veel voorkomend startpunt: ‘afgezien van een x-jaar oud architectuur document hebben we eigenlijk nauwelijks een idee hoe het it-landschap er op dit moment uitziet’.
Zelfs als gebruikers hun eigen ‘devices’ meebrengen en de business zelfstandig een of meerdere clouddiensten in gebruik hebben genomen worden deze automatisch opgenomen in de applicatieplaat.
Alles bij elkaar worden er ook nog eens een paar belangrijke stukken aangeleverd rondom de invulling van de puzzel die heet governance! Immers, ondanks dat het detailniveau kan variëren is er nu zicht op de dingen die bekend zijn en waar nog wat werk aan de winkel is.
Andere toepassingsmogelijkheden
Een dergelijke aanpak is ook prima in te passen tijdens de due dillegence-fase van een sourcing-contract omdat binnen korte tijd helder is wat er op enig moment staat, wat daarvan gebruikt wordt en in welke mate. Ik durf te wedden dat de gesprekken volgend op deze resultaten veel constructiever zijn dan nu vaak het geval is!
Vervolgstappen in de vorm van andersoortige scans zijn nu ook eenvoudig te realiseren doordat er zicht is op de apparatuur, de applicaties en de onderlinge samenhang. Denk bijvoorbeeld aan een scan op servers en zogenaamde appliances rondom de firmware en softwarecomponenten met bijbehorende versienummers.
Wat ook nog wel eens kan helpen is het automatisch bijwerken van deze twee topologie-platen met een bepaald interval. Hoewel mijn persoonlijke voorkeur uit gaat naar het werken met een lijstje van delta’s dat elke 24 uur wordt bijgewerkt. Dit lijstje wordt dan dagelijks (of tenminste wekelijks!) nagelopen op bijzonderheden zoals gebruikersstations die zich in een keer als server gedragen (serveren van torrents?). Of een gebruikersstation met een stevige toename in het mail volume (rondsturen van spam?).
Op deze manier blijven de beheerteams in ieder geval zicht hebben op datgene wat er zich afspeelt in hun it-landschap; ook als de business de resultaten van de changes in het afgelopen weekend eens een keer niet doorgeeft…
@Will
Dat doel – niet de visie – weinig van elkaar verschillen zal ik niet ontkennen maar we stappen wel in op verschillende haltes om dat te bereiken. Want wat is behalve de blonde kuif en grote bek het verschil tussen PVV en VVD als je toch dyslectie hebt aangaande mijn reacties?
Het zou misschien schelen als je wat minder aan marketing doet want kennis verkopen of delen maakt dus wel degelijk een verschil uit, je argumentatie dat iemand niet het beleid uit kan leggen aangaande de risico’s raakt tenslotte de kern van het probleem. Mijn eerste opinie (november 2010) hier bij Computable ging dus over een verstandig gebruik van de informatiespoorweg, bewustzijn is namelijk niet erg hoog. Euvel kunnen we oplossen met het verkopen van meer technologie en opstellen van onbegrijpelijk beleid zoals jij dus blijkbaar als doel hebt gesteld hebt of door het delen van ervaringen om zodoende te leren van de gemaakte fouten om deze niet eindelooos te blijven herhalen.
Sorry Will, maar als jij niet het verschil tussen een dolfijn en een haai in de blauwe oceaan van innovatie begrijpt dan hoef ik je ook niet het doel van open source uit te leggen. Want het gaat hierbij meestal dus niet om de code maar de bron, Computable is door alle content marketing wat dat betreft nogal vervuild. Om de gevraagde leeswijzer welke tot de gesprekken leidde met Valueblue te geven, de opinie Release of relatiemanagement (mei 2011) gaat grotendeels in op de uitdagingen die je ondervindt als je kiest voor de weg van de minste weerstand.
Kijkend naar politiek opportunsisme van participatiemaatschappij zul je eerst moeten leren vissen omdat je anders Crap Gemini projecten krijgt die een onwelriekende stank veroorzaken omdat kennis aangaande de materie buiten de deur is gezet. Ik weet dat ik nog lang niet alles weet en om even in te haken op je meerjarige academische studie ben ik benieuwd welke definitie je geeft aan begrip organisatie en hoe je de veranderingen daarin waarneemt. SIEM gaat tenslotte om event management welke niet alleen de ‘exceptions’ vanuit de infrastructuur mee moet nemen als ik mooie verhalen over de beloften van Big Data mag geloven.
@Ewout:
Ik heb een van mijn tekortkomingen aangehaald (en toegelicht met een voorbeeld) waardoor het voor mij lang niet altijd duidelijk is wat je bedoeld. Vandaar de vraag om een toelichting. Maar daar stopt het dan ook – meer zat er niet achter.
Dat je zoiets vervolgens inzet voor een aanval op mij als persoon door mijn tekortkoming over een kam te scheren met het geschreeuw van een blonde PVV-er… Ewout – dat valt me vies tegen… 🙁
Nog maar los van het feite dat je, afgaande op de rest van je reactie, het blijkbaar beneden je stand vindt om ook maar iets van een toelichting te geven als er iemand langskomt met vragen – hoe dom dan ook (allez – vanuit jouw belevingswereld dan toch).
Tot slot nog twee keer terug naar de bron.
Als eerste dit artikel – hiermee heb ik een stukje kennis en ervaring willen delen met op het eind, onder het kopje met “toepassingsmogelijkheden”, een paar doelen die met deze aanpak gediend zijn. En ja, ondanks dat het niet genoemd is, het inregelen van zoiets als SIEM (of in ieder geval het proces) hoort daar ook bij.
Uiteraard zijn er veel organisatorische en technische aspecten die een rol spelen bij een succesvolle uitvoering met dito resultaat – daar ben ik me terdege van bewust! Inclusief het menselijk aspect om bijvoorbeeld dingen te camoufleren (window-dressing en pleisters plakken) in een poging er zelf beter van te worden – of toch in ieder geval niet slechter.
Maar om die kennisdeling dan te veroordelen tot “onbegrijpelijk beleid” met als (soort van) onderbouwing dat mensen rare dingen doen gaandeweg een proces… Hey, kom op kerel – we zijn hier toch om elkaar te helpen… kom dan op zijn minst met alternatieven! Dus even met de eerder genoemde doelen als uitgangspunt: hoe zou jij zoiets dan aanpakken?
Als tweede mijn studie – dat is het resultaat van een zoektocht naar een voor mij passende route om ook op een wat langere termijn zelf voor een inkomen te kunnen zorgen en tegelijkertijd een positieve bijdrage te kunnen leveren aan de ontwikkelingen onze maatschappij. Althans voor zover deze ontwikkelingen gedreven worden door de inzet van IT middelen en binnen mijn mogelijkheden liggen.
Die zoektocht ging o.a. gepaard met het sparren met anderen, een stuk zelfreflectie en het samenkomen van een paar ingrijpende gebeurtenissen. De essentie daarvan heb ik gedeeld in een artikel zodat anderen er hun voordeel mee kunnen doen. En dat met het idee dat er tussen die anderen vrijwel zeker zijn die met een vergelijkbare zoektocht bezig zijn. Dat is het – en ook hier – meer zat en zit er niet achter!
Natuurlijk kan je dit zien als een kansloze missie… prima! Maar nogmaals, als je al tot zo een oordeel komt, kom dan ook met alternatieven! Dat schiet beter op dan een uiteenzetting waarom het eigenlijk allemaal maar niks is – ook voor anderen!
🙂
@Will
Je argumentum ad populum dat ik niet met alternatieven kom is precies van dezelfde orde als gedoogconstructies van kabinet met bevriende oppositie, wat je niet benoemd hoeft ook niet opgelost te worden. Dat blond gekuifde politicus niet zo eloquent is wil echter nog niet zeggen dat er soms een kern van waarheid zit in zijn woorden.
Met mijn reacties probeer ik ook het licht in het kippenhok aan te doen want bij de opinie ‘Oud maar nog niet vervangen’ reageerde je dus dat ik gehinderd ben door teveel ter zake doende kennis. Aangaande de in voorgaande reactie genoemde halte, veel applicaties werden niet ontwikkeld met beheerbaarheid in het achterhoofd. Zie daar de reden dat ik stelde dat je geen 100% inzichtelijkheid gaat verkrijgen in IT landschap.
Benieuwd trouwens of je in reactie genoemde truc hier wilt delen want inzichtelijkheid tot op de transactie nauwkeurig door de gehele keten voor business processen is de ‘steen der wijzen’ als we het over schaalbaarheid van de workload als geheel in plaats de IT hebben.
Als jij koketteert met academische studie over organisatorische veranderingen dan moet je niet mij jouw domheid verwijten als je de INSEAD theorie van innovatie niet begrijpt. Het is ook nogal vooringenomen om te stellen dat ik visies en ervaringen niet deel, redelijk wat opinies geschreven en presentaties gedeeld. Neem bijvoorbeeld de presentatie over het sourcing dillemma:
http://www.slideshare.net/edekkinga/get-your-house-on-order
Sommigen klagen hier over mijn communicatie welke ’to-the-point’ is en dus confronterend maar gesprekken met CTO’s van de grote Amerikaanse technologie leveranciers zijn hierdoor wel heel verhelderend. Lees de 8-punten die ik opsom in ‘Interessante presentaties CIO’s en CTO’s’ aangaande de wereld schetsen zoals deze is (feiten) en zoals je wilt dat deze eruit ziet (hoop) als het gaat om stippen aan de horizon schetsen.
Een vrij simpel alternatief dat ik heb is gewoon gaan praten met de mensen die elke dag in de praktijk staan. Aangezien steeds meer IT-afdelingen open source oplossingen gebruiken voor wat jij beschrijft omdat business niet wil investeren stelde ik dat je achteruit een vorm van SIEM inricht. Zeker wanneer ik in een rapport van onderzoeksraad lees dat risicobewustzijn alleen aanwezig is bij de ICT-afdeling en niet of nauwelijks bij de top. En dus is er een simpele verklaring te geven voor verwijten naar security officers als deze controleur op de loonlijst staat van degene die hij/zij moet controleren.
Denk dat we dus vooral een cultuur probleem hebben in de IT, culturele antropologen zullen het een complot noemen maar je verhaal rammelt op een paar punten en gezien je reacties lijkt me empirisch bewezen dat boodschapper dan de sjaak is. Dat maakt me huiverig om ervaringen met je te delen, je lijkt me te selectief en hebt de vooringenomenheid van een verkoper.
Laten we ook niet vergeten dat een groot deel van de ‘shadow IT’ door business managers geaccordeerde oplossingen zijn, controleer eerst de boekhouding voordat je gaat investeren in technologie. Een overweging voor de andere lezers van deze discussie (Schaken in de cloud) is wat er zal gaan gebeuren met de adoptie van BYOD als gebruikers weten dat Big Brother de eigen werkgever is?
@Ewout:
Bedankt voor je toelichting – top! 🙂
Over INSEAD en blauwe/rode oceanen: in een van je eerdere reacties noemde je dit in één adem met het betalen van pizza’s door ValueBleu en een verwijzing naar een van hun diensten genaamd BlueDolphin. Ik zag het verband niet (voor zover er dat al is) => vandaar de vraag.
Als ik ze uit elkaar trek dan is:
(1) – INSEAD een opleidingsinstituut waarvan twee professoren een visie en theorie hebben uitgewerkt rondom innovatie. Met als uitgangspunt innovatie als waarde creatie in een nieuwe markt (blauwe oceaan) versus innovatie als een concurrentie voordeel in een bestaande markt (rode oceaan).
(2) – ValueBlue een bedrijf wat ooit eens de rekening van een of meerdere pizza’s heeft betaald.
(3) – BlueDolphin een van hun diensten.
De aspecten van de rode- en blauwe oceaan waren (en zijn) een onderdeel van de opleiding – alleen gebaseerd op literatuur van andere schrijvers. In dat kader en ook als reactie op je eerdere vraag over mijn definitie van een organisatie en het waarnemen van veranderingen een paar voorbeelden.
Organisaties zijn er in verschillende smaken elk met hun eigen krachtenspel. Persoonlijk ben ik erg gecharmeerd van de 8 metaforen die Gareth Morgan gebruikt in zijn boek “Images of Organization”.
Voor het maken van markt- en bedrijfsanalyses is er o.a. gewerkt met het boek “Strategy Synthesis” (de Wit en Meyer). Het 5-sterren model van Galbraith is gehanteerd als een mogelijk instrument om invulling te geven aan een bedrijfsstrategie en bijbehorende organisatiestructuur.
Een artikel over “Organigraphs” (Mintzberg en van der Heyden) is gebruikt als een instrument om, naast de formele harkjes, in kaart te brengen hoe het er in een organisatie nou werkelijk aan toe gaat. Terwijl mogelijke invalshoeken van managers om organisaties te besturen zijn gebaseerd op een artikel van Mintzberg en Gosling met als titel “The five minds of a manager”.
Daarnaast was er een aparte module voor het onderdeel sturing met o.a. het gedrag van organisaties en hoe je daarin kan (bij)sturen. Bij de uitwerking van een van de opdrachten heb ik dat als vertrekpunt gebruikt voor een artikel over de mogelijkheden van sturing in een bedrijf- en organisatie overstijgende waardeketen (Extended Enterprise) en hoe zoiets vanuit IT gefaciliteerd kan worden (voor de liefhebbers – dit artikel kan hier opgehaald worden: http://moonen.me/documents/2014/08/output-van-proces-metingen-in-een-extended-enterprise.pdf.
Nogmaals, dit zijn voorbeelden die gebruikt zijn tijdens dit deel van mijn studie en het resultaat daarvan bij de uitwerking van een van de opdrachten. Het is zeker niet mijn intentie om me hiermee te profileren als een organisatie deskundoloog – het is slechts een eerste stap.
Dan de transacties binnen een keten – ik zal eens een poging wagen.
Als je een transactie definieert als iets wat een-op-een gekoppeld kan worden aan een bedrijfsproces (of een deel daarvan), dan is de kans van slagen het grootst bij een applicatie met een web voorkant, een .Net en/of Java “middenkant” en een SQL-achtige aan de achterkant.
Aan de voorkant wordt er dan gewerkt met Java-script injectie en een vorm van tagging om te herkennen waar een gebruiker zit en klikt – doorgaans zonder agent. De “middenkant” maakt gebruik van een agent en een vorm van tagging. Enerzijds om de executie tijd van de Java en .Net code te meten; anderzijds om de voor- en achterkant aan elkaar te knopen. Aan de achterkant wordt er ook gebruik gemaakt van een agent die de query’s herkent.
Als zoiets niet kan of het is geen web-achtige, dan zou je gebruik kunnen maken van een netwerk georiënteerde aanpak op basis van packet capturing (al dan niet in combinatie met DPI).
Afhankelijk van de plek in het netwerk waar je dit toepast kan het nodig zijn om een of meerdere SSL certificaten te installeren voor dat deel van de applicaties wat via SSL versleuteld is. Er zijn producten die gebruik maken van een agent op een server of desktop en er zijn er die werken als een appliance via een netwerk taps of span poorten.
Welke van de twee het ook gaat worden, de moeilijkheid en het werk zit hem in het configureren van de business transacties: hoe zijn die te herkennen.
Er is een tijd geweest dat hier een belangrijke taak leek te zijn weggelegd voor ARM (Application Response Measurement) – een initiatief uit eind jaren 90 van het toenmalige Tivoli en HP. Het idee was om applicaties te voorzien van een API waarmee timers bijgehouden konden worden tijdens de uitvoering van transacties. Tegenwoordig hoor of zie ik hier niks meer van.
Terwijl ik dit zo neerschrijf realiseer ik me dat het een hoop vragen zal oproepen – veel meer dan ik langs deze weg kan beantwoorden. Daarom stel ik voor om een afspraak te maken zodat ik dit verder kan toelichten en de vragen kan beantwoorden.
Tot slot…
(1) – Ik hoop dat je met deze uiteenzetting me voor de toekomst in ieder geval het voordeel van de twijfel gunt. Ook als mijn betoog (te?) veel weg heeft van een sales-pitch door mijn enthousiasme.
(2) – Van mijn kant zal ik een volgende keer wat meer tekst-en-uitleg geven bij uitspraken als “te veel gehinderd door ter zaken doende kennis”.
Maar op het moment dat ik in beide gevallen alsnog tekort schiet: nogmaals, stel vragen!
🙂
Beste Will,
Precies wat ik bedoel. Automatiseren is standaardiseren en door standaardiseren besparen. Tenminste, dat zou je denken. De praktijk is telkens weer dat men wielen opnieuw aan het uitvinden is, oude wijn, nieuwe zakken, en vooral veel blokkades aan het opwerpen is zichzelf in stand te houden.
In weerwil wat velen roepen of aandragen aan allerlei inzichten, alternatieven en oplossingen, IT is er om zaken te automatiseren en daarmee een begrijpelijk en hanteerbaar landschap in stand te houden. IT is niet commercieel, IT is niet politiek. Dat is iets wat maar weinig professionals zo willen zien. Soit, so be it. Maar roep dan niet dat alle problemen waar men tegen aan kijkt en waar de hausse van de artikelen en reacties hier in computable, zoveel facetten en oorzaken hebben.
IT is er om zaken te stroomlijnen en te verzelfstandigen en daar hoort ook het standaardiseren van het IT landschap bij. De uiteindelijke kern van het verhaal is dat je geen mankracht nodig hebt iets in beweging te houden.
Due Dilligence
Persoonlijk en professioneel heb ik Due Dillegence een volkomen idiotie gevonden. Klein voorbeeld. In 1995, werkende voor Holan in Amstelveen, ABN-Amro, kwamen er twee kwartiermakers die een inventarisatie wilde maken van de hele spullenboel in het gebouw. Ik hoefde me maar om te draaien om een ordner te pakken en die te overhandigen aan twee stomverbaasd kijkende ‘consultants’.
Wat of de bedoeling was? ……
Again, voor mij een gewoon standaard die door velen graag en telkens weer opnieuw moet worden uitgevonden en uitgevoerd.
Onzinnig dus.
Beste NumoQuest (Rene?),
Ik ga een heel eind mee in je visie. Toch ook een paar nuances.
In mijn optiek is automatiseren eigenlijk niks anders dan mensenwerk vervangen door machines. Dat daarbij een voorkeur is voor een hoge mate van standaardisatie is begrijpelijk. Immers, op die manier is er het meest uit te slepen.
Het probleem van standaarden is dat het er zoveel zijn. Welke combinatie ga je gebruiken?
Op enig moment worden er dan toch keuzes gemaakt. Wat als het geheel niet brengt wat verwacht is en er toch (meer?) mensenwerk nodig is. Ga je dan door met wat je hebt en neem je de tekortkomingen voor lief? Of ga je terug naar af om opnieuw te beginnen?
Als je aan het begin of het eind van een dergelijk traject zit, dan zal het antwoord waarschijnlijk niet al te moeilijk zijn. Maar wat als je ergens rond het midden zit… zie daar de opening naar OSI perikelen op laag 8, 9 en 10.
Maar automatiseren zonder enig menselijk handelen (letterlijk) – ik weet het niet. Als menselijk handelen niet meer nodig is en de machinerie van het automatiseren hapert, wie gaat dan waar beginnen met een analyse? Laat staan oplossen?
Ik bedoel, tuurlijk zullen er events afgevuurd worden als er iets mis gaat. Maar zeker bij 2 of meer verstoringen tegelijk zijn dat vaak “symptomen”. Als er voor normaal bedrijf helemaal geen mensenwerk meer aan te pas komt, wie is dan nog in staat om op een dergelijk moment de root-cause van een probleem te bepalen?
Ook de business case zal een belangrijke rol spelen. Als het automatiseren een onderdeel is van een innovatie programma waar eerst bezuinigd wordt om de daaropvolgende innovatie (mede) te financieren, dan zullen er vrijwel zeker andere keuzes gemaakt worden dan wanneer het een onderdeel is van een programma om de winstgevendheid van het bedrijf te verbeteren.
Zo ook een due dillegence – vertrouwen is prima maar controle is beter (niets menselijks is ons vreemd – toch?).
Als een zekere installed base op papier een bepaalde verwerkingscapaciteit heeft met een zekere boekwaarde en een exploitatie budget van de nodige miljoenen, dan zou ik dat toch wel even willen tjekke. Ook als alles goed geadministreerd en gedocumenteerd is.
Achtergrond: ooit was ik (op afstand) betrokken bij een fusie tussen twee internationaal opererende IT bedrijven. De een had in zijn boeken een eigen zeekabel staan. Voor de ander was dat een meer dan welkome verbinding. Bij nadere controle van het contract(!) bleek dat die kabel eigenlijk geen eigendom was maar meer een (soort van) meerjarige huur met automatische verlenging.
Maar dat gezegd hebbende, die controle, dat houdt natuurlijk ook een keer op. Alleen maar doorborduren op wantrouwen lijkt me nou ook weer geen optie. Das funest voor alle ontwikkelingen en vooruitgang… zelfs als die vooruitgang gebaseerd is op drie stappen vooruit met twee stappen terug.
🙂