donderdag 20 juni 2013

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.

Geen opmerkingen:

Een reactie plaatsen