Office 365 SharePoint

Ontwerpen is teamwerk! Orde in de ontwerp chaos!

23 maart 2017

Het ontwerpen van een informatie-, communicatie en samenwerkingsportaal, in de volksmond een intranet, vind ik als architect geweldig om te doen! Het is en blijft een lastige klus, hoe vaak ik dit ook doe.

In deze blog licht ik een tipje van de sluier op over hoe ik als solution architect zo’n traject aanpak.

Als solution architect probeer ik een toekomst vaste oplossing te ontwerpen die werkbaar is maar zeker ook realistisch!

Hoe ga ik te werk?
De meest cruciale vraag waarop ik een antwoord wil vinden is: waarom?

Waarom wilt u een intranet? Waarom wilt u samen werken? Waarom:

  • Een document management systeem?
  • Digitaliseren van de postkamer?
  • Informatie delen met klanten, (toe)leveranciers?
  • Etc.

…om vervolgens te komen met de wie, wat, waar, wanneer en hoe vragen. Vindt men leuk ;-). Waarom ik dit doe? Het gaat namelijk niet om de technologie maar om de business. Hier kom ik zo op terug.

Ik wil in deze blog (nog) niet te veel de diepte in duiken maar ik maak hier even een klein uitstapje naar het volgende model:

Figuur 1 ArchiMate (2.1) 3 lagenmodel

Bovenstaande model is het 3 lagenmodel zoals ArchiMate 2.1 dit kent.
De oplossing die ik wil ontwerpen moet passen binnen, en rekening houden met, deze 3 lagen. Correct mensen, de strategie-, fysieke- en implementatie & migratie laag laat ik even buiten beschouwen om de complexiteit van deze blog te beperken.

Bedrijfslaag

De antwoorden op de w-vragen geven vaak vooral inzicht in de bedrijfslaag. Wat doet het bedrijf(sonderdeel)? Waarom, en hoe, doen ze dit? Je krijg hierdoor inzicht in de essentie van het bedrijf!

Hier blijf ik als architect op hameren bij mijn klanten! Zonder een goed antwoord op deze vragen is de kans groot dat je project een ‘operatie geslaagd maar de patiënt is overleden’ gevalletje wordt en daar zit niemand op te wachten. Ik wil de klant écht helpen. Het komt dus ook weleens voor dat ik een keiharde ‘nee’ verkoop als ik in de gaten krijg dat de wens van de klant, naar de toekomst toe, hen niet gaat bieden wat ze nodig gaan hebben. Tot nu toe legt deze aanpak me geen windeieren :-).

Het analyse traject, en de vastlegging daaromtrent, doe ik zoveel als mogelijk volgens een vaste, maar flexibele, structuur. Onderstaande procesflow toont deze structuur:

 

Elk bolletje/fase kent een set van activiteiten die ik, afhankelijk van de situatie, wel of niet uitvoer…of er nieuwe aan toe voeg. Wat zeer belangrijk in deze procesflow is het pijltje tussen gebruik en verkenning. Hiermee geef ik aan dat het een continu proces is en geen verkapte waterval methode.

Vervolgens heb ik set van templates waarin ik de informatie die tijdens dit proces vrijkomt vastleg.

Mijn volgende stap is hetgeen besproken is uit te werken en deze terug te koppelen aan de klant! Weet je het nog:

 

Regelmatig komt de klant met belangrijke aanvullingen of correcties. Dit kan te maken hebben dat de ontvanger (ik dus) de gegeven informatie verkeerd/anders geïnterpreteerd heeft, maar misschien ook wel dat de zender (de klant) dit soort sessies niet dagelijks doet en dat ook zij hierin moeten groeien. Mooi toch dat we van elkaar leren!

Applicatielaag

Nu is het zaak om de applicatie te gaan ontwerpen en deze aan te laten sluiten op het applicatielandschap. In de opdrachten die ik doe ben ik hierin voornamelijk bezig met Office 365 en Microsoft SharePoint. Op basis van de eerder gevonden requirements moeten we nu een applicatie architectuur gaan ontwerpen. Mijn persoonlijke aanpak hierin is vaak hetzelfde:

  • Onderzoek de benodigde technologieën;
  • Onderzoek de limieten van al deze technologieën;
  • Onderzoek de beheersbaarheid van de oplossing;
  • Onderzoek de best-practices.

Ik vind het extreem belangrijk dat je de limieten van de gebruikte technologie, zoals bijvoorbeeld SharePoint Online, kent! Het is fantastisch dat je weet dat je miljoenen documenten kunt opslaan in een enkele bibliotheek in SharePoint. Ik verwacht dat de klant niet heel erg blij is als hij de bibliotheek opent en geen enkel document ziet maar wel een melding dat het aantal documenten de harde limiet van 5.000 documenten heeft overschreden en dus helemaal geen enkel document te zien krijgt…

Wellicht de belangrijkste best-practice waar een antwoord op moet komen is geen technische maar een functionele. Vraag je altijd het volgende af: hoe gaat iemand de benodigde informatie vinden?

Ook voor deze fase van het ontwerp biedt onze CIM-templates!

Technologielaag

Op dit moment weten we al ontzettend veel. We weten hoe we de bedrijfsfunctie moeten gaan inrichten en hoe de bijbehorende applicatiecomponent ingericht dient te worden…hopelijk heb je ook gekeken naar de koppeling tussen de bedrijfslaag en de applicatielaag 😉

Nu is het zaak om een technologielaag te ontwerpen die snel genoeg, schaalbaar en beheersbaar is. Wanneer we het hebben over een on-premises inrichting komen nu de echte infrastructuur architecten aan bod. Zij weten perfect hoe, om bij het Microsoft SharePoint voorbeeld te blijven, de benodigde servers geconfigureerd moeten worden. Welke services worden geactiveerd op welke server?  Is active-directory correct ingericht? Op welke drives en storage plaatsen we de database en logfiles?

Gaan we voor een volledige cloud oplossing? Dan neemt Microsoft veel werk uit handen maar ook dan moet je infrastructuur (netwerkverkeer, etc.) op orde zijn, de juiste poorten geopend en dien je nog steeds na te denken over een back-up strategie. Ik heb het dan nog niet gehad over hybride scenario’s of Microsoft Azure integratie. Kortom ook de inrichting van de technologielaag is en blijft een zeer uitdagende klus!

Team effort!

Uit bovenstaande relaas is op te maken dat het ontwerpen van een dergelijke architectuur echt teamwerk vereist. Samen met je multidisciplinaire team waartoe ook de klant zorg ik dat er een architectuur komt waar iedereen zich aan wil conformeren. Uiteindelijk bepaal ik als solution architect welke kant we opgaan. Net als op een schip kan er slechts 1 kapitein zijn. Hij of zij is verantwoordelijk voor de totaaloplossing waarbij nauw wordt samengewerkt met alle andere teamleden.

Hieronder is een voorbeeld van een multidisciplinair team.

 

Conclusie

Het ontwerpen van een informatie-, communicatie en samenwerkingsportaal doe ik door:

  1. Te praten met de business;
  2. Het vastleggen van informatie;
  3. Het werken met multidisciplinaire teams;
  4. Te vragen om feedback.

Verder probeer ik het ontwerpproces te standaardiseren om op die manier valkuilen te omzeilen. Door het standaardiseren van de aanpak, deze aanpak te laten evolueren(!) en deze te toetsen blijft de aanpak actueel.

Is dit het hele verhaal? Nee, nog lang niet. Denk aan adoptie en governance maar bijvoorbeeld ook aan apps om écht overal toegang tot je oplossing te hebben. Daarnaast speelt ook de volwassenheid van de organisatie een rol. Eerst lopen dan rennen. Dat geldt ook voor de adoptie van een nieuw platform.

Kortom, het ontwerpen van een toekomst bestendige architectuur is een superleuke en uitdagende klus waarin ik me in elk geval geen moment verveel!

Als u naar aanleiding van deze blog vragen heeft neem dan contact met me op!

You Might Also Like

Geen reacties

Plaats een reactie