IT Arkitektur og Sikkerhed Enterprise Arkitektur.

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

1 IT Arkitektur og Sikkerhed Enterprise Arkitektur

2 Sidste uge I sidste uge gennemgik vi SOA teori 2

3 I denne uge gennemgår vi Introduktion til Enterprise Arkitektur (EA) EA proces EA klassifikation og modellering Arkitektur Cost/Benefit (ATAM & CBAM) 3 Dagsorden

4 Næste uge I næste uge gennemgår vi Kryptering og Enterprise sikkerhedsmodeller 4

5 Enterprise Arkitektur Nuværende situationFremtidig situation Forretningsprocesser, IT, Organisation, Personale “GAP” Virksomhedens struktur

6 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 5

7 EA Formålet med EA er Sikre at IT understøtter Forretningen Sikre identificering af nødvendige ændringer Sikre overblik over konsekvenser ved ændringer Sikre simplificering, og undgå duplikering Sikre hurtig omstilling 10

8 EA EA involverer Processer til brug for etablering og vedligeholdelse af arkitekturen Klassificering og modellering af alle artefakter i arkitekturen 11

9 TOGAF The Open Group Architecture Framework (TOGAF) er et rammeværk for etablering af Enterprise Arkitektur. TOGAF omfatter Design Planlægning Implementering Styring (governance) TOGAF er udviklet af Architecture Forum i The Open Group og er udviklet siden midten af 90'erne. Seneste version er 8.1.1 Enterprise Edition.

10 Arkitektur Principper Arkitektur principper er det generelle regelsæt for arkitektur i virksomheden, og er evigt gældende. Arkitektur principper opbygges på følgende måde

11 Arkitektur Principper Eksempler på Arkitektur Principper indenfor forretningsarkitekturen

12 Arkitektur Principper Eksempler på Arkitektur Principper indenfor applikationsarkitekturen

13 ADM “hjulet” A – Architecture Vision Identificer forretningsmål og -krav Identificer interessenter Definer prioriteter B – Business Architecture Identificer nuværende arkitektur Definer mål arkitektur Identificer gaps Identificer genbrug C – Information System Architecturee Identificer nuværende arkitektur Definer mål arkitektur Identificer gaps Identificer genbrug

14 ADM “hjulet” D - Technology architecture Identificer nuværende arkitektur Definer mål arkitektur Identificer gaps Identificer genbrug E – Opportunities & solutions Analyser gaps i mål arkitektur Cost/Benefit Prioriter og definer roadmap Udform projekt portfolio

15 ADM “hjulet” F - Migration Planning Identificer konsekvenserne af roadmap for andre aktiviteter Identificer konsekvenserne af roadmap på organisation G – Implementation Governance Definer arkitektur kontrakter for hvert projekt i projekt portfolio Udfør arkitektur reviews for at sikre opfyldelse af arkitektur kontrakter H – Architecture Change Management Identificer konsekvenser af arkitektur ændringer

16 TOGAF 8.1.1 formelt TOGAF v8.1.1 består af fire dele PART I: Introduktion PART II: Architecture Development Method (ADM) (*) PART III: Enterprise Continuum PART IV: Resources (*) Som vi netop har gået igennem

17 Referencer Arkitektur I sidste uge berørte vi reference modeller og arkitekturer. TOGAF indeholder også reference arkitekturer i Enterprise Continuum.

18 TOGAF v8.1.1 Part III Enterprise Continuum Foundation Architecture TRM (Technical Reference Model) reference arkitektur bestående af modeller og taxonomi. SIB (Standards Information Base) standarder og definitioner i brug

19 Eksempel på Standards Information Base

20 Demo af http://standarder.oio.dk/Dansk/http://standarder.oio.dk/Dansk/

21 Pause

22 TOGAF v8.1.1 Resources TOGAF lægger vægt på at hvis der skal ske i succesfuld styring af arkitektur i en virksomhed at der etableres et eller flere arkitektur forum Arkitektur forum er et tværgående gruppe med deltagelse af repræsentanter for alle interessenter i organisationen Arkitektur forum har ansvar for Konsistens og sammenhæng mellem sub-arkitekturer/projekter Identificering af komponenter der kan genbruges Modne arkitektur diciplinen i virksomheden Håndtere eskalationer relateret arkitektur problemstillinger mellem afdelinger/systemer/projekter

23 TOGAF v8.1.1 Resources Arkitektur forum har også ansvar for Architecture Governance selvom det ikke er der forum der selv udfører opgaverne Der indgås arkitektur kontrakt ved opstart af projekter enten som en del af almindelig Statement Of Work / Project Management Plan, eller som et særskilt dokument Der udføres “dør stopper” arkitektur reviews i løbet af projektets levetid DesignUdviklingTestUdrulningForvaltning Projekt A Arkitektur Review “dørstopper” Arkitektur Review “dørstopper” Arkitektur Review “dørstopper” Arkitektur Review “dørstopper”Arkitektur Kontrakt

24 TOGAF v8.1.1 Resources

25 John Zachman - The Zachman Framework Født i Toledo, Ohio, December 12, 1934 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: www.zifa.com)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)www.zifa.com EA klassifikation

26 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 Zachman’s klassifikation

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

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

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

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

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

32 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).

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

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

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

36 23

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

38 Eksempler fra virkeligheden; OIO

39

40 TOGAF 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.

41 ADM og Zachman’s klassifikationssystem Pre-lim Architecture Vision Business Architecture IS Architecture Dataarkitektur IS Architecture Applikationsarkitektur

42 IEEE 1471:2000 (ISO/IEC 42010:2007) ANSI/IEEE Std 1471, Recommended Practice for Architectural Description of Software-intensive Systems

43 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 SysML - er et formsprog til at specificere, konstruere og dokumentere systemer. SysML er en videreudvikling af UML. Entreprenør og Underleverandør UML, Dataflow Diagrams, Logical Datamodels, System Area Maps, System Architecture Diagrams UML, Physical Datamodels, Network Concepts Diagrams

44 UML Unified Modeling Language (UML) 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) UML indeholder 14 forskellige diagram typer For mere information om UML henvises til Martin Fowler, UML Destilled (Ikke Pensum) 26

45 UML eksempler (Use case)

46 UML eksempler (Sequence)

47 UML eksempler (Deployment)

48 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) www.zifa.com Enterprise Architecture Artifacts Vs. Application Definition Artefacts (kilde www.zifa.com ZIFA 05)www.zifa.com Det kan anbefales at tjekke Agile Modelling hjemmesiden for yderligere information om modellering http://www.agilemodeling.com http://www.agilemodeling.com

49 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

50 Arkitektur Cost/Benefit (Tekniske Tradeoffs) Architecture Tradeoff Assessment Model (ATAM) The ATAM is intended to analyze an architecture with respect to its quality attributes (non- functional), not its functional correctness. The ATAM involves a wide group of stakeholders (including managers, developers, maintainers, testers, reusers, end users, and customers) in an effort to surface the relevant stakeholders’ quality goals for the system. The ATAM is a method for mitigating architecture risk, a means of detecting areas of potential risk within the architecture of a complex software-intensive system, and not a precise mathematical analysis. As such, the ATAM can be done early in the software development life cycle, and it can be done inexpensively and quickly.

51 Arkitektur Cost/Benefit (Økonomiske Tradeoffs) Cost/Benefit Analysis Method (CBAM) The CBAM – Cost Benefit Analysis Method – builds on ATAM, as exemplified by the cubes labelled P, A, S, and M, in the figure below (representing Performance, Availability, Security, and Modifiability respectively). These quality attribute decisions (and there may be many others, for other qualities) result in some benefit to the system's stakeholders. The CBAM guides system engineers and other stakeholders to determine the costs and benefits associated with the architectural decisions that result in the system's qualities. Given this information, the stakeholders can then reflect upon and choose among the potential architectural decisions

52 Gruppeopgaver :-)

53 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. 33

54 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) 43

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

56 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. 45

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

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

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

60 ITIL bøgerne 49 Planning To Implement Service Management Service Management Service Support Service Delivery TheBusinessTheBusiness The Business Perspective Application Management ICT Infrastructure Management TheTechnologyTheTechnology Security Management

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

62 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. 51

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

64 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. 53

65 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. 54