IT Arkitektur og Sikkerhed Enterprise Arkitektur

Sidste uge I sidste uge gennemgik vi SOA teori 2

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

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

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

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

Sikre at IT understøtter Forretningen 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

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

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.

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

Arkitektur Principper Eksempler på Arkitektur Principper indenfor forretningsarkitekturen

Arkitektur Principper Eksempler på Arkitektur Principper indenfor applikationsarkitekturen

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

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

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

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

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

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

Eksempel på Standards Information Base

Eksempel på Standards Information Base Demo af http://standarder.oio.dk/Dansk/

Pause

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

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 Projekt A Design Udvikling Test Udrulning Forvaltning Arkitektur Kontrakt Arkitektur Review “dørstopper” Arkitektur Review “dørstopper” Arkitektur Review “dørstopper” Arkitektur Review “dørstopper”

TOGAF v8.1.1 Resources

EA klassifikation 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) 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)

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

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

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.

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.

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.

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.

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

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)

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 ?

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

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.

Eksempler fra virkeligheden; OIO

Eksempler fra virkeligheden; OIO

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.

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

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

Modellering Det findes mange modelleringsværktøjer Planlægger Designer 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

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

UML eksempler (Use case)

UML eksempler (Sequence)

UML eksempler (Deployment)

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

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

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.

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

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

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

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

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

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

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 47

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

ITIL bøgerne T Planning To Implement Service Management h T e 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 49

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 50

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

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 52

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

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

Strategy Technology Business EA = S + B + T 66 66

”Complete” EA Approach A “complete” EA approach must have all of these elements, which are specifically designed to work together in the context of the governance process. EA Framework Artifacts Best Practices Methodology EA Tools & Repository Governance Carnegie Mellon University

Scott Bernard's EA3 Cube S + B T EA Methodology EA EA Best Practices • Strategic Level – Strategic Plan Future Operating Scenarios Balanced Scorecard ™ Goals and Measures Business Level Business Plan (E - Commerce Plan / E Government Plan)‏ Business Requirements Use Cases Business Case Investment Portfolio Business Process Management Applications Business Process Reengineering / Improvement Technology Level Service Oriented Architecture Object Oriented Data Modeling/Application Development Network Centric Systems Engineering Enterprise Resource Planning Systems Network Management Applications Security Architecture S + B T EA Methodology Network Infrastructure Networks & Systems & Applications Data & Information Products & Services Goals & Initiatives Lines of Business C O M P N E T S Security, Standards, Workforce Technology – Business - Strategy EA EA Best Practices Artifacts Detailed View Mid Level High Current EA Views Enterprise Architecture Repository Performance Measures Strategic Plan Goals & Initiatives Investment Portfolio Business Processes Data Dictionary Knowledge Warehouse Information Flows Application Inventory Systems Support Buildings & Equipment Wide Area Network Local Area Privacy Security Program System Certifications Goals & Initiatives Products & Services Data & Systems & Applications Networks & Infrastructure Solutions Site Map EA Tutorial EA Program Future EA Views EA Standards EA Management Plan EA Tools & Repository

By the book? bogmos.dk

Doucet, Gøtze, Saha, Bernard (forthcoming) www.coherencymanagement.org Coherency Management - Architecting the Enterprise for Alignment, Agility, and Assurance Doucet, Gøtze, Saha, Bernard (forthcoming) www.coherencymanagement.org

Ross, Weill & Robertson: “Enterprise Architecture as Strategy” NB: Peter Weill gæsteforelæsning på ITU 25/2 kl 17-19, Aud 2

Journals www.aeajournal.org ’pracademic’ journal Ikke-videnskabelige tidsskrifter mv, f.eks. www.architectureandgovernance.com Relaterede videnskabelig journals, eg MISQ, HBR

Foreninger aEAassociation.org aogea.org (Open Group) geao.org aEAdanmark.dk aogea.org (Open Group) geao.org

Konferencer Danmark London, 8-10 juni 2009 Dansk Its EA09 (ca oktober 09) VTU/ITSTs It-arkitekturkonference, 1-2 april 2009 London, 8-10 juni 2009 + 5-10 konferencer worldwide

Om John Gøtze http://gotze.eu http://www.enterprisearchitecture.dk http://www.eafellows.com Twitter.com/gotze

Gruppeopgaver :-)