5 Zaken die NIET in SharePoint architectuur documentatie thuis horen

Ik mijn werk kom ik regelmatig architectuur documenten tegen; ik maak ze zelf, ik gebruik ze en ik review ze. Hoewel iedere situatie weer anders is, kom ik vaak een aantal zaken tegen waarvan ik vind dat ze niet thuis horen in architectuur documentatie.

In deze blogpost de top 5...

1. Een beschrijving van de werking en het gebruik van SharePoint

Op eenzame hoogte: de "SharePoint handleiding" als onderdeel van de architectuur. Pagina's lange beschrijvingen hoe site collecties en site in elkaar zitten, hoe bibliotheken kunnen worden ingericht en welke "out-of-the-box" rollen bij welke rechten horen. Misschien interessant voor een beginnende SharePoint gebruiker, maar niet voor de doelgroep van de architectuur. Bovendien denk ik dat bij SharePoint architecturen juist niet de "standaard" van belang is te beschrijven, maar de wijzigingen die hierop zijn aangebracht.

2. Details, details, details

Er valt aan SharePoint veel in te stellen. En natuurlijk moet dat allemaal gedocumenteerd worden. Het is alleen de vraag waar dat moet gebeuren. Veel informatie hoort niet thuis in een architectuur document en kan verhuizen naar technische documentatie. Een architectuur document hoort de relevante hoofdlijnen te beschrijven en niet de details.

3. Project afhankelijke informatie

Projecten zijn veranderingen op de korte termijn, een architectuur beschrijft in het algemeen de richtlijnen voor de langere termijn. Voor een project relevante principes en richtlijnen (en afwijkingen hierop) horen thuis in een Project Start Architectuur (PSA). Project overstijgende zaken horen thuis in een referentie -, domain - of enterprise architectuur.

4. Architectuur als schetsboek van een eilandbewoner

Een architectuur is een communicatiemiddel; het geeft regels die in de praktijk gebruikt moeten worden. Daarvoor is 1) begrip en 2) draagvlak nodig. Veel architectuurdocumenten verdwijnen in de spreekwoordelijke lade omdat ze niet worden bijgehouden, daarom verouderen en onbruikbaar worden. Zonde van tijd en geld en uiterst frustrerend voor de architect en voor de CIO. Oorzaak hiervan ligt vaak bij de betrokkenheid van de organisatie bij het opstellen van de architectuur en door het type architect. Organisaties hebben veelal de neiging om "het maken van een architectuur ergens te beleggen" en vervolgens het resultaat af te wachten. Daarnaast zie ik dat architecten vaak de neiging hebben om "het beter te weten", "de hele wereld volgens eigen inzicht te willen modelleren" en dit "in hun eigen taal" te willen doen. Met dat laatste doel ik op de bonte verzameling PowerPoint plaatjes waarmee architectuurdocumenten regelmatig worden opgefleurd.

5. Her-her-her-herhaling

Copy and paste is makkelijk en staat garant voor lijvige documenten. Nadelen zijn: verminderde leesbaarheid en verminderde onderhoudbaarheid (wijzigingen moeten op meerdere plaatsen worden doorgevoerd). Ook hier geldt: "less is more".

Om de bovenstaande valkuilen te vermijden, de volgende tips voor SharePoint architecten:

1. Schrijf een architectuur document met het doel ervan in gedachten. Stem het document hierop af en beperk je daarbij. Aanvullende informatie wordt niet gebruikt en ontmoedigt het lezen en gebruiken ervan. Beperk je tot het niveau (waarom, wat, hoe en waarmee) en tot de aspecten (Business, Informatie, Informatie systemen, Infrastructuur, Security, Governance, et cetera) die echt relevant zijn.

2. Voortbouwend op het vorige punt: baken de scope van de te beschrijven architectuur duidelijk af. Bepaal hiervoor vantevoren duidelijk hoe het architectuur landschap wordt ingedeeld en welke delen in het de betreffende architectuur document worden beschreven. Geef ook expliciet aan welke delen buiten scope vallen.

3. Schrijf je architectuur document met de gebruikstermijn in gedachten. Legt een architectuur document richtlijnen vast voor de gehele organisatie (zoals een enterprise -, referentie of domain architectuur), dan mag dit slechts zeer beperkt aan verandering onderhevig zijn.

4. Kom van je eiland af en betrek de doelgroep!
Gebruik architectuur als een echt communicatiemiddel; stem het al op de doelgroep, gebruik raamwerken, talen en technieken (b.v. Archimate, IAF) die open en vrij verkrijgbaar zijn en betrek de doelgroep actief vanaf het begin. Zodoende kan voldoende getest worden of de doelgroep de architectuur nog begrijpt (b.v. door regelmatige reviews, inspraak sessies en informele gesprekken) en of de architectuur nog "gedragen" wordt.

Maatwerk, configuratie en out of the box: waarom en hoe onderscheid maken?

Ik hoor de discussie overal; waar ik ook kom, altijd wordt dezelfde discussie gevoerd: wat is precies maatwerk? En hierbij wordt maatwerk ook altijd angstvallig vermeden.

Tijd om eens wat dieper in te gaan op dit vraagstuk, om duidelijkheid te scheppen en handvatten te geven hoe hiermee om te gaan.

Waarom onderscheid tussen out of the box en maatwerk?
Maatwerk wordt in het algemeen geassocieerd met dure software ontwikkeling in een programmeertaal als C#, lange trajecten, duur in onderhoud en lastig overdraagbaar. Out of the box, daarentegen, wordt geassocieerd met goedkope en snelle ontwikkeling.

Het laatste is voor klanten (management, business) natuurlijk veel aantrekkelijker dan maatwerk, terwijl voor de gebruiker (business) en voor de programmeur (techniek) maatwerk interessanter is.

Voorkeur wordt voor een belangrijk deel gekleurd door emoties (ja, zelfs bij technici) en de gevolgen daarvan kunnen voor een project of programma het verschil betekenen tussen succes of falen.

Voorbeelden hiervan te over, bijvoorbeeld op aanbestedingsgebied. Hierin wordt door de klant vaak "out of the box" geëist waaraan in eerste instantie ook door de leverancier wordt voldaan. Gedurende de implementatie blijft dat maatwerk toch de voorkeur geniet (of zelfs noodzakelijk is), waarna zowel de implementatie doorloop tijd als de bijbehorende kosten door het dak gaan.

Resultaat: klant ontevreden en de leverancier en/of de gekozen technologie (of het platform) krijgen de schuld.

Jammer en niet nodig, als vantevoren maar nagedacht was geweest over de verschillende "smaakjes" en de gevolgen daarvan. In het woord "nadenken" zit het woordje "na", maar dat wil niet zeggen dat je pas ergens na moet gaan denken.

Maar waar gaat het eigenlijk mis?

De beloften van platforms en tooling
De laatste jaren bieden (webportal)platforms (dms,ecm, collaboration), veel beter dan vroeger, mogelijkheden om snel tot resultaat te komen door standaard (out of the box) basis functionaliteit te bieden waarmee de eindgebruiker relatief snel aan de slag kan. Ook tooling biedt steeds meer mogelijkheden voor niet software "gurus" om de functionaliteit van platformen aan te passen en uit te breiden.

Allemaal mooie ontwikkelingen, maar ontwikkelingen die hoge verwachtingen kunnen veroorzaken... en zelfs te hoge verwachtingen...

In de praktijk blijkt namelijk het volgende:
1. Out of the box functionaliteit is vaak te generiek om specifieke business processen te ondersteunen.
2. De eindgebruiker (en de business in het algemeen) weten te weinig af van de standaard mogelijkheden van platforms.
3. De eindgebruikers (en de business in het algemeen) zijn onvoldoende bereid zich neer te leggen bij de discrepanties tussen de eigen werkwijze en de werkwijze die het betreffende platform oplegt.
4. Projectmanagers (ICT, business) bieden onvoldoende weerstand aan de eis van de business om het platform te veranderen, hebben te weinig inhoudelijke bagage om te weten waar de grenzen van een platform liggen en geven specialisten te weinig inspraak bij belangrijke beslissingen die hierover worden gemaakt.

Om juiste beslissingen (lees: waar de klant tevreden mee is en waarvoor hij een redelijke prijs/doorlooptijd voor betaalt) is het nodig om zicht te hebben op de volgende zaken:

Wat wordt (in termen van het platform waaraan gesleuteld wordt) verstaan onder maatwerk? Zijn er gradaties hierin? Welke zijn dit, wat bieden ze aan mogelijkheden, beperkingen?

Wat zijn de gevolgen van de keuze voor een bepaalde gradatie? Wat is hiervoor nodig in termen van kosten en doorlooptijd?

Van out-of-the-box tot maatwerk: definities

Laat ik beginnen met een aantal definities die ik al een tijdje gebruik, en kijken of we die kunnen verbeteren (let wel: het gaat hier om SharePoint):

Out-of-the-box (OOTB): the supporting platform supports the recommended solution by default;
Configuration: the configuration of the supporting platform needs to be changed to support the recommended solution;
Limited Customization: adaptations by means of configuration, browser supported or SharePoint related tooling (e.g. Designer, InfoPath , XSLT);
Customization: software components of the supporting platform need to be changed / extended to support the recommended solution;
Extension: new, independent, software components need to be added to the supporting platform to support the recommended solution.

Van out-of-the-box tot maatwerk: definities
De volgende stap is even terug te gaan naar de vraag achter de vraag, namelijk waarom onderscheid gemaakt wordt tussen de verschillende categorieën. Deze vraag komt vaak neer op het willen beoordelen of een bepaalde oplossing te veel "pijn" gaat doen of niet. Ik heb expres de term "pijn" gebruikt, want in iedere situatie is deze pijn weer anders en wordt deze pijn andere gevoeld. "Pijn" kan betekenen dat een bepaalde oplossing duur is om te ontwikkelen, te veel onderhoud kost of lastig te migreren is naar een ander platform en daarom toekomstige pijn in de portemonnee (lees: budgetten) kost. Pijn kan ook betekenen dat de eindgebruikers (de business) onvoldoende worden ondersteund door de betreffende oplossing omdat deze bijvoorbeeld te weinig mogelijkheden biedt of te ver afstaat van de bestaande werkprocessen.

Bij de afweging tussen maatwerk en het gebruik van out-of-the-box functionaliteit moet dus gekeken worden  waar de "pijn" gelegd moet worden.

Projectmanager en opdrachtgever: kijk verder dan jullie neuzen lang zijn
Bovenstaande voorbeelden illustreren dat pijn voorkomt binnen en buiten het project waarin de oplossing ontwikkeld wordt. Een projectmanager is aangeleerd om zijn zaken binnen het project tijdig, binnen budget en kwaliteitseisen te realiseren, hetgeen natuurlijk op zich goed is, maar in de praktijk vaak niet voldoende blijkt te zijn. De "pijn" die binnen het project wordt vermeden kan buiten het project des te harder aankomen. Een goed voorbeeld hiervan is migratie; in migratieprojecten moeten gevolgen van beslissingen in eerder projecten vaak worden gecorrigeerd. Met name ongecontroleerd toestaan van maatwerk komt tijdens een migratietraject een organisatie duur te staan.

Het is daarom een goede zaak om verder te kijken dan het project zelf, bijvoorbeeld naar het overkoepelende programma of zelfs naar het overkoepelende informatieplan of de enterprise roadmap.

Ee doeltreffend denkraam hierbij is de software life cycle. Hierin wordt grofweg weeggegeven in welke levensfasen software zich kan bevinden en vormt daarmee een denkraam vanwaaruit bepaald kan worden welke gevolgen de keuze van maatwerk of out-of-the-box (of een variant hierop) heeft.

Samenvatting en conclusie
Een platform biedt (potentieel) een middel om snel een oplossing te bieden aan de business. Keuzes bij het aanpassen van het platform aan de wensen en eisen van de business dienen vantevoren goed te worden doordacht, waarbij verder gekeken moet worden dan de eerste op te leveren versie.

Vantevoren (samen met experts) nadenken is hierbij een betere investering dan achteraf de gevolgen van slechte beslissingen te moeten corrigeren.