Architectuur

Principeswat zijn het en wat heb je er aan?

presentatie: Jurgen van de Pol

principes: Dave de Kort & Jurgen van de Pol

Principe

principium/prɪnˈsɪpɪəm/

noun (pl) -ia (-ɪə)

1.

[usually plural] a principle, esp a fundamental one

Word Origin, Latin: an origin, beginning

Wat zijn Architectuur Principes?

● Richtinggevende uitspraken

voor essentiële beslissingen.

● Fundamentele ideeën

bedoeld om algemene eisen te

vervullen.

● Uitgelegd naar:

o zaken die moeten

o zaken die verstandig zijn

Forget not, when up to one's neck in alligators,

that the mission is to drain the swamp.

Waar moet een principe aan voldoen.

Begrijpelijk

Robuust

Compleet

Samenhangend

Stabiel

Principes worden beïnvloed door.

● De ICT missie:

Meer resultaat, Beter fundament.

● Strategische initiatieven

● Directe kanalen (internet)

● Regiefunctie in de zorg (zorgvinder, BI)

● Externe beperkende factoren zoals wet &

regelgeving, compliancy & security

● Huidige stand van systemen & technologie

● Persoonlijke visies in de ICT

Principes volgens TOGAF.

bestaan uit 4 onderdelen:

1. Naam

2. Beschrijving

3. Motivering

4. Implicatie

TOGAF ?

De Open Group Architecture Framework is een

kader - een gedetailleerde methode en een set

van ondersteunende tools - voor het

ontwikkelen van enterprise architectuur.

1. Naam

Is makkelijk te onthouden en

bevat de essentie van de

regel.

2. Beschrijving

Legt kort, bondig &

ondubbelzinnig het

fundament van de regel uit.

3. Motivering

Legt de voordelen

van het naleven uit in

business termen.

Beschrijft eventuele relaties

met ander principes.

4. Implicaties

Beschrijft de impact

op de business

en de gevolgen

van naleving.

"Wat betekent dit voor mij?"

a prototype

is worth

a thousand meetings

Vleesch noch Visch

Principe: we eten vegetarisch

Beschrijving: we eten geen dierlijke producten of

bijproducten, we eten geen producten waarvoor een dier

heeft moeten lijden of sterven zoals eieren en melk

Motivering: we willen niet bijdragen aan dierenleed,

zuiniger zijn met grondstoffen 10 kilo soja=1kilo kip

Implicaties:

● laat voortaan lekkere vleesgerechten staan

● eet niet meer in je favoriete steakhouse

● lastige situaties bij etentjes bij vrienden en familie

http://www.archixl.nl/archixl/publicaties/blog/item/architectuurprincipe-is-vlees-noch-vis

Rationale

● Ontwerpen, oplossingen en

implementaties zijn complex genoeg

op zichzelf, voeg derhalve geen

onnodige complexiteit toe.

● Eenvoud heeft inherente waarde in elk

ontwerp.

● Iets is pas perfect als je niets meer

weg kunt laten.

Implicaties

● Voeg enkel functionaliteit toe die

daadwerkelijk gebruikt zal gaan

worden.

● Faciliteer nieuwe functionaliteiten door

het toepassen van ontkoppeling* en

het gebruik van open standaarden.

● De bewijslast (burden of proof) ligt

altijd bij de complexere oplossing.

● Denk eenvoudig, reduceer het geheel

van de onderdelen tot op het niveau

van de eenvoudigste vorm.

Een oplossing is zo eenvoudig mogelijk, maar niet eenvoudiger dan mogelijk.

Design voor eenvoud

Rationale● Robuust als het tegengestelde van fragiel

dekt de lading onvoldoende.

● Anti-fragility gaat verder dan robuustheid,

het betekent dat iets niet alleen bestand is

tegen een schok, maar daadwerkelijk

verbetert als gevolg van de schokken. (non

fatale failures)

● Systemen moeten blijven functioneren ook

al zijn niet alle aanwezige resources

aanwezig

● Systemen worden beter door veelvuldige

mishandeling. Bij implementatie van dit

soort systemen zijn er nog mogelijkheden

volop om vertrouwen te krijgen.

Implicaties● Maak veelvuldig gebruik van business

continuity maatregelen.

● Voorkom ‘black swans’: problemen die

iedereen, achteraf bezien, wel aan zag

komen.

● Beloon durf, ook al gaat het wel eens fout.

● Stimuleer constante verandering.

Applicatie draaien op onbetrouwbare infrastructuur.

Focus op anti-fragility.

Design for failure is beter dan design for succes.

Design for fail

Rationale

● Full browser is (nu) de enige praktische

en haalbare strategie voor applicatie end

points (sluit aan bij Middle-out principe)

● Webbased is de exit strategie voor dure

en complexe oplossingen als Citrix, etc

● Minimale variatie in (100%)

ondersteunde end points, lagere TCO

● Cliënts kunnen “buiten” het CZ-netwerk

worden gehouden. (Elke cliënt kan

beschouwd worden als een untrusted

device)

Implicaties● Web-enabled ontwikkelen in HTML5

● Webbased maken van presentatielaag van

applicaties, zonder noodzaak van plug-ins,

anders dan full browser met HTML5

ondersteuning

● Tijdens transitie hanteren van VDI (Xen-

Desktop) en TS (XenApp)

● Zorgen voor gecontroleerde opslag van CZ

data op portable devices: de applicatie

bepaalt wat er wel of niet wordt opgeslagen

● Er worden geen eisen gesteld aan het

endpoint (anders dan een ondersteunende

HTML5 browser)

De full browser = nieuwe en enige cliënt.

Maximale variatie in ondersteunde endpoints met minimale variatie in techniek.

De browser garandeert aflevering op elk mogelijk platform.

De browser is de cliënt

Rationale● Bij uitval van 1 of meerdere (n-x)

componenten van een ICT-dienst (bestaat

uit meerdere, simultaan actieve, redundante

componenten), blijft de dienst beschikbaar

● Geen noodzaak voor complexe voorbereide

uitwijk testen

● Geen downtime nodig tijdens testen

● Standaard hoge beschikbaarheid

● Efficiënt gebruik van resources: bij

conventionele DR slechts 50% utilisatie

● Continue gebruik van de gedistribueerde

resources garandeert functionaliteit bij

uitwijk.

Implicaties● Processen en applicaties stateless maken

door maximaal gebruik maken van

gevirtualiseerde infrastructuur

● Starten van transitie naar een robuust

failover-systeem met een zeer hoge

beschikbaarheid

● Bestaande applicaties die niet voldoen aan

dit principe autonoom failover en inherent

maken; nieuwe applicaties dienen hier

vanaf de implementatie al aan te voldoen

● Handhaven van de totale last over een over-

gedimensioneerde infrastructuur (voorbeeld:

70%-70% bij 2 datacentra).

De oplossing is inherent en autonoom hoog beschikbaar.

Van disaster recovery naar resiliency.

Horizontale schaling (cattle vs pets).

Inherent & autonoom

hoog beschikbaar

Rationale● Afnemer en leverancier moeten maximaal

onafhankelijk zijn van de implementatie van

de dienst, zonder hinderlijke structuren en

procedures vanuit ICT

● Kunnen leveren wat de klant nodig heeft om

optimaal te kunnen werken

● Flexibel voldoen aan contractuele afspraken

staat centraal

● Dienst is gestandaardiseerd

● Snellere adoptie en ontwikkeling van nieuwe

diensten / services

● Snellere oplossing van problemen, doordat

aanspreekpunten duidelijk zijn en

betrokkenheid hoog ligt.

Implicaties

● Realiseer meer en betere communicatie

tussen ontwikkeling en beheer

● Horizontaal verantwoordelijke teams voor

elke dienst (Customer Centric IT)

● Per project samenstellen van een multi-

disciplinair team dat verantwoordelijk is,

front-to-back

● Self service portals waar complete

systemen op afroep en zonder vertraging

kunnen worden samengesteld

● Aanbieden variëteit in cloud diensten (SaaS

IaaS, enz), waar mogelijk

● Van budget naar showback naar

chargeback.

Focus op de dienst die de klant ziet.

Een architectuur model voor een systeem opgebouwd uit service contracten die

bestaan uit afspraken tussen afnemers van diensten en leveranciers.

ICT is service georiënteerd

Rationale● Ontkoppeling tussen technologische

componenten maakt vervanging en

opschaling veel eenvoudiger (loose

coupling).

● De ontkoppelingslaag is de meest ideale

plaats voor value added services, vanwege

de onafhankelijkheid van de (harde)

techniek die ontkoppeld wordt

● De ontkoppelingslaag biedt de beste

mogelijkheden om gecontroleerd naar de

cloud te kunnen gaan (cloud bursting).

Implicaties● Ontkoppel componenten via virtualisatie,

daar waar toegevoegde waarde opweegt

tegen extra complexiteit. (Virtualisatie is op

dit moment de enige techniek om fysieke

lagen te ontkoppelen middels een logische

laag, waarbinnen functionaliteit en

flexibiliteit kan worden toegevoegd)

● Implementeer stretched VMware clusters

● Implementeer stretched HP Matrix

● Implementeer storage virtualisatie

Maximale ontkoppeling door virtualisatie

Loose Coupling - High Coherence

Abstract, Pool, Automate

Maximale ontkoppeling

Rationale● Doel is maximale diversiteit in

dienstverlening met minimale diversiteit in

ICT middelen

● Eerst werken naar (open) standaarden om

daarna naar de eindoplossing

● Standard building block methodiek biedt een

meer flexibele, stabiele en robuuste

oplossing

● Betere ondersteuning derde partijen

● Eenvoudig inhuur bij te schakelen door ruim

voorradige kennis

● Toekomstbestendigere uitgangspositie voor

opvolgende trajecten.

Implicaties● Maken van een repository van

geaccepteerde building blocks

● Vormen van een bredere kijk dan enkel

point solution oplossingsgericht denken en

ontwerpen

● In een vroeg stadium tegen het licht houden

van een oplossingsrichting tegen eerder

genomen en geaccepteerde architectuur

keuzes.

Meer bereiken met een selectie van, bij voorkeur, open standaarden.

Cattle versus pets.

Gebruik standaard building

blocks

Rationale● Niet meer onderhouden dan twee releases

van software.

● Stabiliseren van TCO (beperking van het

aantal te beheren platforms), waardoor

beheerlast verlaagd wordt en kwaliteit en

beschikbaarheid beter worden.

● Iets is pas perfect als je niets meer weg kunt

laten.

Implicaties● Gebruik appliances om beheerslast en

complexiteit te verlagen, daar waar mogelijk

● Zoek universele oplossingen die meerdere

doelen dienen.

● Reduce, Reuse, Refactor○ Reduce: minder x = minder onderhoud

○ Reuse: onderzoeken of gewenste

functionaliteit aangeboden kan worden met

wat er al is

○ Refactor: optimaliseren zonder aanpassing

van externe functionaliteit (minder kans op

uitval van dienstverlening).

Less is more…

Reduce, Reuse, Refactor

Kies strategische platformen

Diversiteit beperken

Rationale● Huidige monitoring is onsamenhangend,

jaren van feature creep en overlap.

● Er is sprake van constant bewegende

infrastructuur en applicaties, laag op laag

van verouderde applicaties en een gebrek

aan flexibiliteit naar nieuwe technische

methoden.

Implicaties● Meet end point experience: zie wat de klant

ziet.

● Aggregeren output.

● Communiceer naar en eisen van vendors

een set parameters die een heldere

indicatie geven van capacity, health en

performance van elke component (storage,

enclosure, blade, etc)

● Beperk complexiteit.

● Borg beheer van het centrale monitoring

systeem met brug functie.

Operational intelligence, zien wat in de complete keten van de service gebeurt.

Wat je niet meet, kunnen je niet verbeteren.

Aggregeer de verantwoordelijk voor alerting, correlatie, trending en reporting in

een centraal beheerd systeem.

Operational Intelligence

Rationale● De opslag van data bevindt zich vaak niet

op de meest geschikte locatie of in het

meest geschikte formaat.

● Vraag naar opslag blijft exponentieel stijgen.

● CZ slaat op dit moment vrijwel al haar

ongestructureerde data op, op de minst

geschikte locatie: relationele databases.

● Databases bevinden zich op het kostbaarste

medium, zijnde de SAN storage met de

beste IO eigenschappen, terwijl de

ongestructureerde data niets van de

eigenschappen van dit medium vereist.

Implicaties● Analyseren van de data op het gebied van

gebruik en ontsluiting.

● Kiezen van de meest geschikte locatie om

data op te slaan: ongestructureerde data in

object stores, data-at-rest in archives,

metadata en databases op snelle SAN

storage, backups op gedupliceerde storage

etc etc.

● Uitvoeren onderzoek naar object storage

(OpenStack, Atmos, iBricks).

● Uitvoeren onderzoek naar archief

oplossingen (Amazon Glacier).

Data opslag op het meest geschikte medium

Smart storage

Rationale● Security en compliancy zijn tweeledig, a:

voor jezelf en je klant, b: voor opgelegde

regel en wetgeving.

● Data security is een verantwoordelijkheid,

geen keuze.

● Security is centraal ingeregeld en

gestandaardiseerd.

● Security maatregelen zijn opgenomen de

geautomatiseerde tooling

● Controle is beter dan vertrouwen.

Implicaties● Focus primair op bedrijfsprocessen en data,

niet op techniek.

● Ontwikkelen van metrics en maatregelen

met daaraan gekoppelde grenswaarden en

acties.

● Onderscheid maken tussen bedreigingen &

kwetsbaarheden en risico’s.

● Maatregelen mogen de verhoudingen

Availability, Performance en Security niet

verstoren.

● Security is een evolutionair proces →

proberen de slag te winnen voor deze

begint.

ICT is veilig en voldoet aan wet- en regelgeving.

Security is een integraal onderdeel van de architectuur, applicaties en data.

Security en ontsluiting zijn in balans.

ICT is veilig

Rationale● Repeterende taken worden

geautomatiseerd → operationeel beheer

beperken.

● Diensten opereren autonoom, met minimale

interventie door operationeel beheer.

● Handmatige uitvoer geeft risico.

Herhaalbaarheid van resultaten is erg

belangrijk. Het voorkomt discussies,

bijvoorbeeld bij de productiegang.

● Terugdringen van beheer zorgt voor meer

focus op wat belangrijk is voor de klant.

● Automatisering helpt processen te voldoen

aan compliancy regels.

Implicaties● Automatiseren op alle lagen, naast de cloud

matrix van HP moet er ook worden ingezet

op het automatiseren van de installaties van

applicaties.

● Transparant en vanzelfsprekend maken van

geautomatiseerde processen.

● Processen eenvoudig over laten brengen

naar andere tooling.

Automatiseer elk repetitief proces

Herhaalbaarheid = Betrouwbaarheid

Automation