Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

ICT Architectuur Principes

5,067 views

Published on

ICT Architectuur Principes uitgelegd en voorbeelden

Published in: Technology

ICT Architectuur Principes

  1. 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. 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. 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. 4. Forget not, when up to one's neck in alligators, that the mission is to drain the swamp.
  5. 5. Waar moet een principe aan voldoen.
  6. 6. Begrijpelijk
  7. 7. Robuust
  8. 8. Compleet
  9. 9. Samenhangend
  10. 10. Stabiel
  11. 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. 12. Principes volgens TOGAF. bestaan uit 4 onderdelen: 1. Naam 2. Beschrijving 3. Motivering 4. Implicatie
  13. 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. 14. 1. Naam Is makkelijk te onthouden en bevat de essentie van de regel.
  15. 15. 2. Beschrijving Legt kort, bondig & ondubbelzinnig het fundament van de regel uit.
  16. 16. 3. Motivering Legt de voordelen van het naleven uit in business termen. Beschrijft eventuele relaties met ander principes.
  17. 17. 4. Implicaties Beschrijft de impact op de business en de gevolgen van naleving. "Wat betekent dit voor mij?"
  18. 18. a prototype is worth a thousand meetings
  19. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×