Laat ik met de deur in huis vallen: een klant vroeg mij laatst om "een architectuur te bedenken" om te gebruiken wanneer SharePoint ontwikkeling en beheer uitbesteed zouden worden. Om hier een passend antwoord op te bedenken (eentje waarbij het antwoord niet bestaat uit een stapel papier of PowerPoints die niet worden gebruikt) moeten we de vraag eerst analyseren. Wat bedoelt de klant hier eigenlijk mee en wat heeft hij echt nodig?
Hiervoor moeten we, vanuit de bij uitbesteding betrokken partijen, kijken naar de volgende onderwerpen:
- Uitbesteding;
- SharePoint projecten,
en bepalen in welke opzichten architectuur hier ondersteuning kan bieden.
In deze blogpost deel 1: hoe architectuur kan ondersteunen bij uitbesteding. In een vervolg post de rol van architectuur bij uit te besteden SharePoint projecten.
Uitbesteding
Dit is het contracteren van een externe dienstverlener of toeleverancier om de vantevoren gedefinieerde taken in het vervolg uit te voeren. In de praktijk is het gevolg hiervan dat de samenwerking tussen de verschillende betrokken teams sterk geformaliseerd wordt. En daarbij zijn goede werkafspraken van cruciaal belang. En dan hebben we het alleen nog over het uitvoeren van opdrachten, er zijn in uitbesteding ook anderen fasen van belang. We hebben het hier over:
- Selectie van een leverancier
- Transitie van de dienstverlening naar de geselecteerde leverancier
- Leveren van diensten door de leverancier
- Beëindiging van het contract met de leverancier en overdracht van de werkzaamheden aan een andere leverancier.
In al deze fase speelt de kwaliteit van werkafspraken een cruciale rol. Dit geldt voor alle betrokken partijen; voor zowel de opdrachtgever als de leverancier:
Als opdrachtgever wil je...
De regie in handen hebben; enerzijds veranderingen kunnen sturen en anderzijds de Total Cost of Ownership (TCO) van het geheel aan diensten beheersbaar houden. Hiertoe moeten diensten, programma's en projecten voldoende op kwaliteit, geld en doorlooptijd kunnen worden beheer(s)d.
Bij de selectie is het daarom van belang om een goede inschatting te maken in hoeverre de diensten van een leverancier bij kunnen dragen aan de bovenstaande doelen. In hoeverre beschikt de leverancier bijvoorbeeld over de juiste kennis en ervaring? In hoeverre ondersteunt hij de gevraagde standaarden? In hoeverre sluit hij aan op het geheel van diensten (b.v. infrastructuur)? Hoe beter de aansluiting, hoe beter de leverancier kan presteren.
Een architectuur beschrijving kan voor de beantwoording van de bovenstaande vragen als een checklist worden gebruikt waarin de aansluiting van de diverse leveranciers kan worden beschreven. De architectuur beschrijving bestaat dan onder anderen uit beschrijvingen van de infrastructuur, platformen, applicaties, koppelvlakken, maar ook van proces standaarden als ontwikkel - en beheerprocessen. Op hoger abstractieniveau (contextueel) kan een beschrijving van de strategie, doelstellingen et cetera worden gegeven om de "richting" aan de geven waarin de opdrachtgever zich wil ontwikkelen. Aansluiting van een opdrachtnemer hierop is eveneens van belang. Immers; als de opdrachtgever zijn diensten op den duur in de cloud wil aanbieden, moet de leverancier daar wel de benodigde ondersteuning voor kunnen (gaan) leveren.
Bij het uitvoeren van de transitie dient de architectuur in eerste instantie ook als checklist. Daarnaast zullen, op de gebieden waar aansluiting niet optimaal is, voorzieningen getroffen moeten worden die ook weer van invloed kunnen zijn op de gebruikte architectuur.
Maar waar het uiteindelijk om gaat is de uitvoering van diensten. Deze moeten beheersbaar uitgevoerd worden (kwaliteit, geld en doorlooptijd). Een architectuur (principes en beschrijvingen) vormen hiervoor uitgangspunt in de vorm van Project Start Architecturen.
Tenslotte, wanneer de dienstverlening wordt beëindigd en de opdrachtgever overstapt naar een andere leverancier, is het voor de opdrachtgever van van belang dat de overdracht van alle lopende diensten zo gladjes mogelijk verloopt en de continuïteit zoveel als mogelijk blijft gewaarborgd. En omdat dit in de praktijk niet van groot belang is van de leverancier waarvan afscheid wordt genomen, is het voor de opdrachtgever des te belangrijker om zorg te dragen voor een kwalitatief goede architectuur.
Al met al wil je als opdrachtgever zowel de opdrachtnemer optimaal laten presteren, en aan de andere kant de risico's van het uitbesteden van werk minimaliseren.
Als opdrachtnemer wil je...
Winst maken en meer opdrachten gegund worden. Hiertoe zal doelmatig en doeltreffend gewerkt moeten worden: hoe beter dit gebeurt, hoe meer winst er immers wordt gemaakt en hoe groter de kans is op een tevreden opdrachtgever die "meer" wil.
Bij de selectie is het daarom van belang om een goede inschatting te maken in hoeverre de eigen diensten aansluiten bij de gevraagde dienstverlening. Net als de opdrachtgever kan een architectuur beschrijving als een checklist worden gebruikt waarin de aansluiting van de eigen diensten wordt bepaald.
Ook bij het uitvoeren van de transitie dient de architectuur in eerste instantie ook als checklist. Ook hier zullen, op de gebieden waar aansluiting niet optimaal is, voorzieningen getroffen moeten worden die ook weer van invloed kunnen zijn op de gebruikte architectuur. Over eventuele wijzigingen zullen goede afspraken gemaakt moeten worden, die vastgelegd moeten worden in de architectuur, en dienen als uitgangspunt voor de te leveren diensten. Een ontwikkelstraat (omgeving, methoden, tooling) kan als standaard dienst worden geleverd door een leverancier. Om hiervan optimaal gebruik te maken kan het nodig zijn dat de opdrachtgever zijn ontwikkelprocessen en ICT infrastructuur hierop aanpast. Hierop zal de architectuur moeten worden aangepast.
Voor een tevreden klant is het van belang dat diensten minimaal binnen gemaakte afspraken (kwaliteit, geld en doorlooptijd) uitgevoerd worden, en indien mogelijk, "above customer expectation". Dat laatste maakt de kans op meer en gunstiger/omvangrijkere opdrachten groter. Een architectuur (principes en beschrijvingen) en de daaruit afgeleide Project Start Architecturen (PSA) vormen hiervoor het uitgangspunt. Hierin worden de doelen en randvoorwaarden vastgelegd en wordt vastgelegd in hoeverre hierop (natuurlijk afgestemd met de opdrachtgever) afgeweken wordt. Een goede PSA minimaliseert de risico's die in een project gelopen worden en verhoogt de kans dat de opdrachtgever tevreden is met het geleverde werk.
Daarnaast leveren de noodzakelijke en afgestemde afwijkingen op de bovenliggende Domain - en Enterprise Architecturen die in het PSA worden beschreven leerervaringen op die gebruikt kunnen (moeten) worden voor diezelfde Domain - en Enterprise Architecturen.
Bij beëindiging van de dienstverlening moeten de lopende diensten worden overgedragen aan een andere opdrachtnemer. In eerste instantie lijkt een goede overdracht (en daarmee een goede, actuele, architectuur) niet in het belang voor de "oude" opdrachtnemer, maar in de praktijk ligt dit wat genuanceerder. Een rommelige overdracht is voor zowel de opdrachtgever als de "oude" opdrachtnemer frustrerend. Een goed ingeschat (kosten, doorlooptijd) traject, daarentegen, heeft daarom de voorkeur. En die inschatting kan goed gebeuren met een actuele en complete architectuur (documentatie). Daarnaast laat een goed verlopen overdracht een goede indruk achter die bij een volgende aanbesteding voor de opdrachtnemer gunstig kan zijn.
In het vervolg op deze post de rol van architectuur bij uit te besteden SharePoint projecten...
