Ga naar content
Wij zijn de #1 Microsoft partner
#1 Microsoft partner van NL
Console Werken bij

Architectuur als versneller

Architectuur is lastig, overbodig, je loopt altijd achter de feiten aan en het is een vertragende factor! Zou kunnen, maar ik ben ervan overtuigd dat het tegendeel waar is. In dit artikel ga ik je uitleggen waarom en wat het toverwoord is.

Templates

Om maar meteen met de deur, en het toverwoord, in huis te vallen: templates is het magische woord! Iedereen kent ze en iedereen heeft ze. Wanneer ik een nieuw Word document maak dan start ik eigenlijk altijd met een template. Een template met alleen de huisstijl of een template voor een offerte, statement of work, je kent ze wel.

Architectuur is al behoorlijk vaag (mijn mening) en om dit nog wat aan te dikken hebben we in de architecten wereld templates een andere naam gegeven: building blocks. Eén van de bekendere architectuur frameworks TOGAF deelt deze op in Architecture Building Blocks en Solution Building Blocks en er zijn er vast wel meer. Laten we ze gewoon templates noemen.

Als consultant werk ik vaak aan migratie trajecten waarbij we een on-prem omgeving migreren naar de Microsoft Cloud. Een groot gedeelte van het werk is de hele technische spullenboel vervangen door Microsoft 365 Cloud technologie. Alhoewel elke inrichting anders is, vervangen we een fileshare toch in 10 van de 10 gevallen door Microsoft SharePoint of Microsoft Teams (of een combinatie).

Wanneer ik een architectuur ga ontwerpen voor een dergelijk traject ontwerp ik de huidige- en de doelarchitectuur, en ook transitie hiervan.

Template – FileShare technische architectuur

Een simpel voorbeeld van een fileshare die 2 soorten data ontsluit, persoonlijke- en afdelingsdata  vanuit een technologisch oogpunt.

Mijn ervaring is dat de meeste organisaties hun persoonlijke- en afdelingsdata op fileshares opgeslagen hebben. Dit is een mooi voorbeeld van een template en dus weer een versnelling in de realisatie van je architectuur.

Template - Bedrijfsarchitectuur HR

Ditzelfde kunnen we doen voor de bedrijfslaag. Welke rollen zijn er en welke processen voeren zij uit? Gebruikt men software om bijvoorbeeld documenten te maken te maken en te bewerken?

Mogelijk heb je hier ook weer een mooi voorbeeld voor een template.

In bovenstaand voorbeeld zien we (in geel) dat deze organisatie een HR afdeling met HR medewerkers heeft en dat ze 2 processen uitvoeren: Create contract en Recruitment.

Template - Applicatie architectuur

De vraag die je daarna zou kunnen stellen is: “Dat contract, hoe maak je dat?

Een antwoord zou kunnen zijn: “Ik open het contract template dat op onze M-schijf staat, bewerk het en sla het daarna weer op de M-drive op.

Ook hier weer een situatie die héél vaak voorkomt binnen organisaties. Wat weer een geschikte kandidaat is voor een template.

We hebben op dit moment 3 templates gevonden. Dat zou beteken dat je met 3 klikken de bedrijfs-, applicatie- en de technologie laag voor een groot deel kunt ontwerpen. Is dat niet wat kort door de bocht? Ja, maar in de basis klopt het wel. Het is en blijft een template, een snel starter.

Office 365 - Technische architectuur

Als we kijken naar de digitale transitie dan zou het zo maar kunnen zijn dat de organisatie uit bovenstaand voorbeeld hun fileshare gaat vervangen door services die geleverd worden door Office 365: SharePoint Online en/of Microsoft Teams. Daar kunnen we natuurlijk ook een template voor maken:

Bovenstaande template toont dat Office 365 drie verschillende services realiseert:

  • Microsoft Teams
  • SharePoint Online
  • OneDrive for Business

Ook dit zie je bij bijna alle bedrijven die met Office 365 gaan werken terug komen en is daardoor ook weer een hele geschikte kandidaat als template.

De applicatie laag (de blauwe laag) is de lijm tussen de processen (gele bedrijfslaag) en de technologie (groene laag). Deze zou er mogelijk zo uit kunnen zien:

We zien hier dat er 2 teams gemaakt worden, 1 per proces. Binnen Microsoft Teams is het mogelijk om te werken aan documenten en om hieraan samen te werken, te chatten, discussiëren en te video bellen (collaboration). Ook dat is gemodelleerd. Of ik hier een template van zou maken weet ik niet zeker. Het is zeker iets wat eigenlijk altijd terug komt maar je moet zeker veel aan gaan passen. Stel dat we het wel zouden doen, dan zouden we nu 5 templates hebben:

  • HR Proces – Bedrijfslaag
  • Werken met bestanden via de fileshare – Applicatielaag
  • FileShare – Technologielaag
  • Werken met bestanden via Office 365 – Applicatielaag
  • Office 365 – Technologielaag

Met deze 5 templates kunnen we dan heel snel de huidige- en toekomstige situatie modelleren:

Vervolgens heb jij als architect natuurlijke de taak om deze schema’s specifiek te maken voor deze organisatie/project.

Technische- en functionele templates

In voorgaande blogs (deel 1 en deel 2) hebben we het al gehad over taal. De schema’s hierboven zijn niet voor iedereen even leesbaar. Daarom zou ik er voor kiezen om een tweede variant van je template te maken:

Beide templates zeggen het zelfde maar zijn voor andere stakeholders. De gemiddelde HR manager zal het niet zo interessant vinden dat er een File Explorer functie is op de applicatie laag die de department data service op de technologie laag aanroept.

Het zelfde kun je doen voor de template die toont dat Office 365 drie verschillende services realiseert. Deze kun je mooi complementeren met een PowerPoint weergave zoals onderstaande:

Referentie architectuur

Een ander soort template is een referentie architectuur. Denk bijvoorbeeld aan de Microsoft Cybersecurity Reference Architecture. Een onderdeel hiervan is het zeer actuele Zero Trust User Access-patroon (Implementing a Zero Trust security model at Microsoft).

Eigenlijk een template binnen de architectuur. Dit Zero Trust User Access-patroon kun je als template opnemen. Stel dat je deze als requirement krijgt dan kun je de template, wederom met een druk op de knop, integreren en eventueel fine tunen.

Conclusie

Hopelijk heb ik met bovenstaande aangetoond dat het opstellen van een architectuur wel degelijk een versneller kan zijn en misschien wel een eerste stap richting enterprise architectuur. Tevens is het zeer goed mogelijk om architectuur duidelijk te maken voor mensen die geen idee hebben wat die gekke tekentjes allemaal betekenen.

Onze auteur

Sander Derix

Als Productivity architect ben ik expert op het gebied van content lifecycle, compliance, informatiemanagement en migraties[TK1] . In mijn werk vind ik het leuk om lange termijn denken te combineren met praktische stappen zetten in het hier en nu. Ik krijg er energie van om organisaties verder te helpen door het implementeren van hoogwaardige oplossingen die écht bijdragen aan een productieve en veilige werkomgeving.

In mijn werk combineer ik enerzijds mijn uitgebreide ervaring in informatie-, document- en procesmanagement en anderzijds mijn ervaring in verschillende rollen zoals: developer, lead consultant, teamleider, architect om toekomst vaste en beheerbare oplossingen te ontwerpen. Een project voer ik het liefst uit in samenwerking met een team, omdat ik geloof dat je samen de beste oplossingen realiseert.