Architecture Maturity Requirements Engineering Process Maturity Do not

  • Slides: 16
Download presentation
Architecture Maturity & Requirements Engineering Process Maturity Do not Explain Each Other Maya Daneva

Architecture Maturity & Requirements Engineering Process Maturity Do not Explain Each Other Maya Daneva 1

Contents 1. Introduction 2. Motivation, Research Questions & Research Method 3. Working Context 4.

Contents 1. Introduction 2. Motivation, Research Questions & Research Method 3. Working Context 4. Maturity Models for Architecture and Requirements Engineering 5. Case Study Based on One Company’s Experiences 6. Conclusions 2

Background 1. What we observe in practice? q q q ERP is a vehicle

Background 1. What we observe in practice? q q q ERP is a vehicle not only to excel but also to survive in a highly interconnected business world. Enterprise Architecture and ERP projects feed each other / share a number of deliverables ERP project failures are attributed to poor architecture reqmts 2. Research Questions: q What are the linkages between architecture maturity and to RE process maturity? q How these linkages evolve over phases of ERP evolution? 3

Maturity Concepts 1. IBM 2. 1989, SEI, CMU: Capability Maturity Model (CMM) for software

Maturity Concepts 1. IBM 2. 1989, SEI, CMU: Capability Maturity Model (CMM) for software development 3. Late 90 -ties: CMM in any IT field 4. Architecture Maturity Models (AMM) Goal: - to optimize architecture-related processes, - to increase organizational awareness of business and technical architecture issues. 4

Our Approach 5

Our Approach 5

The Experience Base 13 projects, 67 instances, 1997 -2002 1 Business initiatives vs. IS

The Experience Base 13 projects, 67 instances, 1997 -2002 1 Business initiatives vs. IS projects 2 Fast growing (immature) IS-organization 3 Process Instance Characteristics total time = 4 weeks risk-driven approach 4 RE Teams 5 Assessments: RE Good Practice Guide (Sommerville & Sawer) what worked? what did not? common points of success/failure? 6

RE Assessment Results q 22 Defined Level processes q 29 Repeatable Level processes q

RE Assessment Results q 22 Defined Level processes q 29 Repeatable Level processes q 16 Initial Level Processes 7

Architecture Assessments Establish mappings between assessment criteria & architecture artifacts Review architecture usage scenarios,

Architecture Assessments Establish mappings between assessment criteria & architecture artifacts Review architecture usage scenarios, roles, standards, process documentation Review architecture deliverables for small, mid-sized, & large projects 8

Results: Do. C AMM Maturity Characteristic Level Score Architecture process Managed 4 Architecture development

Results: Do. C AMM Maturity Characteristic Level Score Architecture process Managed 4 Architecture development Managed 4 Business linkage Defined 3 Senior management involvement Managed 4 Architecture communication Managed 4 Operating units’ participation Defined 3 IT security Managed 4 Architecture governance Defined 3 IT investment and acquisition strategy Under Development 2 9

How Architecture Supports RE: Observations q q Architecture facilitates use of common language Tool

How Architecture Supports RE: Observations q q Architecture facilitates use of common language Tool for training new team members Reuse of reference models Architecture provided guiding principles for documenting AS-IS and TO-BE scenarios 10

Discussion: Use of Architecture and RE Maturity Levels Maturity Level Initial Repeatabl e Define

Discussion: Use of Architecture and RE Maturity Levels Maturity Level Initial Repeatabl e Define d Requirements elicitation 37% 55% 72% Requirements modelling 50% 76% 91% Requirements negotiation/validation 50% 70% 91% Use of EA in: 11

Discussion: Use of Architecture in Four Types of Projects Use of EA in: Percen

Discussion: Use of Architecture in Four Types of Projects Use of EA in: Percen tage of RE proces ses RE for implementation projects new 36% RE for enhancement projects 12% RE for projects 91% upgrade 12

Discussion: Use of Architecture in ERP Customization Requirements Definitions Use of EA in the

Discussion: Use of Architecture in ERP Customization Requirements Definitions Use of EA in the tailoring types of: Description of tailoring type Percentage of RE processes Adaptation Setting of parameters & tables, in order to choose between different execution paths 57% Add-ons Implementation of 3 rd party package complementing the ERP system with branch-specific functionality 12% Screen masks Creating new screen mask for data input/output 0% Extended reporting Creating extended data reporting options 25% Workflow programming Developing non-standard workflows 100% User exits Programming of additional code in an open interface 26% ERP Programming Using the ERP-vendor’ programming language to develop additional applications to the standard functionality 12% 13

Related Work 1. We found consistencies regarding: - implicit choices between alternative starting points,

Related Work 1. We found consistencies regarding: - implicit choices between alternative starting points, namely architecture or business requirements; - both architecture and requirements help users build the system they want to use; 2. We found differences between levels of commitment of process owners to architecture and ERP projects 3. Merging enterprise architecture and RE is a bumpy road!! 14

Conclusions: A mature architecture organization does not imply ERP RE process success. A team

Conclusions: A mature architecture organization does not imply ERP RE process success. A team with high AMM maturity systematically helps ERP RE use architecture deliverables for RE purposes. This study revised our perspective to better accommodate the needs of explicit architecture practices in ERP RE. 15

Thank you ! 16

Thank you ! 16