Software Life-Cycle Management

Transcription

1 Ingo Arnold Department Computer Science University of Basel Software Life-Cycle Management Introduction Introduction «evaccine Card» Case Study

2 evaccine Card System Few words up-front.. Take the evaccine System case study with a grain of salt Adequate application of the is a relative concept Overall type of the engagement determines what is adequate AH-application Types of engagement varies significantly based on.. - Where the engagement has its focus LCM-wise (e.g. ideation, investment justification, alternative elaboration, problem understanding, conceptual solutioning) - The type of «system» the engagement is expected to evolve (e.g. package customization, shared infrastructure service, business process) - Whether the engagement is entering into a green-, brown-, burned-field Through conscious AH adaption the AH method s application is tailored to the needs of the given engagement What is an adequate application of the AH method in the context of engagement A might be a totally inadequate adaption of the AH in the context of engagement B 2 Department of Computer Sciences University of Basel

3 e-vaccination Card System Case Study Case Study e-vaccination Card 3 Department of Computer Sciences University of Basel

4 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 0 evaccine Case Study Introduction 1 Initiate the Project 2 Define the Enterprise Context 3 Refine Principles and Requirements 4 Develop Alternatives Initiation #1 #2 #3 #4 #5 #N Transition & Operation 4 Department of Computer Sciences University of Basel

5 Introductory Notes Artifact Types This deck refers to artifacts that are related to a broader set of projectrelated work-products as well as architecture-specific artifacts Project Artifact Artifact Names of artifacts will be shown at the top-right corner of a respective slide <Artifact Name> 5 Department of Computer Sciences University of Basel

6 Introductory Notes Process Steps Each step that we move into will quickly be explained like outlined below 6 Department of Computer Sciences University of Basel

7 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective Introductory Notes View Model Also each step will be positioned from an architecture view model perspective Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 7 Department of Computer Sciences University of Basel

8 Introductory Notes Training Overview 8 Department of Computer Sciences University of Basel

9 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 0 evaccine Case Study Introduction 1 Initiate the Project 2 Define the Enterprise Context 3 Refine Principles and Requirements 4 Develop Alternatives Initiation #1 #2 #3 #4 #5 #N Transition & Operation 9 Department of Computer Sciences University of Basel

10 Problem Statement Activity Problem Statement Company «improvehealth» recently spotted a significant gap in their services landscape: Lacking an IT-Systemt which is possibly internet-based and emulates paperbased Vaccination Cards By closing this gap the company wants to allow Patients, Physicians, as well as «improvehealth» themselves to more efficiently Provide information of new vaccinations in a very targeted manner Alert patients and physicians of overdue vaccinations Capture, track and report vaccination incidents «improvehealth» has decided to launch a project called evaccine Card that is expected to assess this first ideas value as well as feasibility 10 Department of Computer Sciences University of Basel

11 Problem Statement Activity Problem Statement A project (called evaccine Card project) is funded, staffed, and kickstarted in order to Investigate the business value (cost-benefit ratio) Plan, implement, and deploy an appropriate solution (optional) The project manager invites to a constitutional workshop... Business Representative Solution Architect <other groups as appropriate> Project Manager Solution Architect Business Representative 11 Department of Computer Sciences University of Basel

12 Problem Statement Result Problem Statement During the initial workshop the team drafts a first version of a problem statement 12 Department of Computer Sciences University of Basel

13 Analyse Stakeholders Activity Stakeholder Analysis Then the team analyzes concerned stakeholders like for example Business Sponsor Quality and Compliance Representative Security Expert Service Management and Operations Representative During stakeholder analysis the Solution Architects ensures that architecture-significant stakeholders are taken into account significance of «something» means that Business criticality of this «something» is considered high or severe Cost of change of this «something» is anticipated high Risk of this «something» is seen as high (high probability and impact) 13 Department of Computer Sciences University of Basel

14 Analyse Stakeholders Result Stakeholder Analysis After intense discussions the results of the stakeholder analysis are caputed 14 Department of Computer Sciences University of Basel

15 Identify Customer Needs Activity Customer Needs A few days later the «evaccine Card» team invites key stakeholders to a «needs & requirements gathering» workshop At this workshop stakeholders could raise their views of the problem at hand Informally express their thoughts, concerns, and demands Key of the workshop is not to capture all requirements in all details but to stipulate a discussion and gather a first impression of needs The Solution Architect ensures that quality aspects are sufficiently taken into account (1) stakeholders understand the impacts of needs they express to - Cost - Risks - Future evolution 15 Department of Computer Sciences University of Basel (1) Often these are neglected or not adequately taken into account

16 Identify Customer Needs Result Customer Needs Customer needs are semi-formally captured at the end of the workshop 16 Department of Computer Sciences University of Basel

17 Identify Customer Needs Result Customer Needs Customer needs are semi-formally captured at the end of the workshop Customer Needs 17 Department of Computer Sciences University of Basel

18 Identify Customer Needs Result Needs & Requirements Customer needs are semi-formally captured at the end of the workshop 18 Department of Computer Sciences University of Basel

19 Identify High-Level Functional Needs Activity High-Level Functional Needs After a first set of needs was captured the team pays special attention to Key functional needs that stakeholders expressed Key functionality and processes that the solution has to provide Quality aspects relating to these processes and which are considered crucial Goal of this step is to understand the high-level functional needs (1) that «evaccine Card» has to meet The following processes were spotted as key Business Use Cases Patient tracking process Share information on new vaccination process 19 Department of Computer Sciences University of Basel (1) High-level functional need is used as a synonym for Business Use Cases here

20 Identify High-Level Functional Needs Result High-Level Functional Needs 20 Department of Computer Sciences University of Basel (1) Alternatively «Use Case» techniques could have been used here

21 Identify High-Level Functional Needs Result High-Level Functional Needs The Supplier-Input-Process-Output-Consumer (SIPOC) technique (1) is used to capture the schema of the «Patient Tracking» process High-Level Functional Needs «improvehealth» «improvehealth» 21 Department of Computer Sciences University of Basel (1) Alternatively «Use Case» techniques could have been used here

22 Identify High-Level Functional Needs Result High-Level Functional Needs The Supplier-Input-Process-Output-Consumer (SIPOC) technique (1) is used to capture the schema of the «Patient Tracking» process High-Level Functional Needs «improvehealth» 22 Department of Computer Sciences University of Basel (1) Alternatively «Use Case» techniques could have been used here

23 Project Charter Activity Project Charter A presentation to the «evaccine Card» project s steering board is planned for tomorrow and the Project Manager has to present first results A project charter is drafted, which already includes a description of Underlying business needs Project s intended scope Business benefits, as well as impact of not doing Roles and responsibilities 23 Department of Computer Sciences University of Basel

24 Project Charter Result Project Charter 24 Department of Computer Sciences University of Basel

25 Project Charter Result Project Charter 25 Department of Computer Sciences University of Basel

26 Project Charter Result Work Items List First sketch of a work items list 26 Department of Computer Sciences University of Basel

27 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 0 evaccine Case Study Introduction 1 Initiate the Project 2 Define the Enterprise Context 3 Refine Principles and Requirements 4 Develop Alternatives Initiation #1 #2 #3 #4 #5 #N Transition & Operation 27 Department of Computer Sciences University of Basel

28 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 28 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 28

29 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 29 Department of Computer Sciences University of Basel

30 Define Enterprise Context Context Step 1: Enterprise Context Objective Roles Understand project and envisioned solution within a company s broader Enterprise and Domain context Analyse impacts and changes to the As-Is Enterprise architecture landscapes based on envisioned solution s future shape Understand gaps, overlaps, deficiencies, strengths of As-Is Enterprise architecture context regarding Capabilities Services Processes Information Applications Technologies - Solution Architect, Business Analyst, Enterprise Architect 30 Department of Computer Sciences University of Basel

31 Define Enterprise Context Context Very early in the project the «evaccine Card» Solution Architect has to Understand the anticipated solution s broader enterprise architecture (1) context Understand an organization s standards, policies, and constraints The enterprise architecture assessment is based on the EA viewpoints Business (Capabilities and Processes) Information (Information and Data Structures) Application (Applications and their functionality) Technology (Technology platforms hosting applications) Outcomes of such an assessment could for example be Something is missing and not existing today (gap) Something is available but not perfectly fitting (extension, adjustment) Something is available and perfectly fitting (reuse) Several solutions already exist (overlap potential for decomission) (1) «Enterprise» may refer to the architecture of an entire enterprise, the architecture of an 31 Department of Computer Sciences University of Basel entire sub-organization, the architecture of a selected domain (e.g. Network, CRM)

32 Define Enterprise Context Activity During the capabilities assessment (1) the Solution Architect detects «Patient Tracking» capability is not available, yet «Physician Tracking», and «Vaccination Reporting» capabilities already exist During the application assessment the Solution Architect detects «Vaccination System», «Vaccine Reporting & Analysis System», as well as «Vaccination Marketing Material System» already exists «Patient Register», «Physician Register», or «Vaccine Card System» do not exist yet The Solution Architect performs similar assessments for Information Technology 32 Department of Computer Sciences University of Basel (1) Results of the EA assessments are outlined on the following slides

33 Define Enterprise Context Result Business Capabilities Context 33 Department of Computer Sciences University of Basel

34 Define Enterprise Context Result Application Context improvehealth 34 Department of Computer Sciences University of Basel

35 Define Enterprise Context Result Data Context 35 Department of Computer Sciences University of Basel

36 Define Enterprise Context Result Technology Context 36 Department of Computer Sciences University of Basel

37 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 0 evaccine Case Study Introduction 1 Initiate the Project 2 Define the Enterprise Context 3 Refine Principles and Requirements 4 Develop Alternatives Initiation #1 #2 #3 #4 #5 #N Transition & Operation 37 Department of Computer Sciences University of Basel

38 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 38 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 38

39 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 39 Department of Computer Sciences University of Basel

40 Refine Principles and Requirements Context Step 2: Refine Principles and Requirements Objective Roles This step is about generating and documenting a common understanding of what is expected and possible under the given conditions, taking into account all factors driving the architecture. Describe the quality attributes of the Computer System, and the constraints that the solution must satisfy to deliver the business goals, objectives, or capabilities. Assess sizing, cost, and viability of the proposed Computer System, which is very much driven by given non-functional requirements. Crucial within this step is to differentiate those requirements that are architecture significant from the ones that are not. - Solution Architect, Business Analyst, Enterprise Architect 40 Department of Computer Sciences University of Basel

41 Refine Principles and Requirements Context What happened so far A first cut of Needs & Requirements had already been captured Customer Needs 41 Department of Computer Sciences University of Basel

42 Refine Principles and Requirements Context What happened so far (continued) High-level functional needs were captured in the form of SIPOCs 42 Department of Computer Sciences University of Basel

43 Refine Principles and Requirements Context A SIPOCs main process steps indicate System Use Case candidates Register Patient Vaccination Alert Report Vaccination Incident Add Vaccine to an evaccine Card 43 Department of Computer Sciences University of Basel

44 Refine Principles and Requirements Activity The Solution Architect creates a Use Case Overview diagram that Is based on the spotted Use Case candidates May further be based on - Needs that were captured in the «Needs & Requirements» session - Reference architectures Provides a very comprehensive overview of targeted functionality (1) Includes a list of Actors that are associated to targeted functionality Outlines dependencies that may exist among use cases Serves as a basis to conduct discussions with stakeholders in order to - Discuss and agree on completeness, correctness and relevance of functional vision - Define priorities with regards to standing up the system incrementally 44 Department of Computer Sciences University of Basel (1) Use Cases express functional needs / requirements

45 Refine Principles and Requirements Result System UC Overview 45 Department of Computer Sciences University of Basel

46 Refine Principles and Requirements Activity The Solution Architect will elaborate Use Case specific non-functional needs separately when further investigating respective Use Cases System-wide non-functional needs however must be managed as well The Solution Architects ensures that system-wide non-functional needs are Captured Discussed Prioritized Tracked & traced The Solution Architect pays attention only to those requirements (functional as well as non-functional) that are assessed as architecture significant 46 Department of Computer Sciences University of Basel

47 Refine Principles and Requirements Result First sketch of significant non-functional requirements 47 Department of Computer Sciences University of Basel

48 Refine Principles and Requirements Activity Requirements express what an organization wants and needs Constraints however rather express crash barriers which determine a frame within which an organization is striving to meet its own needs Constraints Express framing conditions which a solution but also a project has respect Distinguish between organizational and technical constraints Usually have an impact on solution design and approach 48 Department of Computer Sciences University of Basel

49 Refine Principles and Requirements Result The «evaccine Card» team has identified the following constraints 49 Department of Computer Sciences University of Basel

50 Nota Bene! Make your work as efficient as possible Many architecture-significant requirements may lead to the same Approach 50 Department of Computer Sciences University of Basel

51 Very fundamental Architectural Approaches Less fundamental Nota Bene! Make your work as efficient as possible Many architecture-significant requirements may lead to the same Approach Problem Solution 51 Department of Computer Sciences University of Basel

52 Project Plan Update Activity Project Plan The Project Plan is now updated to reflect the new insights and learnings the team just developed: Stakeholders Dependencies Risks Key functional and non-functional requirements 52 Department of Computer Sciences University of Basel

53 Project Plan Update Result Project Plan 53 Department of Computer Sciences University of Basel

54 Work Items List Update Result Work Items List Work Items List further elaborated 54 Department of Computer Sciences University of Basel

55 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 0 evaccine Case Study Introduction 1 Initiate the Project 2 Define the Enterprise Context 3 Refine Principles and Requirements 4 Develop Alternatives Initiation #1 #2 #3 #4 #5 #N Transition & Operation 55 Department of Computer Sciences University of Basel

56 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 56 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 56

57 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 57 Department of Computer Sciences University of Basel

58 Develop Alternatives Context Step 3: Develop Alternatives Objective Roles Based on the driving factors that were identified in the previous step and taking into account the architecture context, this step supports the identification of architecture candidates which could potentially cope with the problem at hand Broaden the view to not overlook appealing but exceptional approaches to solve the actual business problem Create holistic information basis to be able to take sufficiently broad as well as grounded preferred solution -decision Document the alternative selection process so that it can be communicated to different stakeholder groups - Solution Architect, Business Analyst, Enterprise Architect 58 Department of Computer Sciences University of Basel

59 Different Perspective Session Novel ways of achieving the same German English translate 59 Department of Computer Sciences University of Basel

60 Develop Alternatives Context People, groups, whole organizations have a tendency to follow their own conditioning To break such conditioning and habits (at least counter balance them) is the key purpose of the «develop architecture alternatives» step «Many roads lead to rome» is true not just for rome but for all other problems that seek a solution 60 Department of Computer Sciences University of Basel

61 Develop Alternatives Activity The «evaccine Card» team meets in order to develop alternative architecture approaches to creating the required solution The team uses the following quite helpful technique to systematically develop solution alternatives 1. Draw a topological sketch of the envisioned system s building blocks 2. Traverse all building blocks and determine dimensions that span alternatives - WHAT Vertical (data center, devices, communication stack, application middleware, app,..) Horizontal (break-down of components, alternative COTS products,..) Black-boxedness (build, buy and assemble, hybrid) - WHO Differentiation of Actors Plan ownership (internal, strategic partner,..) Build ownership (internal, strategic partner,..) Run ownership (internal, strategic partner,..) 61 Department of Computer Sciences University of Basel

62 Develop Alternatives Activity The team uses the following quite helpful technique to systematically develop solution alternatives (continued) 2. Traverse all building blocks and determine dimensions that span alternatives - WHERE Geography (global, regional, local) - HOW Security Availability Performance Extensibility Maintainability & Operability 3. Define aspirational forces along architecture principles, standards & strategic directions 4. Pick «thinkable» combinations along spotted dimensions and scales 5. Look at each of these combinations as an architecture alternative candidate and investigate them further 62 Department of Computer Sciences University of Basel

63 Develop Alternatives Activity 1. Draw a topological sketch of the envisioned system s building blocks 63 Department of Computer Sciences University of Basel

64 Develop Alternatives Activity 1. Draw a topological sketch of the envisioned system s building blocks 64 Department of Computer Sciences University of Basel

65 Develop Alternatives Activity 1. Draw a topological sketch of the envisioned system s building blocks 65 Department of Computer Sciences University of Basel

66 Develop Alternatives Activity 1. Draw a topological sketch of the envisioned system s building blocks 66 Department of Computer Sciences University of Basel

67 Develop Alternatives Activity WHAT 2. Traverse building blocks and determine dims. which span alternatives WHAT Horizontal Component Break-Down COTS products {product X, product Y, product Z} WHAT Vertical Application middleware {.Net, J2EE} Communication Stack {TCP/IP, SPX} Device Type (Virtual X86, LPAR, Dedicated, Mobile} Data Center (GDC, RDC, LDC, Cloud} WHAT Black-boxedness Build Buy and Assemble Hybrid 67 Department of Computer Sciences University of Basel

68 Develop Alternatives Activity WHO 2. Traverse building blocks and determine dims. which span alternatives Patient with allergies Patient with private assurance Maintainer of Meta-/Master-Data Maintainer of Marketing Mateiral Maintainer of Roles, Privileges, Entitlements Physician (discountenabled) WHO Plan Ownership Internal {organization, role, individual} WHO Build Ownership Strategic partner {organization, role, individual} Internal {organization, role, individual} WHO Service Run Ownership partner {organization, role, individual} Strategic partner {organization, role, individual} Internal {organization, role, individual} Service partner {organization, role, individual} Strategic partner {organization, role, individual} Service partner {organization, role, individual} 68 Department of Computer Sciences University of Basel

69 Develop Alternatives Activity WHERE 2. Traverse building blocks and determine dims. which span alternatives WHERE Geography Global Regional Local 69 Department of Computer Sciences University of Basel

70 Develop Alternatives Activity HOW 2. Traverse building blocks and determine dims. which span alternatives HOW Security Attack detection, prevention, recovery Data at Rest vs. Data in Motion Physical access control etc. HOW Availability Planned vs. Unplanned down-time RPO/RTO 70 Department of Computer Sciences University of Basel

71 Develop Alternatives Activity 3. Define aspirational forces along architecture principles, etc. Cloud-based (PaaS) Solution Develop native iphone Application COTS-base solution which is customized 71 Department of Computer Sciences University of Basel

72 Develop Alternatives Activity Alternative «develop application» 4. Pick «thinkable» combinations along spotted dimensions WHAT Apple iphone Native ios Application WHO Plan, Build: Vendor Run: improvehealth WHERE Global / Internet HOW Security: PIN (1-factor) Availability: local caching Extensibility: future functions WHAT Java Swing Application JSDK Release 6.x WHO Plan, Build: Vendor WHAT Run: improvehealth Bespoke back-end WHERE application Global / Intranet J2EE app server (WLS) HOW RDBMS (Oracle 10G) Security: gold cert-based WHO Availability: client image Plan, Build: Vendor Extensibility: future functions Run: improvehealth WHERE GDC HOW Security: FW Availability: horizontal 72 Department of Computer Sciences cluster University of Basel WHAT Java Swing Applet Standard http-ua with JSDK Release 6.x plug-in WHO Plan, Build: Vendor Run: improvehealth WHERE Global / Internet HOW Security: silver cert-based Availability: local DB Extensibility: future functions, future reports

73 Develop Alternatives Activity Alternative «customize package» 4. Pick «thinkable» combinations along spotted dimensions WHAT Any Device (tablet, smartp) HTML5/Android Application WHO Plan, Build: COTS Vendor Customize: improvehealth Run: Ops Vendor WHERE Global / Internet HOW Security: PIN (1-factor) Availability: / Extensibility: future functions WHAT Product X (COTS) Console Per vendor s spec WHO Plan, Build: COTS Vendor Customize: improvehealth Run: Ops Vendor WHERE Global / Intranet HOW Security: OTP (built-in solution) Availability: basic Extensibility: basic WHAT Product X (COTS) back-end Per vendor s spec WHO Plan, Build: COTS Vendor Customize: improvehealth Run: Ops Vendor WHERE GDC HOW Security: WAF Availability: DC cluster WHAT Laptop Java Swing Application WHO Plan, Build: COTS Vendor Customize: improvehealth Run: Ops Vendor WHERE Global / Internet HOW Security: PIN (1-factor) Availability: / Extensibility: future functions, future reports 73 Department of Computer Sciences University of Basel

74 Develop Alternatives Activity Alternative «PaaS based app» 4. Pick «thinkable» combinations along spotted dimensions WHAT Mobile Device (tablet, smartp) Android Java Application WHO Plan, Build: Vendor Run: Ops Vendor WHERE Global / Internet Cloud PaaS HOW Security: per PaaS Vendor Availability: / Extensibility: future functions WHAT Bespoke console application.net based UI http-ua as client-side system WHO Plan, Build: Vendor Run: Ops Vendor WHERE Cloud PaaS HOW Security: OTP (built-in solution) Availability: basic Extensibility: basic WHAT Bespoke back-end application.net server (MS IIS) RDBMS (MS SQL) WHO Plan, Build: Vendor Run: PaaS Vendor WHERE Cloud PaaS HOW Per PaaS vendor offer WHAT Mobile Device (tablet, smartp) Android Java Application WHO Plan, Build: Vendor Run: Ops Vendor WHERE Global / Internet Cloud PaaS HOW Security: per PaaS Vendor Availability: / Extensibility: future functions, future reports 74 Department of Computer Sciences University of Basel

75 Develop Alternatives Activity 5. Look at each of these combinations as an architecture alternative candidate and investigate them further Develop Application Customize Package PaaS based Application <evaccine Card Patient> Native ios Application Externally built, internally run Basic security <evaccine Card Patient> Portable HTML 5 / Android Application COTS, internally customized, externally run Basic security <evaccine Card Patient> Android Java app for any device Plan, Build: Vendor Run: Ops Vendor <evaccine Card Physician> RIA Java Applet Externally built, internally run Advanced security <evaccine Card Maintainer> RIA Java Application Externally built, internally run Advanced security <evaccine Card Physician> Laptop Java Swing Application COTS, internally customized, externally run Basic security <evaccine Card Maintainer> RIA Application COTS, internally customized, externally run OTP <evaccine Card Physician> Android Java app for any device Plan, Build: Vendor Run: Ops Vendor <evaccine Card Maintainer> RIA.Net Application Plan, Build: Vendor Run: PaaS Vendor Hosted on Cloud PaaS <evaccine Card Back-End> Java Enterprise Application Externally built, internally run Advanced security Hosted on-premise in GDC <evaccine Card Back-End> Back-End COTS Application COTS, internally customized, externally run Hosted on-premise in GDC <evaccine Card Back-End>.Net Application Plan, Build: Vendor Run: PaaS Vendor Hosted on Cloud PaaS 75 Department of Computer Sciences University of Basel

76 Develop Alternatives Activity This alternatives brainstorming / developing session was intelectually challenging and quite intense for the team The developed alternatives cover broad ranges regarding Technology choices (application middleware, devices, communication stacks) Accountability and ownership of plan, build, and run stages Hosting strategy Strategies to cope with security, availability, extensibilty Results from an end-user perspective ( usability) The team explores all three alternatives further and along System Context Application, Data, Technology Cross-Cutting Perspectives 76 Department of Computer Sciences University of Basel

77 Develop Alternatives Activity During this quick exploration of each alternative s architectural impacts and effects, main focus is given to Requirements coverage - Functional - Non-Functional Cost Risk 77 Department of Computer Sciences University of Basel

78 Develop Alternatives Activity Alternative «customize package» As a first alternative the team choses to look at «customize package» An Internet recherche is performed regarding appropriate COTS packages 3 packages are detected which all seem to fit at first glance The team investigates each COTS package according to its (1).. - Requirements coverage (functional and non-functional) - Cost and licensing model - Risk profile The package which seems most promising to the team is «profecard» - for «profecard» (as well as for all other 3 packages) a quick run through all remaining AH steps is performed to complete the first iteration (1) Any other aspect can be made a crucial selection criterion as well 78 Department of Computer Sciences University of Basel

79 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 5 Develop System Context These steps are repeated (time-boxed) for all spotted Alternatives Develop Vision Develop Application Develop Data 9 Develop Technology Initiation #1 #2 #3 #4 #5 #N Transition & Operation 79 Department of Computer Sciences University of Basel

80 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 80 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 80

81 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 81 Department of Computer Sciences University of Basel

82 Elaborate System Context Context Step 5: Elaborate System Context Objective Roles This step describes the solution as a whole and from a black-box perspective by capturing its highest level solution structures as well as relationships which exist between these and external entities crossing the given system s boundaries. To provide an overview of interfaces to be considered in the solution design. To verify that the information flows between the system and its external factors (i.e. external systems and actors) are in alignment with the external system owners expectations and commitments. To communicate at a high level the system boundaries to respective stakeholder groups. - Solution Architect, Business Analyst, Enterprise Architect 82 Department of Computer Sciences University of Basel

83 Elaborate System Context Context Alternative «profecard» The «profecard» system is put onto a test bench thus system documentation is carefully studied As a first step the profecard system s context is investigated in detail Further input is taken from the Enterprise Context 83 Department of Computer Sciences University of Basel

84 Elaborate System Context Activity A System Context represents the entire system under design as a single element System Context identifies the information and control flows that cross the system boundary from / to from external entities (e.g. human actors, external systems) The System Context highlights important aspects of the system such as: External events to which the system must respond. Events the system generates and that affect external entities. Data that the system receives from external systems Data produced by the system and provided to external systems 84 Department of Computer Sciences University of Basel

85 Elaborate System Context Activity Alternative «profecard» Based on the profecard system s documentation the following is sketched by the team 85 Department of Computer Sciences University of Basel

86 Elaborate System Context Activity Alternative «profecard» Based on the profecard system s documentation the following is sketched by the team 86 Department of Computer Sciences University of Basel

87 Elaborate System Context Activity Alternative «profecard» Based on the profecard system s documentation the following is sketched by the team 87 Department of Computer Sciences University of Basel

88 Elaborate System Context Activity Next step from here is to white-box-zoom into profecard system The team pursues this step by moving on to sketching an Vision for the profecard system 88 Department of Computer Sciences University of Basel

89 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 5 Develop System Context These steps are repeated (time-boxed) for all spotted Alternatives Develop Vision Develop Application Develop Data 9 Develop Technology Initiation #1 #2 #3 #4 #5 #N Transition & Operation 89 Department of Computer Sciences University of Basel

90 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 90 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 90

91 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 91 Department of Computer Sciences University of Basel

92 Elaborate Vision Context Step 6: Elaborate Vision Objective Roles Where the System Context provides a black box view on the system(s) in scope of the solution, the Vision provides a very highlevel first white box view on it. Primary focus of this step is to provide the Architect a handy tool for communicating with a broad variety of different stakeholder groups. The Vision viewpoint combines multiple aspects which are captured in a more focussed fashion throughout the following steps. Be able to communicate a comprehensive overview of the envisioned architecture s future shape, its advantages, functional coverage, implications, and consequences to different stakeholder groups. - Solution Architect 92 Department of Computer Sciences University of Basel

93 Elaborate Vision Context Alternative «profecard» The system context shows profecard from a black-box point of view As a next step the evaccine Card Solution Architect sketches an overview of the envisioned solution s... corner stone elements ( different types can be shown since purpose is to provide a one-glance overview rather than a distinct viewpoint, only) relationships among these corner stone pillars of profecard An Overview Diagram might already include Candidate Subsystems Components Nodes Connections Data Stores Users External Systems 93 Department of Computer Sciences University of Basel

94 Elaborate Vision Activity Alternative «profecard» Based on the profecard system s documentation the following white box view is sketched by the team 94 Department of Computer Sciences University of Basel

95 Elaborate Vision Activity Alternative «profecard» Next step for the e-vaccine Card project team is to zoom into each of the following architecture viewpoints more dedicately Application Data Arcihtecture Technology 95 Department of Computer Sciences University of Basel

96 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 5 Develop System Context These steps are repeated (time-boxed) for all spotted Alternatives Develop Vision Develop Application Develop Data 9 Develop Technology Initiation #1 #2 #3 #4 #5 #N Transition & Operation 96 Department of Computer Sciences University of Basel

97 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 97 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 97

98 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 98 Department of Computer Sciences University of Basel

99 Elaborate Application Context Step 7: Elaborate Application Objective Roles In this step the architect develops a model, which depicts the solution s core functional building blocks (i.e. Application Components) as well as their inter-dependencies. Beyond the solution s functional decomposition, this step also elaborates the realization of use cases which were captured by use case descriptions in the functional requirements step. Identify potential or final Application Components that will be responsible to provide the required functionality. Outline the relationships that exist between Application Components. - Solution Architect 99 Department of Computer Sciences University of Basel

100 Elaborate Application Context This step includes a description of the Computer System s Functional elements Their main responsibilities Their interfaces and primary interactions among themselves The Application is described based on Functional Structure Model (modeling static aspects) Functional Behavior Model (modeling dynamic/collaborative aspects) First orientation for stakeholders regarding functional scope functional decomposition functional cooperation and interaction Department of Computer Sciences University of Basel 100

101 Elaborate Application Activity Alternative «profecard» The e-vaccination Card team uses again profecard s system documentation and sketches the following break-down of functional / application components 101 Department of Computer Sciences University of Basel

102 Elaborate Application Activity Alternative «profecard» Further details are yet omitted since the activity is time-boxed and very much geared to identify cost structure, risk profile, requirements coverage, etc. 102 Department of Computer Sciences University of Basel

103 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 5 Develop System Context These steps are repeated (time-boxed) for all spotted Alternatives Develop Vision Develop Application Develop Data 9 Develop Technology Initiation #1 #2 #3 #4 #5 #N Transition & Operation 103 Department of Computer Sciences University of Basel

104 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 104 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 104

105 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision Department of Computer Sciences University of Basel 105

106 Elaborate Data Context Step 8: Elaborate Data Objective Roles This step observes and captures key information objects as well as their inter-relationships and ownership in scope of the solution. A Data s is THE corner stone of any IT solution, and this is why an Architect must pay serious attention to this step. Any function that a solution exposes at its outside is fully based on its Data s inherent information capabilities thus stays or falls with its quality, and completeness. Describe semantics, flows, structure as well as ownership of the managed information Investigate, understand, and describe approaches to data migration - Solution Architect 106 Department of Computer Sciences University of Basel

107 Elaborate Data Context This step describes the way that the architecture Stores Manipulates Manages Dstributes information Data is represented based on Static Data Structure Model Data Placement Model Department of Computer Sciences University of Basel 107

108 Elaborate Data Activity Alternative «profecard» At this early stage the team feels sufficiently confident with the fact that profecard offers A Connector Framework and custom development kit To expose all data related interfaces via well-formed / parsed XML This is taken as an indicator for that customization and adoption needs can be addressed by profecard s inherent customization features 108 Department of Computer Sciences University of Basel

109 Elaborate Data Activity Alternative «profecard» Also and based on Vision s depicted information needs profecard can be proven to match all respective data structures 109 Department of Computer Sciences University of Basel

110 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 5 Develop System Context These steps are repeated (time-boxed) for all spotted Alternatives Develop Vision Develop Application Develop Data 9 Develop Technology Initiation #1 #2 #3 #4 #5 #N Transition & Operation 110 Department of Computer Sciences University of Basel

111 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 111 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 111

112 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 112 Department of Computer Sciences University of Basel

113 Elaborate Technology Context Step 9: Elaborate Technology Objective Roles Where the Application describes a solution s key functional building blocks (aka: Application Components) and their interconnections, the Technology elaborates the Application Components operational underpinnings. With the Technology an Architect creates a model of System Components and their respective inter-connections. The Architect also develops a model that explains how each of the Application Components in the Application are mapped onto one or more System Components in the Technology An Architect uses the Technology mainly to verify coverage of all non-functional requirements and quality attributes the solution is expected to have. - Solution Architect 113 Department of Computer Sciences University of Basel

114 Elaborate Technology Context Technology describes the environment into which the Computer System will be deployed captures the dependencies a Computer System has on its runtime environment captures operational nodes that underpin and host your Computer System. Examples of such operational nodes are processing nodes like workstations, or servers (e.g. WAS, WS, TxS) network nodes disk and storage nodes back-up and recovery nodes systems management related nodes security nodes persistent system nodes (aka: file servers, databases), etc. 114 Department of Computer Sciences University of Basel

115 Elaborate Technology Activity Alternative «profecard» The e-vaccination Card team uses again profecard s system documentation and sketches the following break-down tech. components 115 Department of Computer Sciences University of Basel

116 Elaborate Technology Activity Alternative «profecard» Further details are yet omitted since the activity is time-boxed (similar to how this was handled for the application architecture viewpoint) 116 Department of Computer Sciences University of Basel

117 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 10 Alternative Selection 11 Iteration Planning 12 Iteration & Inception Closure / Retrospective 13 Define the Enterprise Context 14 Refine Principles and Requirements Initiation #1 #2 #3 #4 #5 #N Transition & Operation 117 Department of Computer Sciences University of Basel

118 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 118 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 118

119 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 119 Department of Computer Sciences University of Basel

120 Select Alternative Activity Remember first the architecture alternatives that the e-vaccination Card team had developed Develop Application Customize Package PaaS based Application <evaccine Card Patient> Native ios Application Externally built, internally run Basic security <evaccine Card Patient> Portable HTML 5 / Android Application COTS, internally customized, externally run Basic security <evaccine Card Patient> Android Java app for any device Plan, Build: Vendor Run: Ops Vendor <evaccine Card Physician> RIA Java Applet Externally built, internally run Advanced security <evaccine Card Maintainer> RIA Java Application Externally built, internally run Advanced security <evaccine Card Physician> Laptop Java Swing Application COTS, internally customized, externally run Basic security <evaccine Card Maintainer> RIA Application COTS, internally customized, externally run OTP <evaccine Card Physician> Android Java app for any device Plan, Build: Vendor Run: Ops Vendor <evaccine Card Maintainer> RIA.Net Application Plan, Build: Vendor Run: PaaS Vendor Hosted on Cloud PaaS <evaccine Card Back-End> Java Enterprise Application Externally built, internally run Advanced security Hosted on-premise in GDC <evaccine Card Back-End> Back-End COTS Application COTS, internally customized, externally run Hosted on-premise in GDC <evaccine Card Back-End>.Net Application Plan, Build: Vendor Run: PaaS Vendor Hosted on Cloud PaaS 120 Department of Computer Sciences University of Basel

121 Select Alternative Activity Beyond the evaluation of profecard System the team performed further alternative introspections in the meanwhile Develop Application -.Net-based low-cost e-vaccination Card application - JEE-based medium-cost e-vaccination Card application Customize Package - «profecard» - «electroni Vaccination Card» - «vaccination Card Mobile» PaaS based Application - «health-from-the-cloud e-vaccination Card PaaS» - «Health-Cloud Vaccination Card PaaS» 121 Department of Computer Sciences University of Basel

122 Elaborate Technology Activity For each alternative the team elaborated on.. Requirements coverage - Functional - Non-Functional Cost Risk On the following slides this step is performed for the profecard system 122 Department of Computer Sciences University of Basel

123 Elaborate Technology Activity Alternative «profecard» Requirements Coverage FR Overview 123 Department of Computer Sciences University of Basel

124 Elaborate Technology Activity Alternative «profecard» Requirements Coverage FR matching How is functional requirements coverage assessed? - team takes key use cases and holds them against profecard s system documentation - this can be done in great detail already or kept at a very high-level profecard system documentation 124 Department of Computer Sciences University of Basel

125 Elaborate Technology Activity Alternative «profecard» Requirements Coverage FR matching summary 125 Department of Computer Sciences University of Basel

126 Elaborate Technology Activity Alternative «profecard» Requirements Coverage NFR overview 126 Department of Computer Sciences University of Basel

127 Elaborate Technology Activity Alternative «profecard» Requirements Coverage NFR matching How is non-functional requirements coverage assessed? - team takes key NFRs and performs technical walk-throughs based on profecard s system documentation in order to verify / falsify non-functional capability of system - this can be done in great detail already or kept at a very high-level - for use-case specific NFRs use cases are taken and mapped onto profecard s Application Technology 127 Department of Computer Sciences University of Basel

128 Elaborate Technology Activity Alternative «profecard» Requirements Coverage NFR matching How is non-functional requirements coverage assessed? (continued) 128 Department of Computer Sciences University of Basel

129 Elaborate Technology Activity Alternative «profecard» Requirements Coverage NFR matching How is non-functional requirements coverage assessed? (continued) 129 Department of Computer Sciences University of Basel

130 Elaborate Technology Activity Alternative «profecard» Requirements Coverage NFR matching How is non-functional requirements coverage assessed? (continued) 200 ms 20 ms 20 ms 300 ms 50 ms 50 ms UC-specific NFR: Log-on to system should not take longer than 10 sec max 150 ms 400 ms Performance: 150 ms 450 ms ms = 1.79 sec 130 Department of Computer Sciences University of Basel

131 Elaborate Technology Activity Alternative «profecard» Requirements Coverage NFR matching summary 131 Department of Computer Sciences University of Basel

132 Elaborate Technology Activity Alternative «profecard» Risk Profile of profecard (based on a common e-vaccination metric) 132 Department of Computer Sciences University of Basel

133 Elaborate Technology Activity Alternative «profecard» Summary of key Pros and Cons of the profecard solution 133 Department of Computer Sciences University of Basel

134 Elaborate Technology Activity Alternative «profecard» Summary of evaluation results for all evaluated architecture alternatives 134 Department of Computer Sciences University of Basel

135 Elaborate Technology Activity Based on... a systematic approach to developing architecture alternatives understanding pros and cons of each alternative by their systematic evaluation an explicit and traceable evaluation schema including requirements and risk... the profecard system got selected as the COTS package that further solution architecture development will now be based upon 135 Department of Computer Sciences University of Basel

136 Update Project Plan Activity Project Plan The Project Plan is updated by the team to reflect Preferred alternative Rejected alternatives If the underlying decision (pro/con alternative(s)) is ever to be tracked back, the can be consulted for the underlying selection criteria rational 136 Department of Computer Sciences University of Basel

137 Update Project Plan Result Project Plan 137 Department of Computer Sciences University of Basel

138 Update Project Plan Result Project Plan 138 Department of Computer Sciences University of Basel

139 Update Work Items List Result Work Items List 139 Department of Computer Sciences University of Basel

140 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 10 Alternative Selection 11 Iteration Planning 12 Iteration & Inception Closure / Retrospective 13 Define the Enterprise Context 14 Refine Principles and Requirements Initiation #1 #2 #3 #4 #5 #N Transition & Operation 140 Department of Computer Sciences University of Basel

141 Iteration Planning Activity evaccine Card s project team has by now Investigated different alternative architectures Selected the most adequate alternative Gained a good first understanding of the problem to be solved Developed first high-level insight into the solution to this given problem Evaluated coverage of requirements, etc. by the selected an alternative Overall created a basis for further analysis and rationalization (of e.g. costs) Important next step for the iteration #1 is to reflect on iteration strategy Organize iterations based on... - Use Cases - Building Blocks - Actors 141 Department of Computer Sciences University of Basel

142 Iteration Planning Activity No matter which strategy you chose there are pros and cons always Therefore the team needs to also understand mitigation strategies Use Case oriented iterations mitigations - Plan / conceptualize a fundament which sufficiently outlines its basic schema - Identify Use Case groups which are heavily based on the same sub-set of fundamental building blocks - Build respective building blocks first - Then build out the selected use cases, iteratively building block oriented iterations - Plan / conceptualize fundament - Identify use cases which you need early on in order to e.g. maintain master data in the system - Build fundament for these use cases first - Build the selected use cases atop in order to make parts o the system visible early on - Focus on the fundamental building block s core feature, only finalize and complete them during later iterations ( the «final icing» can often be postponed) Actor oriented iterations - Put not all your eggs in one (Actor) basket - Balance the high-prio actor group with actors that require totally different use cases of the system 142 Department of Computer Sciences University of Basel

143 Iteration Planning Activity evaccine project team has chosen to go with an building block oriented iteration strategy Dev System Set-Up Patient Module Physician UI Master-Data Mgmt Physician Module Maintainer UI Connector Framework Vaccine Module Patient UI User Management System-wide NFRs Identity Mgmt. System 143 Department of Computer Sciences University of Basel

144 Iteration Planning Result Iteration Plan 144 Department of Computer Sciences University of Basel

145 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 10 Alternative Selection 11 Iteration Planning 12 Iteration & Inception Closure / Retrospective 13 Define the Enterprise Context 14 Refine Principles and Requirements Initiation #1 #2 #3 #4 #5 #N Transition & Operation 145 Department of Computer Sciences University of Basel

146 Iteration Closure Activity evaccine Card s project team also created an s first increment 146 Department of Computer Sciences University of Basel

147 Iteration Closure Activity Further debriefing of an iteration includes what went good / wrong? how was the team s velocity with regards to its anticipated velocity? which work-items were finally popped off the work-items list? which work-items pushed onto the work-items list? what were significant changes that occured during this iteration? - risk profile changed - organisational changes (e.g. budget, timelines, resources) - change regarding direction (e.g. requirements functional and non-functional) how can the overall process (for further iterations) be improved? - team cooperation - artifacts - tooling - etc. 147 Department of Computer Sciences University of Basel

148 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 10 Alternative Selection 11 Iteration Planning 12 Iteration & Inception Closure / Retrospective 13 Define the Enterprise Context 14 Refine Principles and Requirements Initiation #1 #2 #3 #4 #5 #N Transition & Operation 148 Department of Computer Sciences University of Basel

149 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 149 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 149

150 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 150 Department of Computer Sciences University of Basel

151 Define Enterprise Context Context Step 1: Enterprise Context Objective Roles Understand project and envisioned solution within a company s broader Enterprise and Domain context Analyse impacts and changes to the As-Is Enterprise architecture landscapes based on envisioned solution s future shape Understand gaps, overlaps, deficiencies, strengths of As-Is Enterprise architecture context regarding Capabilities Services Processes Information Applications Technologies - Solution Architect, Business Analyst, Enterprise Architect 151 Department of Computer Sciences University of Basel

152 Define Enterprise Context Context profecard the selected solution mandates specific mobile devices Need to be android and HTML5 compatible From an Enterprise Context perspective the e-card team Needs to verify technology standards conformance Has to understand the impacts of profecard system s introduction etc. (1) «Enterprise» may refer to the architecture of an entire enterprise, the architecture of an 152 Department of Computer Sciences University of Basel entire sub-organization, the architecture of a selected domain (e.g. Network, CRM)

153 Define Enterprise Context Activity Zooming into technical capability «Device» verifies that android-as well as HTML5-compatible devices are covered by improvehealth s standards 153 Department of Computer Sciences University of Basel (1) Results of the EA assessments are outlined on the following slides

154 Define Enterprise Context Activity If this hadn t played out that well, the e-vaccination Card team had to.. Request standard exception from the enterprise architecture governance function Propose profecard s device types as new standards to be introduced to improvehealth Reiterate the COTS decision and select a standard-conform COTS solution 154 Department of Computer Sciences University of Basel (1) Results of the EA assessments are outlined on the following slides

155 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 10 Alternative Selection 11 Iteration Planning 12 Iteration & Inception Closure / Retrospective 13 Define the Enterprise Context 14 Refine Principles and Requirements Initiation #1 #2 #3 #4 #5 #N Transition & Operation 155 Department of Computer Sciences University of Basel

156 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 156 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 156

157 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 157 Department of Computer Sciences University of Basel

158 Refine Principles and Requirements Context Step 2: Refine Principles and Requirements Objective Roles This step is about generating and documenting a common understanding of what is expected and possible under the given conditions, taking into account all factors driving the architecture. Describe the quality attributes of the Computer System, and the constraints that the solution must satisfy to deliver the business goals, objectives, or capabilities. Assess sizing, cost, and viability of the proposed Computer System, which is very much driven by given non-functional requirements. Crucial within this step is to differentiate those requirements that are architecture significant from the ones that are not. - Solution Architect, Business Analyst, Enterprise Architect 158 Department of Computer Sciences University of Basel

159 Refine Principles and Requirements Context Two additional requirements were brought up during iteration #1 Requirement 1 - Patients and physicians who self-register are to be semi-automatically provisioned to improvehealth s Identity system. - Manual approval of requested registration is required by Actor «Maintainer» Requirement 2 - The solution is to be set-up in such a way that it can be rolled-out / adopted / scaledup to other business units of the improvehealth enterprise - This is important since several of improvehalth s business units maintain a notion of a patient-centric «passport» - This requirement indicates that there is a set of common need-characteristics across all business units as well as a set of business unit specific needs and that profecard has to be set-up and configured to be able to cope with both: Common business unit needs Specific business unit needs 159 Department of Computer Sciences University of Basel

160 Refine Principles and Requirements Result Updated significant non-functional requirements 160 Department of Computer Sciences University of Basel

161 Refine Principles and Requirements Context An important consideration that Requirement 2 brought up Can be dealt with by a COTS system via - Multi-tenancy capability of the COTS system - Alternatively: by an architecture approach where the COTS system (which is not multi-tenancy capable) is surrounded by solution structures that allow the coresystem (COTS) to be cloned multiple times while always being connected to a single back-end broker. This helps avoid cloning everything that the overall system has in common. Fundamental structures are only built-out once and can then be re-used by each cloned/deployed COTS system instance Will be further looked at throughout the next steps 161 Department of Computer Sciences University of Basel

162 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 15 Develop System Context 16 Develop Application 17 Develop Data 18 Develop Technology 17 Elaborate Cross-Cutting Perspective (Usability Internationalization) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 162 Department of Computer Sciences University of Basel

163 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 163 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 163

164 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 164 Department of Computer Sciences University of Basel

165 Elaborate System Context Context Step 5: Elaborate System Context Objective Roles This step describes the solution as a whole and from a black-box perspective by capturing its highest level solution structures as well as relationships which exist between these and external entities crossing the given system s boundaries. To provide an overview of interfaces to be considered in the solution design. To verify that the information flows between the system and its external factors (i.e. external systems and actors) are in alignment with the external system owners expectations and commitments. To communicate at a high level the system boundaries to respective stakeholder groups. - Solution Architect, Business Analyst, Enterprise Architect 165 Department of Computer Sciences University of Basel

166 Elaborate System Context Context The e-vaccination Card team elaborates the System Context further based on this recently added requirement profecard s documentation clarified that the system is not multitenancy capable Therefore the team decides to complement the overall approach by additional solution structures 166 Department of Computer Sciences University of Basel

167 Set-up / operated out of one single multi-tenancy capable system Logically separated Units Elaborate System Context Context Excurs: multi-tenancy Client «BU 1» Client «BU 2» Client «BU 3» Data Set A PK Name Description 1 Max Description of Max.. 2 Moritz Description of Moritz.. FK Data Set A PK Name Description 1 Max Description of Max.. 2 Moritz Description of Moritz.. FK Data Set A PK Name Description 1 Max Description of Max.. 2 Moritz Description of Moritz.. FK Data Set B PK Name Description 1 Audi A8 Description of Audi A8.. 2 VW Käfer Description of Moritz.. FK Data Set B PK Name Description 1 Audi A8 Description of Audi A8.. 2 VW Käfer Description of Moritz.. FK Data Set B PK Name Description 1 Audi A8 Description of Audi A8.. 2 VW Käfer Description of Moritz.. FK Data Set A Client PK Name Description FK BU 1 1 Max Description of Max... BU 2 1 Max Description of Max... Data Set B Client PK Name Description FK BU 1 1 Audi A8 Description of Audi... BU 2 1 Audi A8 Description of Audi Department of Computer Sciences University of Basel

168 Elaborate System Context Activity As a result of this step the team updated the System Context diagram 168 Department of Computer Sciences University of Basel

169 Elaborate System Context Activity As a result of this step the team updated the System Context diagram 169 Department of Computer Sciences University of Basel

170 Elaborate System Context Activity The team decides to continue and zoom into the Application viewpoint in order to elaborate the multi-tenancy requirement further 170 Department of Computer Sciences University of Basel

171 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 15 Develop System Context 16 Develop Application 17 Develop Data 18 Develop Technology 17 Elaborate Cross-Cutting Perspective (Usability Internationalization) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 171 Department of Computer Sciences University of Basel

172 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 172 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 172

173 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 173 Department of Computer Sciences University of Basel

174 Elaborate Application Context Step 7: Elaborate Application Objective Roles In this step the architect develops a model, which depicts the solution s core functional building blocks (i.e. Application Components) as well as their inter-dependencies. Beyond the solution s functional decomposition, this step also elaborates the realization of use cases which were captured by use case descriptions in the functional requirements step. Identify potential or final Application Components that will be responsible to provide the required functionality. Outline the relationships that exist between Application Components. - Solution Architect 174 Department of Computer Sciences University of Basel

175 Elaborate Application Context In order to elaborate on the multi-tenancy capability first, the team Wants to understand application architecture implications of an addtional component («multi-tenancy broker» as per the System Context) better And therefore decides to investigate an appropriate brokerage scenario 175 Department of Computer Sciences University of Basel

176 Elaborate Application Context This step helped clarify «Multi-Tenancy Broker» responsibilities and lead to the following conclusions «multi-tenancy broker» shall be made part of the e-vaccination Card system s scope This means it is again taken out of the System Context (will be updated later) Decision was taken due to the fact that «Multi-Tenancy Broker»... - Enables key non-functional capabilities (e.g. reusability) of e-vaccination Card - Makes e-vaccination Card a lot more generic 176 Department of Computer Sciences University of Basel

177 Elaborate Application Activity The updated Application viewpoint 177 Department of Computer Sciences University of Basel

178 Elaborate Application Activity The updated Application viewpoint 178 Department of Computer Sciences University of Basel

179 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 15 Develop System Context 16 Develop Application 17 Develop Data 18 Develop Technology 17 Elaborate Cross-Cutting Perspective (Usability Internationalization) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 179 Department of Computer Sciences University of Basel

180 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 180 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 180

181 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 181 Department of Computer Sciences University of Basel

182 Elaborate Data Context Step 8: Elaborate Data Objective Roles This step observes and captures key information objects as well as their inter-relationships and ownership in scope of the solution. A Data s is THE corner stone of any IT solution, and this is why an Architect must pay serious attention to this step. Any function that a solution exposes at its outside is fully based on its Data s inherent information capabilities thus stays or falls with its quality, and completeness. Describe semantics, flows, structure as well as ownership of the managed information Investigate, understand, and describe approaches to data migration - Solution Architect 182 Department of Computer Sciences University of Basel

183 Elaborate Data Context The introduction of «Multi-Tenancy Broker» has an impact to the Data viewpoint There are several questions that this introduction raises: Onto which system will this information be placed? Who will own and maintain this information? Since this information drives the fundamental architecture of e-vaccination Card: how does the team cope with this from a security and compliance perspective? 183 Department of Computer Sciences University of Basel

184 Elaborate Data Activity Also and based on Vision s depicted information needs profecard can be proven to match all respective data structures 184 Department of Computer Sciences University of Basel

185 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 15 Develop System Context 16 Develop Application 17 Develop Data 18 Develop Technology 17 Elaborate Cross-Cutting Perspective (Usability Internationalization) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 185 Department of Computer Sciences University of Basel

186 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 186 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 186

187 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 187 Department of Computer Sciences University of Basel

188 Elaborate Technology Context Step 9: Elaborate Technology Objective Roles Where the Application describes a solution s key functional building blocks (aka: Application Components) and their interconnections, the Technology elaborates the Application Components operational underpinnings. With the Technology an Architect creates a model of System Components and their respective inter-connections. The Architect also develops a model that explains how each of the Application Components in the Application are mapped onto one or more System Components in the Technology An Architect uses the Technology mainly to verify coverage of all non-functional requirements and quality attributes the solution is expected to have. - Solution Architect 188 Department of Computer Sciences University of Basel

189 Elaborate Technology Context Multi-tenancy Broker as it is introduced conceptually as well as to the Application and Data raises two questions here Which technology component can be used to cover the need to maintain the «business unit name bind target» information Which technology component will underpin the application component «multi-tenancy broker»? The separation of infrastructure underpinnings of.. Multi-Tenancy Broker And the remaining proportions of e-vaccination Card (i.e. profecard)... makes a lot of sense, since «Multi-Tenancy Broker» will exist only once for all clones / instances of the profecard system 189 Department of Computer Sciences University of Basel

190 Elaborate Technology Context Furthermore the team wants to zoom into more detail around the development environment s design of the e-vaccination Card system profecard documentation is consulted in order to determine required ITinfrastructure underpinnings among these are: X86 / WinServer7 vsphere Virtual Servers CISCO HW LoadBalancers SSL accelerator cards (recommended) Also attention is paid to standards-conformance regarding improvehealth s technology standards vcenter needs to be consumed via improvehealth s VBlock (1) service (1) VBlock is an applicance which provides an integrated platform comprised of.. - hypervisor (vsphere) - Network - Storage (SAN) 190 Department of Computer Sciences University of Basel

191 Elaborate Technology Context Reflecting back on iteration #1 Technology the team realizes that not all technology architecture layers are covered, yet What s covered so far is this technology architecture layer: - Application infrastructure / middleware These components, for example, are not yet covered: - X86 / WinServer7 - vsphere Virtual Servers 191 Department of Computer Sciences University of Basel

192 Elaborate Technology Context Technology covers a broad variety of technical systems where these systems are often categorized by the notion of vertically stacked layers (i.e. layered system) A coarse grained notion of this is introduced by the view model used Application infrastructure IT-infrastructure 192 Department of Computer Sciences University of Basel

193 Elaborate Technology Context Looking a little closer at both layers we see that Application Infrastructure is very much geared to underpin application components (which is reflected by the tiering of typical app-infra components) Technology Application Infrastructure IT-Infrastructure 193 Department of Computer Sciences University of Basel

194 Elaborate Technology Context Looking a little closer at both layers we see that IT-Infrastructure is usually further layered and stacked Technology Application Infrastructure IT-Infrastructure 194 Department of Computer Sciences University of Basel

195 Elaborate Technology Context Typical technology components that can be found across the below vertical layers are Department of Computer Sciences University of Basel

196 Elaborate Technology Activity Update of the Technology viewpoint Network zones are now mentioned as well Technology as per company s standards Additional components are introduced Infrastructure for «Multi- Tenancy Broker» has also been introduced to the picture 196 Department of Computer Sciences University of Basel

197 Elaborate Technology Activity More details are elaborated regarding selected technology components 197 Department of Computer Sciences University of Basel

198 Elaborate Technology Activity Now that both, Application and Technology have matured a deployment model explains Which deployment units exist Which application components are bundled into which deployment unit Which (+possibly how) deployment units are deployed into which technology component 198 Department of Computer Sciences University of Basel

199 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 15 Develop System Context 16 Develop Application 17 Develop Data 18 Develop Technology 17 Elaborate Cross-Cutting Perspective (Usability Internationalization) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 199 Department of Computer Sciences University of Basel

200 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 200 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 200

201 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 201 Department of Computer Sciences University of Basel

202 Elaborate Cross-Cutting Perspective Context Step 10: Elaborate Cross-Cutting Perspective Objective Roles Cross-cutting architecture perspectives need to be elaborated based on: Application (solution s fundamental functional structures) Technology (solution s operational underpinnings) Data (solution s underlying data structures and flows) Cross-cutting architecture perspectives mainly cover a solution s nonfunctional capabilities and are spanning all above viewpoints Key non-functional areas the covers are: Security Performance and Scalability Availability and Reliability Extensibility and evolutionary fitness - Solution Architect 202 Department of Computer Sciences University of Basel

203 Elaborate Cross-Cutting Perspective Context The team decided to take on NFR after the other and investigate its realization along Application Data Technology First NFR which is picked is I18N 203 Department of Computer Sciences University of Basel

204 Elaborate Cross-Cutting Perspective Context Deep-Dive By reading profecard s system documentation we learn that this feature is built into the «Master Data Module» component Let s understand how they have approached the I18N feature, internally Different architectural approaches exist, when a system needs to be kept open for changes over its life-span: Interpreter approaches Generative approaches Modularization Container-component model Extension points and customization hooks (FW Hollywood Principle) 204 Department of Computer Sciences University of Basel

205 Elaborate Cross-Cutting Perspective Context Deep-Dive For the implementation of their configurable I18N feature, profecard picked a combination of a.. container-component model approach specific architecture pattern «Container-component» is supported by JEE s programming model Component Deployment Descriptor Container 205 Department of Computer Sciences University of Basel

206 Elaborate Cross-Cutting Perspective Context Deep-Dive The rational behind this approach is that profecard implemented a model, that allows for complex tailoring of their UI (e.g. not just terms but also gestures, layout sequences, fonts & styles) Login Dialog Vaccine Info Dialog Incident Report English Style User Password submit Name Description Dose Constraints submit Inc-No Incident Detail 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> Anmelden Vaccine Info Dialog Incident Report German Style Benutzer Passwort **** Daten dieser Anwendung sind vertraulich! Anmelden Name Dosis Beschreibung Nebenwirkung Ändern Inc-No Incident Detail 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> 1 <details-for-1> 206 Department of Computer Sciences University of Basel

207 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their I18N capabilities based on this model 207 Department of Computer Sciences University of Basel

208 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their I18N capabilities based on this model 208 Department of Computer Sciences University of Basel

209 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their I18N capabilities based on this model 209 Department of Computer Sciences University of Basel

210 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their I18N capabilities based on this model 210 Department of Computer Sciences University of Basel

211 Elaborate Cross-Cutting Perspective Context Deep-Dive How «Master Data Module» uses profecard s model 211 Department of Computer Sciences University of Basel

212 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 18 (reflect on progress) 19 Develop Application (Workflow Module) 20 Develop Application (Provision Patient Module) 21 Elaborate Cross-Cutting Perspective (Customizability Interpreter) 22 Elaborate Cross-Cutting Perspective (Modifiability Adapter) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 212 Department of Computer Sciences University of Basel

213 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 213 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 213

214 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 214 Department of Computer Sciences University of Basel

215 Reflection Overview The e-vaccination Card team wants to quickly reflect on their progress Therefore they hold iteration #1 AH against the #2 AH 215 Department of Computer Sciences University of Basel

216 Reflection Overview 216 Department of Computer Sciences University of Basel

217 Reflection Overview 217 Department of Computer Sciences University of Basel

218 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 18 (reflect on progress) 19 Develop Application (Workflow Module) 20 Develop Application (Provision Patient Module) 21 Elaborate Cross-Cutting Perspective (Customizability Interpreter) 22 Elaborate Cross-Cutting Perspective (Modifiability Adapter) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 218 Department of Computer Sciences University of Basel

219 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 219 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 219

220 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 220 Department of Computer Sciences University of Basel

221 Elaborate Application Context Step 7: Elaborate Application Objective Roles In this step the architect develops a model, which depicts the solution s core functional building blocks (i.e. Application Components) as well as their inter-dependencies. Beyond the solution s functional decomposition, this step also elaborates the realization of use cases which were captured by use case descriptions in the functional requirements step. Identify potential or final Application Components that will be responsible to provide the required functionality. Outline the relationships that exist between Application Components. - Solution Architect 221 Department of Computer Sciences University of Basel

222 Elaborate Application Context As a next step the e-vaccination Card Team wants to zoom deeper into Multi Tenancy Broker (MTB) A sub-team has already developed some considerations Driver-based approach should help encapsulate communication to concrete downstream systems (i.e. decouple between MTB and connected systems) Provide common API (e.g. to communicate with «Patient Module») Introduce notion of «workflow» which addresses - Possiblity to configure and register workflows which control the provisioning of data through MTB Introduce notion of «tenant» which addresses - Multiple instances of e.g. «Patient Module» may exist due to profecard clones - MTB provides a common interface to talk to all these instances uniquely - A tenant is qualified by Business Unit Name Bind-target (technical bind-address (e.g. sqlnet End-Point)) Driver Class Name 222 Department of Computer Sciences University of Basel

223 Elaborate Application Context Overview Diagram of Multi Tenancy Broker 223 Department of Computer Sciences University of Basel

224 Elaborate Application Context The team decides to first elaborate «Work-Flow Module» It is important to distinguish.. - Design-Time from - Run-Time.. perspective when discussing workflows Design-Time View of a workflow definition Role X Activity 2 Activity 1 Decision A Join A Update data External System A External System B Base decision on data Role Y Activity 3 Manual Intervention 224 Department of Computer Sciences University of Basel

225 Elaborate Application Context Run-Time View of a workflow definition (continued) Workflow definition is used as basic schema to..... to instantiate multiple runtme instances upon it 225 Department of Computer Sciences University of Basel

226 Elaborate Application Context Systems that offer WF-capabilities often provide tools like outlined below Vaccine Info Dialog Workflow Design Area Workflow Components Activity 1 Decision A Role X Activity 2 Decision B Activity 1 Decision A Activity 3 Decision C Update data External System A External System B Base decision on data Join A Join B External Systems External System A Intervention points Role Y Create Workflow Save Workflow 226 Department of Computer Sciences University of Basel

227 Elaborate Application Context How are such systems built internally? 227 Department of Computer Sciences University of Basel

228 Elaborate Application Context How are such systems built internally? 228 Department of Computer Sciences University of Basel

229 Elaborate Application Context How are such systems built internally? 229 Department of Computer Sciences University of Basel

230 Elaborate Application Context How are such systems built internally? 230 Department of Computer Sciences University of Basel

231 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 18 (reflect on progress) 19 Develop Application (Workflow Module) 20 Develop Application (Provision Patient Module) 21 Elaborate Cross-Cutting Perspective (Customizability Interpreter) 22 Elaborate Cross-Cutting Perspective (Modifiability Adapter) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 231 Department of Computer Sciences University of Basel

232 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 232 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 232

233 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 233 Department of Computer Sciences University of Basel

234 Elaborate Application Context Step 7: Elaborate Application Objective Roles In this step the architect develops a model, which depicts the solution s core functional building blocks (i.e. Application Components) as well as their inter-dependencies. Beyond the solution s functional decomposition, this step also elaborates the realization of use cases which were captured by use case descriptions in the functional requirements step. Identify potential or final Application Components that will be responsible to provide the required functionality. Outline the relationships that exist between Application Components. - Solution Architect 234 Department of Computer Sciences University of Basel

235 Elaborate Application Context As a next step the e-vaccination Card Team wants to zoom deeper into Multi Tenancy Broker (MTB) A sub-team has already developed some considerations Driver-based approach should help encapsulate communication to concrete downstream systems (i.e. decouple between MTB and connected systems) Provide common API (e.g. to communicate with «Patient Module») Introduce notion of «workflow» which addresses - Possiblity to configure and register workflows which control the provisioning of data through MTB Introduce notion of «tenant» which addresses - Multiple instances of e.g. «Patient Module» may exist due to profecard clones - MTB provides a common interface to talk to all these instances uniquely - A tenant is qualified by Business Unit Name Bind-target (technical bind-address (e.g. sqlnet End-Point)) Driver Class Name 235 Department of Computer Sciences University of Basel

236 Elaborate Application Context Overview Diagram of Multi Tenancy Broker 236 Department of Computer Sciences University of Basel

237 Elaborate Application Context This time the team gives a closer look to «ProvisionPatientModule» 237 Department of Computer Sciences University of Basel

238 Elaborate Application Context Remember the broader context here also 238 Department of Computer Sciences University of Basel

239 Elaborate Application Context First the Team guarantees the core module s public interface 239 Department of Computer Sciences University of Basel

240 Elaborate Application Context Next a data structure is introduced which helps carry patient information 240 Department of Computer Sciences University of Basel

241 Elaborate Application Context The main module shall run off a standard provisioning process Department of Computer Sciences University of Basel

242 Elaborate Application Context.. where the provisioning logic can be loaded via appropriate workflows 242 Department of Computer Sciences University of Basel

243 Elaborate Application Context Finally we just need the naming service referred to alreay 243 Department of Computer Sciences University of Basel

244 Elaborate Application Context Now we have already seen a reference to a module «Patient» 244 Department of Computer Sciences University of Basel

245 Elaborate Application Context Now we have already seen a reference to a module «Patient» 245 Department of Computer Sciences University of Basel

246 Elaborate Application Context Now we have already seen a reference to a module «Patient» 246 Department of Computer Sciences University of Basel

247 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 18 (reflect on progress) 19 Develop Application (Workflow Module) 20 Develop Application (Provision Patient Module) 21 Elaborate Cross-Cutting Perspective (Customizability Interpreter) 22 Elaborate Cross-Cutting Perspective (Modifiability Adapter) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 247 Department of Computer Sciences University of Basel

248 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 248 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 248

249 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 249 Department of Computer Sciences University of Basel

250 Elaborate Cross-Cutting Perspective Context Step 10: Elaborate Cross-Cutting Perspective Objective Roles Cross-cutting architecture perspectives need to be elaborated based on: Application (solution s fundamental functional structures) Technology (solution s operational underpinnings) Data (solution s underlying data structures and flows) Cross-cutting architecture perspectives mainly cover a solution s nonfunctional capabilities and are spanning all above viewpoints Key non-functional areas the covers are: Security Performance and Scalability Availability and Reliability Extensibility and evolutionary fitness - Solution Architect 250 Department of Computer Sciences University of Basel

251 Elaborate Cross-Cutting Perspective Context The first NFR of I18N was already built into the system In the meanwhile another workshop was held with all Stakeholders In this workshop to more requirements were spotted and formally added to the due to their architecture-significance: The Customizability requirement is picked for further elaboration here 251 Department of Computer Sciences University of Basel

252 Elaborate Cross-Cutting Perspective Context Deep-Dive Let s put ourselves into the shoes of the profecard team to see how they realized the module «Connector Framework / Customization API» 252 Department of Computer Sciences University of Basel

253 Elaborate Cross-Cutting Perspective Context Deep-Dive Generally different types of approaches exist to introduce Customizability: Data-driven (meta-data approaches) Generater-driven (generater approaches) Configuration (point & Click, configuration files, property pages) APIs and Code Libraries Interpreters profecard picked.. the Interpreter approach combined with APIs and Code Libraries 253 Department of Computer Sciences University of Basel

254 Elaborate Cross-Cutting Perspective Context Deep-Dive From a high-level perspective this is the modular structure of profecard s customizable «Connector Framework / Customization API» But how was the Interpreter implemented? Customization Framework / API Development Bench Interpreter Test Bench Connector Object Model (COM) Connectivity Protocols Security Plugability Connector Framework 254 Department of Computer Sciences University of Basel

255 Elaborate Cross-Cutting Perspective Context Deep-Dive Before we look into the profecard s implementation of Interpreter more light has to be shed at the implementation of «Connector Object Model (COM)» Connector Object Model (COM) Beyond the provision of fundamental objects profecard s Connector Object Model provides a means to work on stream input and output The approach they took allows to very flexibly wrap streams one into another thus to increase the richness of features that are availble to a programmer 255 Department of Computer Sciences University of Basel

256 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their streaming API based on this model 256 Department of Computer Sciences University of Basel

257 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their streaming API based on this model 257 Department of Computer Sciences University of Basel

258 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their streaming API based on this model 258 Department of Computer Sciences University of Basel

259 Elaborate Cross-Cutting Perspective Context Deep-Dive How «Connector Framework / Customization API» uses profecard s Streaming API 259 Department of Computer Sciences University of Basel

260 Elaborate Cross-Cutting Perspective Context Deep-Dive Now that we saw how profecard implemented an important aspect of their «Connector Object Model (COM)» we want to also understand how they approached their Interpreter Component Interpreter 260 Department of Computer Sciences University of Basel

261 Elaborate Cross-Cutting Perspective Context Deep-Dive In order to stand how an Interpreter works, let us look at an example A simple algebra language which supports.. - summation - multiplication - numbers The following expression... + ( ) * Would for example result in this parse tree * Department of Computer Sciences University of Basel

262 Elaborate Cross-Cutting Perspective Context Deep-Dive In order to stand how an Interpreter works, let us look at an example + ( ) * source stream Lexical Analysis (Scanner) token stream + ( ) * grammar x token stream Syntax Analysis (Parser) parse tree x symbol table name type value xvar int 15 yvar float Department of Computer Sciences University of Basel

263 Elaborate Cross-Cutting Perspective Context Deep-Dive Now let us look at the language profecard supports with their Interpreter profecard Interpreter supports the following language constructs.. - Sequences - Iterations - Conditional branching START := prog-start LIST prog-end LIST := STATEMENT LIST LIST := <e> STATEMENT := S-ATOMIC STATEMENT := S-IF STATEMENT := S-LOOP S-ATOMIC := print ( <id> ) S-ATOMIC := readstream ( <id> ) This is where the Interpreter is linked with the Connector Object S-ATOMIC := writestream ( <id> ) Model (COM) S-IF := if ( COND ) { LIST } else { LIST } S-LOOP := while ( COND ) { LIST } COND := <id> OP <id> OP := < OP := == OP := > 263 Department of Computer Sciences University of Basel

264 Elaborate Cross-Cutting Perspective Context Deep-Dive Now let us look at the language profecard supports with their Interpreter profecard Interpreter supports the following language constructs.. - Sequences - Iterations - Conditional branching START := prog-start LIST prog-end LIST prog-start := STATEMENT LIST LIST := <e> int x = 100 STATEMENT := S-ATOMIC int y = 200 STATEMENT := S-IF int z = 300 STATEMENT := S-LOOP S-ATOMIC := print print ( <id> ( x ) ) S-ATOMIC := readstream if ( x < 200 ( <id> ) { ) This is where the Interpreter is linked with the Connector Object S-ATOMIC := writestream ( <id> print ) ( y ) Model (COM) S-IF := if (} else COND { ) { LIST } else { LIST } S-LOOP := while ( COND ) print { LIST ( z ) } COND := <id> } OP <id> OP := < while ( z < 310 ) { // z gets automatically incremented by 1 per each loop iteration (implicit OP := == //increment) OP := > print ( z ) } prog-end 264 Department of Computer Sciences University of Basel

265 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model 265 Department of Computer Sciences University of Basel

266 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model 266 Department of Computer Sciences University of Basel

267 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model 267 Department of Computer Sciences University of Basel

268 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model 268 Department of Computer Sciences University of Basel

269 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model 269 Department of Computer Sciences University of Basel

270 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model 270 Department of Computer Sciences University of Basel

271 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model 271 Department of Computer Sciences University of Basel

272 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model Interpreter 272 Department of Computer Sciences University of Basel

273 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Interpreter based on this model Interpreter prog-start prog-end int x = 100 int y = 200 int z = 300 print ( x ) if ( x < 200 ) { print ( y ) } else { print ( z ) } x = 500 print ( x ) while ( z < 310 ) { // z gets automatically incremented by 1 per each loop iteration (implicit //increment) print ( z ) } 273 Department of Computer Sciences University of Basel

274 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 18 (reflect on progress) 19 Develop Application (Workflow Module) 20 Develop Application (Provision Patient Module) 21 Elaborate Cross-Cutting Perspective (Customizability Interpreter) 22 Elaborate Cross-Cutting Perspective (Modifiability Adapter) Initiation #1 #2 #3 #4 #5 #N Transition & Operation 274 Department of Computer Sciences University of Basel

275 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 275 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 275

276 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 276 Department of Computer Sciences University of Basel

277 Elaborate Cross-Cutting Perspective Context Step 10: Elaborate Cross-Cutting Perspective Objective Roles Cross-cutting architecture perspectives need to be elaborated based on: Application (solution s fundamental functional structures) Technology (solution s operational underpinnings) Data (solution s underlying data structures and flows) Cross-cutting architecture perspectives mainly cover a solution s nonfunctional capabilities and are spanning all above viewpoints Key non-functional areas the covers are: Security Performance and Scalability Availability and Reliability Extensibility and evolutionary fitness - Solution Architect 277 Department of Computer Sciences University of Basel

278 Elaborate Cross-Cutting Perspective Context Remember that in a recent workshop more requirements were spotted and formally added to the : The Customizability requirement was picked already Now it is time for the Adaptability requirement to be further elaborated 278 Department of Computer Sciences University of Basel

279 Elaborate Cross-Cutting Perspective Context Deep-Dive The Adaptability requirement is one that profecard also realized in their module «Connector Framework / Customization API» 279 Department of Computer Sciences University of Basel

280 Elaborate Cross-Cutting Perspective Context Deep-Dive There are again many different ways to approach adaptability: Data-driven (meta-data approaches) Generater-driven (generater approaches) Configuration (point & Click, configuration files, property pages) APIs and Code Libraries Interpreters Realization of the Adapter pattern profecard picked.. The realization of the Adapter pattern as their method of choice 280 Department of Computer Sciences University of Basel

281 Elaborate Cross-Cutting Perspective Context Deep-Dive The Adapter pattern enables the combined use of profecard s connector framework and a proprietary class libary s connector class Furthermore does the class libary s class not fit profecard s connector framework interface Concrete Connectors to Target Systems Proprietary Connector Adapter Connector B Connector A Connector B Connector Framework Interface Connector Framework 281 Department of Computer Sciences University of Basel

282 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Adapter extension based on this model 282 Department of Computer Sciences University of Basel

283 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Adapter extension based on this model 283 Department of Computer Sciences University of Basel

284 Elaborate Cross-Cutting Perspective Context Deep-Dive profecard implemented their Adapter extension based on this model 284 Department of Computer Sciences University of Basel

285 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 21 Develop Technology 22 Develop Security Perspective Initiation #1 #2 #3 #4 #5 #N Transition & Operation 285 Department of Computer Sciences University of Basel

286 Development Process Context Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 286 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 286

287 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 287 Department of Computer Sciences University of Basel

288 Elaborate Technology Context Step 9: Elaborate Technology Objective Roles Where the Application describes a solution s key functional building blocks (aka: Application Components) and their interconnections, the Technology elaborates the Application Components operational underpinnings. With the Technology an Architect creates a model of System Components and their respective inter-connections. The Architect also develops a model that explains how each of the Application Components in the Application are mapped onto one or more System Components in the Technology An Architect uses the Technology mainly to verify coverage of all non-functional requirements and quality attributes the solution is expected to have. - Solution Architect 288 Department of Computer Sciences University of Basel

289 Elaborate Technology Context The team raises the question how the identified modules of Multitenancy Broker are deployed to underpinning technology components A coarse grained deployment model already exists 289 Department of Computer Sciences University of Basel

290 Elaborate Technology Context But how does the next level of detail look like for the Multi Tenancy Broker s components? 290 Department of Computer Sciences University of Basel

291 Elaborate Technology Context But how does the next level of detail look like for the Multi Tenancy Broker s components? 291 Department of Computer Sciences University of Basel

292 Elaborate Technology Context The team decided to created deployment units as outlined, below 292 Department of Computer Sciences University of Basel

293 Case Study e-vaccine Card Steps Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution 21 Develop Technology 22 Develop Security Perspective Initiation #1 #2 #3 #4 #5 #N Transition & Operation 293 Department of Computer Sciences University of Basel

294 Elaborate Security Perspective Case Study Step 10: Elaborate Cross-Cutting Perspective Objective Roles Cross-cutting architecture perspectives need to be elaborated based on: Application (solution s fundamental functional structures) Technology (solution s operational underpinnings) Data (solution s underlying data structures and flows) Cross-cutting architecture perspectives mainly cover a solution s nonfunctional capabilities and are spanning all above viewpoints Key non-functional areas the covers are: Security Performance and Scalability Availability and Reliability Extensibility and evolutionary fitness - Solution Architect 294 Department of Computer Sciences University of Basel

295 Development Process Case Study Do the right thing Do the thing right Run it right Retire it right Plan Build Operate Retire Inception Elaboration Construction Transition Idea Creation & Verification Problem understanding & precision Conceptualize adequate solution outline Implemention of conceptual solution outline Transition of implemented solution & verification Operate the solution Retire the solution Initiation 295 Department of Computer Sciences University of Basel #1 #2 #3 #4 #N Transition & Operation Department of Computer Sciences University of Basel 295

296 Security Perspective Availability & Reliability Perspective Performance & Scalability Perspective Extensibility Perspective View Model Context Enterprise Landscapes & Views Requirements Principles & Constraints Application Technology Data External Viewpoint Alternatives Functional Requirements Application Infrastructure System Context Non-Functional Requirements IT-Infrastructure Vision 296 Department of Computer Sciences University of Basel

297 Elaborate Security Perspective Case Study For each cross-cutting perspective the given chapter s key concern (e.g. Security) is elaborated across all relevant core views: -Application -Data -Technology For each of the core views only those building blocks are elaborated in detailed which are considered crucual from an architecture perspective. This allows, for example a Security Architect, to exclusively focus on those building blocks that the given solution s Security is comprised of while ignoring others. Architecting Security and other crosscutting concerns requires an Architect to work these out in an integrated (and cross-core-view) fashion. Beyond sketching, and observing these components across the core views, an Architect will also depict and describe how these components collaborate in order to realize specific scenarios 297 Department of Computer Sciences University of Basel

298 Security Perspective Elaborate Security Perspective Case Study One way to merge all three core views into a single perspective is to stereotype or color-code components and then use all components in an intermingled fashion to make up the single architecture perspetive Client Component Presentation Component IT Solution Business Logic Component Integration Component Persistence Component Application Data Technology 298 Department of Computer Sciences University of Basel

299 Elaborate Security Perspective Case Study Application Data Technology 299 Department of Computer Sciences University of Basel

300 Elaborate Security Perspective Case Study Application Data Technology 300 Department of Computer Sciences University of Basel

301 Elaborate Security Perspective Case Study Application Data Technology 301 Department of Computer Sciences University of Basel

302 Elaborate Security Perspective Case Study Application Data Technology 302 Department of Computer Sciences University of Basel

303 Elaborate Security Perspective Case Study Application Data Technology 303 Department of Computer Sciences University of Basel

304 Elaborate Security Perspective Case Study Application Data Technology 304 Department of Computer Sciences University of Basel

305 Elaborate Security Perspective Case Study Application Data Technology 305 Department of Computer Sciences University of Basel

306 Questions? 306 Department of Computer Sciences University of Basel

307 Introductory Notes Roles and Disciplines Solution Architect Technology Architect Security Architect Project Manager Enterprise Architect Solution Architect Oversees the overall solution architecture (top-2-bottom and end-2-end). Engages specialized architects roles on a need-basis. Technology Architect Specialized Architect who is responsible for engaging with the Solution Architect and to come up with an operational enabling architecture to underpin application components. Security Architect Specialized Architect who is responsible for the security related concerns of the overall IT solution. Similar roles exist who specialize in fields like availability, or extensibility Project Manager Responsible for managing the overall project throughout its life-cycle. Focusses on resources, timelines, budget, scope and engages with Solution Architect. Enterprise Architect Has a portfolio and strategic planning point of view onto IT platforms of a broader domain (e.g. whole Enterprise). Provides contextual input to a respective project. Department of Computer Sciences University of Basel 307