Software Life-Cycle Management

Transcription

1 Ingo Arnold Department Computer Science University of Basel Introduction Software Life-Cycle Management IT Governance and Process Overview Lecture Introduction

2 IT Business The Problem Complexity Complex system of forces spans the environment within which IT finds itself positioned today Patients Challenges External Touch Points Innovation Pharma Projects Divisions & BUs Regions & Locations Associates & Externals Programs & Projects Applications IT Platforms Network & Messaging Data Centers Sourcing & Partners >1.1 billion patients served around the world Globalization, Consumerizm, new medical & technological treatments, expensive diseases, aging, overweight Patients, whole-salers, hospitals, physicians, interest groups, states >16% of net sales as innovation fund / year Industry leading pipeline with >130 projects in ph clinical dev. And 15 major ph approvals per year NI, PH, NIBR, SDZ, ALCON, OTC, VD, GIS Global player, >140 countries, >350 sites >124k associates, >150k external partners, contractors, consultants 250+ IT-projects and -programs/ year, >650 project portfolio / year 4+k applications, most of the world s key application platforms and frameworks 800 IT platforms and frameworks 150k mailboxes, 120k network devices, 350k network points, 1.5 Mio incoming mails/day 40+ DCs, 350 supported sites, 1.5 terra bytes external traffic Department of Computer Sciences University of Basel 2 Multi-national, global outsourcing, off-shoring and services partners / sourcing models world-wide

3 The Problem Organizational Structure Novartis organization structure is federated. Divisions have their own IT organizations, where GIS provides x-divisional services Department of Computer Sciences University of Basel 3

4 The Problem Diverging Objectives The Corporate IT dilemma: Continuously evolving business models and innovations in the health environment require very flexible & adaptable IT solutions while at the same time cost pressure increases CEO Functionality New functionality New services New operating models Legacy Outsourcing Offshoring Efficiency & Productivity CIO Corporate IT Cost CFO Technological Change Pace of change Change adaption Scale effects Department of Computer Sciences University of Basel 4

5 functionality (t) The Problem Evolution Focus on functional growth and contribution to business value led to a complexity problem from an evolutionary perspective functionality (t) 0 system system interconnection interconnected systems form new systems Department of Computer Sciences University of Basel 5 t

6 agility The Problem Functionality versus Quality Quality attributes of big information systems (e.g. agility) compete with these systems functional growth (1) C 1 C 1 := loss of agility is worth 5 times an increase in functional value C 2 := loss of agility already outweighs functional gains G A := gap of agility between desired and actual system end state G F := gap of functionality between desired and actual system end state change -projects of equal size desired system end state G A C 2 C 1 C 2 system end state functionality G Department F of Computer Sciences University of Basel 6 (1) Managed Evolution, Springer, Stephan Murer et al, Zürich 2010

7 The Problem Functionality versus Quality The Corporate IT dilemma resolved: Architecture enables Quality, Agility and Transparancy for Corporate IT CIO Functionality Quality, Agility CIO Legacy Corporate IT Transparency Technological Change Cost CFO Department of Computer Sciences University of Basel 7

8 agility The Solution IT Governance Framework The solution to Corporate IT dilemma is to manage a «big system s» evolution. Question remains: how to govern and manage evolution?? desired system end state accepted evolution channel change -projects of equal size functionality Department of Computer Sciences University of Basel 8

9 The Solution IT Governance Framework Do the right thing Do the thing right Run it right Plan Build Run Q&C PPM APM EA/DA ICE CM PM CP SM Decision Excellence SA PM BA IM Project Excellence Operational Excellence EA/DA = Enterprise & Domain Architecture PPM = Project Portfolio Management APM = Application Portfolio Management Q&C = Quality & Compliance CM = Change Management PM = Problem Management CP = Capacity Planning SM = Service Management Department of Computer Sciences University of Basel 9

10 The Solution IT Governance Framework (Industry Frameworks) Do the right thing Do the thing right Run it right Plan Build Run Q&C PPM APM EA/DA ICE CM PM CP SM Decision Excellence SA PM BA IM Project Excellence Operational Excellence TOGAF (Rational) Unified Process ITIL EA/DA = Enterprise & Domain Architecture PPM = Project Portfolio Management APM = Application Portfolio Management Q&C = Quality & Compliance CM = Change Management PM = Problem Management CP = Capacity Planning SM = Service Management Department of Computer Sciences University of Basel 10

11 The Solution IT Governance Framework Plan Build Run Q&C PPM APM EA/DA CM PM CP SM SA PM BA IM Decision Excellence Project Excellence Operational Excellence EA/DA = Enterprise & Domain Architecture PPM = Project Portfolio Management APM = Application Portfolio Management Q&C = Quality & Compliance CM = Change Management PM = Problem Management CP = Capacity Planning PM = Project Management SM = Service Management BA = Business Analysis SA = Solution Architecture IM = Implementation Department of Computer Sciences University of Basel 11

12 agility The Solution IT Governance Framework applied Combining governance disciplines is key to manage the evolution of «big systems» holistically Architecture is a crucial discipline desired system end state accepted evolution channel change -projects of equal size functionality Department of Computer Sciences University of Basel 12

13 The Solution Multiple-disciplinary Governance Plan Build Run Q&C PPM APM EA/DA CM PM CP SM SA PM BA IM EA/DA = Enterprise & Domain Architecture PPM = Project Portfolio Management APM = Application Portfolio Management Q&C = Quality & Compliance CM = Change Management PM = Problem Management CP = Capacity Planning PM = Project Management SM = Service Management BA = Business Analysis SA = Solution Architecture IM = Implementation Department of Computer Sciences University of Basel 13

14 The Solution Enterprise versus Domain versus Solution Architecture Solution Architecture is concerned with ONE single system is a change/solution/project discipline focusses primarily this system s internal structure adresses external interfaces mainly contributes to the system s quality attributes anology: architecture of buildings Enterprise and Domain Architecture are concerned with mutliple systems are a planning/enterprise/portfolio discipline anology: city planning and architecture of urban structures Department of Computer Sciences University of Basel 14

15 The Solution Enterprise and Domain Architects Enterprise and Domain Architects... typically manage a portfolio of hundreds of applications of large corporations are supporting IT-strategy and IT-planning are definining and performing an IT-Governance model are usually not concerned with solution architectures of individual software solutions and applications Department of Computer Sciences University of Basel 15

16 The Solution Enterprise and Domain Architecture Enterprise & Domain Architecture you find in enterprises... which operate hundreds if not thousands of solutions that have an IT-budget Mio (mid-size insurance company) Mio (large insurance company) - 1+ Mrd (automobile manufacturer) which have an Enterprise Architecture organization/group - ~1% of general IT-staff - ~10 group members Department of Computer Sciences University of Basel 16

17 The Solution Architecture Development and Evolution Method Solution Architecture Enterprise Architecture Department of Computer Sciences University of Basel 17

18 The Solution Multiple-disciplinary Governance Plan Build Run Q&C PPM APM EA/DA CM PM CP SM SA PM BA IM EA/DA = Enterprise & Domain Architecture PPM = Project Portfolio Management APM = Application Portfolio Management Q&C = Quality & Compliance CM = Change Management PM = Problem Management CP = Capacity Planning PM = Project Management SM = Service Management BA = Business Analysis SA = Solution Architecture IM = Implementation Department of Computer Sciences University of Basel 18

19 The Solution Enterprise versus Solution Architecture Enterprise Architecture Domain Architecture Solution Architecture Department of Computer Sciences University of Basel 19

20 The Solution Enterprise versus Solution Architecture Enterprise Architecture What is all out there? How do different elements relate to each other? Do we have gaps? Do we have overlaps? What is important? What is the right order to tackle the problem? How would a change impact this domain (internally)? How would a change impact other domains (externaly)? Domain Architecture Department of Computer Sciences University of Basel 20

21 Initiate, Guide and Govern Solutions The Solution Enterprise Architecture Overview Enterprise Architecture Life-Cycle Model Reference Architecture Solution Architecture Life-Cycle Define Enterprise Architecture Context Refine Principles & Requirements Model As-Is Architecture Develop & Evaluate Alternatives Elaborate System Context Model To-Be Architecture Perform Gap Analysis Elaborate Architecture Vision <<Black Box>> Solution Architecture Elaborate Application Architecture Elaborate Data Architecture Elaborate Technology Architecture Derive and define Roadmaps Elaborate cross-cutting Architecture Perspectives Review Architecture Department of Computer Sciences University of Basel 21

22 The Solution Enterprise Architecture Model Reference Architecture Department of Computer Sciences University of Basel 22

23 The Solution Enterprise Architecture Model Reference Architecture TOGAF can be used as an EA reference framework. The notion of domains is used to create architecture-related manageable clusters Department of Computer Sciences University of Basel 23

24 Initiate, Guide and Govern Solutions The Solution Enterprise Architecture Overview Enterprise Architecture Life-Cycle Model Reference Architecture Solution Architecture Life-Cycle Define Enterprise Architecture Context Refine Principles & Requirements Model As-Is Architecture Develop & Evaluate Alternatives Elaborate System Context Model To-Be Architecture Perform Gap Analysis Elaborate Architecture Vision <<Black Box>> Solution Architecture Elaborate Application Architecture Elaborate Data Architecture Elaborate Technology Architecture Derive and define Roadmaps Elaborate cross-cutting Architecture Perspectives Review Architecture Department of Computer Sciences University of Basel 24

25 The Solution Enterprise Architecture Model As-Is Architecture As-Is Architectures are created and evolved per architecture domain to improve planning, gap-analysis, and strategic alignment across domains Department of Computer Sciences University of Basel 25

26 Initiate, Guide and Govern Solutions The Solution Enterprise Architecture Overview Enterprise Architecture Life-Cycle Model Reference Architecture Solution Architecture Life-Cycle Define Enterprise Architecture Context Refine Principles & Requirements Model As-Is Architecture Develop & Evaluate Alternatives Elaborate System Context Model To-Be Architecture Perform Gap Analysis Elaborate Architecture Vision <<Black Box>> Solution Architecture Elaborate Application Architecture Elaborate Data Architecture Elaborate Technology Architecture Derive and define Roadmaps Elaborate cross-cutting Architecture Perspectives Review Architecture Department of Computer Sciences University of Basel 26

27 The Solution Enterprise Architecture Perform Gap Analysis Gap analysis are performed based on heat-mapping and similar techniques Department of Computer Sciences University of Basel 27

28 Initiate, Guide and Govern Solutions The Solution Enterprise Architecture Overview Enterprise Architecture Life-Cycle Model Reference Architecture Solution Architecture Life-Cycle Define Enterprise Architecture Context Refine Principles & Requirements Model As-Is Architecture Develop & Evaluate Alternatives Elaborate System Context Model To-Be Architecture Perform Gap Analysis Elaborate Architecture Vision <<Black Box>> Solution Architecture Elaborate Application Architecture Elaborate Data Architecture Elaborate Technology Architecture Derive and define Roadmaps Elaborate cross-cutting Architecture Perspectives Review Architecture Department of Computer Sciences University of Basel 28

29 The Solution Enterprise Architecture Model To-Be Architecture Roadmaps are derived from target (to-be) architectures. Roadmaps underpin PPM and support the alignment of change initiatives Department of Computer Sciences University of Basel 29

30 Initiate, Guide and Govern Solutions The Solution Enterprise Architecture Overview Enterprise Architecture Life-Cycle Model Reference Architecture Solution Architecture Life-Cycle Define Enterprise Architecture Context Refine Principles & Requirements Model As-Is Architecture Develop & Evaluate Alternatives Elaborate System Context Model To-Be Architecture Perform Gap Analysis Elaborate Architecture Vision <<Black Box>> Solution Architecture Elaborate Application Architecture Elaborate Data Architecture Elaborate Technology Architecture Derive and define Roadmaps Elaborate cross-cutting Architecture Perspectives Review Architecture Department of Computer Sciences University of Basel 30

31 The Solution Enterprise Architecture Initiate, Guide and Govern Solutions Architecture patterns are only one of many means and techniques to govern along agreed paths Department of Computer Sciences University of Basel 31

32 The Solution Multiple-disciplinary Governance Plan Build Run Q&C PPM APM EA/DA CM PM CP SM SA PM BA IM EA/DA = Enterprise & Domain Architecture PPM = Project Portfolio Management APM = Application Portfolio Management Q&C = Quality & Compliance CM = Change Management PM = Problem Management CP = Capacity Planning PM = Project Management SM = Service Management BA = Business Analysis SA = Solution Architecture IM = Implementation Department of Computer Sciences University of Basel 32

33 The Solution Enterprise versus Solution Architecture How the system works (its static and dynamic structures)? How do system components collaborate & work together? How is the system internally connected? How is performance achieved for the system? How is availability achieved for the system? How is security achieved for the system? How is extensibility achieved for the system? What are the system s dependencies to other systems? Solution Architecture Department of Computer Sciences University of Basel 33

34 The Solution Solution Architecture Symptoms of immature architectures Symptoms of immature architectures Results of analysis phase are not adequately considered. Holistic view of IT-System is missing. Complexity increases and becomes unmanageble. Planning and risk-management becomes difficult. Reuse of expertise as well as system building blocks is difficult. Flexibility, maintainability, interoperability become a problem. Architecture documentation is missing or not up-to-date. Steep learning curve for new staff entering the project. Redundancy of code and functionality. System s building blocks are heavily interdependent. Very long development and change cycles Department of Computer Sciences University of Basel 34

35 The Solution Solution Architecture Nature of distributed systems Systems are decomposed into components which are horizontally as well as vertically distributed across many compute nodes and locations Department of Computer Sciences University of Basel 35

36 The Solution Solution Architecture View models Systems are decomposed into components which are horizontally as well as vertically distributed across many compute nodes and locations Application Architecture Technology Architecture Data Architecture Application Infrastructure IT-Infrastructure Department of Computer Sciences University of Basel 36

37 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective The Solution Solution Architecture View models Systems are decomposed into components which are horizontally as well as vertically distributed across many compute nodes and locations Client Component Presentation Component Business Logic Component Integration and Persistence Component Application Architecture Technology Architecture Data Architecture Application Infrastructure IT-Infrastructure Department of Computer Sciences University of Basel 37

38 The Solution Solution Architecture View models IT Solution Business Architecture Processes Services Capabilities Application Architecture Client Component Presentation Component Business Logic Component Integration Component Persistence Component Technology Architecture Data Architecture Information Component Information Relation Information Flow Application Infrastructure Client Infrastructure Presentation Infrastructure Business Logic Infrastructure Integration Infrastructure Persistence Infrastructure OS Hypervisor IT-Infrastructure Computing (Client & Server Devices) Network & NOS Storage Data Centres Department of Computer Sciences University of Basel 38

39 The Solution Solution Architecture View Models in a Nutshell What are common characteristics of Architecture View Models? End User View Model Security Officer Data Analyst Compliance Officer Infrastructure Service Manager Business Analyst applied to End User Data Analyst View Model Adapted and Instantiated IT System Security Officer Department of Computer Sciences University of Basel 39

40 The Solution Solution Architecture View Models in a Nutshell Architecture View Models describe... all views that the architecture view model is comprised of diagrams, elements, nomenclature, etc. used to express and constitute a view who is interested in a view (i.e. stakeholders) and the concerns this group has who is responsible for creating and maintaining a view how a view is created and further evolved how a view relates to other views how a view is utilized in order to answer given questions when a view can be considered complete and adequate what the right level of detail is for a view and in a given context (e.g. early project phase) Department of Computer Sciences University of Basel 40

41 The Solution Solution Architecture View Models in a Nutshell Architecture View Models serve a to-be-determined context stakeholders have different concerns with regard to a system, or rather, its architecture based on their specific concerns, different stakeholders each adopt a specific viewpoint a specific architecture view (e.g., data view) is available to stakeholders from each respective viewpoint (different angles) it is defined by the viewpoint and refers to a set of specific concerns each architecture view has a reference to exactly one viewpoint architecture views essentially determine the content and structure of architecture documentation Department of Computer Sciences University of Basel 41

42 The Solution Solution Architecture View Models in a Nutshell Relevance of architecture views architecture views can be used to look at specific aspects of an IT system they make it easier to manage the complexity of all aspects of an IT system the aspects considered in architecture views depend on the respective stakeholder and his or her current activity in the creation of an IT system architecture views are specified using viewpoints an architecture viewpoint is the specification of an architecture view and covers stakeholders and their concerns, as well as artefacts the creation of an architecture view can also be specified following basic architecture views exist: requirements view, logical view, data view, implementation view, process view, and deployment view to ensure the quality of the architecture, it is important to create or describe an architecture on the basis of architecture views from the very beginning it is not necessary to define architecture viewpoints from scratch; you can use existing architecture view models the Architecture Handbook defines its own architecture viewmodel geared to the needs of Novartis Department of Computer Sciences University of Basel 42

43 level of detail The Solution Solution Architecture View Models in a Nutshell Architecture View Models allow you to determine... What you see The level of detail you see All Architecture View Models span the following two dimensions perspective selection Functionality Information Technology Security... System Landscape Level System Level Sub-System Level Department of Computer Sciences University of Basel 43

44 The Solution Solution Architecture View Models in a Nutshell Looking at systems through a telescope you can change the level of detail at which you look at a system using the zoom factor I will use the telescope metaphor again to develop the architecture levels imagine (throughout the next slides to come) you want to look at an IT system through a telescope Department of Computer Sciences University of Basel 44

45 The Solution Solution Architecture View Models in a Nutshell Organization before you can focus on a specific IT system, the telescope first shows you the external contexts of the IT system first you see different organizations and how they collaborate in their different roles (clients, suppliers, partners, etc.) with the next telescope setting, you look at a specific organization more closely you see the systems (employees, departments, IT systems, etc.) within the organization and how they are used and interact in the business processes of the organization System Level you increase the zoom factor of the telescope again and now you can look at a specific IT system of the organization in more detail you see interfaces of the system, its functionality, its quality attributes as they are perceived on the system s outside (e.g. security, performance, availability), and its users Department of Computer Sciences University of Basel 45

46 The Solution Solution Architecture View Models in a Nutshell Building Block Level then you zoom inside the system the telescope shows you the internal contexts of the system you recognize the building blocks that make up the system you see their interfaces, responsibilities, and interactions you then increase the zoom factor again and now you can see the internal workings of the system building blocks in detail Change of Level and while you zoom further into individual building blocks you discover that each of them is made up of system building blocks, yet again you realize that the indistinguishability makes the borders between what a system and what a system s building block (aka: sub-system) blur Department of Computer Sciences University of Basel 46

47 The Solution Solution Architecture Solution Architecture in a Nutshell An architecture description is the manifestation of a computer system s architecture. It describes this system s key structures as well behavior Tangible Architecture Intangible Architecture Department of Computer Sciences University of Basel 47

48 The Solution Solution Architecture Solution Architecture in a Nutshell Architecture descriptions on paper can describe how and prove that the anticipated physical system realizes all its requirements Requirements (Needs) logically realizes Architecture Description physically realizes Implements specification Physical Computer System Department of Computer Sciences University of Basel 48

49 The Solution Solution Architecture Solution Architecture in a Nutshell Architecture descriptions on paper can describe how and prove that the anticipated physical system realizes all its requirements Requirements (Needs) logically realizes Architecture Description physically realizes Implements specification Physical Computer System Department of Computer Sciences University of Basel 49

50 The Solution Solution Architecture Solution Architecture in a Nutshell When an architecture description demonstrates that and explains how agreed requirements are met we can flag it as complete Requirements Functional Requirements A functional requirement expresses a functional capability that an appropriate system is expected to expose to its outside. The sum of all functional requirements constitute the reason for the system s existence Non-Functional Requirements Non-functional requirements can be seen as complementary to the functional requirements since they express the quality side of the house and they are almost as equally important as functional requirements. Functional Requirement (FR) Non-functional Requirement (NFR) Department of Computer Sciences University of Basel 50

51 The Solution Solution Architecture Solution Architecture in a Nutshell Use cases (UC) do a good job stating functional requirements while NFRs are either complementary to UCs or stated as system-wide requirements Department of Computer Sciences University of Basel 51

52 The Solution Solution Architecture Solution Architecture in a Nutshell Do these architecture descriptions, randomly picked off the Internet, explain how they meet the system s functional and non-functional requirements? Department of Computer Sciences University of Basel 52

53 The Solution Solution Architecture Solution Architecture in a Nutshell Do these architecture descriptions, which I randomly picked from the Internet, explain how they meet the system s functional and non-functional requirements? Department of Computer Sciences University of Basel 53

54 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective The Solution Solution Architecture Solution Architecture in a Nutshell The Architecture Handbook view model is a holistic architecture view model which meets the needs of the professional solution architect Enterprise Architecture Landscapes & Views Requirements Principles & Constraints Application Architecture Technology Architecture Data Architecture External Viewpoint Architecture Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Architecture Vision Department of Computer Sciences University of Basel 54

55 The Solution Solution Architecture Solution Architecture in a Nutshell A quite distilled version of the Architecture Handbook still demonstrates how an appropriate architecture description can be traced back to the requirements Functional Requirements Use Case 1. Step A (initiate session with ATM) Use Case 2. Step B (enter PIN) 1. Step A (initiate session with ATM) 3. Step C (enter amount to be withdrawn) 2. Step B (enter PIN) 3. Step C (enter amount to be withdrawn) NFRs Use Case specific NFRs System-wide NFRS Application Architecture Use Case Realization Use Case Realization A1 A2 A3 A4 step A a step B A1 A2 A3 A4 step A c d step C a step B c e d step C e Application Component Diagram Application Component A2 Diagram A1 A2 A3 A1 A3 A4 A4 A5 A5 Technology Architecture Deployment Diagram Deployment T1 A1 Diagram T2 T3 T4 x x A2 T1 T2 x T3 T4 A1 x x x A2 A3 x x x A3 x Technology Component Diagram Technology Component T2 Diagram T4 T1 T2 T3 T4 T5 T1 T3 T5 Department of Computer Sciences University of Basel 55

56 The Solution Solution Architecture Solution Architecture in a Nutshell Applying the distilled viewpoint sequence of the Architecture Handbook to the ATM Show Case this is what we would get. Use Case Overview Diagram Non-functional Requirements Use Case specific NFRs System-wide NFRS Department of Computer Sciences University of Basel 56

57 The Solution Solution Architecture Solution Architecture in a Nutshell Applying the distilled viewpoint sequence of the Architecture Handbook to the ATM Show Case this is what we would get. Use Case Description Department of Computer Sciences University of Basel 57

58 The Solution Solution Architecture Solution Architecture in a Nutshell Applying the distilled viewpoint sequence of the Architecture Handbook to the ATM Show Case this is what we would get. Use Case Realization Department of Computer Sciences University of Basel 58

59 The Solution Solution Architecture Solution Architecture in a Nutshell Applying the distilled viewpoint sequence of the Architecture Handbook to the ATM Show Case this is what we would get. Application Component Diagr. Non-functional Requirements Use Case specific NFRs System-wide NFRS Department of Computer Sciences University of Basel 59

60 The Solution Solution Architecture Solution Architecture in a Nutshell Applying the distilled viewpoint sequence of the Architecture Handbook to the ATM Show Case this is what we would get. Application Component Diagr. Technical Component Diagr. Department of Computer Sciences University of Basel 60

61 The Solution Solution Architecture Solution Architecture in a Nutshell Applying the distilled viewpoint sequence of the Architecture Handbook to the ATM Show Case this is what we would get. Deployment Diagram 50ms Non-functional Requirements Use Case specific NFRs System-wide NFRS 350ms 500ms 400ms 110ms 110ms Department of Computer Sciences University of Basel 61

62 The Solution Solution Architecture Solution Architecture in a Nutshell Applying the distilled viewpoint sequence of the Architecture Handbook to the ATM Show Case this is what we would get. DOs Requirements demonstrates how it realizes Architecture Description DON Ts Requirements does not demonstrate how it realizes Architecture Description Department of Computer Sciences University of Basel 62

63 Questions? Department of Computer Sciences University of Basel 63