Software Life-Cycle Management

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

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

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 3

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 4 t

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 5 (1) Managed Evolution, Springer, Stephan Murer et al, Zürich 2010

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 6

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 7

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 8

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 9

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 10

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 11

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 12

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 13

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 14

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 - 50+ Mio (mid-size insurance company) - 250+ 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 15

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

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

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 19

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 20

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

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 22

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 24

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 26

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 28

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 30

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 32

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 33

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 34

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 35

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 36

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 37

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 38

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 40

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 41

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 42

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 43

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 44

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 45

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 46

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 49

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 50

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 51

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 52

Questions? Department of Computer Sciences University of Basel 53