ICT Architectuur Principes uitgelegd en voorbeelden

1. Architectuur
Principes
wat zijn het en wat heb je er aan?
presentatie: Jurgen van de Pol
principes: Dave de Kort & Jurgen van de Pol

2. 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

3. 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

4. Forget not, when up to one's neck in alligators,
that the mission is to drain the swamp.

5. Waar moet een principe aan voldoen.

6. Begrijpelijk

7. Robuust

8. Compleet

9. Samenhangend

10. Stabiel

11. 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

12. Principes volgens TOGAF.
bestaan uit 4 onderdelen:
1. Naam
2. Beschrijving
3. Motivering
4. Implicatie

13. TOGAF ?
De Open Group Architecture Framework is een
kader - een gedetailleerde methode en een set
van ondersteunende tools - voor het
ontwikkelen van enterprise architectuur.

14. 1. Naam
Is makkelijk te onthouden en
bevat de essentie van de
regel.

15. 2. Beschrijving
Legt kort, bondig &
ondubbelzinnig het
fundament van de regel uit.

16. 3. Motivering
Legt de voordelen
van het naleven uit in
business termen.
Beschrijft eventuele relaties
met ander principes.

17. 4. Implicaties
Beschrijft de impact
op de business
en de gevolgen
van naleving.
"Wat betekent dit voor mij?"

18. a prototype
is worth
a thousand meetings

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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

29. 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

30. 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

31. 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