Door de bouwblokken de patronen niet meer kunnen zien

Door Equator op maandag 12 september 2011 19:57 - Reacties (6)
Categorie: Work, Views: 6.087

Inleiding
Wie zich bezighoudt met architectuur raamwerken als Togaf en DyA zal ongetwijfeld wel eens van de term bouwblokken en patronen gehoord hebben.

Voor hen die dit niet weten, en kleine inleiding.

In de infrastructuur architectuur (maar ook daarbuiten) vinden we naast principes de zogenaamde bouwblokken waaruit een stuk infrastructuur is opgebouwd. Bouwblokken worden beschreven als op zichzelf staande onderdelen die een deel van een gestandaardiseerde functionele oplossing vormen.
Op een hoger abstractieniveau vinden we de patronen. Patronen zijn een samenstelling van één of meerdere bouwblokken om een functionele oplossing te bieden.

In dit artikel/blog wil ik het principe van patronen en bouwblokken wat proberen te verduidelijken. Ik beperk me even tot de vrij tastbare infrastructuur architectuur, maar in principe zal dit verhaal ook passen op de Security Architectuur, Software architectuur en Business Architectuur. In de Enterprise Architectuur komen we wel patronen tegen, maar naar alle waarschijnlijkheid geen bouwblokken. Dit is echter geen vaststaande regel.
bouwblokken
Zoals reeds gemeld is een bouwblok een op zichzelf staande onderdeel van een oplossing. Bouwblokken zijn opgebouwd uit elementen. Elementen zijn vaste onderdelen van het bouwblok.

Hieronder staat een DyA weergave van een bouwblok:
http://tweakers.net/ext/f/CIB86sYCOdww2G0E3A47bSO4/thumb.jpg

Denk hierbij aan een bouwblok wat een SQL Database oplossing biedt. Het bouwblok zal dan bestaan uit één of meerdere database servers, een stuk storage, een netwerk om het aan elkaar te knopen en te ontsluiten naar de buitenwereld, een stuk configuratie en documentatie en wellicht een backup/restore invulling.

Een ander bouwblok kan worden ingevuld met een Oracle op Linux oplossing waarbij een enkele server met lokale storage wordt gebruikt om de database te hosten.

Beiden zijn bouwblokken en lijken voor wat betreft functionaliteit enigszins op elkaar. Beide bouwblokken kunnen ingezet worden om een database oplossing neer te zetten als backend voor een webapplicatie.
Bouwblok Types
De hierboven beschreven bouwblokken vallen onder een enkele noemer. Namelijk het bouwblok type "Database"
Database is een zelf in te vullen naamgeving. Om het begrip tastbaar te houden heb ik voor deze naamgeving gekozen.
Het bouwblok type is dus een generieke naam voor onze bouwblokken. Onze bouwblokken zijn varianten van het bouwblok type.
Bouwblok varianten
Ons bouwblok type "Database" kent in ons geval een tweetal bouwblok varianten.
Te weten:
  • Bouwblok "MS SQL zilver"
  • Bouwblok "Oracle brons"
Wederom, de naamgeving is niet direct van invloed, bij varianten mag het wat beschrijvend zijn. Dat in tegenstelling tot de generieke naamgeving van het bouwblok type, wat geen merknamen of beschrijvingen zou mogen bevatten.

Waar er in een project nu een database oplossing nodig is waarbij de beschikbaarheid van groot belang is, kan er gekozen worden uit een tweetal standaard oplossingen (bouwblokken). In ons geval zal het bouwblok "SQL Zilver" een betere ontwerpkeuze zijn vanwege de eisen aan beschikbaarheid.

Kort resumerend:
We kennen het bouwblok type: "Database", en daarvan leiden we 2 bouwblok varianten af: "MS SQL zilver" & "Oracle Brons".
Bouwblokken zijn standaard deeloplossingen. Varianten kunnen verschillen in gebruikte software, hardware en configuraties.
patronen
Waar bouwblokken nog vrij tastbaar zijn, worden patronen wat minder begrijpelijk.

Binnen DyA onderkent men patroon types, en patroon varianten. Een patroon type is een set met bouwblokken die een infrastructurele oplossing vormen. Een patroon variant is een bepaalde technische invulling van het patroon type.
Een patroon impliceert iets herhalend. Denk daarbij aan het brei-patroon op een trui.

Hieronder een plaatje van het DyA patroon type "Data Transport"
http://tweakers.net/ext/f/GR2HT4njhgTdV7gFgyGyDtfW/thumb.png

Zoals je ziet is het patroon opgebouwd uit enkele bouwblokken waarvan sommigen optioneel zijn. Bovendien heeft het patroon optionele links met andere patronen.

Dit is allemaal vrij abstract, en dus best lastig te begrijpen. Ik zal proberen het duidelijk te maken met wat meer alledaagse begrippen.
Onthoudt dat een patroon een set met bouwblokken is die een infrastructurele oplossing vormt. Aangezien er altijd een probleem (of uitdaging) vooraf gaat aan een oplossing, ga ik in het hieronder staande voorbeeld een vrij tastbaar probleem beschrijven.
Voorbeeld
Probleem
Je staat met 3 auto's, en 30 mensen bij een rivier. Jullie moeten deze rivier zien over te steken zonder dat jullie nat worden. Er is geen tijdslimiet, maar het moet wel veilig gebeuren.

Uitwerking
Goed, hoe steken we een rivier over? Juist, we bouwen een brug.
Maar wat voor een brug? Gelukkig hebben we enkele functionele eisen gekregen bij de probleemstelling:
  • Er moeten auto's over kunnen rijden
  • Er moeten mensen over kunnen lopen
  • Er is geen tijdslimiet
  • Het moet veilig zijn
Oké, onze patroon type "brug" bestaat uit een 3 tal bouwblokken:
  • Peilers (optioneel)
  • brugdek
  • brugleuning (optioneel)
Nu moeten we een brug bouwen die voldoet aan de gestelde eisen.

Aangezien er auto's over de brug moeten, is het ontwerptechnisch wel verantwoord om het optionele bouwblok "peilers" te gebruiken. Die staan immers zwaardere belasting toe. Indien we van het bouwblok type peilers meerdere varianten hebben (Hout, staal, beton) kiezen we de variant die voldoende belasting kan hebben.

Over de peilers komt dan een brugdek. Vanwege de zware belasting van de auto's moet het dek voldoende draagkrachtig zijn om de auto's te dragen. Het bouwblok type "brugdek" moet dus ingevuld worden met een variant die draagkrachtig genoeg is.
Aangezien er geen tijdslimiet is, hoeft het brugdek niet breder te zijn dan een enkele auto.

Aangezien het een eis is dat er mensen over de brug moeten kunnen lopen, zal het brugdek voorzien moeten zijn van wandelpaden met een effen loopvlak. Bovendien zal vanwege de veiligheid het optionele bouwblok type "brugleuning" gebruikt moeten worden. Als variant kiezen we voor een houten brugleuning wat veilig genoeg wordt geacht.

Goed, geloof het of niet, maar we hebben zojuist een patroon variant gemaakt van het patroon type "brug". De naamgeving van de variant laat ik aan jullie over.

Indien we dit probleem nu vaker tegen komen, dan kan je dit patroon variant uit de kast trekken als standaard oplossing.
En dat is werken volgens architectuur. Het hergebruiken van standaard oplossingen.

edit: Op verzoek, een vergelijkbaar probleem maar nu een technische invulling :)
Voorbeeld 2
In dit voorbeeld gaan we iets dieper in de techniek, maar we beginnen op vrij abstract niveau.
Schets:
Vanuit de klant komt het verzoek om middels een webportaal wat bedrijfsgegevens beschikbaar te maken op het Internet. De bedrijfsgegevens moeten nog in een databank worden ingevoerd. De eis van de directie is dat deze gegevens ten alle tijden beschikbaar moeten zijn voor hun klanten.
Het webportaal wordt ontwikkeld door een externe partij en zal gehost moeten worden op een webserver die met ASP.Net kan werken. De externe partij zal ook het databank ontwerp maken, en vereist een Microsoft SQL Database.


De vraag van de klant is als volgt:
Ontwerp een veilige ontsluiting vanaf het Internet tot het webportaal, en vanaf het webportaal tot de databank.
Neem hierbij in op dat het ten alle tijden beschikbaar moet zijn. Neem de wensen en eisen van de externe leverancier mee in het ontwerp.

Gaan we het totaal plaatje nu eens in een patroon gieten, dan zou dat er ongeveer zo uit kunnen komen te zien:
http://tweakers.net/ext/f/347eg39u6AA1N8FG43WlA88m/medium.jpg
Zoals te zien is, heb ik gebruik gemaakt van enkele subpatronen. Een subpatroon is een op zich zelf staand patroon wat gebruikt kan worden in een totaal oplossing. Hergebruik is het sleutelwoord hierin.

Het eerste subpatroon wat we tegenkomen is het patroon DMZ. Nu kennen de meesten wel de term Demilitarized Zone, maar hieronder zie je een voorbeeld hoe dat als patroon eruit zou kunnen zien:
http://tweakers.net/ext/f/HnRsBxTakafbmGGe9ySPCZTu/medium.jpg

Ook hierin vinden we weer subpatronen. Deze heb ik niet verder uitgewerkt, maar dat laat ik aan de fantasie van de lezer over.


Een tweede subpatroon dat we tegen komen (onder de DMZ) is het subpatroon hoogbeschikbaar webportaal. Als patroon zou dat er zo uit kunnen zien:
http://tweakers.net/ext/f/YhtsVAUBUxqdtt6V5jHFef6p/medium.jpg
In dit patroon komen we de eerste bouwblokken tegen.
Namelijk het bouwblok "Loadbalancing". Dit is een bouwblok type. Een variant hiervan zou een F5 Big-IP kunnen zijn.

Het tweede bouwblok type wat we tegenkomen is het bouwblok "Webserver". Een invulling (variant) va dit bouwblok zou in ons geval een Microsoft 2008 IIS Server kunnen zijn. De eis was immers dat ASP.Net gebruikt moest kunnen worden.

Het laatste subpatroon wat we tegenkomen is het patroon: hoogbeschikbaar databank.
Een weergave hiervan ziet er ongeveer zo uit:
http://tweakers.net/ext/f/jKxQLTNv9beP1q5x5z1NG9Qv/medium.jpg

Hierin vinden we weer een bouwblok type "Database". Als we hier invulling aan moeten geven kunnen we kiezen uit de twee varianten die we eerder in dit blog hebben gebruikt. Aangezien de wens van de klant een hoogbeschikbare omgeving is, en tevens de eis van de externe leverancier een op Microsoft gebaseerde database is, zijn we vrij beperkt in de keuze. Maar het gaat hier om het idee. Als variant kiezen we de "Microsoft SQL Zilver" bouwblok.

Ik hoop dat ik hiermee wat duidelijkheid heb kunnen brengen. Op en aanmerkingen zijn altijd welkom.
links
http://www.dya.info/Home/dya/index.jsp
https://dya-knowledge.sogeti.nl/dir/Main_Page
http://www.opengroup.org/togaf/

PKI in the Enterprise

Door Equator op donderdag 6 maart 2008 20:23 - Reacties (2)
Categorie: Work, Views: 5.079

Voorbeeld van een implementatie van PKI in een middelgrote tot grote omgeving

Lees verder »

PKI (Deel 2)

Door Equator op vrijdag 21 december 2007 12:00 - Reacties (2)
Categorie: Work, Views: 7.581

Ok, in PKI (Deel 1) hebben we een eerste kennismaking gehad met de principes van PKI, en hebben we de certificaten vluchtig bekeken.

In dit volgende deel gaan we de certificaten verder bespreken, kijken we naar de verschillende typen en kijken we naar hun geldigheid.

In deel 1 meldde ik reeds dat een certificaat gemaakt wordt van een CSR (Certificate Signing Request). Hoe een CSR is opgebouwd gaan we nu bekijken.

Lees verder »

PKI (Deel 1)

Door Equator op dinsdag 11 december 2007 16:08 - Reageren is niet meer mogelijk
Categorie: Work, Views: 7.181

PKI, het buzzwoord in de wereld van Security, maar wat is het en wat kan je ermee?

Voor we hier echt antwoord op kunnen geven, zullen we eerst moeten weten wat PKI daadwerkelijk is.

Lees verder »