Archief: Boris Minnaert

Recente Posts

Beveiligingsvraag: mijn perceel, jouw perceel

Ik krijg ze regelmatig: vragen over beveiliging. Vaak biedt het ArcGIS-platform één of meerdere oplossingen die passen in de situatie van die organisatie, maar soms is het lastig. In die gevallen zijn organisaties verbaasd. Hoe kan dit? Die vraag zal toch wel vaker voorkomen?

In deze blogpost bespreek ik een situatie die weinig voorkomt, maar wel tot interessant inzicht leidt.

Beveiliging

Er zijn in Nederland organisaties die een GIS-systeem nodig hebben waarin honderden tot tienduizenden agrariërs met (landbouw)percelen werken. De featureservice ‘Perceel’ kan eenvoudig worden gemaakt en ArcGIS for Server kan zo worden ingericht dat tienduizenden gebruikers worden bediend. Maar bij de organisaties in dit voorbeeld is de beveiliging lastig, omdat de agrariërs ieder alleen hun eigen percelen mogen bekijken en wijzigen.

Om gebruikers toegang tot alleen hun eigen percelen te geven, heb je iets nodig wat in de databasewereld ‘row level security’ heet. Elke feature is een rij in een databasetabel en agrariërs zouden alleen toegang moeten krijgen tot de rijen waar hun eigen percelen in staan. In mainstream IT is dit gangbaar. Als je via een website een bestelling plaatst, dan kun je als klant alleen je eigen bestellingen raadplegen en wijzigen. Natuurlijk, daar staan we niet eens bij stil.

GIS is anders

Voor GIS komt deze vraag naar row level security weinig voor. Dit is een van de punten waar GIS fundamenteel anders is dan mainstream IT, om de eenvoudige reden dat we in GIS een ander soort problemen oplossen dan in mainstream IT. In GIS heb je ruimtelijke verbanden tussen objecten, zoals kabels die horen bij een lantaarnpaal. Een assetbeheerder kan in die gevallen het ene object niet verplaatsen zonder een ander object mee te verplaatsen.blog-mijn-perceel-jouw-perceel

Als je vlakdekkend werkt, zoals bijvoorbeeld in de BGT, dan heeft het weinig zin om een lock op precies één perceel te leggen. Een wijziging in de geometrie van een perceel is dan niet mogelijk zonder ook een wijziging te maken op een of meer aangrenzende percelen. Als een BGT-beheerder een kruising moet veranderen in een rotonde, dan heeft hij een lock nodig op de directe omgeving, niet op een enkel object.

Wijzigen op een gebied

Kortom, in GIS moet je wijzigingen vaak op een gebied maken, niet op een rij. En uiteraard biedt het ArcGIS-platform al lange tijd voorzieningen om wijzigingen op een gebied te maken: versioning. Voor de meeste organisaties biedt versioning ruim de mogelijkheden om met meerdere gebruikers wijzigingen te maken.

Voor de gevallen waar echt row level security nodig is in GIS, zoals de klanten die ik in begin noemde, is een aparte benadering mogelijk.

LinkedInFacebookTwitterDeel deze blogpost
Posted in ArcGIS, Beveiliging | Tags: , , , , | Plaats een reactie

Portal for ArcGIS: de menukaart in uw handen

Sommigen hebben weleens moeite om Portal for ArcGIS te plaatsen, een lokaal portaal waarmee services kunnen worden gehost. Waarom vindt Esri dit belangrijk? Om dat uit te leggen, vergelijk ik het ArcGIS-platform graag met dineren. Ik geef toe, een onverwachte analogie, maar hij werkt verhelderend.

Analogie dineren.

Analogie dineren bij een restaurant.

Analogie
In deze analogie is ArcGIS for Server de chefkok, die bij het bereiden van het diner gebruik maakt van keukengerei (de hardware) en ingrediënten (data) uit de voorraadkast (de database). De klant (browser) wordt bediend door de ober (de interface) en de voorraadkast wordt bevoorraad door een bezorgdienst (externe interface met push-model) of door zelf te foerageren (externe interface met pull-model).

Menukaart
Maar hoe weet je als klant wat je zoal kunt bestellen? Het ArcGIS-restaurant richtte zich tot voor kort vooral op vaste klanten en had daarom geen gebruiksvriendelijke menukaart nodig. ArcGIS for Server is als een chefkok die wel razendsnel een bestelling bereidt, maar niet zo’n gebruiksvriendelijk overzicht kan geven van alle mogelijke gerechten. Nu het ArcGIS-restaurant een breder publiek wil bedienen, is er behoefte aan een gebruiksvriendelijke menukaart. Portal for ArcGIS is die gebruiksvriendelijke menukaart, waarop je kunt zien wat je allemaal kunt krijgen. De onderdelen van het menu zijn informatieproducten (zie Bœuf bourguignon maar als informatieproduct).

Het ArcGIS-restaurant had tot voor kort <BR>geen gebruiksvriendelijke menukaart.

Het ArcGIS-restaurant richtte zich tot voor kort
op vaste klanten.

Thuiskok en thuisbezorgd.nl
De analogie gaat verder: de professionele GIS-gebruiker is een thuiskok die met ArcGIS for Desktop werkt in zijn eigen keuken (laptop). En een clouddienst als thuisbezorgd.nl is te vergelijken met ArcGIS Online: via deze clouddienst kun je gerechten bestellen van meerdere koks. Helemaal niet zo gek. In het dagelijks leven eet je ook niet altijd buiten de deur. Maar het is heel handig en fijn dat het kan. In deze analogie zie je goed dat Portal for ArcGIS onmisbaar is bij ArcGIS for Server.

Een keuze
Esri vindt het belangrijk om een keuze te bieden. Niet elke organisatie heeft de mogelijkheid om te werken in de cloud, andere organisaties hebben juist weer niet de resources om alles on-premises (lokaal) te regelen. In ArcGIS 10.3 biedt Esri een keuze: ArcGIS Online voor de cloud en/of Portal for ArcGIS on-premises. Bij elke ArcGIS for Server zit een Portal for ArcGIS. Daarmee heeft u de menukaart in uw handen.

Posted in Achter de schermen, ArcGIS Online, Esri | Tags: , , , | Plaats een reactie

Het keurmerk van ArcGIS Online

Klanten vragen me weleens of er geen gevaren zijn verbonden aan het gebruik van ArcGIS Online. Dat is goed te begrijpen als je denkt aan recente berichten in het nieuws over problemen met cloudoplossingen.

cloud-veilig

We doen de hele dag niet anders
dan omgaan met gevaren. Foto: Rasbak

Veiligheidsniveaus
Niet om het onderwerp te bagatelliseren, maar een wereld zonder gevaren bestaat niet. We doen de hele dag niet anders dan omgaan met gevaren. Grote delen van Nederland liggen onder zeeniveau, zoals mooi te zien is op de AHN-hoogtekaart in ArcGIS Online. We vinden het heel normaal dat we elektriciteit in natte ruimtes hebben. En als vader van drie opgroeiende dochters denk ik dagelijks na over de gevaren die zij lopen. ‘Veilig’ bestaat niet, er bestaan alleen veiligheidsniveaus.

Vertrouwen
Gelukkig hebben we een mengeling van strategieën gevonden om met al die gevaren en veiligheidsniveaus om te gaan. Voor sommige gevaren moet je alert blijven. We drukken bijvoorbeeld onze kinderen van alles op het hart – “kijk uit voor e-mails van onbekenden!” en “kijk uit bij het oversteken!”. Voor andere gevaren vertrouwen we erop dat de overheid het voor ons regelt. Zo vertrouwen we voor onze droge voeten op overheidsinstellingen als de waterschappen en Rijkswaterstaat. En voor weer andere gevaren vertrouwen we op een keurmerk, zoals KEMA-keur voor elektriciteit in natte ruimtes. “Als het maar een KEMA-keur heeft”, wordt dan gezegd.

Het is het werk van specialisten om te bepalen
aan welke keurmerken een oplossing moet voldoen.

Langer en completer
Om een keurmerk te behalen en behouden, moet aan een hele lijst van eisen worden voldaan. De lijst met eisen voor een keurmerk is langer en completer dan de lijst waar we zelf aan denken. Logisch, want er is door meerdere professionals over nagedacht. Het is het werk van specialisten om te bepalen aan welke keurmerken een oplossing moet voldoen. Zoals eerst in de Deltawet en later in de Wet op de Waterkering is bepaald aan welk veiligheidsniveau een dijk moet voldoen, zo moeten de securityspecialisten bepalen welke keurmerken een cloudoplossing moet hebben voor een bepaalde toepassing.

Veilig
Als klanten vragen of er geen gevaren zijn verbonden aan het gebruik van ArcGIS Online, raad ik ze aan om de vraag op die manier te herformuleren samen met hun securityspecialisten. En omdat ArcGIS Online voldoet aan zo’n beetje alle keurmerken die een SaaS-oplossing maar kan hebben (zoals ISO 27001, FedRAMP en FISMA), concluderen de meeste klanten dat ArcGIS Online veilig genoeg is voor hun toepassing.

Posted in ArcGIS Online | Tags: , , , , | Plaats een reactie

Het belang van een proeflapje

In een vorige blogpost wees ik op het belang van het omgaan met risico’s. Een hele begrijpelijke reactie vond ik: “Boris, hoe ga ik dan om met risico’s in de technologie?”.


Risico  

Stel, je hebt een technisch risico geïdentificeerd in een project. Laten we als uitgangspunt nemen dat je in het project een combinatie hebt van vertrouwde technologie en een technologie die je nog niet goed kent. Hoe ga je dan om met het laatste risico? Een belangrijke techniek die je kunt gebruiken is het proeflapje!

Proeflapje

Met een proeflapje weet je hoeveel wol
je nodig hebt.Foto van Arne Heggestad, ga naar foto 

Proeflapjes maken doe je zo 
Voor mensen die veel breien is een proeflapje een bekend begrip, maar voor de meeste mensen zal een uitleg op zijn plaats zijn. In het breipatroon staat aangegeven hoeveel pennen en steken je moet gebruiken om bijvoorbeeld een wollen trui met een bepaalde maat te maken – in mijn geval zou dat al snel lengtemaat XXL zijn. Maar de één maakt net wat lossere steken bij het breien dan de ander. En wol is een natuurlijk materiaal, dus de elasticiteit verschilt wel eens. Het aantal pennen en steken in een patroon is een gemiddelde. Daarom maak je eerst een proeflapje, om uit te proberen hoe je het precies moet doen. Als je weet hoe het moet, haal je het proeflapje gewoon weer uit. De wol kan dan worden hergebruikt.

Teveel geitenwollen sokken?  
Misschien spreekt deze analogie je niet zo aan. Dan is hier een militaire versie, want in gevechtssituaties doen ze net zoiets: daar sturen ze een verkenner voor de troepen uit. Bij Arendsoog was dat Witte Veder, in de Golfoorlog gebruikte Stormin’ Norman SEAL’s met Hummers. De verkenner bepaalt de beste route, geeft schattingen over de reistijd en geeft aan of er hindernissen moeten worden overwonnen. En dan kunnen de troepen aan de slag.

Het throw-away prototype
Ook in IT-projecten is het mogelijk op deze manier om te gaan met technische risico’s. Het proeflapje heet daar dan een throw-away prototype. Laat een ontwikkelaar (de verkenner) een versie maken die alleen maar aantoont hoe je met de technologie werkt. Hierbij worden de functies beperkt tot het absolute minimum. De code hoeft voor deze keer niet netjes of onderhoudbaar in elkaar te zitten en er zit geen foutafhandeling en logging in.

Verkenner3

Kies een goede verkenner

Foto van Cpl. James L.
Yarboro, U.S. Marine Corps 

 

 

 

Kies de goede verkenner
Uiteraard kies je een goede ontwikkelaar voor deze klus. De geschiedenis zit vol met voorbeelden van de rampzalige gevolgen van ontbrekende of verkeerde informatie van verkenners. Zo verloren de Romeinen in de slag om het Teutoberger Woud drie complete legioenen mede door ontbreken van verkenners en verloor Napoleon de slag bij Waterloo mede door verkeerde informatie van de verkenners. Xerxes en zijn Perzen daarentegen wonnen juist de slag bij Thermopylae van de Spartanen door goede informatie van verkenners.

Gooi het throw-away prototype weg
Als het prototype klaar is, gebruik je de inzichten die het maken heeft opgeleverd. De inzichten van het prototype worden verwerkt in het ontwerp en urenschattingen, het team kan nu worden opgeschaald en er kan worden begonnen met het bouwen van de echte versie in een schone omgeving. Het throw-away prototype zelf wordt na afloop weggegooid, zoals de naam al aangeeft. De verleiding is misschien groot om door te willen bouwen op het prototype, maar trap niet in die valkuil. Het prototype is niet geschikt als fundament; het was een bewuste keus om het prototype quick & dirty te realiseren. In je urenschatting ga je er vanuit dat je geen hergebruik kunt doen van het throw-away prototype in het echte product.

Pijpinspecties
Een mooi praktijkvoorbeeld van de inzet van een throw-away prototype komt van de ontwikkeling van EngeMOVI’s nieuwe device voor pijplijninspectie, of Pipe Inspection Gauge (PIG). Een pijplijninspectie-device wordt in een olie- of gaspijplijn ingebracht om de staat van de leiding te inspecteren. Bij de ontwikkeling identificeerden de ontwerpers het geolocatie algoritme als hun grootste technische risico. Hun throw-away prototype bestond uit een basale versie van meetapparatuur, bevestigd met tie-wrap op een fiets. Dit prototype stelde hen in staat hun algoritme te testen en te verfijnen, mede omdat een fiets bij benadering de gewenste snelheid heeft. Na de tests werd het prototype weer gedemonteerd.

Risicomitigatie
Als je een technisch risico hebt geïdentificeerd, dan is het gebruik van een throw-away prototype een goede manier om dit technisch risico aan te pakken of op zijn minst de impact te beperken (het risico te mitigeren). Een throw-away prototype kun je in iedere ontwikkelmethode gebruiken (waterval, scrum, jbf etc).  Dus: bepaal het risico van het project en pak het aan! Maak een proeflapje of stuur een kundige verkenner vooruit. Met deze onmisbare informatie kun jij de (wed)strijd winnen: het project op tijd en binnen budget succesvol afronden.

Posted in Developer, Projecten | Tags: , , , , | Plaats een reactie

Let op de piano van het project!

Laatst werd ik betrokken bij een project dat me deed denken aan mijn laatste verhuizing. Het projectteam was in moeilijkheden geraakt. Het project was bijna af, maar liep helemaal vast op het allerlaatste onderdeel. Zonder dit onderdeel zou de opdrachtgever beslist niet akkoord gaan met oplevering van het project. Of ik even kon helpen…

Er moest een hoogwerker worden besteld om de piano te verhuizen.

Er moest een hoogwerker worden besteld
om de piano te verhuizen.

Te zwaar om te dragen
De situatie leek op wat tijdens mijn verhuizing gebeurde: de verhuizers keken de hele dag telkens even naar onze 19e-eeuwse Bechstein-piano. Ze voelden soms even hoe zwaar onze piano was en gingen dan vooral snel verder met taken in hun comfortzone. Zoals het verhuizen van al die dozen met boeken. Aan het eind van de dag was de hele flat leeg en bezemschoon, maar de piano stond nog op zijn plek. Eindelijk kwam het hoge woord er uit. De ene piano is de andere niet en onze piano was met zijn degelijke gietijzeren binnenwerk te zwaar om de smalle trappen af te dragen – ze dachten dat hij wel 450 kilo zou zijn. Kortom, er moest een hoogwerker worden besteld. Natuurlijk gaf hun baas niet meteen zijn goedkeuring voor die extra kosten en daarna moesten we nog een hele tijd wachten voor de hoogwerker er was. Het werd dus een latertje.

Vooruit schuiven
Dit is hoe het soms ook gaat met projecten. De teamleden gaan allemaal enthousiast aan de slag met het soort problemen dat ze kennen en schuiven het onbekende nog even voor zich uit. Aan het einde van het project blijkt het onbekende tegen te vallen en mag de baas opdraaien voor de extra doorlooptijd en kosten.

Extra hulp en routineklussen
In het voorbeeld van de piano wordt goed duidelijk dat het slimmer is om de meest risicovolle delen van een project zo vroeg mogelijk aan te pakken. Als zo’n deel langer duurt dan verwacht of als er moet worden gewacht op extra hulp, dan kan de wachttijd immers worden gevuld met routineklussen die toch gedaan moeten worden. Zo lijdt de projectduur niet onder de moeilijkere projectonderdelen. In het ergste geval blijkt dat het risicovolle deel helemaal niet uit te voeren is, maar dat wordt dan dus al duidelijk voor er veel geld is uitgegeven aan de routineklussen.

Bij RUP pakt het ontwikkelteam al vroeg in het project de meest riskante onderdelen aan.

Bij RUP pakt het ontwikkelteam al vroeg in het
project de meest riskante onderdelen aan.

Risico’s vroeg aanpakken
Sommige ontwikkelmethodes hebben deze gedachte hoog in het vaandel, zoals Rational Unified Process (RUP). Bij RUP pakt het ontwikkelteam al vroeg in het project de meest riskante onderdelen aan. RUP is een ‘incrementele ontwikkelmethode’, waarbij een systeem in een aantal etappes (increments) wordt gemaakt. Incrementeel ontwikkelen heeft een aantal voordelen ten opzichte van de traditionele ‘waterval’: er is meer ruimte voor veranderende eisen en wensen, er is meer ruimte voor voortschrijdend inzicht, en er worden vaste piketpaaltjes geslagen richting eindacceptatie. Bij RUP worden de risico’s bovendien slimmer gemanaged.

Let op de piano
En het project waar ik moest helpen? Het had anders kunnen lopen, maar in dit geval zat er helaas niets anders op dan de opdrachtgever te vertellen dat het project uitliep. Gelukkig kon de opdrachtgever hierop wachten en kon het team leren van deze veelgemaakte fout. Zij letten voortaan op de piano!

Posted in Achter de schermen, Projecten | Tags: , , , , , , , | Plaats een reactie