Infrastructuur Architectuur. Frank van Valkenburg

Transcriptie

1 Infrastructuur Architectuur Frank van Valkenburg 1 / November 12, 2008

2 Programma Introductie Architectuur De klassieke vierdeling Infrastructuur Kwaliteit Architectuur aspecten De succesvolle aanpak Beheer en support Vragen 2 / November 12, 2008

3 Introductie: Frank van Valkenburg 15 jaar ICT ervaring Van systeem & netwerkbeheer naar engineering naar infrastructuur ontwerp & architectuur Opdrachtgevers o.a.: o Auto Lease Holland o AEGON o Moret Ernst & Young o Postbank (Internet Bankieren) o ABN AMRO (Transaction Banking) o Fortis Samenwerking met o.a.: o Sun Microsystems o Cisco Systems o IBM o Oracle Drs. Frank van Valkenburg is getrouwd en vader van twee kinderen. Frank is infrastructuur architect bij Ideas to Interconnect BV (i-to-i), gespecialiseerd in grootschalige internet hosting omgevingen. Ideas to Interconnect B.V. is een management- en consultancybedrijf dat haar klanten helpt bij het realiseren van ICT veranderdoelstellingen. Frank werkte eerder bij Pink Elephant. 3 / November 12, 2008

5 Architectuur...is een proces, geen product...speelt zich af op het snijvlak van business en technologie...neemt altijd de business als uitgangspunt...gaat over non-functionele eigenschappen...maar ook over het realiseren van functionele eigenschappen...is holistisch (kijkt naar alle relevante aspecten) en betreft derhalve het maken van afwegingen...beoogt structuur en strategische juiste keuzes te realiseren (gaat dus vaak over de langere termijn)...beoogt veelal complexiteit te reduceren 5 / November 12, 2008

6 Architectuur benaderingen Top-down: halen van (business) requirements deze requirements vertalen in (technologische) oplossingen Bottom-up: brengen van technologische mogelijkheden technologische mogelijkheden vertalen in (business) opportunities Een goede architect past beide benaderingen toe! 6 / November 12, 2008

7 Architectuur lagen Afhankelijk van het gebruikte framework bestaan er verschillende lagen van architectuur. Wij onderkennen in ieder geval: Business Architectuur Informatie Architectuur Applicatie Architectuur Technische Architectuur Hier dwars overheen onderscheiden we drie niveaus: Conceptueel Logisch Fysiek 7 / November 12, 2008

9 De klassieke vierdeling business criteria functioneel ontwerp business SLA s, onderhoud applicatie ontwikkeling / pakketselectie applicaties exploitatie beheer (tools, monitoring) deployment / installatie infrastructuur hosting (netwerk, servers, OS, middelware, databases, oplossingen) embedding (tests, acceptatiecriteria) 9 / November 12, 2008

11 Infrastructuur: Componenten Netwerk (connectivity) o routers, switches, TCP/IP o firewalls o load balancing o proxying Servers (inclusief OS, middleware etc.), bijvoorbeeld o web servers o applicatie servers o directory servers o database servers o messaging servers Oplossingen, bijvoorbeeld: o Storage o Backup o Authenticatie-oplossingen 11 / November 12, 2008

12 Infrastructuur: Simpel of niet? Misvatting bij business en applicatie ontwikkelaars: Infrastructuur is simpel! Hierdoor worden problemen vaak te snel met (extra) infrastructuur opgelost. Waarom is dit een misvatting? Infrastructuur en applicaties die niet op elkaar zijn afgestemd, leiden tot inefficiëntie en instabiliteit. Ketenafhankelijkheid tussen infra componenten (OS, middleware, libraries, database etc) en applicaties. Infrastructuur oplossingen leiden uiteindelijk altijd tot toenemende complexiteit. Complexe omgevingen zijn moeilijk te beheren. Bovendien ook duur. 12 / November 12, 2008

13 Infrastructuur Architectuur Mappen van functionaliteit (applicaties, services, databases etc.) op infrastructuur componenten. Rekening houdend met kwaliteitscriteria, o.a.: Beschikbaarheid Schaalbaarheid (horizontaal vs verticaal) Veiligheid Wijzigbaarheid Misvatting: Kwaliteitscriteria zijn alleen infrastructureel van aard. 13 / November 12, 2008

15 Kwaliteitscriteria Based upon the Quint Extended ISO 9126 Model Maturity Time Behaviour Adaptability Reliability Fault Tolerance Recoverability Availability Degradability Efficiency Resource Behaviour Portability Installability Conformance Replaceability Suitability Understandability Analysability Functionality Accuracy Interopability Compliance Security Traceability Usability Learnability Operability Explicitness Customisability Attractivity Clarity Maintainability Changeability Stability Testability Manageability Reusability Helpfulness User-friendliness 15 / November 12, 2008

16 Kwaliteit; enkele infrastructuur principes Holistisch Aansluitend op applicaties en beheer Beheerbaarheid Reduceer complexiteit, o.a. door standaardisatie en het beperken van het aantal componenten: building blocks Schaalbaarheid Horizontaal of verticaal Voorspelbaarheid Testmogelijkheden, PoC Wijzigbaarheid Gelaagdheid, (web)services: buiding blocks Beschikbaarheid Redundantie, virtualisatie Veiligheid Encryptie, PKI 16 / November 12, 2008

17 Kwaliteit: Bepaald door de som der delen Business Requirements Deze moeten zowel functionele criteria als kwaliteitscriteria omvatten. Vaak ontbreken de kwaliteitscriteria. Applicatie ontwikkeling (of pakketselectie) Traditioneel ligt hier de focus op functionaliteit. Kwaliteit (b.v. veiligheid, schaalbaarheid, wijzigbaarheid) moet echter vanaf het begin onderdeel zijn van het ontwerp. Hosting (infrastructuur) Traditioneel ligt hier de focus op kwaliteit. Kwaliteit is echter een samenspel van business, applicatie, infrastructuur en beheer. Exploitatie (beheer) Op applicatieve en infrastructurele kwaliteitskenmerken moet door een beheerorganisatie gestuurd worden. Bijvoorbeeld middels monitoring & capaciteitsbeheer. Een beheerorganisatie hanteert echter zelf ook kwaliteitscriteria, bijvoorbeeld om SLA s te kunnen behalen. 17 / November 12, 2008

18 Kwaliteit: Foute aanpak en gevolgen Gescheiden aanpak van ontwikkeling, infrastructuur en beheer. Partijen werken langs elkaar heen. Functionaliteit heilig verklaren. Infrastructurele (en beheersmatige) consequenties kunnen een business case echter wel eens breken. Projectkosten bepalend laten zijn. Operationele kosten worden echter niet (voldoende) meegerekend. Kiezen voor ad-hoc en one-off oplossingen. Structurele oplossingen zijn op lange termijn beter dan quick-wins. Spaghetti omgevingen laten ontstaan. Alles zit aan alles vast. Totaal gebrek aan flexibiliteit. Wijzigingen leiden tot onvoorspelbare resultaten. Change-management spiraal. Testen nagenoeg onmogelijk. Basis ITIL processen (b.v. configuratiebeheer) onderschatten. Zonder overzicht is goed en efficient beheer nagenoeg onmogelijk. Aantal betrokken partijen en mensen te groot laten groeien. Dit versterkt een groot aantal bovengenoemde effecten. 18 / November 12, 2008

19 Kwaliteit: Foute aanpak en gevolgen (2) 19 / November 12, 2008

21 Architectuur aspecten Functioneel Applicatie Outsourcing / Offshoring Decentraal Tactische oplossingen (Monolitische) applicaties Dedicated resources Tightly coupled Applicatiebeheer Specialisatie Proprietary Zelfbouw Organisatie bepalend Korte termijn Projectkosten Ring-fencing Kwalitatief (non-functioneel) Infrastructuur In house Centraal Strategische oplossingen Services Shared resources Loosely coupled Services beheer Standaardisatie Open standaards COTS Standaardapplicatie bepalend Lange termijn Operationele kosten Hergebruik van componenten 21 / November 12, 2008

22 Overige architectuur aspecten (1) CMDB Configuratiebeheer is van levensbelang, inclusief de relaties tussen de verschillende componenten. Kosten Veranderkosten (kosten van projecten) zijn eenmalig. Operationele kosten zitten hoofdzakelijk in infrastructuur en beheer en zijn wederkerig. Operationele kosten zijn vaak verborgen, maar bepalen grotendeels de TCO! Business cases houden hiermee onvoldoende rekening en zouden wel eens negatief kunnen uitpakken wanneer dat wel zou gebeuren. Service Management Het managen van generieke, door iedereen te gebruiken, services is volkomen anders dan het managen van monolithische applicaties. Not-invented-here syndroom Er bestaat veelal een culturele belemmering voor het hergebruiken van componenten van anderen (afdeling, business unit, organisatie). 22 / November 12, 2008

23 Overige architectuur aspecten (2) Wijzigbaarheid Functioneel een pas op de plaats maken ten gunste van nonfunctionele progressie stimuleert de agility (wendbaarheid, wijzigbaarheid) van de functionaliteit op langere termijn. M.a.w. functionaliteit kan daardoor sneller en gemakkelijker gewijzigd worden. Communicatie, communicatie, communicatie Verschillende belanghebbenden hebben verschillende inzichten, maar kennen die van elkaar meestal niet (voldoende). De beste oplossingen houden rekening met alle inzichten door deze inzichtelijk te maken en tot compromissen te komen. 23 / November 12, 2008

25 De succesvolle aanpak business business applicaties exploitatie infrastructuur 25 / November 12, 2008

26 De succesvolle aanpak business business criteria ict project applicaties exploitatie infrastructuur 26 / November 12, 2008

28 Beheer en support - klassiek business 1e lijns beheer applicaties functioneel beheer helpdesk functioneel beheer netwerk java unix database infrastructuur security 2e & 3e lijns beheer 28 / November 12, 2008

29 Beheer en support - alternatief Dedicated teams & Generalisatie business 1e lijns beheer applicaties helpdesk 2e & 3e lijns beheer: netwerk netwerk, unix, java, database, security, applicaties, etc unix java database security kleine teams multidisciplinaire kennis 29 / November 12, 2008

30 Vragen? 30 / November 12, 2008