Siebel deployment is a project on its own. Although you can tell yourself that all your hard work is done by completing the system integration testing, experienced guys will tell you that your work is not complete until the application is deployed in production environment (& accepted by users :).

Any deployment activity has many dependencies – both internal and external. Siebel deployment adds multiple components to the deployment activity, and each one of them had to be carefully grouped, any parallel deployment opportunities identified, and the deployment activities to be properly sequenced.

All this and more have to be part of a deployment plan. Although oracle does provide the deployment guide encompassing all this practices that are specific to Siebel, I have seen that evoking very little interest - people tend to do the same mistakes over and over again.

What goes into a Siebel deployment plan? #

Siebel deployment plan consists of -

All activities that are important for deployment #

The activities that much earlier than the actual deployment process. It will start right from Infrastructure readiness through the post-deployment support activity.

Each activity must have an individual owner, a target date, any dependencies, and has to reflect the latest status ( in terms of percentage completion, etc.). These out to be periodically reported and discussed in a focused deployment readiness meeting.

Deployment activities are broadly classified into -

Technical deployment activities

• Setup of any additional infrastructure required for deployment
• Preparation of deployment artefacts
• Documentation of how deployment will be done
• Testing of any automated deployment scripts
• Preparation of data migration files for master, transactional and admin data
• Transition knowledge to support teams including any open issues, expected system behaviour, common/typical issues identified by users during UAT
• Deployment dry runs including code and data migration
• Test rollback of code/data

Deployment management activities #

• Monitor deployment readiness status
• Collaborate between all IT teams, business teams and support teams for deployment planning and preparation
• Validate deployment dry run results
• Ensure roll-back strategy is in place and is tested
• Identify, mitigate and monitor any risks associated to deployment
• Ensure support team readiness
• Communicate deployment readiness and prepare users for the new/upgraded application
• Ensure users are trained, and experts available at all sites
• Ensure sign-off of data migration artefacts and code
• Clearly define the go/no-go criteria on the deployment day, and identify individuals empowered to take that call

Dependencies #

• Identify any external teams teams responsible to support the technical team during the deployment period - includes DBA, Network team, Middleware team
• Ensure support from technical teams from the interfacing applications and applications from where data is being migrated

Siebel deployment planning tips #

Deployment planning has to keep this in perspective - anything that has the possibility of going wrong will go wrong on the deployment day.

• Provide enough time to cover all aspects of deployment
• Never leave anything to chance. Never assume activities get done just because they are in the plan.
• The actual technical deployment should not take more than 1-1.5 days. If it will take more than that time, plan to split deployment activities - they get spread out, and the risks are not concentrated on those two days
• Plan for user testing before go/no-go meeting
• Communicate to users not only through emails but also through webinars, group sessions, and senior management pep talks
• Automate as much as possible. 100% percent automation is the target. Encourage automation scripts to have all environment details parameterised so that deployment scripts can be reused across environments and for dry runs
• Data migration automation is a must. Any and all problems associated with data migration how to be identified during the dry runs. Ideally you should use the same data migration input files during the final deployment
• Encourage design of data migration scripts that will support incremental data migration and data loads to be split across days

If you have an agile project on your hands consider investment in deployment automation tools like Oracle Enterprise Manager.

Have any other deployment lessons to share? Comment and let me know.