IT Arkitektur og Sikkerhed

Præsentationer af emnet: "IT Arkitektur og Sikkerhed"— Præsentationens transcript:

1 IT Arkitektur og Sikkerhed
IT Arkitektur og Sikkerhed Enterprise Arkitektur 1

2 Sidste uge I sidste uge gennemgik vi
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
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 3

4 Næste uge I næste uge gennemgår vi
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)
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 06-03-07 Appl. Appl. Appl. Appl. Appl. Data Data
Teknisk infrastruktur Teknisk infrastruktur Teknisk infrastruktur

7 I virkeligheden Det har i de seneste tre til fire år været kendt, at visse af Toldskats it-systemer er bygget på en forældet teknologi og kompleks systemarkitektur. Det vurderer Rigsrevisionen i et notat til statsrevisorerne, som siden januar har ønsket at få et overblik over Toldskats it-driftsudgifter og planerne for at udvikle nye systemer. - De forældede IT-systemer udgør en teknologisk risiko, fordi det er svært og dyrt at drive og vedligeholde systemerne og at lave systemerne om, så de kan håndtere ændringer som for eksempel digital forvaltning, større brugervenlighed over for borgere og virksomheder, indførelse af euro og nye skattereformer, skriver Rigsrevisionens Henrik Otbo i notatet. 71 systemer ToldSkat har ifølge egne oplysninger 71 forskellige it-systemer, som er opdelt i 36 personsystemer, 18 erhvervssystemer, otte toldsystemer, syv vurderingssystemer og to interne systemer. De ældste af systemerne stammer fra begyndelsen af 1970?erne, og fundamentet er efter årtiers knopskydning præget af forskellige teknologiske løsninger. Ifølge Rigsrevisionen udgør it-systemernes kompleksitet en barriere for konkurrence på it-markedet, når der skal bydes på it-opgaver for Toldskat. CSC har leveret 46 af Toldskats 71 it-systemer, og en intern Toldskat-rapport fra konsulenthuset Gartner påpegede sidste år, at Toldskat betalte en væsentlig overpris til leverandørerne CSC og KMD for systemdrift. Afviser kritikken Toldskats it-udgifter var sidste år 608 millioner kroner, hvilket udgjorde 18 procent af Toldskats samlede driftsudgifter. Beløbet er højere end de to foregående år, men lavere end i 2000. De årlige udgifter til konsulentbistand er steget fra 54 millioner kroner i 1999 til 72 millioner kroner i 2001, hvorefter de faldt til 28 millioner kroner i Der er dog knyttet en vis usikkerhed til de årlige udgifter til konsulentbistand, fordi Toldskat har været nødt til at anslå beløbet. Toldskat meddelte i sidste måned til Finansministeriet, at it-kontrakterne er genforhandlet, så der ikke længere betales overpris, og underdirektør Steffen Normann Hansen afviser kritikken af it-systemerne. - Så længe, jeg har været her, har vi i den grad fokuseret på at reducere omkostningerne. Ingen ser, hvis det går galt i private virksomheder. Men alle er der, hvis der er problemer i det offentlige, siger han til Politiken. Kilde: Rigsrevisionen rapport om XXX 21. Juni 2004

8 I virkeligheden 71 kærnesystemer Årlige IT udgifter 36 personsystemer
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 ?
Spørgsmål Hvorfor stiger IT udgifterne ? Hvorfor stiger konsulentudgifterne ?

10 EA Formålet med EA er Sikre at IT understøtter Forretningen
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 Framework Født i Toledo, Ohio, December 12, Ansat 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: 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:

13 Zachman’s klassifikation
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 Aspekt Perspektiv

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

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
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 ?
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)

23

24 Så blev vi så meget klogere
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 06-03-07 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
UML UML indeholder 14 forskellige diagram typer For mere information om UML henvises til Martin Fowler, UML Destilled (Ikke Pensum)

28 UML eksempler (Use case)
UML eksempler (Use case)

29 UML eksempler (Sequence)
UML eksempler (Sequence)

30 UML eksempler (Deployment)
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 ZIFA 03) Enterprise Architecture Artifacts Vs. Application Definition Artefacts (kilde ZIFA 05) Det kan anbefales at tjekke Agile Modelling hjemmesiden for yderligere information om modellering

32 Modelleringsværktøjer
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
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
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 06-03-07 Pre-lim Fastlæggelse af arkitektur standarder
Architecture Vision Identificer behov, interessenter, principper, prioriteter, omfang m.m. Business Architecture Identificer nuværende og kommende forretningsarkitektur Information System Architecture Identificer kommende data og applikationsarkitektur Technology Architecture Identificer kommende teknologiarkitektur Opportunities and Solutions Bestem implementeringer og projekter Migration Planning Prioriter implementeringer og projekter Implementation Governance Guide de enkelte implementeringer og projekter Architecture Change Management Etablering af procedure for styring af ændringer iht. Arkitekturprincipperne

37 ADM og Zachman’s klassifikationssystem
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
ADM og Zachman’s klassifikationssystem Business Architecture IS Architecture Applikationsarkitektur Pre-lim Architecture Vision IS Architecture Dataarkitektur

39 Continuum TOGAFv8.1 definere reference arkitektur som
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 06-03-07 Architecture Board Architecture Compliance
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
Eksempler Arkitektur Principper Principle 1: N-layering Applications will be N-layered with a separation of the Presentation, Business Logic, and Data Access Tiers Rationale .... Implications .... Principle 2: Service Orientation Applications will communicate using web services Implications ..... Principle 3: Use of Common Integration Infrastructure Applications will use a common integration infrastructure

42 Eksempler Architektur mønstre (”lego-klodser”)
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.” kilde Pattern Oriented Software Architecture af 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 CobIT 06-03-07 Audit Models ITIL Service Mgmt.
App. Dev. IT Security Project Mgmt. IT Planning Quality System PMI PRINCE2 CMMI DS484 ISO17799 ISO SIX SIGMA IT OPERATIONS

45 CobIT (Control Objectives for IT)
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 & Acquire & Implement Organize Monitor
(PO Process Domain) Acquire & Implement (AI Process Domain) Monitor (M Process Domain) Deliver & Support (DS Process Domain)

47 Planning & Organization
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 Manage Human Resource Ensure Compliance With External Standards Assess Risks Manage Projects Manage Quality Monitor Deliver & Support Monitor The Process Assess Internal Control Adequacy 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 Provide Independent Audit Educate & Train Users Assist & Advise IT Customers Manage Configuration Manage Problems & Incidents Manage Data Manage Facilities

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 Planning To Implement Service Management h T e h e
ITIL bøgerne T h e T e c h n o l o g y Planning To Implement Service Management T h e B u s i n Service Management Service Support The Business Perspective ICT Infrastructure Management Service Delivery Security Management Application Management

50 The Business, Customers or Users
Monitoring Tools Difficulties Queries Enquiries Communications Updates Work-arounds Incidents Incidents Service Desk Customer Survey reports 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 Change schedule CAB minutes Change statistics Change reviews Audit reports Release Management Release schedule Release statistics Release reviews Secure library’ Testing standards Audit reports Configuration Management CMDB reports CMDB statistics Policy standards Audit reports Problems Known Errors Cls Relationships Incidents Changes Releases CMDB

51 ITIL Service Support Model
ITIL Service Support Model Service Desk. To provide a strategic central point of contact for customers and an operational single point of contact for managing incidents to resolution. In addition, the Service Desk handles Service Requests. Incident Management. To restore normal service operation as quickly as possible and minimize the adverse impact on business operations. Problem Management. To minimize the adverse impact of incidents and problems on the business that are caused by errors in the IT Infrastructure and to prevent recurrence of incidents related to these errors. Change Management. To ensure that standardized methods and procedures are used for efficient and prompt handling of all changes to minimize the impact of change-related incidents and improve day-to-day operations. Release Management. Release Management takes a holistic view of a change to an IT service and should ensure that all aspects of a Release, both technical and non-technical, are considered together. Configuration Management. To identify, record and report on all IT components that are under the control and scope of Configuration Management.

52 Business, Customers and Users
Business, Customers and Users Queries Enquiries Communications Updates Reports Availability Management Service Level Management Availability plan AMDB Design criteria Targets/Thresholds Reports Audit reports Capacity Management Requirements Targets Achievements SLAs, SLRs OLAs Service reports Service catalogue SIP Exception reports Audit reports Capacity plan CDV Targets/thresholds Capacity reports Schedules Audit reports Financial Management For IT Services Financial plan Types and models Costs and charges Reports Budgets and forecasts Audit reports IT Service Continuity Management Alerts and Exceptions Changes IT continuity plans BIS and risk analysis Requirements def’n Control centers DR contracts Reports Audit reports Management Tools

53 ITIL Service Delivery Model
ITIL Service Delivery Model Service Level Management. To maintain and improve IT service quality through a constant cycle of agreeing, monitoring and reporting to meet the customers’ business objectives. Availability Management. To optimize the capability of the IT infrastructure, services and supporting organization to deliver a cost effective and sustained level of availability enabling the business to meet their objectives. Capacity Management. To ensure that all the current and future capacity and performance aspects of the business requirements are provided cost effectively. Financial Management. To provide cost-effective stewardship of the IT assets and resources used in providing IT services. Continuity Management. To ensure that the required IT technical and services facilities can be recovered within required, and agreed timescales. IT Service Continuity Planning. IT Service Continuity Planning is a systematic approach to create a plan and/or procedures to prevent, cope with and recover from the loss of critical services for extended periods.

54 Så hvad er ITIL Aligning IT services with business requirements
Så hvad er ITIL Aligning IT services with business requirements A set of best practices, not a methodology Providing guidance, not a step-by-step, how-to manual; the implementation of ITIL processes will vary from organization to organization A non-proprietary, vendor-neutral, technology-agnostic set of best practices.