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, bovenal, 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:
…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:
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!
Binnen Valid blijven we hier bij onze klanten op hameren. 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.
De analyse van dit onderdeel zie je daarom ook terugkomen in de, door Valid ontwikkelde, methode: Collaboratie Implementatie Methode. Binnen deze methode maken we gebruik van analyse-tools om zo efficiënt mogelijk tot bovenstaande informatie te komen. Dit doen we onder andere met behulp van templates. Zowel voor het achterhalen van de benodigde informatie (workshoptemplates) als de vastlegging (informatiedocumenten).
Onze volgende stap is hetgeen we besproken hebben uit te werken en deze terug te koppelen aan de klant! Weten we het nog:
Regelmatig komt men met belangrijke aanvullingen of correcties. Dit kan te maken hebben dat de ontvanger (wij 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 Microsofts 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:
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 bieden onze CIM-templates de uitkomst!
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 onze 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 moeten open staan en dien je nog steeds na te denken over een back-up strategie. We hebben 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!
Hij of zij is verantwoordelijk voor de totaaloplossing waarbij nauw wordt samengewerkt met alle andere teamleden.
Conclusie
Het ontwerpen van een informatie-, communicatie- en samenwerkingsportaal doen we bij Valid door:
Verder proberen we het ontwerpproces te standaardiseren om zo valkuilen te omzeilen. Door het standaardiseren van de aanpak, deze aanpak te laten evolueren(!) en te toetsen bij mijn collega's blijft de aanpak actueel en leren we elke keer weer bij!
Is dit het hele verhaal? Nee, nog lang niet. Collega’s van me hebben al geblogd over informatiebeveiliging, onderdelen van Office 365, adoptie, governance en mobile app development 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 je naar aanleiding van deze blog vragen hebt over hoe je Microsoft SharePoint, Office 365 of een ander gedeelte van het applicatielandschap beter op de functionele behoefte aansluit zie ik het graag terug in de comments!