NextGen Consulting

IT Consulting CRM BSS OSS

Migrating Amdocs CRM Classic to Smart Client (part 2)

In the first part of this post we discussed some of the business and technical drivers for migration from Amdocs Classic to Smart Client technology . We discussed the preliminary information needed for migration assessment, as well as the required resources for such assessment.

This part describes the following migration assessment aspects:

  • Migration Assessment Planning 
  • Migration Project Planning
  • Phasing
  • Migration Techniques

 

Migration Assessment Planning

The purpose of the migration assessment is to provide the management a Statement of Work, Project Plan, Hardware sizing and Estimate for the migration of the current customized Classic implementation to the Smart Client platform.

A typical migration assessment can broadly be divided into the following stages:

  • Information Gathering
  • Map the Gaps
  • Plan Implementation and Deployment

 

Information Gathering

  • Gather information about processes, functions and architecture.
  • Gain thorough understanding of functional use of the current Classic client Implementation – solution overview.
  • Review current functional and technical requirements and identify specific requirements that must be considered as part of the migration.
  • In order to limit the project scope it is necessary to limit the inclusion of significant amounts of new functionality. Yet, the introduction of new functionality may be one of the key business drivers to migration.

 

Mapping and Gap Analysis

Map the existing functionality in the currently customized solution to the OOB Smart client application.

The goals of this task are as follows:

  • Identify customizations that could be replaced by existing OOB Smart Client functionality.
    The goal is to move away from complex customization in favour of OOB in order to reduce TCO.
  • Identify required baseline forms that are not available in the Smart client OOB application.
  • Identify customizations that are to be migrated as is.
  • Identify customizations that should be re-written.

 

Interface and Integration Analysis

  • Identify Client side integrations (integrations need to be re-written)
  • Identify all Backend interfaces and integrations (minimal affected by migration – all the old interface techniques are still supported)
  • The main efforts with interfaces are data model changes. 

 

Data migration

  • Identify data that needs to be migrated and / or restructured.
    For example: CIM interaction model.
  • Infrastructure Analysis – the current infrastructure must be understood and documented.
  • Identify existing infrastructure which can be re-used.
  • Identify additional required infrastructure.
  • Identify required performance, sizing, fail-over and high availability (as per stage 1).

 

Implementation and Deployment Plan

  • Determine the ideal way to carry out and deploy the migrated solution;
  • Consider  big-bang Vs. gradual, phased migration
  • Consider using Classic client co-existence with Smart Client.
  • Determine the expected level of support to be provided during deployment. 
  • Assign responsibilities for testing, training etc.
  • Produce a high level project plan and costs estimation.
  • Return on Investments (ROI) Analysis –provide the management with an understanding of the expected costs and associated benefits.
  • Scope the migration task – produce a Statement of Work.

 

Migration Techniques

A brief overview of the techniques used when migrating from Classic to the Smart Client Application. 

 

Migration Areas

There are three main areas of consideration:

  • UI (Forms)
  • Business logic (forms code)
  • Common business logic (Global code modules)
  • Interfaces

  

UI (Forms)

The techniques used in migrating Classic application to Smart Client vary on a form by form basis. It is determined by the work done during the analysis. 

Some forms will be completely re-implemented using the Smart Client designer, others will be migrated by customizing a derived version of an existing Smart Client Application form and some will not be migrated at all.

 

Business Logic

It is likely that the logic embedded in custom Classic (Clear Basic) code has NOT been written with a separation of UI logic from business logic.

The Clear Basic code has to be reviewed and converted to take advantage of the newer Java technology.

 

Interfaces and Integrations

Most of the following integration techniques are still supported in the Smart Client backend (application server and database) and may need some changes to the code base:

  • DB level integrations
  • Tuxedo – CBCode on the server
  • High Level and Low Level APIs
  • Dataex
  • Middleware solutions
  • Email Manager
  • Business Rules
  • CBBatch
  • CBO (Core Business Objects)

  

Since the Tuxedo server is no longer required as part of the Smart Client server Architecture, it  is recommended that the Clear Basic code running in the Tuxedo environment will be rewritten as Java code. 

However, if CBCode is heavily used on the server-side in the current implementation, it may be best to leave Tuxedo in place allowing the code to be migrated overtime and decommissioning of the Tuxedo server at a later date.

 

Client Side Integrations

The client side integrations need to be completely rewritten.

Classic client side integration techniques not supported directly by Smart Client:

  • Button Actions
  • ActiveX Server
  • DDE
  • DLL’s

Some embedded ActiveX (com) components can still be used in the Smart Client Application within the Smart Client Internet Explorer control. There are also 3rd party solutions for bridging Java and DDE.

  

Migration Project Planning

Implementation

  1. Prepare Development / Test Environments
     
  2. Upgrade Database, Prepare Repository
     
  3. Merge Repository
     
  4. Import Languages and Locale-specific Objects into Smart Client UI (form properties, style properties file)
     
  5. Migrate Custom Client-side Scripts to Script Manager or APM server Scripts
    • Applet Scripts
    • Scripts that reference the UI or Desktop context
    • Embedded ActiveX Controls
         
  6. Outbound / Inbound COM
       
  7. Update Interfaces and Integration Scripts
       
  8. Perform Testing – Unit, System, Integration
      
  9. Performance
       
  10. Perform Production Environment Sizing review
       
  11. Perform User Acceptance Testing
       
  12. Develop Training (End Users, Help Desk)
       

 

Phasing

The concept of gradually phasing the migration (vs. Big Bang approach) is very appealing.  On the surface it would seem to be the lowest risk way to proceed.

 

Phased migration allows customers to leverage browser apps where ROI is highest

  • Prioritize based on business needs, ROI
      
  • Lower up-front costs
       
  • Less disruption to users, IT and infrastructure
       
  • Reduced Risk: Phase in smart client to keep organizational and infrastructure change manageable
       
  • Convenience: Incorporate smart clients at your own speed – in phases, by groups, by functionality, etc
       
  • Flexibility:  Leverage Smart Client applications immediately where needed, without disrupting productive client-server users
       
  • Financial Protection:  Leverage current infrastructure.  Migrate users as infrastructure investment shifts
      

 

Organizations often have a specific time-frame in mind for a project whether it is a migration project, upgrade project or implementation project.

It is often impossible to fit within the required time frame with a big bang approach, depending on the complexity of the current implementation.

Existing implementations are moving goals – customisation continues in order to support the day-to-day business needs. 

Pro

  • Lower risk
      
  • Easier to manage people and change aspects, don’t need to train everyone in one go
      
  • More manageable, phases are smaller and take less time to deliver
      
  • Reduced strain on existing resources, testing, support etc.

     

Con

  • Higher risk
      
  • Increased cost due to increased project overheads
      
  • Increased infrastructure may be required – can’t reuse existing servers if they are still supporting Classic client users

  

Phasing Methodology

Different methodologies apply for each organization, depending on their implementation. Consider the following factors:

  • Is the Call Center blended or specific teams are used?
    If specific teams are use, it would lend itself to phasing.
       
  • Are separate areas of the application used by separate teams?
    If not separate teams, it is more than likely phasing will prove to not be a viable option.

  

Migration Estimate

Effort estimates are based on design, build and unit test in man days. 

Areas to be considered for inclusion in the estimate are discussed in the following sections.  Where appropriate a sample table has been included indicating the type of information that should be included in the estimation for the migration effort.

 

Assumptions

When assessing which UI forms should be migrated it is important to keep in mind the size of the user community that will be using the forms.

 

Integrations

  • Interfaces                                    
    Each interface should be considered in the estimate, based on  earlier analysis.
      
  • Client-side Integrations        
    Each identified client-side integration needs to be included in the estimate, as the UI is changed; each requires some level of  effort.

 

Forms

For the purposes of migration estimation the forms used within the current implementation are categorised as follows:

  1. Customization / Forms to be migrated
  2. Customizations / Forms to be re-implemented
  3. Customizations / Forms that will use OOB product functionality and not be migrated.
  4. Baseline forms to be used that are not in the Smart client application.
  5. Customizations required for new requirements

 

Global Code Modules

Code modules may need migration depending upon the chosen approach.

  • Global code is run via Tuxedo
  • Global code affected by data model changes 

 

Note that code modules required by new requirements should be accounted for in the Forms section, not in this section.

 

Data Migration

Data migration may be required based on the functional mapping and gap analysis.

For example, migration to the new interaction model, migration from custom objects to OOB objects, migration required due to more requirements.

 

Scripting

  • Effort required re-implementing existing scripts,
  • Effort required implementing new scripts.

 

 

Automation (Process Manager)

  • Effort required for creating new Process Manager’s processes as required using OOB functionality.
  • Effort required migrating existing Process Manager’s processes to new version of PM. 

 

 

Additional Considerations

Data Model

Changes to the existing data model may be required depending on the functional mapping, gap analysis and additional requirements.

 

System Testing

  • Training
  • Online Documentation
  • Project Overheads

 

 

2 Comments »

  1. Hi Yuval,

    It was a great read indeed, since this was the are on which i worked the most extensively during my 43 months at Amdocs. One point i would like to raise here, we (me and one more person) developed a tool called Smart Migration Tool which can convert all the forms (customized as well as out of box) and just for information we won multiple awards for that innovation as well. If we use the same the migration effort in terms of time and cost would reduce dramatically. I am not very sure if the current state of that tool.

    Regards,
    Vihan

    Comment by Vihan Srivastava | 04/01/2011 | Reply

    • Thanks Vihan for your comment.

      Indeed, a classic to smart migration tool named C2S Migration Tool does exist.
      The tool is implemented as a UI Editor extension.

      To my best knowledge, this tool is exclusively used by Amdocs PSO (Professional Services Organization) and is not available for 3rd parties.

      Although it is a very nice tool which performs quite well, I do not think that using this tool is the right approach for migration.

      An automatic transformation of Clear Basic Code and UI to Smart Client retains all Classic UI limitation and can never take full advantage of the rich user experience provided by Java SWING technology used by Smart Client.

      Any migration is a good opportunity for a complete ‘overhaul’ of the application. A well designed migration should verify the original business process with its stakeholders and re-design an updated UI which exploits the powerful SWING UI capabilities such as panels, threads and skinning to provide enhanced user experience.

      Similar tool was created for an automated migration of thin client to smart client forms.
      It was used to migrate most of the OOB (out of box) Smart Client forms. The resulting forms do function quite well, but their look and feel is not optimal and they are very difficult to maintain. My post Upgrading Smart Client Form discusses this issue and demonstrates how to improve such automated form into a usable one.

      Perhaps the C2S migration tool can be used for prototyping or proof of concepts, but not for the actual migration process.

      Yuval

      Comment by Yuval R. | 04/01/2011 | Reply


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: