IT Arkitektur og Sikkerhed

1. IT Arkitektur og Sikkerhed Enterprise Arkitektur

2. Sidste uge • I sidste uge gennemgik vi • Introduktion til Service Orienteret Arkitektur • Påbegyndte SAP og Citrix ROI case

3. Dagsorden • I denne uge gennemgår vi • Introduktion til Enterprise Arkitektur (EA) • EA klassifikation og modellering • EA procesforløb • EA styring (ITIL + Cobit) • Afslutter SAP og Citrix ROI case

4. Næste uge • I næste uge gennemgår vi • Kryptering og Enterprise sikkerhedsmodeller • Prøveeksamen Bemærk at næste gang er 22. marts 2007. Den 15. marts 2007 er der heldagsarrangement.

5. Enterprise arkitektur (EA) • Forretningsarkitektur • Virksomhedsstrategi • Virksomhedens kontrolmekanismer • Virksomhedens organisation • Virksomhedens forretningsprocesser og -funktioner • Data og Informationsarkitektur • Logiske datastrukturer • Fysiske datastrukturer • Data management • Applikationsarkitektur • Applikationerne og deres indbyrdes relationer • Applikationerne og deres sammenhænge til forretningsprocesser og -funktioner • IT Arkitektur • Tekniske infrastruktur til at understøtte HA applikationer

6. Alt hænger sammen Appl. Appl. Appl. Appl. Appl. Data Data Data Data Teknisk infrastruktur Teknisk infrastruktur Teknisk infrastruktur

7. I virkeligheden Kilde: Rigsrevisionen rapport om XXX 21. Juni 2004

8. I virkeligheden • 71 kærnesystemer • 36 personsystemer • 18 forretningssystemer • 8 support systemer • 7 vurderingssystemer • 2 interne systemer • Årlige IT udgifter • 608 kroner i 2003 (18% af driftsudgifterne) • IT udgifterne har været stigende • Brugte 54 millioner i 1999 til konsulenter • Bruger 72 millioner i 2003 til konsulenter Kilde: Rigsrevisionen rapport om XXX 21. Juni 2004

9. Spørgsmål • Hvorfor stiger IT udgifterne ? • Hvorfor stiger konsulentudgifterne ?

10. EA • Formålet med EA er • Sikre at IT understøtter Forretningen • Sikre overblik over konsekvenser ved ændringer • Sikre simplificering, og undgå duplikering • Sikre hurtig omstilling

11. EA • EA involverer • klassificering og modellering af alle artefakter i arkitekturen • Processer til brug for etablering og vedligeholdelse af arkitekturen • Styring af arkitekturen

12. Klassifikation • John Zachman - The Zachman FrameworkFødt i Toledo, Ohio, December 12, 1934Ansat 26 år i IBM hvor han arbejdede med IS strategi og EA. • I 1987 udgave han den første hvidbog om sit klassifikationssystem i IBM Systems Journal ”A Framework for Information Systems Architecture”. (kilde: www.zifa.com) • Der kom flere opfølgende hvidbøger om emnet, herunder en vigtig udvidelse til den første hvidbog i 1992, ”Extending and formalizing the framework for information systems architecture”. (kilde: www.zifa.com)

13. Aspekt Perspektiv Zachman’s klassifikation • Zachman beskriver en EA i seks perspektiver og i seks aspekter • Perspektiv er SYNSVINKLEN • Aspekt er HVAD, HVORDAN, HVOR, HVEM, HVORNÅR og HVORFOR

14. Aspekt Perspektiv Zachman’s perspektiver • Ejer (Forretning) • Planlægger(Program/Projekt) • Designer (IT arkitekt) • Entreprenør (Leverandør) • Underleverandør • (subcontractor) • Fungerende virksomhed(færdig system)

15. Ejer • Ejeren er normalt modtageren af det endelige produkt eller service der bliver produceret. • Ejeren er interesseret i at definere, og se, hvordan produktet eller servicen ser ud og/eller virker når det er i hans/hendes varetægt. • Ejeren har en konceptuel synsvinkel på produktet eller servicen.

16. Planlægger • Planlæggeren kender virksomhedens mål, prioriteter, regler og ressourcer. • Planlæggeren bestemmer indhold og omfang af produkter og services der bliver produceret. • Planlæggeren har en kontekstuel synsvinkel på produktet eller servicen.

17. Designer • Designeren er normalt arkitekten eller ingeniøren der skal oversætte hvad ejeren vil have til hvad der er fysisk og teknisk muligt at bygge af entreprenøren. • Designeren bestemmer produktets eller servicens funktion, og afgrænsning. • Designeren har en logisk synsvinkel på produktet eller servicen.

18. Entreprenør • Entreprenøren har ansvaret for fabrikation af produktet eller servicen. • Entreprenøren forstår det miljø produktet eller servicen skal implementeres i, samt hvordan det blive fabrikeret og brugt. • Entreprenøren har en fysisk synsvinkel på produktet eller servicen.

19. Underleverandør • Underleverandøren udformer detaljerede specifikationer for komponenter eller elementer i produktet eller servicen således at de kan fabrikeres. • Underleverandøren er udenfor kontekst og fokuserer kun på fabrikation af komponenter eller elementer (ingen synsvinkel).

20. Fungerende virksomhed • Den fungerende virksomhed er den fysiske realisering af produktet eller servicen baseret på designerens, entreprenørens, og underleverandørens arbejde. • Den fungerende virksomhed skal reflektere ejerens synsvinkel, og er hvad brugerne af produktet eller servicen oplever fysisk (fysisk realisering)

21. Zachman’s aspekter • HVAD er den/det lavet af ? • HVORDAN virker den/det ? • HVOR er den/det lokaliseret/placeret ? • HVEM gør hvad ? • HVORNÅR sker hvad ? • HVORFOR sker det ?

22. Zachman’s aspekter • HVAD – DATA. Entiteter (entity), Relationer (relationships) • HVORDAN – PROCES. Processer (processes), Input/Output (I/O) • HVOR– NETVÆRK. Steder (nodes), Forbindelser (link) • HVEM – MENNESKER. Ansvar (responsibility), Arbejde (work) • HVORNÅR – TID. Tid (time), Begivenheder (cycle) • HVORFOR – MOTIVATION. Resultat (end), Ressourcer (means)

24. Så blev vi så meget klogere • Zachman har defineret en standardiseret måde at anskue verdenen. • Zachman har opfundet en ”reol” med faste navne på hylderne. • Zachman har ikke bekymret sig over hvilke bøger der skal på hylderne.

25. Modellering • Det findes mange modelleringsværktøjer • Planlægger • Balanced Scorecards, Portfolio Management tools, Project Management tools, Earned Value Management tools • Designer • IDEF0 - IDEF0 er et formsprog til at beskrive beslutninger, aktioner, og aktiviteter i en organisation • IDEF3 - IDEF3 er et formsprog til at beskrive hvordan systemer, processer, og organisationer virker og snakker sammen • BPMN - BPMN er grafisk notation for at udtrykke forretningsprocesser • UML - UML er et formsprog til at specificere, konstruere og dokumentere software systemer • Entreprenør og Underleverandør • UML, Dataflow Diagrams, Logical Datamodels, System Area Maps, System Architecture Diagrams • UML, Physical Datamodels, Network Concepts Diagrams

26. UML • UML (Unified Modeling Language) er et standard sprog til at modellere ting i den virkelige verden. • UML sikre at der ikke er misforståelser når artefakts beskrevet med UML notationen overleveres mellem personer. • UML er nu en standard under Object Management Group (OMG).

27. UML • UML indeholder 14 forskellige diagram typer • For mere information om UML henvisestil Martin Fowler, UML Destilled (IkkePensum)

28. UML eksempler (Use case)

29. UML eksempler (Sequence)

30. UML eksempler (Deployment)

31. Modellering • ZIFA har selv udgivet en række hvidbøger om hvordan de enkelte celler i Zachman’s klassifikationssystem skal repræsenteres. • The Framework for Enterprise Architecture Cell Definitions (kilde www.zifa.com ZIFA 03) • Enterprise Architecture Artifacts Vs. Application Definition Artefacts (kilde www.zifa.com ZIFA 05) • Det kan anbefales at tjekke Agile Modelling hjemmesiden for yderligere information om modellering http://www.agilemodeling.com

32. Modelleringsværktøjer • En række leverandører tilbyder software produkter til at understøtte EA modellering • Telelogic SystemArchitect • IBM Rational Rose • Aonix Select Component Architect • Sparx Enterprise Architect • Microsoft Visio • Computas Metis • IDS Scheer ARIS • Telematica RSD Studio • BizzDesign Testbed Studio

33. Model-Driven Architecture • Using the MDA methodology, system functionality is defined as a platform-independent model (PIM), using an appropriate specification language and then translated to one or more platform-specific models (PSMs) for the actual implementation. • To accomplish this goal, the MDA defines an architecture that provides a set of guidelines for structuring specifications expressed as models. The translations between the PIM and PSMs are normally performed using automated tools.

34. EA proces • The Open Group The Open Group er der et leverandør- og teknologiuafhængigt konsortium har specificeret et proces rammeværk, eller et proces forløb, til at udvikle en EA kaldet The Open Group Architectural Framework version 8.1 (TOGAFv8.1)

35. TOGAF8.1 • TOGAFv8.1 består af fire dele • PART I: Introduktion • PART II: Architecture Development Method (ADM) • PART III: Enterprise Continuum • PART IV: Resources

36. ADM • Pre-limFastlæggelse af arkitektur standarder • Architecture VisionIdentificer behov, interessenter, principper, prioriteter, omfang m.m. • Business ArchitectureIdentificer nuværende og kommende forretningsarkitektur • Information System ArchitectureIdentificer kommende data og applikationsarkitektur • Technology ArchitectureIdentificer kommende teknologiarkitektur • Opportunities and SolutionsBestem implementeringer og projekter • Migration PlanningPrioriter implementeringer og projekter • Implementation GovernanceGuide de enkelte implementeringer og projekter • Architecture Change ManagementEtablering af procedure for styring af ændringer iht. Arkitekturprincipperne

37. ADM og Zachman’s klassifikationssystem • The Open Group har forholdt sig til Zachman’s klassifikationssystem • Som det fremgår af nedenstående figur forholder ADM sig til alle perspektiver; Ejer (owner), Planlægger (planner),Designer (designer), Entreprenør (builder), Underleverandør (subcontractor). Dog ikke Fungerende virksomhed.

38. ADM og Zachman’s klassifikationssystem BusinessArchitecture IS ArchitectureApplikationsarkitektur Pre-lim ArchitectureVision IS ArchitectureDataarkitektur

39. Continuum • TOGAFv8.1 definere reference arkitektur som • Foundation Architectures; arkitektur bestående af retningslinier, standarder, og byggeklodser der understøtter arkitekturer for specifikke løsningsdomæner. • Common Systems Architectures; arkitektur der gå på tværs af specifikke løsningsdomæner; sikkerhedsarkitektur, netværksarkitektur, management arkitektur • Industry Architectures; specifik arkitektur for specifikke industri segmenter, eksempel Petrotechnical Open Software Corporation (POSC) Data Model • Enterprise Architectures; specifik arkitektur for virksomheden til implementering.

40. Ressourcer • Architecture Board • Roller, Ansvar, Udformning, Dag-til-Dag, • Architecture Compliance • Project Impact Assessment, Architecture Compliance Reviews, Compliance Review Process, Checklists, Review Guidelines • Architecture Contracts • Architecture Governance • Architecture Maturity Models • Capability Model for IT Architecture - The US Department of Commerce's ACMM Framework • Capability Maturity Models Integration (CMMI) • Architecture Patterns • Architecture Principles • Architecture Skills Framework • Examples & Case Studies

41. Eksempler • Arkitektur Principper • Principle 1: N-layeringApplications will be N-layered with a separation of the Presentation, Business Logic, and Data Access Tiers • Rationale .... • Implications .... • Principle 2: Service OrientationApplications will communicate using web services • Rationale .... • Implications ..... • Principle 3: Use of Common Integration InfrastructureApplications will use a common integration infrastructure • Rationale .... • Implications .....

42. Eksempler • Architektur mønstre (”lego-klodser”) • "expressing a fundamental structural organization schema for software systems. It provides a set of predefined subsystems, specifies their responsibilities, and includes rules and guidelines for organizing the relationships between them.”kildePattern Oriented Software Architectureaf Frank Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, and Michael Stal (Ikke pensum)

43. IT Governance • Governance is essentially about ensuring that business is conducted properly. It is less about overt control and strict adherence to rules, and more about guidance and effective and equitable usage of resources to ensure sustainability of an organisation's strategic objectives (TOGAF 8.1) • IT Governance provides the framework and structure that links IT resources and information to enterprise goals and strategies. Furthermore, IT Governance institutionalizes best practices for planning, acquiring, implementing, and monitoring IT performance, to ensure that the enterprise's information technology assets support its business objectives (TOGAF 8.1) • Governance is a program that makes sure that people do what's “right.” When used in conjunction with software, governance controls the development and operation of software. A governance program is implemented using policies, processes, metrics, and organization (Burton group). • Boards and executive management have long known the need for enterprise and corporate governance. However, most are beginning to realize that there is a need to extend governance to information technology as well, and provide the leadership, organisational structures and processes that ensure that the enterprise’s IT sustains and extends the enterprise’s strategies and objectives (ISACA/COBIT)

44. IT Governance Model Audit Models CobIT Service Mgmt. App. Dev. Project Mgmt. IT Planning IT Security Quality System ITIL PMI PRINCE2 CMMI DS484 ISO17799 ISO SIX SIGMA IT OPERATIONS

45. CobIT (Control Objectives for IT) • CobIT er en åben standard kontrol system for at sikre IT Governance. Fokus er IT standarder og Audit. • CobIT beskriver standarder, kontroller og modenheds guidelines for fire domæner og 34 kontrol processer.

46. CobIT domæner Plan & Organize (PO Process Domain) Acquire & Implement (AI Process Domain) Monitor (M Process Domain) Deliver & Support (DS Process Domain)

47. Plan & Organize Planning & Organization Acquire & Implement Define Strategic IT Plan Define Information Architecture Determine Technological Direction Identify Automated Solutions Acquire & Maintain Application Software Install & Accredit Systems Manage Change Acquire & Maintain Technology Infrastructure Develop & Maintain IT Procedures Define IT Organization & Relationships Manage IT Investment Communicate Aims & Direction Ensure Compliance With External Standards Assess Risks Manage Human Resource Manage Quality Manage Projects Monitor Deliver & Support Assess Internal Control Adequacy Monitor The Process Define & Manage Service Levels Manage Third-Party Services Manage Performance & Capacity Ensure Continuous Service Ensure System Security Identify & Allocate Costs Manage Operations Obtain Independent Assurance Educate & Train Users Assist & Advise IT Customers Manage Configuration Manage Problems & Incidents Manage Data Manage Facilities Provide Independent Audit

48. ITIL (Information Technology Infrastructure Library) • ITIL er syv bøger som guider forretningsbrugere til at planlægge, levering og kontrol af IT services

49. ITIL bøgerne T h e Technology Planning To Implement Service Management T h e B u s i n e s s Service Management Service Support The Business Perspective ICTInfrastructureManagement Service Delivery Security Management Application Management

50. The Business, Customers or Users Monitoring Tools Difficulties Queries Enquiries Communications Updates Work-arounds Incidents Customer Survey reports Service Desk Incidents Changes Incident Management Customer Survey reports Problem Management Releases Service reports Incident statistics Audit reports Change Management Problem statistics Problem reports Problem reviews Diagnostic aids Audit reports Release Management Change schedule CAB minutes Change statistics Change reviews Audit reports Release schedule Release statistics Release reviews Secure library’ Testing standards Audit reports Configuration Management CMDB reports CMDB statistics Policy standards Audit reports Cls Relationships Problems Known Errors Incidents Changes Releases CMDB