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
maandag 5 december 2011
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...
vrijdag 2 september 2011
Out-of -the-box of maatwerk, that's the question
Waar ik ook advies geef, altijd steekt de maatwerk-discussie weer de kop op. "We willen absoluut geen maatwerk, alles moet 'out-of-the-box'!", is daarbij een veelgesteld standpunt. In de praktijk, echter, werkt dit standpunt nogal eens averechts; angstvallig vermijden van maatwerk kan namelijk ook onnodig geld en tijd kosten. En afgezien daarvan is vaak ook niet echt duidelijk wat wordt verstaan onder "maatwerk" en "out-of-the-box". Tijd dus om een en ander eens uitgebreid te behandelen om licht op de zaak te werpen en zo beter beslissingen te kunnen nemen.
Definities
Laten we beginnen met wat definities te geven en beschrijvingen wat maatwerk, out-of-the-box en de "smaken" daartussen in zijn.
Maatwerk, oftewel custom software: is software die speciaal voor een bepaalde situatie is gemaakt. Dit is niet gebaseerd op een bestaand platform, maar is vanaf de grond af speciaal ontworpen en gebouwd, speciaal voor de situatie.
Out-of-the-box software is software die, als het ware, na installatie al kan worden gebruikt voor het doel waarvoor het is aangeschaft. Dat is nogal ambitieus, want iedere situatie is namelijk anders en een software fabrikant kan natuurlijk nooit helemaal voorspellen waarvoor zijn software(platform) zal worden ingezet.
Vandaar ook dat aanpassingen aan software(platforms) vaak noodzakelijk zijn om deze aan te passen aan de situatie waarin ze gebruikt worden. En deze aanpassingen kunnen de volgende vormen aannemen:
- Aanpassingen in de vorm van configuratie; via de gebruikersinterfaces van de software instellen en aanpassen van de werking en functionaliteit van de software
- Uitbreidingen van de software, in de vorm van modules, adapters, enz..
Naast goed te weten wat voor type aanpassingen er aan de software mogelijk zijn is het ook belangrijk te weten wanneer welk type aanpassing in welke situatie gewenst is. De keuze om bijvoorbeeld voor out-of-the-box te kiezen, bijvoorbeeld, hoort namelijk geen doel op zich te zijn, maar een valide doel te dienen. En om dit doel te daarvoor moeten we wat breder kijken dan de ICT projecten zelf en kijken hoe een organisatie alternatieven beoordeelt. Het beoordelen van alternatieven gaat vaak, en ook in dit geval, op basis van risico inschattingen.
Risico's
Een organisatie streeft doelen (kwaliteit) na en die doelen kunnen op verschillende manieren worden gerealiseerd, waarbij kosten worden gemaakt en tijd wordt verbruikt. Geld en tijd is meestal van tevoren gereserveerd en beschikbaar, waarbij men ernaar streeft dit uit te geven met zo min mogelijk risico voor overschrijding en het niet behalen van de gestelde doelen en kwaliteit. En dat is de kern van de maatwerk vs. out-of-the-box problematiek: bepalen van het alternatief waarbij de gestelde doelen met een minimum aan risico kunnen worden behaald.
Maar hoe schatten we dat risico nu in? Waar moeten we naar kijken? Waar heeft dat risico betrekking op?
Vaak wordt helaas alleen gekeken naar de bouw van de eerste versie van een software oplossing, en nog niet eens naar installatie ervan, laat staan onderhoud, uitbreidingen en andere werkzaamheden. En dat terwijl de keuze voor out-of-the-box, maatwerk of een tussenvorm verdergaande gevolgen kan hebben.
Een praktijkvoorbeeld:
In een SharePoint ontwikkelomgeving wordt, volgens het out-of-the-box principe een prototype gebouwd van een website die vervolgens moet worden geïnstalleerd in de productie omgeving. Hiervoor blijken scripts noodzakelijk te zijn die ervoor moeten zorgen dat de website automatisch wordt geïnstalleerd in deze omgeving. De scripts moeten als maatwerk worden ontwikkeld, terwijl het uitgangspunt out-of-the-box was.
Een ander voorbeeld:
Een software oplossing wordt uitgebreid met een interface waardoor het mogelijk wordt om content via de RSS standaard te delen met andere applicaties. Hier wordt uitgegaan van maatwerk, maar met als gevolg dat verwachtte uitbreidingen kunnen worden gebaseerd op een standaard, hetgeen koppelen met out-of-the-box software oplossingen mogelijk wordt.
Het verdient daarom aanbeveling om te kijken naar de gehele software life cycle, en ook te kijken naar de gevolgen (impact) van de introductie van de oplossing binnen de organisatie.
Software life cycle
Software wordt niet eenmalig gebouwd, om vervolgens onaangepast tot in de eeuwigheid te functioneren. Grofweg zijn de volgende levensfasen van een software(platform) te onderscheiden:
1. Bouw en installatie van de eerste versie
2. Onderhoud, aanpassingen, uitbreidingen
3. Migratie naar een nieuwe versie
4. Afbouw
In alle bovenstaande fasen kan sprake zijn van maatwerk, out-of-the-box of een tussenvorm. En wanneer een eerste versie van een software oplossing wordt gebouwd als out-of-the-box wil dat niet zeggen dat voor de rest van de levensfasen uitgegaan kan worden van datzelfde out-of-the-box principe.
Het verdient dus aanbeveling om de gevolgen (impact) van de keuze voor maatwerk, dan wel out-of-the-box of een tussenvorm te bepalen voor alle levensfasen van de software oplossing.
Impact breder bekeken
Nu we het toch hebben over gevolgen (impact), laten we deze impact ook eens bepalen voor de omgeving waarin de software wordt gebruikt. Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk (als IAF) waarin helder gemaakt kan worden wat de gevolgen van oplossingskeuzen zijn voor business(processen, functies), informatiearchitectuur, technische infrastructuur, beheer en beveiliging. De keuze voor out-of-the-box kan bijvoorbeeld grote gevolgen hebben voor business processen.
Voorbeeld:
Introductie van een collaboratie platform waarbij eindgebruikers zelf hun omgeving kunnen inrichten (b.v. virtuele werkruimten aanmaken, collega's toegang geven, zelf content beheren) lijkt in eerste instantie de ontwikkelkosten voor een eerste versie te minimaliseren. Immers: in plaats van "dure" ICT specialisten, doen "gewone" eindgebruikers het (ontwikkel)werk. Echter, vanuit oogpunt van beheerbaarheid (governance) wordt een deel van de verantwoording bij niet-experts neergelegd, waardoor extra risico's worden gelopen op bijvoorbeeld wildgroei, waardoor beheerkosten en migratiekosten uiteindelijk hoger uitvallen.
Het nut van een bredere kijk op de gevolgen van keuze voor maatwerk, out-of-the-box of een tussenvorm is daarmee aangetoond.
Het lijkt allemaal logisch, maar toch denken we iedere keer weer van tevoren niet genoeg na over de keuze tussen maatwerk, out-of-the-box of een tussenvorm. De vraag is natuurlijk wat hiervan de oorzaak is.
De beperkte blik van projectmanagement
In de praktijk blijkt het hebben van een brede kijk op ICT projecten een uitdaging op zich te zijn. Reden hiervan is de manier waarop software ontwikkeling is georganiseerd; dit leent zich niet altijd voor een bredere (en daarmee kritische) kijk. Projecten worden namelijk beheerd door projectmanagers en projectmanagers worden beoordeeld kwaliteit, doorlooptijd en kosten van slechts een zeer beperkt deel van de software levensloop, vaak alleen de bouw van de eerste versie. Als de bouw van de eerste versie van een software oplossing naar tevredenheid verloopt, volgt een goede beoordeling. De gevolgen voor kosten, doorlooptijd en kwaliteit in volgende levensfasen, zal de projectmanager niet interesseren, hij is er immers niet verantwoordelijk voor. Zeker wanneer het project onder druk staat (lees: wanneer vooral doorlooptijd, en/of kosten dreigen te worden overschreden) zal een projectmanager kiezen voor oplossingen op de korte termijn, hetgeen gevolgen heeft in de latere levensfasen van de software oplossing.
De gevolgen
De gevolgen laten zich raden: implementatie - en onderhoudskosten voor ICT projecten rijzen de pan uit en lijken onbeheersbaar te zijn. Te hoge verwachtingen van mogelijkheden die platformen out-of-the-box aan functionaliteit bieden leiden tot teleurstellingen en moeten achteraf worden waargemaakt door (duur) maatwerk of sterk worden bijgesteld.
Dit kan natuurlijk beter.
Praktische tips om beter om te gaan met de keuze voor maatwerk, out-of-the-box of tussenvormen
In het algemeen: over de gevolgen van de verschillende strategieën zal van tevoren en projectoverstijgend nagedacht moeten worden.
Eerst zullen de verschillende mogelijke strategieën: van out-of-the-box tot en met maatwerk, goed gedefinieerd moeten worden. Wanneer wordt bij voorbeeld iets gerekend tot out-of-the-box? Aan welke eigenschappen moet het voldoen?
Daarna zal duidelijk moeten worden wat de gevolgen zijn van de mogelijke strategieën, in de verschillende levensstadia van de betreffende software oplossing.Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk als IAF.
Op basis van de bovenstaande uitwerking kan een onderbouwde keuze worden gemaakt.
Tenslotte zullen de genomen beslissingen projectoverstijgend moeten worden bekrachtigd; de verantwoordelijkheid van de projectmanager, als hij niet voor de hele software lifecycle verantwoordelijk is, is hierbij onvoldoende.
Definities
Laten we beginnen met wat definities te geven en beschrijvingen wat maatwerk, out-of-the-box en de "smaken" daartussen in zijn.
Maatwerk, oftewel custom software: is software die speciaal voor een bepaalde situatie is gemaakt. Dit is niet gebaseerd op een bestaand platform, maar is vanaf de grond af speciaal ontworpen en gebouwd, speciaal voor de situatie.
Out-of-the-box software is software die, als het ware, na installatie al kan worden gebruikt voor het doel waarvoor het is aangeschaft. Dat is nogal ambitieus, want iedere situatie is namelijk anders en een software fabrikant kan natuurlijk nooit helemaal voorspellen waarvoor zijn software(platform) zal worden ingezet.
Vandaar ook dat aanpassingen aan software(platforms) vaak noodzakelijk zijn om deze aan te passen aan de situatie waarin ze gebruikt worden. En deze aanpassingen kunnen de volgende vormen aannemen:
- Aanpassingen in de vorm van configuratie; via de gebruikersinterfaces van de software instellen en aanpassen van de werking en functionaliteit van de software
- Uitbreidingen van de software, in de vorm van modules, adapters, enz..
Naast goed te weten wat voor type aanpassingen er aan de software mogelijk zijn is het ook belangrijk te weten wanneer welk type aanpassing in welke situatie gewenst is. De keuze om bijvoorbeeld voor out-of-the-box te kiezen, bijvoorbeeld, hoort namelijk geen doel op zich te zijn, maar een valide doel te dienen. En om dit doel te daarvoor moeten we wat breder kijken dan de ICT projecten zelf en kijken hoe een organisatie alternatieven beoordeelt. Het beoordelen van alternatieven gaat vaak, en ook in dit geval, op basis van risico inschattingen.
Risico's
Een organisatie streeft doelen (kwaliteit) na en die doelen kunnen op verschillende manieren worden gerealiseerd, waarbij kosten worden gemaakt en tijd wordt verbruikt. Geld en tijd is meestal van tevoren gereserveerd en beschikbaar, waarbij men ernaar streeft dit uit te geven met zo min mogelijk risico voor overschrijding en het niet behalen van de gestelde doelen en kwaliteit. En dat is de kern van de maatwerk vs. out-of-the-box problematiek: bepalen van het alternatief waarbij de gestelde doelen met een minimum aan risico kunnen worden behaald.
Maar hoe schatten we dat risico nu in? Waar moeten we naar kijken? Waar heeft dat risico betrekking op?
Vaak wordt helaas alleen gekeken naar de bouw van de eerste versie van een software oplossing, en nog niet eens naar installatie ervan, laat staan onderhoud, uitbreidingen en andere werkzaamheden. En dat terwijl de keuze voor out-of-the-box, maatwerk of een tussenvorm verdergaande gevolgen kan hebben.
Een praktijkvoorbeeld:
In een SharePoint ontwikkelomgeving wordt, volgens het out-of-the-box principe een prototype gebouwd van een website die vervolgens moet worden geïnstalleerd in de productie omgeving. Hiervoor blijken scripts noodzakelijk te zijn die ervoor moeten zorgen dat de website automatisch wordt geïnstalleerd in deze omgeving. De scripts moeten als maatwerk worden ontwikkeld, terwijl het uitgangspunt out-of-the-box was.
Een ander voorbeeld:
Een software oplossing wordt uitgebreid met een interface waardoor het mogelijk wordt om content via de RSS standaard te delen met andere applicaties. Hier wordt uitgegaan van maatwerk, maar met als gevolg dat verwachtte uitbreidingen kunnen worden gebaseerd op een standaard, hetgeen koppelen met out-of-the-box software oplossingen mogelijk wordt.
Het verdient daarom aanbeveling om te kijken naar de gehele software life cycle, en ook te kijken naar de gevolgen (impact) van de introductie van de oplossing binnen de organisatie.
Software life cycle
Software wordt niet eenmalig gebouwd, om vervolgens onaangepast tot in de eeuwigheid te functioneren. Grofweg zijn de volgende levensfasen van een software(platform) te onderscheiden:
1. Bouw en installatie van de eerste versie
2. Onderhoud, aanpassingen, uitbreidingen
3. Migratie naar een nieuwe versie
4. Afbouw
In alle bovenstaande fasen kan sprake zijn van maatwerk, out-of-the-box of een tussenvorm. En wanneer een eerste versie van een software oplossing wordt gebouwd als out-of-the-box wil dat niet zeggen dat voor de rest van de levensfasen uitgegaan kan worden van datzelfde out-of-the-box principe.
Het verdient dus aanbeveling om de gevolgen (impact) van de keuze voor maatwerk, dan wel out-of-the-box of een tussenvorm te bepalen voor alle levensfasen van de software oplossing.
Impact breder bekeken
Nu we het toch hebben over gevolgen (impact), laten we deze impact ook eens bepalen voor de omgeving waarin de software wordt gebruikt. Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk (als IAF) waarin helder gemaakt kan worden wat de gevolgen van oplossingskeuzen zijn voor business(processen, functies), informatiearchitectuur, technische infrastructuur, beheer en beveiliging. De keuze voor out-of-the-box kan bijvoorbeeld grote gevolgen hebben voor business processen.
Voorbeeld:
Introductie van een collaboratie platform waarbij eindgebruikers zelf hun omgeving kunnen inrichten (b.v. virtuele werkruimten aanmaken, collega's toegang geven, zelf content beheren) lijkt in eerste instantie de ontwikkelkosten voor een eerste versie te minimaliseren. Immers: in plaats van "dure" ICT specialisten, doen "gewone" eindgebruikers het (ontwikkel)werk. Echter, vanuit oogpunt van beheerbaarheid (governance) wordt een deel van de verantwoording bij niet-experts neergelegd, waardoor extra risico's worden gelopen op bijvoorbeeld wildgroei, waardoor beheerkosten en migratiekosten uiteindelijk hoger uitvallen.
Het nut van een bredere kijk op de gevolgen van keuze voor maatwerk, out-of-the-box of een tussenvorm is daarmee aangetoond.
Het lijkt allemaal logisch, maar toch denken we iedere keer weer van tevoren niet genoeg na over de keuze tussen maatwerk, out-of-the-box of een tussenvorm. De vraag is natuurlijk wat hiervan de oorzaak is.
De beperkte blik van projectmanagement
In de praktijk blijkt het hebben van een brede kijk op ICT projecten een uitdaging op zich te zijn. Reden hiervan is de manier waarop software ontwikkeling is georganiseerd; dit leent zich niet altijd voor een bredere (en daarmee kritische) kijk. Projecten worden namelijk beheerd door projectmanagers en projectmanagers worden beoordeeld kwaliteit, doorlooptijd en kosten van slechts een zeer beperkt deel van de software levensloop, vaak alleen de bouw van de eerste versie. Als de bouw van de eerste versie van een software oplossing naar tevredenheid verloopt, volgt een goede beoordeling. De gevolgen voor kosten, doorlooptijd en kwaliteit in volgende levensfasen, zal de projectmanager niet interesseren, hij is er immers niet verantwoordelijk voor. Zeker wanneer het project onder druk staat (lees: wanneer vooral doorlooptijd, en/of kosten dreigen te worden overschreden) zal een projectmanager kiezen voor oplossingen op de korte termijn, hetgeen gevolgen heeft in de latere levensfasen van de software oplossing.
De gevolgen
De gevolgen laten zich raden: implementatie - en onderhoudskosten voor ICT projecten rijzen de pan uit en lijken onbeheersbaar te zijn. Te hoge verwachtingen van mogelijkheden die platformen out-of-the-box aan functionaliteit bieden leiden tot teleurstellingen en moeten achteraf worden waargemaakt door (duur) maatwerk of sterk worden bijgesteld.
Dit kan natuurlijk beter.
Praktische tips om beter om te gaan met de keuze voor maatwerk, out-of-the-box of tussenvormen
In het algemeen: over de gevolgen van de verschillende strategieën zal van tevoren en projectoverstijgend nagedacht moeten worden.
Eerst zullen de verschillende mogelijke strategieën: van out-of-the-box tot en met maatwerk, goed gedefinieerd moeten worden. Wanneer wordt bij voorbeeld iets gerekend tot out-of-the-box? Aan welke eigenschappen moet het voldoen?
Daarna zal duidelijk moeten worden wat de gevolgen zijn van de mogelijke strategieën, in de verschillende levensstadia van de betreffende software oplossing.Hiertoe kan gebruik worden gemaakt van een architectuur raamwerk als IAF.
Op basis van de bovenstaande uitwerking kan een onderbouwde keuze worden gemaakt.
Tenslotte zullen de genomen beslissingen projectoverstijgend moeten worden bekrachtigd; de verantwoordelijkheid van de projectmanager, als hij niet voor de hele software lifecycle verantwoordelijk is, is hierbij onvoldoende.
Abonneren op:
Posts (Atom)