IT arkitektur & sikkerhed

1. IT arkitektur & sikkerhed IT arkitektur i praksis Lektion 5 Version 1.01

2. Sidste uge • I sidste uge gennemgik vi • Enterprise Arkitektur • Vi har derudover arbejdet med • Grundbegreber – Netværk og Computere • IT infrastruktur • SOA

3. Denne uge • I denne uge gennemgår vi • IT arkitektur i praksis • Forretningsarkitektur • IT arkitektur • IT arkitektur-dreven design • IT arkitektur cost/benefit (ATAM & CBAM)

4. Næste uge • I næste uge arbejder vi i grupper med en case som skal præsenteres i plenum • I dag udvælger I én virksomhed og ét system I vil arbejde med • For virksomheden udarbejder I • Fungerende arkitektur principper som adresserer Data, Function, Locations, People, Time, Motivation – Præsenter Arkitektur Principper • Definer hvilke typer modeller der skal benyttes I jeres virksomhed på niveau 0, 1, og N til at beskrive IT – samt bestem hvor mange niveau N I skal have. Udarbejd en model på niveau 0 for target state i jeres virksomhed (forklar hvorfor denne target state).Præsenter niveau 0 target state • Beskriv en række forretningskrav til jeres valgte system - beskriv det overordnede design – Præsenter System • Gennemfør ATAM workshop for jeres system design – Præsenter resultaterne fra ATAM workshop

5. Forretningsarkitektur Collect Current State Data Analyze Current State Data Analyze Gaps and Opportunities Target State Business Collect Business Target State Identify Projects

6. Forretningsarkitektur

7. Forretningsarkitektur • Collect Current State Business Data • Indsamling af forretningsstrategi dokumenter • Vision/Mission • Strategiske og operationelle forretningsplaner • Nøgle forretnings- og programinitiativer • Interviews med forretningsledere om prioriteter mm. for virksomheden • Identificer væsentlige ændringer i virksomheden og lessons learned fra disse ændringer • Identificer væsentlige forretningsdrivere og markedsvilkår som påvirker virksomheden • Identificer væsentlige begrænsninger; love, regler, tilsyn, strukturelle m.v. • Yderligere basal information

8. Forretningsarkitektur • Analyze Current State Business Data • PEST (Political, Economic, Socio-cultural, and Technological) model kan benyttes til at analysere makro forhold der påvirker virksomheden • SWOT(Strengths, Weakness, Opportunity, Threats) strategisk model kan benyttes til at vurdere virksomhedens strategi • Porter’s Five Forcesmodel kan benyttes til analysere markedssituationen

9. Forretningsarkitektur • Analyze Current State Business Data • Value Chain Analysismodel kan benyttes til at analysere virksomhedens primære og sekundære aktiviteter • Ansoff model kan benyttes til at analysere virksomhedens produkt mix • Boston Growth-share matrix (cash cows and dogs), Mckinsey Matrixm.fl. • Alle modeller er inkl. i Strategisk Planlægning og Analyse i gængse MBA programmer

10. Forretningsarkitektur • Analyze Target State • Target Operating Models / Enterprise Models • Domain Models

11. Forretningsarkitektur • TMFforum eTOM - overview TMFforum The eTOM Business Process Framework is known around the world for the common vocabulary it establishes for both business and functional processes. By mapping processes in language that all facets of an organization understand, the Framework helps to identify and prioritize which operational areas are most critical to business objectives

12. Forretningsarkitektur • TMFforum eTOM – drill down

13. Forretningsarkitektur • Andre Target Operating Models / Enterprise Models • IFW (Information Framework) • ITIL (Information Technology Infrastructure Library) • Øvrige leverandør og branche drevne TOM’ere

14. Forretningsarkitektur • Analyze Gaps and Opportunities • Omfatter den nødvendige gap-analyse for at detaljere nye og ændrede forretningsfunktioner og -processer

15. IT arkitektur Collect Business Current State Data Translate Business Target State to Principles Model Current State IT (level 0-N) Create Current State Inventory/Standards Target State Arch. Repository Model Target State IT (level 0-N) Create Target State Inventory/Standards Identify Projects

16. IT arkitektur

17. IT arkitektur

18. IT arkitektur • Vi gennemgik strukturen af Architecture Principles sidste uge; principperne skal grupperes under Data, Function, Locations, m.v.

19. IT arkitektur • Eksempler

20. IT arkitektur • Eksempler

21. IT arkitektur • Model Current State IT • God praksis for modellering • Regel 1: Bestem standard komponenter • Software Applications • Service Components; ESB, ETL, BPM, BAM, m.v. • Enterprise Ressource Planning (ERP) Applications • Operating Systems & Databases • Regel 2: Bestem standard notation • Regel 3: Bestem omfang og afgrænsninger

22. IT arkitektur • Model Current State IT • God praksis for modellering • Regel 4: Bestem detaljeringsniveau • Niveau 0: F.eks. 1-sides konceptuel model der viser nøgle komponenterne og deres indbyrdes sammenhæng. Denne model er typisk brugt til at kommunikere basale koncepter til forretningen • Niveau 1: F.eks. En mere model der beskriver dele af niveau 0 modellen i større detalje. Denne model er typisk brugt til at kommunikere retning for forretning og IT • Niveau N1, N2, N3: Mere detaljerede modeller som benyttes til at kommunikere til systemudvikling og –implementering. Disse modeller er typisk brugt af systemudviklere til at oversætte arkitektur til system krav og –design • Præsentation: Executive Presentation på endnu højere niveau end niveau 0 til brug for kommunikation med senior ledelse Hvert niveau kan være yderligere opdelt jf. Zachman’s aspekter og perspektiver

23. IT arkitektur • Model Current State IT • Regel 4 - Eksempel på Præsentationsniveau

24. IT arkitektur • Model Current State IT • Regel 4 - Eksempel på level 0

25. IT arkitektur • Model Current State IT • God praksis for modellering • Regel 5: Bestem state for modelleringen • Current State (as-is) • Target State (to-be eller nirvana) • End-of-year State (to-be for 1-år eller under) • Andre • Regel 6: bestem miljøer • Eksekveringsmiljø / runtime miljø. Det miljø som virksomhedens produktionsapparat er lokaliseret i • Udviklingsmiljø / test miljø. Det miljø der understøtter systemudvikling og –implementering • Operationsmiljø. Det miljø som benyttes til at styre og kontrollere virksomhedens eksekveringsmiljø / runtime miljø, samt udviklingsmiljø / test miljø (sikkerhed, overvågning, backup/restore mv.)

26. IT arkitektur • Model Current State IT • Overvejelser om Current State IT • I hvilket omfang kan eksisterende komponenter og systemer bliver genbrugt • Hvordan ser teknologi roadmap ud for de enkelte komponenter og systemer • Hvad er kvaliteten af de enkelte komponenter og systemer • Hvor tæt er de enkelte komponenter og systemer koblede • Hvor hurtigt kan vi ændre på komponenter og systemer • O.s.v.

27. IT arkitektur • Model Target State IT • Target State IT modelleres på baggrund af forretningsarkitekturen, og på baggrund af samme regler som specificeret under Current State IT.

28. IT arkitektur • IT Inventory (ITIL CMDB) • Metadata inventory – data der beskriver data – kan også omfatte ontologi, taxonomi, m.v. • Data inventory • Application inventory • Communication/Interface inventory • Platform inventory • People/Process inventory

29. IT arkitektur

30. IT arkitektur Select and prioritize projects Scope projects & describe (SOW) Define drivers, requirements, metrics, etc Identify Projects Arch. Repository

31. Arkitektur-dreven design • Der findes en lang række metoder til software design – for en IT arkitekts synsvinkel er det enormt vigtigt at valget af metode inkludere både en • Funktionel Synsvinkel • Non-funktionel Synsvinkel Jeg har lagt whitepapers på hjemmesiden – • ”A Practical Example og Applying Attribute-Driven Design (ADD)”, version 2.0 på hjemmesiden. Dette dokument vil være en del af pensum og beskriver en metode udviklet af Bass, Bachmann, Kazman for Carnegie-Mellon University • “Architectural Blueprints—The “4+1” View Model of Software Architecture” på hjemmesiden. Dette dokument vil være en del af pensum og beskrive en metode udviklet af Krutchen for Rational Software

32. 4+1 View Model End user Logical view Development view Programmers & software managers Scenarios Process View Physical View System Engineer Integrator

33. 4+1 View Model • Logical View • Viewer: End-user • Considers: Functional requirements - What the system should provide in terms of services to its users. • Style: UML Class Diagram, UML Communication diagram, UML Sequence diagram • Tool: Rational Rose among others • Process View • Viewer: Integrators • Considers: Non - functional requirements (concurrency, performance, scalability) • Style: UML Activity Diagram, UML Timing Diagram and others on multiple levels of abstractions

34. 4+1 View Model • Development View • Viewer: Software Managers, Configuration Managers, Programmers • Considers: Software module organization (Hierarchy of layers, software management, reuse, constraints of tools) • Style: UML Package Diagram • Physical View • Viewer: System Engineers, Support Staff • Considers: Non-functional req. regarding to underlying hardware (Topology, Communication) • Style: UML Deployment Diagram

35. 4+1 View Model • Scenarios • Viewer: All users of other views and Evaluators • Considers: System consistency, validity • Style: UML Use Cases and others

36. Arkitektur-dreven design • Incrementaleller Iterativdesign egner sig specielt godt som basis for Arkitektur-dreven design, pg.a. • Høj synlighed af løsningen under udviklingsprocessen • Høj grad af mulighed for tilpasning baseret på øget forståelse af løsningen • Lav risiko

37. Arkitektur-dreven design Software concept • Some projects are suited to more detailed architectural design and Staged Delivery Requirements analysis Architectural design Stage 1: design, code, test, deliver Stage 2: design, code, test, deliver Stage N: design, code, test, deliver

38. Arkitektur-dreven design • Other projects tend towards less (or no…) architectural design and Evolutionary Prototyping Software concept Complete and release prototype Design and implement initial prototype Refine prototype Elicit customer feedback

39. ATAM • 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, 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.

40. ATAM - Vocabulary • Scenario – A scenario is a short statement describing an interaction of one of the stakeholders with the system • Stakeholder – An individual, team, or organization (or classes thereof) with interests in, or concerns relative to, a system • Architectural view – A representation of a whole system from the perspective of a related set of concerns • Functional requirements - specify what software has to do. • Non-functional requirements specify how well it should be done.

41. ATAM – Cost/Benefit • Cost • 1 – 2 weeks of time for 8 – 10 highly paid people, 2 days for another 10-12 people (for full formal process!) • Delays project start • Forces development of architecture up front • Benefit • Financial – saves money • Forces preparation / documentation / understanding • Captures rationale • Catch architectural errors before built • Make sure architecture meets scenarios • More general, flexible architecture • Reduces risk

42. ATAM Steps • Phase 1 – evaluators and decision makers • Present • ATAM • Business drivers • Architecture • Identify architectural approaches • Generate quality attribute utility tree • Analyze architectural approaches • Phase 2 – add stakeholders • Brainstorm and prioritize scenarios • Analyze architectural approaches • Present results • Phase 3 • Analyze cost / benefit of ATAM  CBAM

43. Present ATAM • Evaluation Team presents an overview of the ATAM in brief • Techniques • Utility tree generation • Architecture analysis • Scenario brainstorming/mapping • ATAM customer representative describes the system’s business drivers • Business context for the system • High-level functional requirements • High-level quality attribute requirements • Architectural drivers: quality attributes that “shape” the architecture • Critical requirements: quality attributes most central to the system’s success

44. Present ATAM • Architect presents an overview of the architecture including • Technical constraints such as an OS, hardware, or middle-ware prescribed for use • Other systems with which the system must interact • Architectural approaches/styles used to address quality attribute requirements

45. Identify Architectural Approaches • Start to identify places in the architecture that are key for realizing quality attribute goals • Identify any predominant architectural approaches – for example: • client-server • 3-tier • proxy • publish-subscribe • redundant hardware

46. Generate quality attribute utility tree • Identify, prioritize, and refine the most important quality attribute goals by building a utility tree • A utility tree is a top-down vehicle for characterizing the “driving” attribute-specific requirements • Select the most important quality goals to be the high-level nodes (typically performance, modifiability, security, and availability)

47. Generate quality attribute utility tree • Scenarios are used to • Represent stakeholders’ interests • Understand quality attribute requirements • Scenarios should cover a range of • Anticipated uses of (use case scenarios), • Anticipated changes to (growth scenarios), or • Unanticipated stresses (exploratory scenarios) to the system. • A good scenario makes clear what the stimulus is that causes it, and what responses are of interest • Use case scenario - Remote user requests a database report via the Web during peak period and receives it within 5 seconds. • Growth scenario - Add a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week. • Exploratory scenario - Half of the servers go down during normal operation without affecting overall system availability. • Scenario’s are typically the leaves on the utility tree

48. Analyze Architectural Approaches • Analyze architectural approach for each scenario

49. Analyze Architectural Approaches • Evaluation Team probes architectural approaches from the point of view of specific quality attributes to identify risks • Identify the approaches that pertain to the highest priority quality attribute requirements • Generate quality-attribute specific questions for highest priority quality attribute requirement Examples • Performance • How are priorities assigned to processes? • What are the message arrival rates? • What are transaction processing times? • Modifiability • Are there any places where layers/facades are circumvented ? • What components rely on detailed knowledge of message formats? • What components are connected asynchronously? • Ask quality-attribute specific questions • Identify and record risks and non-risks, sensitivity points and tradeoffs

50. Sensitivity & Tradeoffs • Sensitivity – A property of a component that is critical to success of system • The number of simultaneous database clients will affect the number of transaction a database can process per second. This assignment is a sensitivity point for the performance • Keeping a backup database affects reliability • Power of encryption (Security) sensitive to number of bits of the key • Tradeoff point- A property that affects more than one attribute or sensitivity point. • In order to achieve the required level of performance in the discrete event generation component, assembly language had to be used thereby reducing the portability of this component. • Keeping the backup database affects performance also so it’s a trade-off between reliability and performance