Pingdom is een Software-as-a-Service-oplossing voor de monitoring van online services zoals websites, DNS, e-mail, etc. Pingdom wordt sterk aangeraden voor beginnende én professionele gebruikers die op een snelle en eenvoudige manier een effectieve monitoring van hun dienst willen opzetten.

• Promotiefilmpje over het medicatieschema

Zo getuige de media-aandacht dat het Vitalink project kreeg, na de officiële voorstelling van de pilootprojecten voorbije maandag 30 april:

• Turnhoutse regionale televisie
• TV Limburg
• De redactie

De aanpak van VAZG in het bijzonder vind ik erg snugger — in plaats van de “mastodont” aanpak die vaak aangewend wordt (en faalt) bij de eHealth projecten in het buitenland, kiest VAZG voor een tragere maar zekere uitrol vanuit de basis. Naar mijn mening heeft deze aanpak het meeste succes op slagen op lange termijn.

Het gaat immers om een zeer ingrijpende verandering en erg gevoelige gegevens…

Hoewel dit onoverkomelijk en dramatisch lijkt, kan men dit euvel in praktijk vaak verhelpen op voorwaarde dat men hier reeds tijdens de requirements analyse rekening mee houdt. De levensduur en vluchtigheid van de gegevens moet in kaart gebracht worden evenals de eisen op vlak van beschikbaarheid voor elke use-case, in plaats van voor het volledige systeem.

Als dit proces rigoureus uitgevoerd wordt, kan tijdens de architectuurfase de beschikbaarheid aanzienlijk verhoogd worden met een factor 40x (van 90 tot 99.75%). De uiteindelijke beschikbaarheid wordt bepaald door de kans op falen (menselijk, configuratie, hardware, software), maar ook door de tijd die nodig is voor de detectie en het herstellen van het incident. Om deze reden is een goed geoliede organisatie essentieel.

In deze nota worden aanbevelingen geformuleerd ter verhoging van de beschikbaarheid tijdens requirements analyse, wanneer de architectuur wordt uitgetekend, tijdens development, op infrastructuurvlak. Ook wordt het belang van transparantie, governance en automatisering aangetoond. Gezien de breedte van het onderwerp, zal de bespreking beperkt blijven tot een high-level overzicht.

Presentation

Hoewel dit onoverkomelijk en dramatisch lijkt, kan men dit euvel in praktijk vaak verhelpen op voorwaarde dat men hier reeds tijdens de requirements analyse rekening mee houdt. De levensduur en vluchtigheid van de gegevens moet in kaart gebracht worden evenals de eisen op vlak van beschikbaarheid voor elke use-case, in plaats van voor het volledige systeem.

Als dit proces rigoureus uitgevoerd wordt, kan tijdens de architectuurfase de beschikbaarheid aanzienlijk verhoogd worden met een factor 40x (van 90 tot 99.75%). De uiteindelijke beschikbaarheid wordt bepaald door de kans op falen (menselijk, configuratie, hardware, software), maar ook door de tijd die nodig is voor de detectie en het herstellen van het incident. Om deze reden is een goed geoliede organisatie essentieel.

In deze nota worden aanbevelingen geformuleerd ter verhoging van de beschikbaarheid tijdens requirements analyse, wanneer de architectuur wordt uitgetekend, tijdens development, op infrastructuurvlak. Ook wordt het belang van transparantie, governance en automatisering aangetoond. Gezien de breedte van het onderwerp, zal de bespreking beperkt blijven tot een high-level overzicht.

In enterprise applicaties is functionaliteit een belangrijk, maar vaak ook het gemakkelijkere deel van software ontwerp.  Zolang iedereen maar weet wat ie wilt: dat heeft meer  te maken met visie, duidelijke communicatie, verantwoordelijkheden en overleg, ethiek, eerlijkheid, psychologisch en sociologisch inzicht, dan met informatica.

Niet-functionele requirements (NFRs) zijn de uitdaging

De niet-functionele requirements maken software ontwerp echter moeilijk op een andere manier omdat ze niet dicteren wàt de software moet doen, maar hoé ze haar werk moet doen.  Behalve dat het verband tussen niet-functionele requirements en een ontwerp minder expliciet zijn (hoe druk je robuustheid van software formeel uit in functie van de geschreven code?), verhogen ze ook aanzienlijk de dimensionaliteit van het op te lossen vraagstuk. Het is niet moeilijk om snelle code te schrijven, het wordt moeilijk als ze ook functioneel correct moet zijn, hoogbeschikbaar, schaalbaar, elegant, uitbreidbaar, goedkoop in onderhoud en ga zo maar voort.

De vraag is: hoe kun je software leveren die een bepaalde beschikbaarheid belooft (bv. max. 8u downtime per jaar voor 99.9%) als je de beschikbaarheid nog nooit gemeten hebt? Of maar gedurende 3 maand in Acceptatie? Misschien had je geluk (goede statistische corner)? Is deze meting wel onder een realistische load gebeurd? Dezelfde redenering gaat op voor schaalbaarheid, fail-over, aanpasbaarheid, robuustheid, continuous operations, …

Meet de test de applicatie of omgekeerd?

Uit ethisch standpunt zou dus elke applicatie die in productie gezet wordt, rigoureus getest moeten worden op alle NFRs.  Hiervoor moet uiteraard test-software geschreven worden.  Essentieel hierbij is dat de test-software zeer goed geschreven en beheersd wordt, zodat we bij het verkijgen van een resultaat zeker weten dat deze beïnvloed werd door de applicatie en niet door de test.  Dit is de reden waarom test-apparatuur in elektronica zo duur is, bijvoorbeeld.

De arrogantie van de onwetendheid

Als een mens naar de wolken kijkt en zegt welke figuur zij/hij ziet, zegt dit meer over die persoon dan over de wolken. Niemand heeft de arrogantie om anders te beweren – waarom kunnen we dan niet hetzelfde bij software ontwerp?

Tijd dan voor een denkoefening: we gaan de klassieke manier van ontwerpen toepassen op de werking van een McDonalds restaurant…

Synchrone verwerking

Bij McDonalds is de verwerking van de bestellingen ontkoppeld van het vervaardigen van de hamburgers.  Beeld u in dat een verkoper verantwoordelijk zou zijn voor de hele (verticale) keten.   Hij zou de bestelling opnemen, de hamburger klaarmaken,de afrekening geven en slechts dan de volgende klant bedienen.  Als deze handeling 5 minuten duurt, kun je met één verkoper 12 klanten kunnen bedienen per uur.

Hij zou niet weten dat de volgende bestelling identiek zou zijn.. Hij zou voortdurend van context moeten veranderen (handen wassen), geld in ontvangst nemen.   Ook zou er erg moeilijk samengewerkt kunnen worden tussen de verschillende verkopers. Niet echt efficiënt dus.

Geen concurrency control (volledige parallellisatie)

Wat als je 24 klanten per uur wil bedienen? Per veelvoud van 12 moet er een extra verkoper aangeworven worden.  En wat als op een bepaald moment  deze 12 klanten tegelijk zouden aankomen?  De 12de zou een uur moeten wachten…

Maar wacht — deze verkoper kan misschien wel verschillende bestellingen tegelijk aannemen? (cf. multithreading) In het extreme geval wordt elke nieuwe bestelling meteen door een verkoper behandeld.  Hij is dan tegelijk bezig met het afhandelen van een betaling, het maken van een paar hamburgers, het opnemen van enkele bestellingen.  Iedereen ziet wel in dat de efficiëntie van deze verkoper drastisch zal dalen door deze “parallellisatie” –– hij beschikt immers slechts over beperkte resources (kan bv. maar N woorden per minuut schrijven – I/O)

Het is duidelijk dat er een optimale trade-off moet gevonden worden tussen de hoeveelheid parallellisatie (# tegelijk behandelde requests door een machine) en de grootte van de wachtrijen.  Stel dan nog dat je “oneindig” veel verkopers kunt aannemen… Op een bepaald moment is er een plaatsgebrek, niet?  Het evenwicht bevindt zich typisch niet aan een van de extremen en hangt af van de bezoekpatronen van de McDanolds —  misschien komen er nooit 12 mensen tegelijk aan?

Centraal register met recepten (centrale database)

Omwille de kwaliteit te garanderen, stelt de chef-kok een centraal register op waarin beschreven staat hoe elke hamburger bereid moet worden.  Omdat de chef zeker wil zijn dat de juiste recepten gevolgd worden, is het een verplichting  om het register steeds te raadplegen voor het klaarmaken van een hamburger.  5 verkopers kunnen wel samen lezen, maar als de chef een wijziging aanbrengt, is het register niet meer zichtbaar.

Wat als er 50 verkopers een recept willen lezen? Of wat als er heel vaak wijzigingen gebeuren?  Hoeveel verkopers er ook aangeworven worden, de bottleneck bevindt zich op het centraal register.  En wat als iemand het register per ongeluk onleesbaar maakt?

Caching aan het eind van de keten

Een ingrediënt voor een bepaald type hamburger is niet meer in stock.  Het is dus onmogelijk om deze hamburger te bereiden.   Omdat de verkoper echter geen korte-termijn geheugen heeft (geen cache), moet hij telkens het recept gaan opzoeken in het centraal register.  Hier haalt hij de ingrediënten op en vraagt of ze nog beschikbaar zijn.  Niet dus — de verkoper loopt terug naar de klant en brengt het spijtige nieuws. Hij loopt onnodig heen, en weer.

Bottom line

Het is belangrijk om bepaalde ontwerp-reflexen in vraag te stellen. Vaak zijn het dogma’s die niet universeel geldig zijn en een serieuze performantie, beschikbaarheid en schaalbaarheidsimpact hebben.

“Een mens is niet gemaakt om alleen te leven,
en vanaf twee maakt ge ruzie“.

Of, het gezond omgaan met conflicten maakt een wezenlijk deel uit van elke relatie. Deze les geldt ook voor een professionele relatie: het ontwikkelen van een applicatie gebeurt immers steeds in team.  Het succes van het uiteindelijke resultaat is volgens mij dan ook meer een gevolg van een vlotte samenwerking dan van de individuele competenties.

Hoewel dit al reeds begin jaren ’70 als cruciale succesfactor werd opgetekend, wordt het belang hiervan volgens mij onderkend, en wordt er (bijvoorbeeld tijdens aanwerving) teveel gefocused op technische competenties (die gemakkelijk aangeleerd worden als de nodige basis aanwezig is), In deze context stootte ik op het interessant artikel over “Egoless Programming”.

Voor meer informatie verwijs ik naar het artikel The Ten Commandments of Egoless Programming – ik herneem kort de tien geboden:

— 1 —
Understand and accept that you will make mistakes.

— 2 —
You are not your code.

— 3 —
No matter how much “karate” you know,
someone else will always know more.

— 4 —
Don’t rewrite code without consultation.

— 5 —
Treat people who know less than you
with respect, deference, and patience.

— 6 —
The only constant in the world is change.

— 7 —
The only true authority stems from
knowledge, not from position.

— 8 —
Fight for what you believe,
but gracefully accept defeat.

— 9 —
Don’t be “the guy in the room.”

— 10 —
Critique code instead of people —
be kind to the coder, not to the code.

Wegschrijven van gegevens naar de kluis

Kort komt threshold encryptie neer op traditionele asymmetrische encryptie met één publieke encryptiesleutel maar met twee private decryptiesleutels.  Het schrijven van een medisch dossier naar de “kluis” (de plek waar alle dossiers centraal worden opgeslagen) gebeurt op traditionele manier. Elk veld wordt apart aan de hand van een telkens unieke symmetrische sleutel vercijferd.  De symmetrische sleutel zelf wordt aan de hand van de publieke sleutel van het systeem, vercijferd:

Lezen van een dossier uit de kluis

Het lezen van een dossier is echter verschillend van standaard asymmetrische encryptie, en geschiedt in 3 fases:

1. De dokter vraagt een dossier op in de kluis en ontvangt de vercijferde unieke sessiesleutel, samen met de data vercijferd met deze sleutel
2. De vercijferde unieke sessiesleutel wordt naar 2 verschillende partijen gestuurd – elk met hun eigen private key – die een deel van de decryptie voor hun nemen.
3. De dokter combineert de twee delen tot een ontcijferde unieke sessiesleutel, waarme de werkelijke gegevens ontcijferd kunnen worden.

Merk dus op dat de gegevens enkel zichtbaar zijn bij de dokter en dat géén gegevens (zelfs niet vercijferd), door een van de externe partijen, vloeien.  Het is op dit gebruik van threshold encryptie, dat een patent is genomen.

]]> https://www.smalsresearch.be/dood-aan-de-standaardisatie/ https://www.smalsresearch.be/dood-aan-de-standaardisatie/#comments Fri, 06 May 2011 11:35:44 +0000 http://blogs.smals-mvm.be/research/?p=2138 Dilemma: Vernieuwing vs. Beheersing

Het beheersen van complexiteit wordt steeds belangrijker in het huidige IT landschap. In een poging om de complexiteit te beheersen, kiezen vele bedrijven voor het pad van “standaardisatie”, bijvoorbeeld  op vlak van gebruikte softwares of middlewareplatformen. Hoewel standaardisatie een manier is tot simplificatie, mag de strategie niet beperkt worden tot één logisch niveau omdat dit de complexiteit kan verhogen ipv. te verlagen. Bovendien worden bedrijven geconfronteerd met een fundamenteel conflict, ten gevolge van de onstopbare technologische vooruitgang :

Vernieuwing vs. Beheersing

In deze blogpost pleit ik dan ook voor een verticaal-georiënteerde standaardisatie over de gehele stack hardware-OS-middleware-software, rekening houdend met zowel vernieuwing als beheersing.   Noodzakelijkerwijs zal deze visie voor sommige lagen een destandaardisatie inhouden.

Standaardisatie kan de complexiteit verhogen

Samenspraak tussen de verschillende lagen in de stack (bv. OS, middleware, software) is noodzakelijk,omdat de beperking van de keuzes op een bepaald niveau (bv. OS), de complexiteit op een hoger niveau aanzienlijk kan verhogen.  De realiteit is nu eenmaal dat bepaalde technologieën beter draaien en eenvoudiger integreren op een specifiek platform.

Behalve dat bij standaardisatie het luik “configuratie” over het hoofd gezien wordt (ook configuraties moeten gestandaardiseerd worden — het beheersen van configuraties is meestal moeilijker dan het beheersen van de software zelf), heeft standaardisatie op één bepaald logisch niveau tot gevolg dat de complexiteit op een hoger niveau toeneemt.

Stel bv. dat een bedrijf qua Web Server enkel IIS toelaat.  Stabiele Out-Of-The-Box oplossingen zoals Drupal op een LAMP stack, worden hierdoor onnodig complex gemaakt omdat Drupal ontplooid wordt op een platform of in een configuratie waar het oorspronkelijk niet voor gebouwd is.  Best-of-breed aanpakken, waarbij “de juiste aanpak” wordt gebruikt voor een specifiek probleem, worden hierdoor dus onmogelijk, waardoor we dus komen tot suboptimale oplossingen, die vaak ook nog complexer zijn.

Destandaardisatie kan dus de complexiteit verlagen, omdat de stack in zijn geheel eenvoudiger wordt.

Last but not least speelt er een cultureel aspect: met het steeds hoger tempo van technologische innovatie,is het misschien beter om werknemers deze realiteit te laten omarmen, eerder dan ze er van af te schermen?