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

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

Embed Size (px)

Citation preview

1

Architecture Maturity & Requirements Engineering Process Maturity Do not Explain Each Other

Maya Daneva

2

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

3

Background 1. What we observe in practice? 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: What are the linkages between architecture maturity and

to RE process maturity? How these linkages evolve over phases of ERP evolution?

4

Maturity Concepts1. 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.

5

RE GoodPracticeGuide

ArchitectureMaturityModel

Maturity Concepts RE Processes

EA Processes

RE MaturityAssessments

ArchitectureAssessments

LinkagesLessonsLearnt

Our Approach

6

The Experience Base

2

1 Business initiatives vs. IS projects

Fast growing (immature) IS-organization

Process Instance Characteristics

total time = 4 weeks risk-driven approach

RE Teams

3

4

13 projects, 67 instances, 1997-2002

5 Assessments: RE Good Practice Guide (Sommerville & Sawer)

what worked?

what did not?

common points of success/failure?

7

RE Assessment Results

22 Defined Level processes 29 Repeatable Level processes 16 Initial Level Processes

8

Architecture Assessments

Establish mappingsbetween

assessment criteria & architecture

artifacts

Reviewarchitecture usage

scenarios,roles, standards,

process documentation

Reviewarchitecture

deliverables for small, mid-sized, & large projects

9

Results: DoC 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

10

How Architecture Supports RE: Observations

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

11

Discussion: Use of Architecture and RE Maturity Levels

  Maturity Level

Use of EA in: Initial Repeatable Defined

Requirements elicitation 37% 55% 72%

Requirements modelling 50% 76% 91%

Requirements negotiation/validation

50% 70% 91%

12

Discussion: Use of Architecture in Four Types of Projects

Use of EA in: Percentage of RE processes

RE for new implementation projects 36%

RE for enhancement projects 12%

RE for upgrade projects 91%

RE for alignment projects 100%

13

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 3rd 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%

14

Related Work1. 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!!

15

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.

16

Thank you !