Evolution Planning

1
SIF8018 SystemutviklingIDI, NTNU
John Fanaro, Intech (Ed.) 16. februar 1999
F11B The Renaissance Method
2
INTRODUCTIONTopics covered in this presentation

• The Renaissance approach to system evolution
• The Renaissance repository
• Planning for Evolution
• Implementation
• Delivery
• Deployment
• Customisation
• The Renaissance Web Site

3
The RENAISSANCE Consortium

• European Union
• CAP Gemini, France
• Cap Gemini ISM, France
• debis Systemhaus, Germany
• Engineering - Ingegneria Informatica, Italy
• Intecs Sistemi, Italy
• Lancaster University, England
• Sintef / NTNU, Norway
• Telesoft, Italy

4
Renaissance Applications

• Aging hardware and software systems
• Constantly changing business and functional
  requirements
• Problems with performance and system failure rate
• Introduction of the Euro
• Year 2000 Problem

5
The Legacy Dilemma
Drastic
Continued Maintenance

• Business critical legacy systems
• They must remain operational in some way
• Because of their old structures, continued
  maintenance is often too expensive
• But the cost of replacement (e.g. with a
  commercial Enterprise Resource Planning package)
  is often unacceptable
• Prohibitively expensive
• Oten means complete change of business process
  and losing the old business process
• The role of Renaissance a middle road between
  themcontrolled evolution

Controlled Evolution
Total Replacement
Drastic
6
The Renaissance Approach
Evolutionary Application
Existing Application
Continuous Improvement
Renaissance
7
The Renaissance Method

• A genuine method a market niche in the
  reengineering business
• Not a set of isolated techniques
• Covers the entire reengineering process
• Full method guidebook plus supporting
  documentation
• Organised responsibilities, tasks, inputs and
  outputs

8
The Renaissance Cycle of Evolution
PLAN EVOLUTION

• Fundamental principles of the Renaissance
  approach
• Evolution must be company and project specific
• Evolution is continuous

Continuous Evolution
DEPLOY
IMPLEMENT
DELIVER
9
A Process For System Evolution
Activities are the building blocks
Select strategy
inputs
Assess current strategy
Develop new architecture
A well-defined, sequenced set of generic
activities, with well-defined inputs and outputs.
outputs
...
10
A Journey
Artifacts

• What makes Renaissance a true method? It
  organises your journey through reengineering

Simple and composite documents
Current System Report
Evolution Strategy
Deployment Plan
Defined Responsibilities
11
Applying the Method

• Method handbook supported by detailed consultancy
  reports

Method Handbook
12
Evolution Planning
13
Starting Scenarios
A bewildering variety

• Scenario 3
• We want to expand into mass customer business
• Small incremental system change to increase
  capacity

• Scenario 1
• Are we ready for the e-commerce world?
• Continue maintaining the current system?
• Replace older subcomponents?

• Scenario 2
• Our old-fashioned system is making us lose
  market share
• Re-vamp the user interface?
• Throw away the old system?

• Scenario 4
• Management has dictated a migration to
  client-server architecture
• Wide-ranging system transformation

14
Starting up
Customised method
Organising for Assessment
15
Assessment

• Why Assessment?
• Reengineering can be very, very expensive
• It is labor-intensive
• It disrupts your normal working process
• Dangers
• Reengineering the wrong parts of the system
• Miscalculations risk, cost, duration of
  evolution project
• Our approach
• Determine the minimum set of system components to
  assess
• Find those components which really benefit from
  reengineering

16
Preparing for Assessment
Cataloguing
Context Modelling
Determine Assessment Level Structure
Increasing Knowledge of System
17
Assessment Level
System

• The Assessment Level Structure key to
  cost-effective assessment
• System level? Quick and inexpensive
• Subsystem level? Detailed analysis of system
  components
• Constituent level? Formal, tool support, full
  details, more expense

Subsystem
Constituent
18
Assessing Value
Technical Quality
Replace with commercial package
Business Value
The Renaissance approach to assessment considers
two aspects of a system Technical Quality and
Business Value This enables systems to be ranked
by their need for re-engineering It identifies
candidates for evolution (known as Portfolio
Analysis - developed by Nolan Norton Co)
19
Evolution Strategies
Prepackaged, preanalysed, individual Renaissance
Evolution Strategies
Re-vamp old interface?
Re-architecture legacy design?
Re-structure?
Reuse?
20
Cost / Benefit Analysis
Evolution Planning
A battery of sophisticated analysis techniques
Parametric Estimating
Cost / Risk Analysis
Risk Assessment
Size Cost Estimation
21
Overall System Evolution Strategy
Architectural Modelling
Evolution Strategy Assessment
Conceptual Modelling
Evolution Planning
Iterative Process
Overall Strategy Development
Target Design
Client-Server Migration
Re-design
Re-vamp
22
Results of Evolution Planning

• With the business goals in mind, you have
  assessed the technicall quality and business
  value of the system.
• You have developed a set of candidate evolution
  strategies
• taking into account constraints such as
  availability of resources
• You have made a cost/benefit analysis of each
  candidate
• You have identified an overall system evolution
  strategy
• You have taken a Go/NoGo decision

Go
NoGo
23
Implementation
24
Preparing for Implementation
Mapping out structural and control
characteristics of the legacy system
Architectural Modelling
25
Technical Modelling
Modelling and documenting from multiple
viewpoints with the Unified Modelling Language
Architectural Modelling
26
Architectural Migration
Client-Server Migration
Guidance on resolving the many questions that
arise in the migration to modern distributed
architectures.
27
System Transformation

• Transformation of legacy to target system must be
  controlled
• Component batches are identified
• They can be migrated together
• Continuous, incremental testing and
  transformation process

Transformation
Testing
28
Preparation for Delivery

• The Implementation Phase does not necessarily
  consider the target environment
• implementation may be in-house, not on customer
  site
• the customer may not be involved during
  implementation
• The Delivery Phase must be prepared now
• hardware procured
• software purchased
• acceptance tests prepared

Implementation might take place in isolation
Delivery will involve the client
29
Delivery
30
Delivery and Installation
Onsite installation of new hardware, software
packages
Onsite acceptance testing. Separation of concerns
from implementation team and operational team
31
Data Migration

• Data migration from legacy system to new system
  can be complex and expensive
• Renaissance provides up to date information on
  modern data migration technology and tool support

32
Deployment
33
Changeover Design
Old

• One of the most neglected aspects of deployment
• How fast should the organisation switch over from
  the old system to the new system?
• Gradual?
• Abrupt?
• Co-existence for a time?
• How to control the changeover process?

New
34
Training

• Training programs will be necessary in most cases
• They may be customised according to the degree of
  transformation that occurred
• Incremental
• Major overhaul
• Complete replacement
• Renaissance provides guidelines in the
  development of courses

35
In-Use Evaluation

• Deployment contains the key to achieving immortal
  systems
• documentation of the revised business process
  supported by the new system
• in-use evaluation
• In-use evaluation identifies criteria for future,
  smooth evolution of the system, through
  monitoring critical factors
• User satisfaction with system functionality
• System performance (response, number of users,
  etc.)
• Evolving business goals of the organisation, and
  contribution of the system to these goals
• New requirements arriving from business community
  and user community

36
The Method in Practice
The key customisation
Primary objection Using a method is too
expensive. We cant afford all of these
documents, activities, organisational overheads,
...
Project factors
Organisational factors
Customised Method
37
Project Customisation

• Management has mandated this particular
  platform.
• We only need top-level assessment, nothing
  detailed. Our budget is too small for anything
  else.
• This is only a feasibility study. We only need
  the Evolution Planning phase.
• We already know exactly what we have to do. We
  only need the Implementation, Delivery, and
  Deployment phases.

Plan
Implement
Deliver
Deploy
Plan
Implement
Deliver
Deploy
38
Organisational Customisation

• We have a tried and true method for risk
  management that is used organisation-wide.
• We have a document production and approval
  process for all of our activities.
• We have standardised on this software for
  project management.
• We are certified ISO9000.
• We use the XYZ design documentation method.
• We have bought the toolset from Company X for
  reverse engineering support.

39
A Practical Method

• The method is not prescriptive of particular
  techniques and tools
• the repository is conceptual
• the process model is a framework it says what
  to do, but leaves how to practitioners. They use
  their own techniques and tools.
• The method is subject to continual evolution
• as organisations gain experience with applying
  the method, they can improve it and make it fit
  their own particular work practices.

40
Renaissance Web Site

• Part of the Renaissance evolution strategy
• Contains continually updated material on the
  state of the art
• reverse engineering technology
• data migration technology
• risk management techniques
• etc.
• http//www.comp.lancs.ac.uk/projects/renaissance