In de praktijk zie ik nog regelmatig dat architectuur wordt gezien als een onregelmatig terugkerende exercitie waarin grote hoeveelheden PowerPoint slides en lijvige Word documenten worden opgeleverd of als een noodzakelijk kwaad dat (ook vaak achteraf) aan projecten wordt toegevoegd.
Architectuur lijkt vaak (te veel) tijd (en geld) te kosten en te weinig toegevoegde waarde te hebben.
De toegevoegde waarde van architectuur
Komt het bovenstaande bekend voor? Dat is jammer, want architectuur heeft voor u dan niet de toegevoegde die het uw organisatie kan bieden. Architecten kunnen er namelijk voor zorgen dat uw ICT projecten doeltreffender en doelmatiger verlopen. Wat hier dan wel voor gedaan moet worden is dat architectuur zelf doeltreffend en doelmatig wordt ingezet. Hoe dit (op hoofdlijnen) kan worden gedaan zal in dit artikel worden beschreven.
Het doel van een architectuur is, grofweg, het vastleggen van richtlijnen voor (de ontwikkeling van) ICT oplossingen en business processen. Het biedt dus een uitstekende mogelijkheid om programma's en projecten op elkaar af te stemmen. En een juiste afstemming betekent doeltreffender en doelmatiger uitvoeren van programma's en projecten, en daarmee een doeltreffender functioneren van de organisatie in zijn geheel.
Wat hiervoor echter nodig is, is een juiste inzet van architectuur. En daar gaat het in de praktijk vaak mis. Reden hiervoor is dat architectuur vaak veel te veel "los" staat van de van de daadwerkelijke veranderingen in een organisatie (lees: programma's en projecten). Hierdoor wordt architectuur in de praktijk vaak niet of onvoldoende toegepast, wordt niet geleerd van de toepassing ervan en verliest architectuur daarmee snel zijn waarde.
Een geïntegreerde inzet van architectuur
Om architectuur waardevol te laten zijn voor een organisatie is een geïntegreerde inzet ervan cruciaal. Architectuur moet op alle niveau's in een organisatie worden ingezet en leerervaringen die opgedaan worden bij de toepassing ervan moeten ook daadwerkelijk worden verwerkt in de architectuur. Hierdoor wordt architectuur praktisch toepasbaar en wordt de waarde van architectuur zichtbaar verhoogd.
Architectuur op verschillende niveau's
Architectuur kan op verschillende niveau's in organisaties worden ingezet:
- Enterprise level: richtlijnen die gelden voor de hele organisatie
- Domain level: richtlijnen die gelden voor een specifiek toepassingsgebied
- Programma/Project architectuur: richtlijnen die gelden voor een specifiek programma of project
Ieder niveau biedt concrete principes (richtlijnen) voor het daaronder liggende niveau. De principes moeten helder, concreet en praktisch toepasbaar zijn, en zijn daarmee van waarde voor het onderliggende niveau. Principes zorgen ervoor dat keuzes gemakkelijker gemaakt kunnen worden, concepten en oplossingen kunnen worden hergebruikt en risico's beperkt kunnen worden. Daarmee zorgen principes ervoor dat in programma's en projecten doeltreffender en doelmatiger gewerkt kan worden.
Leren van ervaringen
Maar dat is slechts een deel van het verhaal. Richtlijnen bieden in de praktijk namelijk niet altijd een perfecte "oplossing". Soms bieden de richtlijnen geen (precies) passend antwoord op de vraag en moet hierop afgeweken worden. Nieuwe ontwikkelingen, innovaties, uitzonderingen zorgen voor een vraag naar nieuwe antwoorden en nieuwe - en aangepaste principes. En juist aan het doorvoeren van deze nieuwe - en aangepaste principes wordt in organisaties vaak te laat, weinig of geen aandacht besteed.
In programma's en projecten worden vaak nieuwe problemen (uitdagingen) tegengekomen en daarvoor nieuwe concepten en oplossingen bedacht. En jammer genoeg worden leerervaringen vaak niet voor hergebruik geschikt gemaakt waardoor andere programma's en projecten hier niet van kunnen profiteren.
Wat hiervoor nodig is een extra stap die in ieder programma en project zou moeten worden opgenomen: evaluatie en aanpassing van de gebruikte architecturen.
Aan het begin van een programma of project wordt meestal een Project Start Architectuur (PSA) opgesteld, op basis van een Domain (DA) - of Enterprise Achitectuur (EA). Relevante principes uit de DA en EA worden hierin opgenomen, waarbij noodzakelijke afwijkingen hierop worden bepaald, beschreven en onderbouwd. Deze afwijkingen worden met de DA en EA architecten besproken, doorgevoerd, tijdens het project bijgehouden en na afloop van een project geëvalueerd en gedocumenteerd.
Hiermee wordt bereikt dat "leerervaringen" van de toepassing van architectuur doeltreffend en doelmatig worden verwerkt in de diverse architecturen en deze snel praktisch toepasbaar zijn in andere programma's en projecten. De organisatie in zijn geheel leert hiermee dus snel en doeltreffend van de opgedane ervaringen.
Snel veranderende omstandigheden eisen snelle aanpassing
In deze snel veranderende wereld zullen organisaties zich steeds sneller moeten aanpassen aan veranderende omstandigheden. Een organisatie zal dus snel moeten leren van ervaringen. Dit is al een uitdaging op zich, wat alleen maar een grotere uitdaging wordt wanneer organisaties met elkaar gaan samenwerken. Wanneer opdrachten bijvoorbeeld worden uitbesteed aan meerdere partijen is de "grip" die een organisatie heeft op de uitbesteedde programma's en projecten van een nog groter belang. Onjuiste afstemming kost hier namelijk nog meer tijd (en geld) dan het geval is wanneer opdrachten binnen de eigen organisatie worden uitgevoerd. En een goede afstemming kan alleen bereikt worden met een gedeelde architectuur.
Des te meer reden dus om architectuur serieus te nemen, dit op de juiste manier in te richten en dit van "jaarlijks terugkerende exercitie" om te vormen in een continu proces waarmee de organisatie en de partners snel en doelmatig leren van de opgedane ervaringen.
zaterdag 30 maart 2013
maandag 5 december 2011
Architectuur standaarden
ArchiMate:
Business Process Modeling Notation (BPMN)
Design and Engineering Methodology for Organizations (DEMO)
Integrated Architecture Framework (IAF)
Model Architectuur Rijksdienst (MARIJ)
Nederlandse Overheid Referentie Architectuur (NORA)
Provinciale Referentie Architectuur (PETRA)
The Open Group Architecture Framework (TOGAF)
TOGAF online: reference guide
Unified Modeling Language (UML)
Zachman
Business Process Modeling Notation (BPMN)
Design and Engineering Methodology for Organizations (DEMO)
Integrated Architecture Framework (IAF)
Model Architectuur Rijksdienst (MARIJ)
Nederlandse Overheid Referentie Architectuur (NORA)
Provinciale Referentie Architectuur (PETRA)
The Open Group Architecture Framework (TOGAF)
TOGAF online: reference guide
Unified Modeling Language (UML)
Zachman
Tools
http://www.modelworld.nl/
Modelworld is een gratis online tool voor het maken van business architectuur modellen, business proces modellen en informatie systeem modellen. Ondersteund worden: ArchiMate, DEMO, BPMN, UML, Mockups.
Archi
Archi is gratis, open source, cross-platform en ondersteunt ArchiMate.
ArchiMate Starter's Kit
Veel documentatie over Archimate, maar ook een aantal Visio sjablonen waarmee meteen aan de slag gegaan kan worden.
Modelworld is een gratis online tool voor het maken van business architectuur modellen, business proces modellen en informatie systeem modellen. Ondersteund worden: ArchiMate, DEMO, BPMN, UML, Mockups.
Archi
Archi is gratis, open source, cross-platform en ondersteunt ArchiMate.
ArchiMate Starter's Kit
Veel documentatie over Archimate, maar ook een aantal Visio sjablonen waarmee meteen aan de slag gegaan kan worden.
Online modeling tool: www.modelworld.nl
Modelworld is een gratis online tool voor het maken van business architectuur modellen, business proces modellen en informatie systeem modellen. Ondersteund worden:
- ArchiMate
- Design and Engineering Methodology for Organizations (DEMO)
- Business Process Modeling Notation (BPMN)
- Unified Modeling Language (UML)
- Mockups
Modellen worden op een centrale server opgeslagen. De modelleertools werken in een browser, zonder daarbij gebruik te hoeven maken van plugins. Aangeraden browsers zijn Internet Explorer 9, Firefox 5, Chrome 12 en Safari 5.1.
De modellen kunnen door meerdere gebruikers tegelijk worden onderhouden. Ideaal voor in situaties waarin je niet de beschikking hebt over tools of wanneer je tools niet mag installeren op je pc.
Beta versie
Het gaat hier om een beta versie. Daardoor kunnen opgeslagen modellen verloren gan wanneer de server wordt gereset.
http://www.modelworld.nl/
Modelworld kan hier gevonden worden.
Voor uitleg is een Wiki beschikbaar.
- ArchiMate
- Design and Engineering Methodology for Organizations (DEMO)
- Business Process Modeling Notation (BPMN)
- Unified Modeling Language (UML)
- Mockups
Modellen worden op een centrale server opgeslagen. De modelleertools werken in een browser, zonder daarbij gebruik te hoeven maken van plugins. Aangeraden browsers zijn Internet Explorer 9, Firefox 5, Chrome 12 en Safari 5.1.
De modellen kunnen door meerdere gebruikers tegelijk worden onderhouden. Ideaal voor in situaties waarin je niet de beschikking hebt over tools of wanneer je tools niet mag installeren op je pc.
Beta versie
Het gaat hier om een beta versie. Daardoor kunnen opgeslagen modellen verloren gan wanneer de server wordt gereset.
http://www.modelworld.nl/
Modelworld kan hier gevonden worden.
Voor uitleg is een Wiki beschikbaar.
vrijdag 11 november 2011
Een informatie werkplek bestaat uit meer dan een website
Soms kan ik wel van de daken roepen. Dit is niet iets dat ik vaak bij klanten doe, tenzij ik te vroeg mijn koffie uit de automaat tracht te halen, het blijkt dat ik eerst een bekertje had moeten plaatsen en de automaat de hete koffie plichtsgetrouw maar niet gebruiksvriendelijk over mijn hand giet. De reden waarom ik dit soms figuurlijk wil doen is dat SharePoint weer een keer als Steen der wijzen wordt gebruikt. Nogmaals: het is een mooi, veelomvattend platform, maar soms zijn er handiger oplossingen waarin SharePoint een onderdeel is, en niet de totale oplossing. Dit vergt echter een kritische blik en vantevoren nadenken.
Maar wat is het geval?
SharePoint wordt vaak inzet als portal (in de vorm van en website), als (web) toegangsdeur en bewaarplaats voor documenten, andere informatie en functionaliteit. Dat is op zich terecht, want SharePoint leent zich daar uitstekend voor. Maar bij het doen van "dagelijks werk" hebben eindgebruikers nueenmaal indivuele eisen en wensen. En gezien eindgebruikers zowel de beschikking hebben over een ruime hoeveelheid aan gereedschappen (lees: applicaties en apparatuur) en ze de laatste decennia veel ruimte hebben gekregen hun eigen informatiewerkplek (lees: pc, desktop, "windows" of andere omgeving) zelf in te richten, is het opleggen van een nieuwe werkwijze (lees: een website waarin ineens (samen)gewerkt moet worden), een uitdaging.
Een concreet voorbeeld: de "startpagina"
Een voorbeeld van wat ik in de praktijk tegenkom is de zogenaamde startpagina; een pagina die als verplichte toegangspoort wordt gebruik voor functionaliteit die ook (of beter) via andere wegen kan worden benaderd. Neem nu een startpagina voor het maken van vergadersites. Een vergadersite is een SharePoint website waarin informatie over een vergadering en documentatie bij een vergadering wordt opgeslagen. Aanmaken ervan wordt verplicht gesteld via de startpagina terwijl vergaderverzoeken door eindgebruikers worden gemaakt in Outlook. De eindgebruiker moet dan twee handelingen uitvoeren in twee verschillende applicaties: namelijk aanmaken van een nieuwe vergadering in Outlook en de bijbehorende website aanmaken via de startpagina in SharePoint. En tot overmaat van ramp moet de eindgebruiker de vergadersite ook nog op de een of andere manier laten gebruiken door de deelnemers aan de vergadering. Dat kan hij doen door de een mail te sturen of door de link in de vergadersite op te nemen. Dit legt de eindgebruiker dus een omslachtige manier van werken op die in de praktijk natuurlijk slecht zal worden gebruikt en zal worden omzeild.
Een betere oplossing voor de bovenstaande casus is de vergadersites via Outlook te kunnen aanmaken en beheren en de startpagina te gebruiken als "een handig overzicht van alle vergaderingen". Zo sluit de SharePoint vergaderruimte aan op de vertrouwde en handige werkwijze van de eindgebruiker. Gevolg: de eindgebruiker is eerder geneigd vergadersites te gebruiken en informatie wordt beter en op een handiger manier gedeeld; deelnemers aan de vergadering hebben bijvoorbeeld allemaal dezelfde versies van agenda's, notulen en andere documentatie.
In het bovenstaande voorbeeld is duidelijk is dat de inzet van alleen SharePoint (websites) onvoldoende (en zelfs onhandig) is.
Wat hier verkeerd gaat is dat uitsluitend wordt uitgegaan van de website functie van SharePoint, niet van het totaal aan gereedschappen (lees: apparatuur en applicaties) die de gebruiker ter beschiking heeft. Daarmee wordt SharePoint, en niet de eindgebruiker, als uitgangspunt genomen. En dat is fundamenteel fout.
Uitgangspunt: de eindgebruiker
Uitgangspunt zal altijd moeten zijn: de eindgebruiker. In dit geval natuurlijk gemodelleerd in een persona (of meerdere persona's). Een persona, een archetype van een gebruiker, ofwel een karakterisering van een bepaald type van gebruiker (zie: http://nl.wikipedia.org/wiki/Persona_(IT)), geeft de analist, ontwerper, bouwer inzicht in de doelstellingen, omstandigheden en voorkeuren van een eindgebruiker(stype). Daarmee kan de te bouwen oplossing beter afgestemd worden op de behoeften van de eindgebruiker. Wat hierin, mijnsinziens, nogal eens over het hoofd gezien wordt, maar toch belangrijk is, zijn de gereedschappen die de eindgebruiker tot zijn beschikking heeft en het gebruik ervan voor zijn taken in de diverse omstandigheden waarin deze eindgebruiker terecht kan komen. Klinkt misschien cryptisch? Laat ik een concreet voorbeeld geven...
Maak kennis met de Accountmanager
Persona Accountmanager heeft als taak om produkten bij klanten te verkopen, klanten voor te lichten en klanten te vragen hoe ze de producten ervaren. 't Is een drukke baan waarvoor hij veel onderweg is en onder hoge druk moet presteren. Hij werkt dagelijks in de ochtend op kantoor en tegen de middag gaat hij naar zijn afspraken. Als hij de afspraken heeft gehad gaat hij naar huis en werkt hij daar op zijn laptop verder. Hij heeft daarbij toegang tot het netwerk van zijn werkgever.
De accountmanager werkt onder drie verschillende omstandigheden:
- Op kantoor
- Onderweg, in de auto
- Bij de klant
- Thuis
De accountmanager heeft de beschikking over de volgende gereedschappen:
- Zijn laptop, met daarop MS-Office (Word, Excel, Outlook, Access en PowerPoint ('t blijft een accountmanager), VPN applicatie voor toegang tot het netwerk van zijn werkgever, een WiFi zender/ontvanger, een synchronisatie applicatie om mail met zijn smartphone uit te wisselen.
- SharePoint: de verzamelplaats voor alle documenten van zijn verkoopafdeling, waarvoor een speciale site is ingericht. Hierin zijn offertes, documentatie over de procedures, klantinformatie et cetera opgeslagen. De omgeving wordt door alle accountmanagers gebruikt.
- Zijn smartphone, met daarop een e-mail "App", een "App" voor navigatie, een WiFi zender/ontvanger en GPS (voor zijn navigatie)
- Een WiFi thuisnetwerk voor thuisgebruik van zijn laptop.
In de bovenstaande omstandigheden kunnen niet alle gereedschappen gebruikt worden. En daarbij heeft de accountmanager onder verschillende omstandigheden een voorkeur voor bepaalde gereedschappen.
Voorbeelden
Enkele voorbeelden:
- Op werk mailt de accountmanager met Outlook vanaf zijn laptop. Gebruik van zijn SmartPhone is voor hem minder gebruiksvriendelijk, tenzij hij natuurlijk in een vergadering zit.
- De accountmanager werkt veel in Outlook, Excel en PowerPoint. De documenten slaat hij voornamelijk op op zijn lokale harde schijf. Definitieve versies en versies die door anderen beoordeeld of gebruikt worden, upload hij naar SharePoint (als hij op dat moment tenminste toeganbg heeft tot het netwerk van zijn werkgever). Vanwege de drukte schiet het "delen" van documenten via SharePoint er in de praktijk weleens bij in.
- Onderweg mail de accountmanager via zijn SmartPhone (even aangenomen dat de auto dan stil staat).
- Bij de klant heeft de accountmanager geen toegang tot internet en daarmee ook niet tot het netwerk van zijn werkgever (dit is een aanname voor deze casus, in de praktijk kan toegang technisch mogelijk zijn). Zodoende kan hij niet mailen, en niet bij documenten (SharePoint). Hij kan alleen offline werken. - Thuis heeft de accountmanager via zijn laptop toegang tot dezelfde informatie en applicaties als op werk.
Uit het bovenstaande blijkt dat de accountmanager de beschikking heeft over een aantal gereedschappen die hij onder verschillende omstandigheden wel, liever niet of helemaal niet kan gebruiken. Wat al grote verbeteringen zouden zijn in de gereedschapset van deze accountmanager zijn:
- Kunnen mailen van documenten naar dde gezamenlijke SharePoint site.
- Documenten beschikbaar stellen via een Outlook folder zodat de accountmanager voor de meest recente documenten niet naar de SharePoint web site hoeft te navigeren.
- Automatische synchronisatie van lokaal (laptop) opgeslagen documenten met de documenten in de SharePoint site.
En wat daar natuurlijk bij hoort is een instructie / training om de gereedschappen doeltreffend en doelmatig te gebruiken.
De juiste communicatiemix
Bovenstaande verbeteringen kunnen natuurlijk verder worden aangevuld, maar wat ik ermee wil zeggen is dat hierin verder wordt gekeken dan SharePoint zelf. Er wordt rekening gehouden met (bijna) alle gereedschappen en (bijna) alle omstandigheden waarin de persona zijn taken uitvoert. In andere woorden: de "communicatiemix" (zie voor een aardige definitie hiervan: http://pensioen-wiki.wikidot.com/communicatiemix) wordt zoveel mogelijk afgestemd op de taken en omstandigheden van deze persona.
Te veel focus op websites
In SharePoint implementaties zie ik in de praktijk echter een te grote focus op de website functie van SharePoint en daarmee wordt de eindgebruiker verplicht om alle functionaliteit en informatie via de webbrowser te benaderen. En dat legt de gebruiker beperkingen op, bijvoorbeeld:
- De website is lastiger te gebruiken op apparatuur met een kleiner beeldscherm als SmartPhones
- De gebruiker moet op dat moment toegang hebben tot de SharePoint omgeving, online zijn en b.v. via VPN toegang hebben
- De gebruiker moet zijn voorkeur werkwijze aanpassen. Nu moet hij documenten vanuit een website ophalen en, na aanpassen, hierin weer uploaden.
De makkelijkste weg kan leiden tot ondoelmatig (samen)werken
En in de praktijk zal de eindgebruiker (en zeker eindgebruikers die het druk hebben, zoals onze Accountmanager) de makkelijkste weg kiezen en de beste manier van werken wellicht omzeilen. Dit heeft gevolgen voor het doelmatig uitvoeren van taken (ergens omheen werken kost nueenmaal meer tijd dan nodig), en voor het doelmatig kunnen samenwerken (delen van informatie gebeurt nu minder en meer op ad hoc basis).
Conclusie en aanbevelingen
Bij het bedenken van gebruikersondersteuning wordt vaak uitsluitend uitgegaan van slechts 1 stuk gereedschap, vaak alleen de website functie van SharePoint, niet van het totaal aan de voor de eindgebruiker beschikbare gereedschappen (lees: apparatuur en applicaties). Daarmee worden oplossingen bedacht die niet aansluiten op de behoeften en mogelijkheden van de eindgebruiker, hetgeen het doelmatig uitvoeren van taken en samenwerking niet ten goede komt.
Denk dus breder dan websites en inventariseer eerst de beschikbare gereedschappen en de omstandigheden waarin deze gebruikt kunnen worden.
't Is weer een kwestie van (durven) nadenken voordat de weg van de implementatie wordt bewandeld, en het risico nemen dat dat niet altijd in dank wordt afgenomen.
Maar wat is het geval?
SharePoint wordt vaak inzet als portal (in de vorm van en website), als (web) toegangsdeur en bewaarplaats voor documenten, andere informatie en functionaliteit. Dat is op zich terecht, want SharePoint leent zich daar uitstekend voor. Maar bij het doen van "dagelijks werk" hebben eindgebruikers nueenmaal indivuele eisen en wensen. En gezien eindgebruikers zowel de beschikking hebben over een ruime hoeveelheid aan gereedschappen (lees: applicaties en apparatuur) en ze de laatste decennia veel ruimte hebben gekregen hun eigen informatiewerkplek (lees: pc, desktop, "windows" of andere omgeving) zelf in te richten, is het opleggen van een nieuwe werkwijze (lees: een website waarin ineens (samen)gewerkt moet worden), een uitdaging.
Een concreet voorbeeld: de "startpagina"
Een voorbeeld van wat ik in de praktijk tegenkom is de zogenaamde startpagina; een pagina die als verplichte toegangspoort wordt gebruik voor functionaliteit die ook (of beter) via andere wegen kan worden benaderd. Neem nu een startpagina voor het maken van vergadersites. Een vergadersite is een SharePoint website waarin informatie over een vergadering en documentatie bij een vergadering wordt opgeslagen. Aanmaken ervan wordt verplicht gesteld via de startpagina terwijl vergaderverzoeken door eindgebruikers worden gemaakt in Outlook. De eindgebruiker moet dan twee handelingen uitvoeren in twee verschillende applicaties: namelijk aanmaken van een nieuwe vergadering in Outlook en de bijbehorende website aanmaken via de startpagina in SharePoint. En tot overmaat van ramp moet de eindgebruiker de vergadersite ook nog op de een of andere manier laten gebruiken door de deelnemers aan de vergadering. Dat kan hij doen door de een mail te sturen of door de link in de vergadersite op te nemen. Dit legt de eindgebruiker dus een omslachtige manier van werken op die in de praktijk natuurlijk slecht zal worden gebruikt en zal worden omzeild.
Een betere oplossing voor de bovenstaande casus is de vergadersites via Outlook te kunnen aanmaken en beheren en de startpagina te gebruiken als "een handig overzicht van alle vergaderingen". Zo sluit de SharePoint vergaderruimte aan op de vertrouwde en handige werkwijze van de eindgebruiker. Gevolg: de eindgebruiker is eerder geneigd vergadersites te gebruiken en informatie wordt beter en op een handiger manier gedeeld; deelnemers aan de vergadering hebben bijvoorbeeld allemaal dezelfde versies van agenda's, notulen en andere documentatie.
In het bovenstaande voorbeeld is duidelijk is dat de inzet van alleen SharePoint (websites) onvoldoende (en zelfs onhandig) is.
Wat hier verkeerd gaat is dat uitsluitend wordt uitgegaan van de website functie van SharePoint, niet van het totaal aan gereedschappen (lees: apparatuur en applicaties) die de gebruiker ter beschiking heeft. Daarmee wordt SharePoint, en niet de eindgebruiker, als uitgangspunt genomen. En dat is fundamenteel fout.
Uitgangspunt: de eindgebruiker
Uitgangspunt zal altijd moeten zijn: de eindgebruiker. In dit geval natuurlijk gemodelleerd in een persona (of meerdere persona's). Een persona, een archetype van een gebruiker, ofwel een karakterisering van een bepaald type van gebruiker (zie: http://nl.wikipedia.org/wiki/Persona_(IT)), geeft de analist, ontwerper, bouwer inzicht in de doelstellingen, omstandigheden en voorkeuren van een eindgebruiker(stype). Daarmee kan de te bouwen oplossing beter afgestemd worden op de behoeften van de eindgebruiker. Wat hierin, mijnsinziens, nogal eens over het hoofd gezien wordt, maar toch belangrijk is, zijn de gereedschappen die de eindgebruiker tot zijn beschikking heeft en het gebruik ervan voor zijn taken in de diverse omstandigheden waarin deze eindgebruiker terecht kan komen. Klinkt misschien cryptisch? Laat ik een concreet voorbeeld geven...
Maak kennis met de Accountmanager
Persona Accountmanager heeft als taak om produkten bij klanten te verkopen, klanten voor te lichten en klanten te vragen hoe ze de producten ervaren. 't Is een drukke baan waarvoor hij veel onderweg is en onder hoge druk moet presteren. Hij werkt dagelijks in de ochtend op kantoor en tegen de middag gaat hij naar zijn afspraken. Als hij de afspraken heeft gehad gaat hij naar huis en werkt hij daar op zijn laptop verder. Hij heeft daarbij toegang tot het netwerk van zijn werkgever.
De accountmanager werkt onder drie verschillende omstandigheden:
- Op kantoor
- Onderweg, in de auto
- Bij de klant
- Thuis
De accountmanager heeft de beschikking over de volgende gereedschappen:
- Zijn laptop, met daarop MS-Office (Word, Excel, Outlook, Access en PowerPoint ('t blijft een accountmanager), VPN applicatie voor toegang tot het netwerk van zijn werkgever, een WiFi zender/ontvanger, een synchronisatie applicatie om mail met zijn smartphone uit te wisselen.
- SharePoint: de verzamelplaats voor alle documenten van zijn verkoopafdeling, waarvoor een speciale site is ingericht. Hierin zijn offertes, documentatie over de procedures, klantinformatie et cetera opgeslagen. De omgeving wordt door alle accountmanagers gebruikt.
- Zijn smartphone, met daarop een e-mail "App", een "App" voor navigatie, een WiFi zender/ontvanger en GPS (voor zijn navigatie)
- Een WiFi thuisnetwerk voor thuisgebruik van zijn laptop.
In de bovenstaande omstandigheden kunnen niet alle gereedschappen gebruikt worden. En daarbij heeft de accountmanager onder verschillende omstandigheden een voorkeur voor bepaalde gereedschappen.
Voorbeelden
Enkele voorbeelden:
- Op werk mailt de accountmanager met Outlook vanaf zijn laptop. Gebruik van zijn SmartPhone is voor hem minder gebruiksvriendelijk, tenzij hij natuurlijk in een vergadering zit.
- De accountmanager werkt veel in Outlook, Excel en PowerPoint. De documenten slaat hij voornamelijk op op zijn lokale harde schijf. Definitieve versies en versies die door anderen beoordeeld of gebruikt worden, upload hij naar SharePoint (als hij op dat moment tenminste toeganbg heeft tot het netwerk van zijn werkgever). Vanwege de drukte schiet het "delen" van documenten via SharePoint er in de praktijk weleens bij in.
- Onderweg mail de accountmanager via zijn SmartPhone (even aangenomen dat de auto dan stil staat).
- Bij de klant heeft de accountmanager geen toegang tot internet en daarmee ook niet tot het netwerk van zijn werkgever (dit is een aanname voor deze casus, in de praktijk kan toegang technisch mogelijk zijn). Zodoende kan hij niet mailen, en niet bij documenten (SharePoint). Hij kan alleen offline werken. - Thuis heeft de accountmanager via zijn laptop toegang tot dezelfde informatie en applicaties als op werk.
Uit het bovenstaande blijkt dat de accountmanager de beschikking heeft over een aantal gereedschappen die hij onder verschillende omstandigheden wel, liever niet of helemaal niet kan gebruiken. Wat al grote verbeteringen zouden zijn in de gereedschapset van deze accountmanager zijn:
- Kunnen mailen van documenten naar dde gezamenlijke SharePoint site.
- Documenten beschikbaar stellen via een Outlook folder zodat de accountmanager voor de meest recente documenten niet naar de SharePoint web site hoeft te navigeren.
- Automatische synchronisatie van lokaal (laptop) opgeslagen documenten met de documenten in de SharePoint site.
En wat daar natuurlijk bij hoort is een instructie / training om de gereedschappen doeltreffend en doelmatig te gebruiken.
De juiste communicatiemix
Bovenstaande verbeteringen kunnen natuurlijk verder worden aangevuld, maar wat ik ermee wil zeggen is dat hierin verder wordt gekeken dan SharePoint zelf. Er wordt rekening gehouden met (bijna) alle gereedschappen en (bijna) alle omstandigheden waarin de persona zijn taken uitvoert. In andere woorden: de "communicatiemix" (zie voor een aardige definitie hiervan: http://pensioen-wiki.wikidot.com/communicatiemix) wordt zoveel mogelijk afgestemd op de taken en omstandigheden van deze persona.
Te veel focus op websites
In SharePoint implementaties zie ik in de praktijk echter een te grote focus op de website functie van SharePoint en daarmee wordt de eindgebruiker verplicht om alle functionaliteit en informatie via de webbrowser te benaderen. En dat legt de gebruiker beperkingen op, bijvoorbeeld:
- De website is lastiger te gebruiken op apparatuur met een kleiner beeldscherm als SmartPhones
- De gebruiker moet op dat moment toegang hebben tot de SharePoint omgeving, online zijn en b.v. via VPN toegang hebben
- De gebruiker moet zijn voorkeur werkwijze aanpassen. Nu moet hij documenten vanuit een website ophalen en, na aanpassen, hierin weer uploaden.
De makkelijkste weg kan leiden tot ondoelmatig (samen)werken
En in de praktijk zal de eindgebruiker (en zeker eindgebruikers die het druk hebben, zoals onze Accountmanager) de makkelijkste weg kiezen en de beste manier van werken wellicht omzeilen. Dit heeft gevolgen voor het doelmatig uitvoeren van taken (ergens omheen werken kost nueenmaal meer tijd dan nodig), en voor het doelmatig kunnen samenwerken (delen van informatie gebeurt nu minder en meer op ad hoc basis).
Conclusie en aanbevelingen
Bij het bedenken van gebruikersondersteuning wordt vaak uitsluitend uitgegaan van slechts 1 stuk gereedschap, vaak alleen de website functie van SharePoint, niet van het totaal aan de voor de eindgebruiker beschikbare gereedschappen (lees: apparatuur en applicaties). Daarmee worden oplossingen bedacht die niet aansluiten op de behoeften en mogelijkheden van de eindgebruiker, hetgeen het doelmatig uitvoeren van taken en samenwerking niet ten goede komt.
Denk dus breder dan websites en inventariseer eerst de beschikbare gereedschappen en de omstandigheden waarin deze gebruikt kunnen worden.
't Is weer een kwestie van (durven) nadenken voordat de weg van de implementatie wordt bewandeld, en het risico nemen dat dat niet altijd in dank wordt afgenomen.
donderdag 22 september 2011
Gebruiksstatistieken... weet wat je meet!
Ik heb deze week een flink deel van de dag met mijn hoofd in Excel gezeten. Niet dat ik plotseling een management functie ambieer, maar omdat ik een goed (beter) beeld wilde hebben van het gebruik van een bepaalde SharePoint omgeving. Dit om een goede inschatting te krijgen van de hoeveelheid verkeer die ik kan verwachten op een applicatie die vanuit een SharePoint webpagina wordt aangesproken.
Ook een mooie gelegenheid om eens wat gedachten over web statistieken op een rijtje te zetten.
Allereerst antwoord op de vragen:
- Wat meten we?
- Waarom meten we?
Wat meten we?
Als een gebruiker (bezoeker) een web adres in zijn browser intypt dan legt de browser contact met de webserver waar de betreffende website is ondergebracht. Tijdens dit contact (request) worden gegevens over het verzoek door webserver vastgelegd in een logbestand. Dit is onder anderen wie het verzoek doet, welke bestanden hij opvraagt en wanneer de aanvraag is binnengekomen, maar ook zaken als het gebruikte besturingssysteem, de browserversie, etc.). Omdat een web pagina vaak bestaat uit een tekstbestand (HTML) waarin ook zaken als plaatjes voorkomen, zal de browser meerdere verzoeken doen aan de webserver: voor ieder bestand 1 request. Een webpagina waarin 3 plaatjes zijn opgenomen zal bijvoorbeeld 4 requests vergen: 1 voor de web pagina en 3 voor de plaatjes. Interactieve web pagina's, bijvoorbeeld waarin de eindgebruiker formulieren kan invullen en waarin ingevulde veldwaarden worden gecontroleerd, of web pagina's waarin illustraties elkaar afwisselen, zullen na het laden van de web pagina nog steeds requests aan de web server versturen voor additionele bestanden (plaatjes, controle resultaten, etc.).
Hier ontstaat een mogelijke verwarring: het verschil tussen hits en bezoekers.
Lang geleden, toen webpagina's, JavaScript en Perl-scripts nog met teksteditors werden geschreven, had ik een discussie met een business manager van een internet bedrijf over bezoek statistieken van een bepaalde web site. De sponsor van de web site werd maandelijks een rapport voorgeschoteld met daarin een uitspraak over de populariteit van deze web site en de de directeur was erop gebrand de getallen zo hoog mogelijk te laten uitvallen. In de logbestanden die ik moest analyseren maakte ik duidelijk verschil tussen het aantal hits (webpagina's, plaatjes, ander bestanden die door de browser werden opgevraagd) en bezoekers (toendertijd het aantal web pagina's dat werd opgevraagd). Het aantal bezoekers was natuurlijk aanmerkelijk lager en had niet de voorkeur van de betreffende directeur. Na uitleg van mij over wat precies werd gemeten werd de voorkeur enigszins aangepast door te sturen op het voorzien van de web pagina's van zoveel mogelijk plaatjes. Rest mij te zeggen dat ik hier niet aan heb meegewerkt :).
Ik wil met het bovenstaande voorbeeld overigens niet zeggen dat het meten van hits geen doel dient, want dat is geenszins het geval. Je moet alleen weten waarvoor je het kunt gebruiken, wat me brengt op het doel van het meten.
Web site of web applicatie?
Maar allereerst het volgende. In de onderstaande tekst heb ik het over web applicaties. Hieronder versta ik de verzamelnaam voor web sites (html, rss, etc.) en applicaties (b.v. apps) die gebruik maken van een web server.
Waarom meten we?
Grofweg kunnen de volgende doelen met meten worden nagestreefd:
- Meten van de populariteit van een produkt of dienst
- Meten van het gebruiksgemak van een web applicatie
- Meten van beschikbaarheid, prestaties en werklast van een web applicatie
Meten van de populariteit van een produkt of dienst
Dit is een breed doel, maar komt is essentie neer op het bepalen in hoeverre het produkt of de dienst die door de betreffende web applicatie ondersteunt interesse geniet van de internet gebruiker. Van belang hierbij zijn bijvoorbeeld hoeveel echte bezoekers de web applicaties krijgt, of deze bezoekers regelmatig terugkomen en welke handelingen de bezoekers uitvoeren. Dit laatste is natuurlijk het allerbelangrijkst: een bezoeker kan slechts de begin pagina bekijken, maar ook geinteresseerd rondkijken, en in het beste geval een of meerdere transacties afsluiten (lees: iets via de web applicatie aanschaffen).
Indirect is de populariteit trouwens het meten van de doeltreffendheid van de verwijzingen naar de betreffende web applicaties, bijvoorbeeld vanuit zoekresultaten en banners/advertenties. In het algemeen: wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat iets zeggen over de populariteit van de web applicatie en/of het ondersteunde produkt of de ondersteunde dienst. Wellicht is het gelinkte onderdeel zoveel gebruikt dat het een gemakkelijker te bereiken plaats in het menu verdient?
Aanvullende, belangrijke metingen kunnen natuurlijk gedaan worden door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).
Meten van het gebruiksgemak van een web applicatie
Hierbij gaat het om meetgegevens waaruit kan worden afgeleid hoe gebruiksvriendelijk de bezoeker de betreffende web applicatie vindt, ofwel: antwoord vinden op de vraag of de bezoeker zijn doel op een voor hem voldoende gemakkelijke manier kan bereiken. Wat hierbij belangrijk is te meten welke weg (klik- of zoekpad) de bezoeker aflegt voordat hij zijn doel bereikt, en dit te vergelijken met de optimale navigatie zoals die in het ontwerp van de web applicatie is bedacht.
Interessant hierin is ook het gebruik van de zoek faciliteiten de betreffende web applicatie. Ingevulde zoektermen, zoekresultaten verfijnen (b.v. door faceted search) en navigatie vanuit de zoekresultaten zeggen veel over de onderwerpen waarnaar de bezoeker naar op zoek is en de doelmatigheid van zijn zoektocht. Wellicht betekent veelvuldig gebruik van de zoekmachine naar een bepaalde term dat het onderwerp in kwestie slecht vindbaar is?
Ook wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat ook iets over het gebruiksgemak van de web applicatie. Wellicht is het gelinkte onderdeel dan ook lastig te vinden?
Gerelateerd aan het meten van het gebruiksgemak van een web applicatie is het meten van het gebruiksgemak van de wijze waarop de web applicatie wordt gevonden, bijvoorbeeld vanuit zoekresultaten en banners/advertenties.
Ook hierbij kunnen aanvullende, belangrijke, metingen natuurlijk worden gedaan door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).
Tenslotte zeggen foutmeldingen veel over het gebruiksgemak dat een bezoeker ervaart. Fouten als een "404" of "Not Found" (zie ook: HTTP 404) worden wel vastgelegd maar regelmatig niet meegenomen in bezoekstatistieken.
Meten van beschikbaarheid, prestaties en werklast van een web applicatie
Deze categorie doelen heeft een duidelijk technische achtergrond.
Meten van beschikbaarheid van web applicaties (en de onderliggende diensten als servers, besturingssystemen, platforms etc.) is essentieel binnen web dienstverlening. Hierbij gaat het in essentie om het halen van gemaakte afspraken (SLA's) die over de web dienstverlening zijn gemaakt tussen de klant (business) en de IT-leverancier waarbij het meten van beschikbaarheid als onderbouwing kan worden gebruikt. Hierbij gaat het trouwens dus om hits in plaats van bezoekers, omdat de beschikbaarheid gemeten wordt van alle (technische) bronnen; HTML webpagina's, plaatjes, scripts, etc..
Een speciaal doel van het meten (zowel hits als bezoekers) is het bepalen van de werklast die een bepaalde web applicatie zal moeten kunnen verwerken of de werklast die een daaraan gerelateerde (gelinkte of geintegreerde) (web) applicatie zal moeten kunnen verwerken. Zie hiervoor ook mijn artikel over integratie: Platform integratie: functionaliteit onder handbereik.
Een paar voorbeelden ter illustratie...
Een web applicatie zal worden gemigreerd naar een nieuw platform
Hierbij zal bepaald moeten worden in hoeverre het nieuwe platform (en onderliggende soft- en hardware) voldoende geschaald is of schaalbaar is om de verwachtte werklast te kunnen verwerken. Een goede inschatting van het bezoek en het gebruik van bronnen (hits op bestanden) is hiervoor essentieel.
In een bestaande nieuws webpagina worden RSS feeds vanuit een andere bron weergegeven
In het algemeen: een web applicatie zal gebruik maken van een andere web applicatie, en hier dus web verkeer op genereren en daarmee de werklast van de andere web applicatie verhogen. Het is hierbij dus van belang om te weten om welke extra werklast het hier gaat. Bezoekersaantallen van de web applicatie (b.v. de nieuwspagina in het voorbeeld) zijn hierbij daarom van belang. Voor iedere bezoek wordt minimaal een request gedaan aan de andere web applicatie. Mocht de andere web applicatie de extra werklast niet kunnen verwerken, kan dat negatieve gevolgen hebben voor de web applicatie(s) die ervan gebruik ma(a)k(t)(en). Een web applicatie kan dan bijvoorbeeld trager functioneren of deels of geheel niet beschikbaar lijken te zijn.
Van belang bij het meten hiervan is onderscheid te maken tussen gemiddelde werklast en piekbelasting.
Valkuilen en praktische tips, een overzicht
Op basis van de bovenstaande doelen en praktische ervaringen, onderstaand een aantal belangrijke valkuilen en praktische tips.
- Houd het doel van de analyse goed in de gaten en gebruik de juiste metingen daarbij
Gaat het om populariteit, ga dan niet uit van hits. Gaat het om werklastbepaling, ga niet alleen uit van bezoekers, maar neem alle web verkeer mee in de analyse.
- In vakantieperioden is het aanmerkelijk rustiger dan in "normale" werkweken.
Daarnaast vieren we niet tegelijk onze vakanties; ons land is ingedeeld in regio's, dus als het in de ene regio een normale werkweek lijkt, kan een regio waar vakantie gevierd wordt, de hoeveelheid web verkeer omlaag brengen. Tenslotte zijn (dat is voornamelijk bij intranetten van belang) werkweken niet bij iedere organisatie dezelfde: soms wordt er bijvoorbeeld ook in het weekend gewoon doorgewerkt. Ga daarom uit van "normale" werk weken zoals die in de betreffende organisatie gelden.
- Bij het berekenen van gemiddelde - en piekbelasting moet je rekening houden met werkdagen, werktijden, pauzetijden, en andere bijzondere tijdsperioden.
In het algemeen zou rekening gehouden kunnen worden met een 8 urige werkdag waarin medewerkers eerder kunnen beginnen of later kunnen stoppen. Ik ga meestal uit van een 10 urige tijdsspanne. Gedurende pauzes en aan het begin en einde van de werkdag ontstaan vaak pieken of dalen in het webverkeer.
Pieken in web verkeer, vooral aan het begin van de dag, ontstaan doordat...
- ... bij het opstarten van de browser vaak meteen een standaard webpagina (b.v. de homepage van het intranet) wordt geladen.
Dit geeft een vertekend beeld van de populariteit van de homepage (en een piek in het webverkeer aan het begin van de dag). Dit webverkeer zal daarom buiten de populariteitsmetingen gehouden moeten worden, maar zal wel meegenomen moeten worden bij belastingmetingen. Let op: in de praktijk veelvuldig crashen van pc's en browsers zorgt eveneens voor een toename in webverkeer op de standaard ingestelde browser homepage.
- Spiders en monitors genereren ook webverkeer; filter dit verstandig uit. Een web server registreert alle requests vanuit alle bronnen. Naast browsers (die verzoeken namens gebruikers doen), worden requests ook automatisch gedaan door programmatuur. Voorbeelden hiervan zijn: monitors, spiders (bijvoorbeeld voor zoekmachines), maar ook: RSS newsreaders. Deze requests zijn herkenbaar aan de informatie die bij die requests aan de web server worden meegegeven zoals gebruikersnaam (zoals bijvoorbeeld service accounts in het geval van spiders op intranetten) en type client (b.v. browser / reader versie). Dergelijke requests zullen ook met de regelmaat van een klok plaatsvinden; op vaste dagen / tijdstippen.
Wat betreft web verkeer vanuit RSS readres: het opvragen van een (RSS) web pagina hoeft niet noodzakelijkerwijs te betekenen dat een nieuwsbron populair is. Een klik vanuit een RSS feed naar het achterliggende artikel zegt meer.
Wanneer een inschatting van belasting gemaakt moet worden, moet web verkeer van spiders, monitors, etc. meegenomen worden. Wordt de populariteit gemeten, dan kan dit verkeer er wellicht beter uit gefilterd worden of kan het web verkeer opgesplitst worden naar kanaal / device / type applicatie waarvan het afkomstig is.
- Meten van webverkeer op individuele pagina's zegt relatief weinig over de populariteit van een site of web pagina.
Wat meer zegt is het gedrag van de bezoeker; klikpaden, zoektermen, afsluiten van transacties, etc..
- Vergeet niet te meten wat er fout gaat.
Een bezoeker die regelmatig geconfronteerd wordt met fouten, haakt af. En dat kan nooit de bedoeling zijn.
Conclusie
Aanleiding voor het schrijven van dit artikel was dat ik deze week een flink deel van de dag met mijn hoofd in Excel heb gezeten. Waarom ik dat deed is dat ik twijfelde aan de bezoekstatistieken die ik in mooie diagrammen en overzichtjes vanuit een web statistiek software pakket kreeg voorgeschoteld en die normaliter voor waarheid werd aangenomen.
Mijn twijfel bleek terecht: een groot deel van de gemeten "populariteit" bleek veroorzaakt te worden door automatische bezoekjes van spiders en monitors.
Meten is weten, maar weet eerst wat je meet.
Ook een mooie gelegenheid om eens wat gedachten over web statistieken op een rijtje te zetten.
Allereerst antwoord op de vragen:
- Wat meten we?
- Waarom meten we?
Wat meten we?
Als een gebruiker (bezoeker) een web adres in zijn browser intypt dan legt de browser contact met de webserver waar de betreffende website is ondergebracht. Tijdens dit contact (request) worden gegevens over het verzoek door webserver vastgelegd in een logbestand. Dit is onder anderen wie het verzoek doet, welke bestanden hij opvraagt en wanneer de aanvraag is binnengekomen, maar ook zaken als het gebruikte besturingssysteem, de browserversie, etc.). Omdat een web pagina vaak bestaat uit een tekstbestand (HTML) waarin ook zaken als plaatjes voorkomen, zal de browser meerdere verzoeken doen aan de webserver: voor ieder bestand 1 request. Een webpagina waarin 3 plaatjes zijn opgenomen zal bijvoorbeeld 4 requests vergen: 1 voor de web pagina en 3 voor de plaatjes. Interactieve web pagina's, bijvoorbeeld waarin de eindgebruiker formulieren kan invullen en waarin ingevulde veldwaarden worden gecontroleerd, of web pagina's waarin illustraties elkaar afwisselen, zullen na het laden van de web pagina nog steeds requests aan de web server versturen voor additionele bestanden (plaatjes, controle resultaten, etc.).
Hier ontstaat een mogelijke verwarring: het verschil tussen hits en bezoekers.
Lang geleden, toen webpagina's, JavaScript en Perl-scripts nog met teksteditors werden geschreven, had ik een discussie met een business manager van een internet bedrijf over bezoek statistieken van een bepaalde web site. De sponsor van de web site werd maandelijks een rapport voorgeschoteld met daarin een uitspraak over de populariteit van deze web site en de de directeur was erop gebrand de getallen zo hoog mogelijk te laten uitvallen. In de logbestanden die ik moest analyseren maakte ik duidelijk verschil tussen het aantal hits (webpagina's, plaatjes, ander bestanden die door de browser werden opgevraagd) en bezoekers (toendertijd het aantal web pagina's dat werd opgevraagd). Het aantal bezoekers was natuurlijk aanmerkelijk lager en had niet de voorkeur van de betreffende directeur. Na uitleg van mij over wat precies werd gemeten werd de voorkeur enigszins aangepast door te sturen op het voorzien van de web pagina's van zoveel mogelijk plaatjes. Rest mij te zeggen dat ik hier niet aan heb meegewerkt :).
Ik wil met het bovenstaande voorbeeld overigens niet zeggen dat het meten van hits geen doel dient, want dat is geenszins het geval. Je moet alleen weten waarvoor je het kunt gebruiken, wat me brengt op het doel van het meten.
Web site of web applicatie?
Maar allereerst het volgende. In de onderstaande tekst heb ik het over web applicaties. Hieronder versta ik de verzamelnaam voor web sites (html, rss, etc.) en applicaties (b.v. apps) die gebruik maken van een web server.
Waarom meten we?
Grofweg kunnen de volgende doelen met meten worden nagestreefd:
- Meten van de populariteit van een produkt of dienst
- Meten van het gebruiksgemak van een web applicatie
- Meten van beschikbaarheid, prestaties en werklast van een web applicatie
Meten van de populariteit van een produkt of dienst
Dit is een breed doel, maar komt is essentie neer op het bepalen in hoeverre het produkt of de dienst die door de betreffende web applicatie ondersteunt interesse geniet van de internet gebruiker. Van belang hierbij zijn bijvoorbeeld hoeveel echte bezoekers de web applicaties krijgt, of deze bezoekers regelmatig terugkomen en welke handelingen de bezoekers uitvoeren. Dit laatste is natuurlijk het allerbelangrijkst: een bezoeker kan slechts de begin pagina bekijken, maar ook geinteresseerd rondkijken, en in het beste geval een of meerdere transacties afsluiten (lees: iets via de web applicatie aanschaffen).
Indirect is de populariteit trouwens het meten van de doeltreffendheid van de verwijzingen naar de betreffende web applicaties, bijvoorbeeld vanuit zoekresultaten en banners/advertenties. In het algemeen: wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat iets zeggen over de populariteit van de web applicatie en/of het ondersteunde produkt of de ondersteunde dienst. Wellicht is het gelinkte onderdeel zoveel gebruikt dat het een gemakkelijker te bereiken plaats in het menu verdient?
Aanvullende, belangrijke metingen kunnen natuurlijk gedaan worden door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).
Meten van het gebruiksgemak van een web applicatie
Hierbij gaat het om meetgegevens waaruit kan worden afgeleid hoe gebruiksvriendelijk de bezoeker de betreffende web applicatie vindt, ofwel: antwoord vinden op de vraag of de bezoeker zijn doel op een voor hem voldoende gemakkelijke manier kan bereiken. Wat hierbij belangrijk is te meten welke weg (klik- of zoekpad) de bezoeker aflegt voordat hij zijn doel bereikt, en dit te vergelijken met de optimale navigatie zoals die in het ontwerp van de web applicatie is bedacht.
Interessant hierin is ook het gebruik van de zoek faciliteiten de betreffende web applicatie. Ingevulde zoektermen, zoekresultaten verfijnen (b.v. door faceted search) en navigatie vanuit de zoekresultaten zeggen veel over de onderwerpen waarnaar de bezoeker naar op zoek is en de doelmatigheid van zijn zoektocht. Wellicht betekent veelvuldig gebruik van de zoekmachine naar een bepaalde term dat het onderwerp in kwestie slecht vindbaar is?
Ook wanneer een bezoeker direct vanuit een externe bron (b.v. een favorite, externe link, zoekmachine) naar een lokatie (web pagina) in de betreffende web applicatie "springt", kan dat ook iets over het gebruiksgemak van de web applicatie. Wellicht is het gelinkte onderdeel dan ook lastig te vinden?
Gerelateerd aan het meten van het gebruiksgemak van een web applicatie is het meten van het gebruiksgemak van de wijze waarop de web applicatie wordt gevonden, bijvoorbeeld vanuit zoekresultaten en banners/advertenties.
Ook hierbij kunnen aanvullende, belangrijke, metingen natuurlijk worden gedaan door het houden van enquetes of het laten beoordelen van de web applicatie door de bezoeker (tagging/rating).
Tenslotte zeggen foutmeldingen veel over het gebruiksgemak dat een bezoeker ervaart. Fouten als een "404" of "Not Found" (zie ook: HTTP 404) worden wel vastgelegd maar regelmatig niet meegenomen in bezoekstatistieken.
Meten van beschikbaarheid, prestaties en werklast van een web applicatie
Deze categorie doelen heeft een duidelijk technische achtergrond.
Meten van beschikbaarheid van web applicaties (en de onderliggende diensten als servers, besturingssystemen, platforms etc.) is essentieel binnen web dienstverlening. Hierbij gaat het in essentie om het halen van gemaakte afspraken (SLA's) die over de web dienstverlening zijn gemaakt tussen de klant (business) en de IT-leverancier waarbij het meten van beschikbaarheid als onderbouwing kan worden gebruikt. Hierbij gaat het trouwens dus om hits in plaats van bezoekers, omdat de beschikbaarheid gemeten wordt van alle (technische) bronnen; HTML webpagina's, plaatjes, scripts, etc..
Een speciaal doel van het meten (zowel hits als bezoekers) is het bepalen van de werklast die een bepaalde web applicatie zal moeten kunnen verwerken of de werklast die een daaraan gerelateerde (gelinkte of geintegreerde) (web) applicatie zal moeten kunnen verwerken. Zie hiervoor ook mijn artikel over integratie: Platform integratie: functionaliteit onder handbereik.
Een paar voorbeelden ter illustratie...
Een web applicatie zal worden gemigreerd naar een nieuw platform
Hierbij zal bepaald moeten worden in hoeverre het nieuwe platform (en onderliggende soft- en hardware) voldoende geschaald is of schaalbaar is om de verwachtte werklast te kunnen verwerken. Een goede inschatting van het bezoek en het gebruik van bronnen (hits op bestanden) is hiervoor essentieel.
In een bestaande nieuws webpagina worden RSS feeds vanuit een andere bron weergegeven
In het algemeen: een web applicatie zal gebruik maken van een andere web applicatie, en hier dus web verkeer op genereren en daarmee de werklast van de andere web applicatie verhogen. Het is hierbij dus van belang om te weten om welke extra werklast het hier gaat. Bezoekersaantallen van de web applicatie (b.v. de nieuwspagina in het voorbeeld) zijn hierbij daarom van belang. Voor iedere bezoek wordt minimaal een request gedaan aan de andere web applicatie. Mocht de andere web applicatie de extra werklast niet kunnen verwerken, kan dat negatieve gevolgen hebben voor de web applicatie(s) die ervan gebruik ma(a)k(t)(en). Een web applicatie kan dan bijvoorbeeld trager functioneren of deels of geheel niet beschikbaar lijken te zijn.
Van belang bij het meten hiervan is onderscheid te maken tussen gemiddelde werklast en piekbelasting.
Valkuilen en praktische tips, een overzicht
Op basis van de bovenstaande doelen en praktische ervaringen, onderstaand een aantal belangrijke valkuilen en praktische tips.
- Houd het doel van de analyse goed in de gaten en gebruik de juiste metingen daarbij
Gaat het om populariteit, ga dan niet uit van hits. Gaat het om werklastbepaling, ga niet alleen uit van bezoekers, maar neem alle web verkeer mee in de analyse.
- In vakantieperioden is het aanmerkelijk rustiger dan in "normale" werkweken.
Daarnaast vieren we niet tegelijk onze vakanties; ons land is ingedeeld in regio's, dus als het in de ene regio een normale werkweek lijkt, kan een regio waar vakantie gevierd wordt, de hoeveelheid web verkeer omlaag brengen. Tenslotte zijn (dat is voornamelijk bij intranetten van belang) werkweken niet bij iedere organisatie dezelfde: soms wordt er bijvoorbeeld ook in het weekend gewoon doorgewerkt. Ga daarom uit van "normale" werk weken zoals die in de betreffende organisatie gelden.
- Bij het berekenen van gemiddelde - en piekbelasting moet je rekening houden met werkdagen, werktijden, pauzetijden, en andere bijzondere tijdsperioden.
In het algemeen zou rekening gehouden kunnen worden met een 8 urige werkdag waarin medewerkers eerder kunnen beginnen of later kunnen stoppen. Ik ga meestal uit van een 10 urige tijdsspanne. Gedurende pauzes en aan het begin en einde van de werkdag ontstaan vaak pieken of dalen in het webverkeer.
Pieken in web verkeer, vooral aan het begin van de dag, ontstaan doordat...
- ... bij het opstarten van de browser vaak meteen een standaard webpagina (b.v. de homepage van het intranet) wordt geladen.
Dit geeft een vertekend beeld van de populariteit van de homepage (en een piek in het webverkeer aan het begin van de dag). Dit webverkeer zal daarom buiten de populariteitsmetingen gehouden moeten worden, maar zal wel meegenomen moeten worden bij belastingmetingen. Let op: in de praktijk veelvuldig crashen van pc's en browsers zorgt eveneens voor een toename in webverkeer op de standaard ingestelde browser homepage.
- Spiders en monitors genereren ook webverkeer; filter dit verstandig uit. Een web server registreert alle requests vanuit alle bronnen. Naast browsers (die verzoeken namens gebruikers doen), worden requests ook automatisch gedaan door programmatuur. Voorbeelden hiervan zijn: monitors, spiders (bijvoorbeeld voor zoekmachines), maar ook: RSS newsreaders. Deze requests zijn herkenbaar aan de informatie die bij die requests aan de web server worden meegegeven zoals gebruikersnaam (zoals bijvoorbeeld service accounts in het geval van spiders op intranetten) en type client (b.v. browser / reader versie). Dergelijke requests zullen ook met de regelmaat van een klok plaatsvinden; op vaste dagen / tijdstippen.
Wat betreft web verkeer vanuit RSS readres: het opvragen van een (RSS) web pagina hoeft niet noodzakelijkerwijs te betekenen dat een nieuwsbron populair is. Een klik vanuit een RSS feed naar het achterliggende artikel zegt meer.
Wanneer een inschatting van belasting gemaakt moet worden, moet web verkeer van spiders, monitors, etc. meegenomen worden. Wordt de populariteit gemeten, dan kan dit verkeer er wellicht beter uit gefilterd worden of kan het web verkeer opgesplitst worden naar kanaal / device / type applicatie waarvan het afkomstig is.
- Meten van webverkeer op individuele pagina's zegt relatief weinig over de populariteit van een site of web pagina.
Wat meer zegt is het gedrag van de bezoeker; klikpaden, zoektermen, afsluiten van transacties, etc..
- Vergeet niet te meten wat er fout gaat.
Een bezoeker die regelmatig geconfronteerd wordt met fouten, haakt af. En dat kan nooit de bedoeling zijn.
Conclusie
Aanleiding voor het schrijven van dit artikel was dat ik deze week een flink deel van de dag met mijn hoofd in Excel heb gezeten. Waarom ik dat deed is dat ik twijfelde aan de bezoekstatistieken die ik in mooie diagrammen en overzichtjes vanuit een web statistiek software pakket kreeg voorgeschoteld en die normaliter voor waarheid werd aangenomen.
Mijn twijfel bleek terecht: een groot deel van de gemeten "populariteit" bleek veroorzaakt te worden door automatische bezoekjes van spiders en monitors.
Meten is weten, maar weet eerst wat je meet.
maandag 19 september 2011
Platform integratie: functionaliteit onder handbereik
Vaak krijg ik de vraag of ik een applicatie kan ontsluiten binnen een platform, bijvoorbeeld SharePoint. Wat een gebruiker of ICT beheerorganisatie hieronder verstaat, verschilt van geval tot geval, en daarmee lopen de verwachtingen die ik moet scheppen of bijstellen ook nogal.
Daarom heb ik maar eens een overzicht van varianten gemaakt die in in de praktijk tegenkom, in volgorde van mogelijkheden en complexiteit.
1. Link (vanuit het bronplatform wordt gelinkt naar het doelplatform of de doelapplicatie):
a. Zonder authenticatie/autorisatie
b. Met handmatige authenticatie/autorisatie (onhandig)
c. Met automatische authenticatie/autorisatie (single sign on)
d. Directe link naar gewenst scherm / gewenste functionaliteit
2. Viewport (publicatie van (deel van) gebruikersinterface van het doelplatform in het bronplatform):
a. Zonder authenticatie/autorisatie
b. Met handmatige authenticatie/autorisatie (erg onhandig)
c. Met automatische authenticatie/autorisatie (single sign on)
d. Directe link naar gewenst scherm / gewenste functionaliteit
3. View (geïntegreerd gegevens overzicht , of rapportage, vanuit de doelapplicatie naar de bronapplicatie):
a. Niet geparameteriseerd: altijd hetzelfde overzicht
b. Geparameteriseerd : varianten van het overzicht, op basis van aan de doelapplicatie opgegeven parameters
4. Interact:
a. Submit: opsturen van formulieren (webform, via workflow of integration broker / bus, via e-mail, etc.) en Response hierop vanuit het doelsysteem (view, e-mail, etc.)
b. Interactive: de gebruikersinterface van het doelsysteem is geïntegreerd in de gebruikersinterface van het bronplatform.
5. Informatiewerkplek integratie: geintegreerde applicaties koppelen aan (een) andere (geintegreerde) applicatie(s)
Wat voorbeelden ter illustratie:
- Via Word (een extra knop in de "Ribbon") kan een lijst uit SharePoint worden gehaald en worden gebruikt voor een mailmerge naar klanten (gebruik van velden in Word-documenten).
- In een Excel sheet (.qry file) kan een SharePoint lijst worden geimporteerd, die vervolgens binnen MS-Word wordt gebruikt voor een mailmerge.
Kenmerk van dergelijke integratie is dat het gebruik van de geintegreerde functies niet in een vaste volgorde of samenstelling hoeft te gebeuren. In een informatiewerkplek bepaalt de gebruiker veelal zelf hoe hij zijn werk "doet".
Wat nu een interessante vraag is, is de volgende: waarmee moet ik "rekening houden" bij de verschillende vormen van integratie? Wat zijn de gevolgen van gemaakte keuzen?
Om deze vraag te beantwoorden, zullen we eerst moeten bekijken waar de gevolgen van keuzes plaats gaan vinden. Daarvoor gebruik ik vaak een architectuur raamwerk (in dit geval IAF), waarbij de verschillende aspecten (business, informatie, applicaties, infrastructuur) waarin gevolgen zichtbaar zijn, aan de orde komen.
Meer volgt...
Daarom heb ik maar eens een overzicht van varianten gemaakt die in in de praktijk tegenkom, in volgorde van mogelijkheden en complexiteit.
1. Link (vanuit het bronplatform wordt gelinkt naar het doelplatform of de doelapplicatie):
a. Zonder authenticatie/autorisatie
b. Met handmatige authenticatie/autorisatie (onhandig)
c. Met automatische authenticatie/autorisatie (single sign on)
d. Directe link naar gewenst scherm / gewenste functionaliteit
2. Viewport (publicatie van (deel van) gebruikersinterface van het doelplatform in het bronplatform):
a. Zonder authenticatie/autorisatie
b. Met handmatige authenticatie/autorisatie (erg onhandig)
c. Met automatische authenticatie/autorisatie (single sign on)
d. Directe link naar gewenst scherm / gewenste functionaliteit
3. View (geïntegreerd gegevens overzicht , of rapportage, vanuit de doelapplicatie naar de bronapplicatie):
a. Niet geparameteriseerd: altijd hetzelfde overzicht
b. Geparameteriseerd : varianten van het overzicht, op basis van aan de doelapplicatie opgegeven parameters
4. Interact:
a. Submit: opsturen van formulieren (webform, via workflow of integration broker / bus, via e-mail, etc.) en Response hierop vanuit het doelsysteem (view, e-mail, etc.)
b. Interactive: de gebruikersinterface van het doelsysteem is geïntegreerd in de gebruikersinterface van het bronplatform.
5. Informatiewerkplek integratie: geintegreerde applicaties koppelen aan (een) andere (geintegreerde) applicatie(s)
Wat voorbeelden ter illustratie:
- Via Word (een extra knop in de "Ribbon") kan een lijst uit SharePoint worden gehaald en worden gebruikt voor een mailmerge naar klanten (gebruik van velden in Word-documenten).
- In een Excel sheet (.qry file) kan een SharePoint lijst worden geimporteerd, die vervolgens binnen MS-Word wordt gebruikt voor een mailmerge.
Kenmerk van dergelijke integratie is dat het gebruik van de geintegreerde functies niet in een vaste volgorde of samenstelling hoeft te gebeuren. In een informatiewerkplek bepaalt de gebruiker veelal zelf hoe hij zijn werk "doet".
Wat nu een interessante vraag is, is de volgende: waarmee moet ik "rekening houden" bij de verschillende vormen van integratie? Wat zijn de gevolgen van gemaakte keuzen?
Om deze vraag te beantwoorden, zullen we eerst moeten bekijken waar de gevolgen van keuzes plaats gaan vinden. Daarvoor gebruik ik vaak een architectuur raamwerk (in dit geval IAF), waarbij de verschillende aspecten (business, informatie, applicaties, infrastructuur) waarin gevolgen zichtbaar zijn, aan de orde komen.
Meer volgt...
Abonneren op:
Posts (Atom)