Het bouwblokken model bestaat uit de generieke entiteiten bouwblok en catalogus. Deze vormen de basis van een referentie architectuur. Catalogi zijn groeperingen van bouwblokken binnen een bepaald domein. Er zullen meerdere catalogi ontstaan die aan elkaar gerelateerd zijn en elkaar overlappen binnen de visualisaties. Het voordeel van de opzet van het werken met catalogi en bouwblokken is:

• Er ontstaan registers van herbruikbare architectuur onderdelen gericht op een bepaald werkveld.
• Inzet van bouwblokken brengt standaardisatie met zich met en stimuleert hergebruik van architecturele configuraties.
• Bouwblokken maakt het architectuur- en het ontwikkelproces eenvoudiger.
• Er ontwikkelen zicht architecturele product catalogi gericht op specifieke werkvelden. Dit heeft een positieve invloed op de dienstverlening naar de rest van de organisatie.

De bouwblokken kennen drie specialisaties waarvan de definities in detail zijn uitgewerkt. Deze beschrijvingen zijn hieronder in de paragrafen uitgewerkt. Indien relevant is aan deze uitwerking extra informatie toegevoegd zoals links naar Togaf en voorbeelden van de implementatie van deze architecturele concepten In het model wordt gewerkt met een pragmatisch model voor wat betreft de associaties tussen Service en SBB. Vanuit ArchiMate perspectief is de route van service via ABB naar SBB. Dit heeft als kenmerk dat het functionele aspect goed ingebed is in het bouwblokken model. Bij het publiceren van deze modellen wordt gezocht naar een mogelijkheid om rapporten en webpagina's te genereren die voor niet architectuur stakeholders geen gegevens bevatten niet relevant voor het model, dat kan betekenen dat in een aantal situaties de ABBs niet uitgewerkt hoeven te worden. Het in de modellering toepassen van de directe associatie tussen service en SBB voldoet niet aan de viewpoints.

Statement Een bouwblok is een afgebakend en herkenbaar architectureel concept dat invulling geeft aan een informatievoorziening behoefte. Omschrijving Een bouwblok is in dit document een abstract concept dat in drie concrete specialisaties is uitgewerkt, service, ABB en SBB. Bouwblokken worden binnen onze definities als synoniem gezien van een architectuur patroon. De drie specialisaties kennen een hiërarchie. Een service is in ons model het hoogste abstractieniveau, daarbinnen worden Architectuur bouwblokken onderkend welke geïmplementeerd worden door een of meerdere solutions bouwblokken. Een belangrijke karakteristiek van bouwblokken is dat ze samengesteld kunnen zijn. Deze samenstelling kan op twee manieren:

• Een bouwblok is een samenstelling van bouwblokken van dezelfde specialisatie (bijvoorbeeld een service is opgebouwd uit een of meerdere subservices)
• Een bouwblok wordt bediend door een samenstelling van een of meerdere bouwblokken uit de onderliggende laag (bijvoorbeeld een service wordt gerealiseerd door meerdere gedragselementen in een ABB.
• Samengestelde bouwblokken worden binnen onze definities als synoniem gezien van een architectuur patroon.

Bij de specialisaties van de bouwblokken wordt de samenstelling voor de specialisaties uitgewerkt. De samenstelling binnen bouwblokken kan uit meerdere lagen bestaan. Echter het is wenselijk dat het aantal niveaus van bouwblokken binnen een specialisatie (Service, ABB of SBB) beperkt blijft. Wordt een catalogus te complex door het aantal lagen en bouwblokken dan kan beter een splitsing van een catalogus toegepast worden. Kenmerken

• Een bouwblok heeft een afgebakende grens en is herkenbaar als een specifiek architectureel concept.
• Een bouwblok is herbruikbaar.
• Een bouwblok is loosely coupled.
• Een bouwblok kan interacteren met een of meerdere andere bouwblokken van verschillende typen.
• Een bouwblok is onderdeel van een catalogus.
• Template voor een oplevering die aan een combinatie van eisen en wensen voldoet.
• Een bouwblok kan bestaan uit andere bouwblokken en wordt daarmee een samengesteld bouwblok.
• Een bouwblok kan onderdeel zijn van een compositie (samengesteld bouwblok).
• Bouwblokken kunnen recursief zijn en worden in dat geval samengesteld.

Statement Services zijn de beschrijving van een combinatie van functionaliteiten en diensten tussen aanbieder(s) en afnemer(s). Omschrijving Services zijn een vorm van inkapseling van de functionaliteit en implementatie van een samenstelling van bouwblokken. Services worden, net als ABB en SBB, gebruikt als communicatiemiddel om tussen aanbieder en afnemer aan te geven welke dienst door de aanbieder aan de afnemer geleverd gaat worden. Services kunnen ook intern binnen de organisatie gedefinieerd zijn (ook in aanbieder en afnemer verband), bijvoorbeeld infrastructurele services voor een applicatieve service of afnemer. Een service kan een samenstelling zijn van een bouwblok dat functionaliteit implementeert binnen het ICT landschap. Daarnaast kan een service bestaan uit het leveren van een meer ingerichte (ICT) werkprocessen in relatie met de bovengenoemde ICT landschappen, bijvoorbeeld een servicedesk. In dit document hebben we de scope beperkt gehouden tot die van de ICT architectuur, ICT werkprocessen worden hier niet uitgewerkt maar zijn binnen andere delen van de organisatie zeker relevant (service management). Dit bouwblokken model kan desgewenst op meerdere manieren toegepast worden en niet alleen in het ICT werkveld. Hier beperken we ons tot ICT architectuur. Services kunnen samengesteld zijn uit onderliggende services. Daarnaast kunnen zij opgebouwd zijn uit een of meerdere architectuur bouwblokken. Door deze samenstellingen kunnen constellaties ontstaan van bouwblokken die zorgdragen voor standaardisatie van herbruikbare toegepaste services. Denk hierbij aan een standaard ingerichte applicatieserver met services (zoals back-up en restore) en ABB (bijvoorbeeld relationele opslag) Services zijn gerelateerd aan requirements, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke behoeften vanuit afnemersperspectief een invulling wordt gegeven en aan welke niet. Rond de term service bestaat veel verwarring. Om te voorkomen dat bij iedere samenstelling van personen een discussie over de definitie ontstaat wordt gekozen voor de term service welke gebaseerd is op onderstaande kenmerken. Daarnaast is er een lijst van synoniemen geformuleerd die verwijzen naar dezelfde onderstaande kenmerken. Kenmerken

• Een herhaalbare activiteit of gedrag die wordt gevraagd te worden uitgevoerd.
• Een service biedt een of meerdere voor de afnemer begrijpelijke invulling van ICT behoeften.
• Combinatie van een implementatie van een functionaliteit in een of meerdere ABBs.
• Eventueel in combinatie met een of meer ICT werkprocessen als service.
• Services worden aangeboden aan afnemers vanuit aanbieders.
• Services hebben een commercieel en een financieel (kosten) aspect.
• Services kennen voorwaarden voor gebruik cq implementatie.

Statement Een collectie van logisch gerelateerde bouwblokken van dezelfde specialisatie (service, ABB of SBB). Omschrijving Een catalogus is een collectie of register van bouwblokken van eenzelfde type. Het is veelal gericht op een specifiek werkveld, denk hierbij bijvoorbeeld aan infrastructuur, geo, integratie. Binnen een catalogus zitten veelal bouwblokken van dezelfde specialisatie dus services, architectuur - of solution bouwblokken. Echter de bouwblokken hierbinnen zullen veelal eveneens samengesteld zijn. Een catalogus kan gezien worden als een etalage van generieke en herbruikbare architecturele producten. Wanneer deze bouwblokken door een project worden ingezet wordt voldaan aan een aantal architecturele eisen, principes en requirements. Voordeel voor architectuur is dat deze bouwblokken worden hergebruikt. Voordeel vanuit projectperspectief is dat er voldaan wordt aan de architecturele principes en dat implementatie gestandaardiseerd wordt en waarschijnlijk sneller kan. Vanuit veranderingen in de omgeving (projecten, LCM, innovaties) zal de inhoud van een catalogus regelmatig worden aangepast, uitgebreid of meer gedetailleerd worden uitgewerkt. Een catalogus en de daarin opgenomen entiteiten wordt daarmee een "levend" ecosysteem. In eerste instantie wordt gewerkt met een aanbod gestuurd catalogus model. Met andere worden. Iedere domein architect maakt voor zijn domein een bouwblokken catalogus. In een later stadium wordt dit aangepast naar een vraaggerichte uitwerking, het zogenaamde etalagemodel. Kenmerken

• Collectie van bouwblokken.
• Bouwblokken van hetzelfde (architectuur) concept kunnen opgenomen worden in een catalogus.
• Catalogi worden gecategoriseerd op basis van een scope. (bijvoorbeeld, infrastructuur, integratie, geo).
• Catalogi binnen een scope hebben een eigenaar.
• Catalogi worden beschreven in een register (beheerd in Sparx Enterprise Architect en gepubliceerd naar HTML en PDF documenten)
• Catalogi zijn veelal hiërarchisch cq gelaagd van opzet. Enerzijds door de indeling in Service, ABB en SBB, anderzijds door de opzet met samengestelde bouwblokken.

Statement Een architectuur bouwblok is de logische definitie van een functionaliteit Omschrijving Voor een architectuur bouwblok wordt de afkorting ABB gebruikt. Een architectuur bouwblok beschrijft de functionaliteiten die aangeboden worden aan een hoger liggende entiteit. Een ABB beschrijft WAT er nodig is, zonder te schrijven naar een specifieke oplossing. De hoger liggende entiteit kan een service of een samengestelde ABB zijn. Een ABB kan samengesteld zijn uit één of meerdere SBB. Deze SBB zijn de implementatie van de functionaliteit. Met andere woorden de SBB realiseert de ABB. Kenmerken

• Beschrijving van een functionaliteit
• Beschrijving van het gedrag van informatievoorziening elementen zonder kenmerken van fysieke implementatie
• ABB is logisch, zonder technische specificatie of merknamen
• Infrastructurele- en applicatie laag zijn in de huidige fase van dit model het belangrijkste toepassingsgebied.
• Architectuur bouwblokken zijn gerelateerd aan kwaliteiten, constraints en principes.
• Dit is het kader waarbinnen bijv. een productmanager een product kan selecteren.
• Wanneer een product aan het einde van de LCM is, kunnen de kaders in het ABB opnieuw worden gebruikt om een nieuw product te selecteren.
• Uitgangspunt is het voorkomen dat een ABB wordt geschreven naar een beschikbare oplossing. Deze dient daarom oplossing- en technologie neutraal te zijn.

Statement Een solution bouwblok is de fysieke implementatie van een functionaliteit uitgewerkt in één of meerdere ABB. Omschrijving Voor een solution bouwblok wordt de afkorting SBB gebruikt. Een SBB beschrijft de implementatie waarmee een functionaliteit gerealiseerd wordt. Een SBB biedt deze implementatie aan een hoger liggende entiteit. In ons model is een SBB implementatie van ABB of van een samengestelde SBB. Hierbij is het relevant dat er een onderscheid gemaakt wordt in architecturele lagen. Voor ons zijn de infrastructurele- en de applicatie laag het belangrijkste toepassingsgebied. Een SBB op applicatieniveau kan hiermee een samenstelling zijn van SBBs op zowel de applicatie- als de infrastructurele laag. SBB zijn gerelateerd aan kwaliteiten, constraints en principes. Dit is bij voorkeur uitgewerkt om aan te geven aan welke vereisten vanuit implementatie perspectief een invulling wordt gegeven en aan welke niet. Dit in combinatie met het model van kwaliteiten binnen de ABB en de requirements zoals op serviceniveau zijn uitgewerkt biedt een complete beschrijving van de kenmerken die door een service worden aangeboden. Kenmerken

• SBB is een fysieke implementatie van een (deel van) of meerdere ABBs cq functies.
• Technische en productspecificatie zijn bekend.
• Merk- en leveranciersnamen zijn bekend.
• Een SBB is veelal vervangbaar door een ander product of implementatie.