Maya-Daneva-IWSM-2005-Montreal

Document Sample
Maya-Daneva-IWSM-2005-Montreal Powered By Docstoc
					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. 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?
   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?
                                                                     3
             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

Maturity Concepts   RE Processes


    RE Good
                                    RE Maturity
    Practice
                                   Assessments
     Guide
                                                             Lessons
                                                  Linkages
                                                              Learnt
  Architecture
                                   Architecture
    Maturity
                                   Assessments
     Model



                    EA Processes


                                                                       5
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?               common points of
                                   success/failure?
        what did not?
                                                          6
RE Assessment Results

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




                                  7
              Architecture Assessments
                                  Review
    Establish               architecture usage
    mappings                    scenarios,
     between                 roles, standards,
assessment criteria              process
  & architecture              documentation
     artifacts



                                                  Review
                                               architecture
                                              deliverables for
                                             small, mid-sized,
                                             & large projects




                                                                 8
                    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
                                                                       9
     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




                                                      10
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
                            50%            70%          91%
 negotiation/validation


                                                                 11
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%



                                                     12
 Discussion: Use of Architecture in ERP Customization
              Requirements Definitions
Use of EA in    Description of tailoring type                           Percentage
the tailoring                                                             of RE
types of:                                                               processes
Adaptation      Setting of parameters & tables, in order to choose         57%
                between different execution paths
Add-ons         Implementation of 3rd party package complementing the      12%
                ERP system with branch-specific functionality
Screen masks    Creating new screen mask for data input/output             0%

Extended        Creating extended data reporting options                   25%
reporting
Workflow        Developing non-standard workflows                         100%
programming
User exits      Programming of additional code in an open interface        26%

ERP             Using the ERP-vendor’ programming language to              12%
Programming     develop additional applications to the standard
                                                                                 13
                functionality
                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 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