De relevantie van regels bij bouwen onder architectuur

18-02-2021

Deze klanten gingen je al voor

Wanneer je een huis laat bouwen of dit zelf gaat doen, moet er een hoop worden geregeld. Uiteraard begint het met het verkrijgen van vergunningen en heb je meestal een bouwtekening nodig met goedkeuring van een architect. Dit is relevant omdat een kenner zo kan bevestigen dat de bouwconstructie – in elk geval op papier – deugt. Met de zekerheid dat de gehele constructie straks staat als een huis. Letterlijk, maar ook figuurlijk. Het doet me denken aan de architectuur die voor OutSystems in hun low-code platform beschikbaar is. In dit artikel leg ik vanuit mijn eigen praktijkervaring graag uit waarom het drie lagen model met de bijbehorende regels binnen de OutSystems Architectuur bij het bouwen relevant is en de nodige aandacht verdient.

Bouwen onder architectuur

Zoals bekend is OutSystems een low-code applicatie development platform waarmee je razendsnel responsieve applicaties kan realiseren die eenvoudig integreren met bestaande systemen. Net als met het bouwen van een huis, kent OutSystems ook een aantal basismodellen waaruit gekozen kan worden. Wanneer je op je kavel wilt bouwen, dan heb je in de bouwwereld grofweg drie smaken:

  • Catalogusbouw;
  • Bouwen onder architectuur;
  • Een bouwsysteem

Catalogusbouw kun je in IT termen vergelijken met een kant-en-klare oplossing die je van de plank pakt. Bouwen onder architectuur is dan in IT termen een maatwerkoplossing. Bij een bouwsysteem werk je met basismodellen waarbij elk basismodel wordt voorzien van een andere uitstraling. Er is geen enkele plattegrond, en dus geen woning, hetzelfde. Iedere opdrachtgever is uniek en heeft een specifiek wensenpakket. Daardoor ontstaat er steeds weer een op maat gesneden woning in lengte, breedte, hoogte, vorm én stijl. Uiteraard wel binnen de kaders van een basismodel waarvan we weten dat de architectuur deugd.

OutSystems Architectuur keuzes

OutSystems kun je heel goed vergelijken met zo’n bouwsysteem. Ook zij kennen een aantal basismodellen die gebruik maken van een vooraf door OutSystems ontworpen architectuur. Net als bij een huis zijn dat kaders, alleen moet je zelf nog heel wat beslissen. Zou een low-code platform zoals OutSystems dat niet hebben, dan is er meteen een obstakel. Keuzes in de te gebruiken architectuur vind ik direct al één van de moeilijkste dingen om mee te beginnen als je geen standaard hebt. OutSystems heeft hierover nagedacht een geeft je een duidelijke drie lagen model. Maar hoe vertaalt zich dit naar de praktijk? Is het überhaupt wel handig om te gebruiken? Wat zijn de beste tools ervoor? Ik leg het graag uit.

Wat is het OutSystems drie lagen model

Zoals de naam al aangeeft bestaat deze architectuur uit drie lagen: End-user, Core en Foundation. Globaal gezien zit in de End-user laag alles wat de gebruiker kan zien en is dus vooral clientside gericht. De Core is gericht op data vasthouden en berekeningen uitvoeren met deze data. Mochten er bij je applicatie andere systemen aan te pas komen, dan wordt de verbinding gelegd via de Foundation laag. Deze laatste twee zijn in principe alleen te vinden op de server side. Natuurlijk is het niet zo zwart wit als je denkt, want het vergt meer aandacht dan verwacht.

Relevantie regels in de praktijk

Aan de hand van een recente praktijksituatie, illustreer ik dit graag. Voor een interne applicatie gebruikte ik dit 3 lagen model om tot een duidelijke architectuur te komen. Toen ik daar mee bezig was, viel het me op dat er veel meer bij komt kijken. Op voorhand had ik gedacht de applicatie te maken met drie à vier modules. Dat werden er uiteindelijk meer dan tien. Ook de hoeveelheid applicaties gaat tegelijkertijd flink omhoog wanneer je je aan alle regels houdt.

Bij aanvang dacht ik dat veel van de regels overbodig waren, maar na enige tijd aan de applicatie te hebben gewerkt, bleek dat er dingen niet klopten. Ik moest toch terug naar de tekentafel. Toen ik weer opnieuw naar de opbouw van de architectuur keek, en dan met name naar alle modules, leek het redelijk goed. Helaas kon ik dit op applicatie-niveau niet zeggen. Het bleek dat de kaders die OutSystems je met het drie lagen model meegeeft, meer dan zinvol zijn. Na wat puzzelen in het drie lagen model was dit zo opgelost. Met bovendien wat handigheidjes links en rechts was het snel doorgevoerd in de OutSystems applicatie zelf.

Hoe te realiseren

De vraag hoe deze architectuur tot stand is gekomen, heb ik nog niet beantwoord. Zo eenvoudig als ik het vertel, is het niet volbracht. In eerste instantie heb ik gebruik gemaakt van het Electronic Canvas dat in de OutSystems Forge beschikbaar is. Dit hulpmiddel hielp mij bij het ontwerpen van een nieuwe architectuur doordat ik mijn concepten kon plaatsen en verplaatsen in een digitaal Architectuur Canvas dat is gebaseerd op het vier lagen model. Inmiddels wordt er gewerkt met een drie lagen model in OutSystems versie 11. Hoewel dit hulpmiddel ook voor deze versie geschikt is, hielp het mij weinig. Ik kon bijvoorbeeld niet achterhalen hoe de onderlinge communicatie tussen modules en applicaties verloopt. Wellicht is dat niet het doel van dit hulpmiddel, maar voor mij als ontwikkelaar wel enorm nuttig. Voor de architectuur heb ik uiteindelijk Microsoft Visio gebruikt. Ik kende dit sinds mijn studietijd en van eerdere opdrachten. Ik heb dit altijd al een fijn programma gevonden voor het maken van diagrammen. Je kan hier naast alleen je architectuur veel meer informatie in kwijt. Ik heb bijvoorbeeld een tweede diagram gemaakt met daarin de rechten voor iedere rol binnen bepaalde applicaties en heb ook een applicatieflow gemaakt. Een gratis alternatief voor Microsoft Visio is overigens Draw.io en naar mijn mening een goede vervanger. Vooralsnog heeft Visio mijn voorkeur boven het Electronic Canvas. Wie weet verandert dat nog want OutSystems staat niet stil en verbetert zich continue.

Meer weten

Met deze praktijkervaring kan ik niet anders concluderen dan dat het OutSystems drie lagen model met de bijbehorende regels nuttig en noodzakelijk is. Het is makkelijk te gebruiken, toe te passen en aan te passen. Nu we nagenoeg altijd gebruik maken van een iteratieve ontwikkelmethode, komt dit zeker goed van pas. Neem contact met ons op als je jouw ervaringen met ons wilt delen.

id=”25940″][/contact-form-7]

Meer weten over OutSystems Architectuur?

Lees onze andere blogs

Deze website gebruikt cookies

Met deze cookies kunnen wij en derde partijen informatie over jou en jouw internetgedrag verzamelen, zowel binnen als buiten onze website. Op basis daarvan passen wij en derde partijen de website, onze communicatie en advertenties aan op jouw interesses en profiel. Meer informatie lees je in ons cookie statement.

Accepteren Afwijzen Meer opties

Deze website gebruikt cookies

Met deze cookies kunnen wij en derde partijen informatie over jou en jouw internetgedrag verzamelen, zowel binnen als buiten onze website. Op basis daarvan passen wij en derde partijen de website, onze communicatie en advertenties aan op jouw interesses en profiel. Meer informatie lees je in ons cookie statement.

Functionele cookies
Arrow down

Functionele cookies zijn essentieel voor het correct functioneren van onze website. Ze stellen ons in staat om basisfuncties zoals paginanavigatie en toegang tot beveiligde gebieden mogelijk te maken. Deze cookies verzamelen geen persoonlijke informatie en kunnen niet worden uitgeschakeld.

Analytische cookies
Arrow down

Analytische cookies helpen ons inzicht te krijgen in hoe bezoekers onze website gebruiken. We verzamelen geanonimiseerde gegevens over pagina-interacties en navigatie, waardoor we onze site voortdurend kunnen verbeteren.

Marketing cookies
Arrow down

Marketing cookies worden gebruikt om bezoekers te volgen wanneer ze verschillende websites bezoeken. Het doel is om relevante advertenties te vertonen aan de individuele gebruiker. Door deze cookies toe te staan, help je ons relevante inhoud en aanbiedingen aan je te vertonen.

Alles accepteren Opslaan

Ontdek onze QSEH Star