IT arkitektur & sikkerhed

Præsentationer af emnet: "IT arkitektur & sikkerhed"— Præsentationens transcript:

1 IT arkitektur & sikkerhed
IT arkitektur i praksis Lektion 5

2 Sidste uge I sidste uge gennemgik vi Vi har derudover arbejdet med
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) Måling af effektiviteten af struktureret IT arkitektur tilgang

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 Forces model kan benyttes til analysere markedssituationen

9 Forretningsarkitektur
Analyze Current State Business Data Value Chain Analysis model 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 Matrix m.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 Data Function Locations People Time Motivation
Principles Models Eg. Logical Data Models, Physical Data Models Eg. Application Architecture, System Design Eg. Distributed System Architecture, Technology Architecture Eg. Human Interface Architecture, Presentation Architecture Eg. Process Structure, Control Structure Eg. Business Rule Model, Rule Design Inventory Standards

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

19 IT arkitektur Eksempler Statement
Overall the it architecture will be service orientated, meaning that systems and components within it will be viewed as a set of independent and reusable services that can be composed to provide a solution for the company Rationale Utilizing a service orientated architecture framework provides rapid and low-cost system development, improved quality, as well as greater system reusability. Service orientated architecture is to be considered an architecture approach, rather than a technology dictate, 19. service orientated architecture does not equal the use of web services exclusively given the inherent problems with response time, support of event-driven, asynchronous parallel applications and so on in web services technologies. Implications The banks service orientated architecture follows the OASIS SOA Reference Model (SOA-RM) Services will be divided into two groups; business and technical services. All services will have a owner either in business or in it Services will be decomposed to the smallest reusable unit while remaining usable, and understandable and usable by the owner. The services will be as autonomous as possible The bank will ensure full services lifecycle management - this include services being discoverable, services being versioned, services being contractible , and services being retired when appropriate

20 IT arkitektur Eksempler Statement
Overall the it architecture will be based on open industry standards Rationale Systems which are compliant with industry standards will be the most likely to be easily integrated with new systems over time Industry standards are most likely to be supported by tools and training Industry standards provide a higher level of robustness and stability than proprietary and custom developed approaches Industry standard approaches save time and energy, as well as training and support costs Implications Where industry standards exist, one must be chosen and followed Interoperability between competing standards should be considered, but internal development focuses on one standard The It architect will a maintain repository of industry standards to be used in the bank now, evolving, as well as roadmap for standards being retired.

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å level 0

24 IT arkitektur Model Current State IT Regel 4 - Eksempel på level 1

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 Scope projects & describe (SOW)
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 whitepaper – ”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 Logical view Development view Scenarios Process View
End user Logical view Development view Programmers & software managers Scenarios Process View Physical View The architecture in fact partially evolved from these scenarios as well as The model is rather generic, and other notations and tools can be used, other design methods can be used especially for the logical and process decompositions For each view, the architects can pick a certain architectural style Similar views in UML Use case view> - Encompass the use cases that describe the behavior of the system as seen by its end users, analysts, and testers Design view - Encompass the classes, interfaces, and collaborations that form the vocabulary of the problem and its solution Process view - Encompass the threads and processes that form the system's concurrency and synchronization mechanisms Implementation view - Encompass the components and files that are used to assemble and release the physical system Deployment view - Encompass the nodes that form the system's hardware topology on which the system executes System Engineer Integrator

33 4+1 View Model Logical View Process 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 Physical 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
Incremental eller Iterativ design 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 Requirements analysis Architectural design Stage 1: design, code, test, deliver Some projects are suited to more detailed architectural design and Staged Delivery Stage 2: design, code, test, deliver Stage N: design, code, test, deliver

38 Arkitektur-dreven design
Software concept Complete and release prototype Design and implement initial prototype Refine prototype Other projects tend towards less (or no…) architectural design and Evolutionary Prototyping 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 (approach) Preparation (elapsed time 20d) Business track
Interview project leader Interview business representatives Prepare quality attribute tree Prepare scenario brainstorm Architecture track Interview architect Interview lead developers Prepare example architecture documentation Identify approaches Analysis

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

42 ATAM – Cost/Benefit Cost
1 – 2 weeks of time for 8 – 10 highly paid people, 2 days for another 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

43 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 Present results Phase 3 Analyze cost / benefit of ATAM  CBAM

44 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 Repeat the last steps of phase 1 In a broader forum…

45 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 Evaluation team begins probing for and capturing risks. Repeat the last steps of phase 1 In a broader forum…

46 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 Repeat the last steps of phase 1 In a broader forum…

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

48 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

49 Analyze Architectural Approaches
Decide architectural approach for each scenario

50 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

51 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

52 Risks & Non-Risks Risk Non Risk
The decision to keep backup is a risk if the performance cost is excessive Rules for writing business logic modules in the second tier of your 3-tier style are not clearly articulated. This could result in replication of functionality thereby compromising modifiability of the third tier. Non Risk The decision to keep backup is a non-risk if the performance cost is not excessive Assuming message arrival rates of once per second, a processing time of less than 30 ms, and the existence of one higher priority process, a 1 second soft deadline seems reasonable Performance.

53 Brainstorm & Prioritize Scenarios
Stakeholders evaluate scenarios using a facilitated brainstorming process. Additional scenarios can appear and can be added to the quality attribute utility tree. Each stakeholder is allocated a number of votes and will vote to prioritize the scenarios

54 Analyze Architectural Approaches
Identify the architectural approaches impacted by the scenarios generated in the previous step – new architectural may be needed for new scenarios. Continue identifying sensitivity and tradeoffs Continue identifying risks and non-risks. Continue annotating architectural information.

55 Present ATAM results Architectural approaches Utility tree Scenarios
Risks and “non-risks” Sensitivity points and tradeoffs

56 CBAM 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

57 CBAM steps Step 1: Collate scenarios (N)
From ATAM and new scenarios Prioritize the scenarios based on satisfying the business goals and choose the top one-third Step 2: Refine scenarios (N/3) Determine quality attribute response levels for best, worst, current and desired cases of the scenario Step 3: Prioritize the scenarios (N/3) Allocate 100 votes to each stakeholder and have them distribute among the scenarios Total the votes and choose top 50% of the scenarios Assign weights Step 4: Assign utility (N/6) Determine the utility for the best, worst, current and desired levels for each scenario (N/6)

58 CBAM steps Step 5: Develop architectural strategies
Strategies for scenarios and determine quality attribute response levels Step 6: Determine the expected utility value Step 7: Calculate total benefit Expected level – Current level Sum across all scenarios Step 8: Choose architectural strategies Calculate ROI Step 9: Confirm results with intuition