Latest IRM - Siebel upgrade to IP17 +

That's it, jokes aside - let's talk about the eternal. In this post you will not find a spray of joy or a hint of the ease of being. Because it is for those who fought and searched, passing every new round of Siebel upgrade. Since 2013, Oracle has been conducting a campaign to fundamentally modernize its CRM system. So far, we have already experienced seven (from IP13 to IP19) Innovation Packs. Until 2013, releases were released every 2-3 years, the last 5-6 years Siebel updates were published much more often, keeping to a clear schedule: minor releases (patchset) were released monthly, fundamentally new versions (major) - annually and often this meant a client’s need global processing or even “re-introduction” of your system. To simplify upgrades Siebel, the vendor has developed IRM (Incremental Repository Merge) - a functional that facilitates the process of installing new versions with innovation packages. It will be discussed.

IRM principle

In order to update the system to a new version with the Innovation Pack, you must update the system repository. To do this, merge with the repository of the new version.
The repository is the system metadata, i.e. Schemes of everything that is its functionality. During the project, customer consultant developers (Siebel consumers) make thousands of changes to the repository. However, these changes are absent in the delivery of the release from Oracle, and the vendor himself, modifying the system, adds new metadata and can completely rework a particular object scheme.

Obviously, a mechanism is needed here that would make it possible to seamlessly combine the changes made by the consumer of the system with new developments from Oracle. For this, IRM was created.

Tasks solved during the Siebel upgrade

1. Preparing repositories and environments for consolidation.
   
2. Direct integration on an update environment (DEV) (IRM).
   
3. Analysis and resolution of conflicts.
   
4. Apply changes to the update environment.
   
5. Regression testing.
   
6. Correction of all defects that appeared during the update.
   
7. Migration from the upgrade environment to pre-production and further to production.
   

What is the benefit of switching to IP17 +

1. New engine: OpenUI - the ability to more deeply configure the interface, increasing the usability of the system.
   
2. Functionality analysis of user behavior in the system (Usage Pattern Tracking) will create a unique UX.
   
3. Cross-browser support: IE is no longer a limitation - you can now work in Edge, Firefox, Chrome and Safari.
   
4. The WebTools (Composer) tool allows you to make changes to the interface and to the business logic of the system from a browser without requiring a server reboot, i.e. without downtime. Development prototyping is faster.
   
5. CI / CD technology, patch transfer automation, parallel development, auto-testing.
   
6. Support for REST integration technology, which is well applicable when integrating with client portals.
   
7. Industry innovations: from building beautiful analytical dashboards on the popular JS library to Big Data and Machine Learning technologies.
   

The key to a successful upgrade

IRM defines a set of discrepancies in objects and properties that are present in the original repository, in the customer version and in the new version. The functionality allows, based on the developer's decision, to choose a method for combining objects and, at the last stage, start an effective process of migrating an updated repository from the update environment to the productive.

During the merger, conflicts arise , that is, discrepancies between the properties of the object of the current repository and the same object of the repository of the new version.

Non-critical conflicts are discrepancies in objects that have not been affected by the customer, i.e. discrepancies between the original repository and the new one. 99% of such conflicts are resolved in favor of a new repository.

Critical conflicts- This is a discrepancy in objects between the client repository and the new repository.

If you follow the Oracle methodology from the very beginning of the project, subsequent upgrades will require minimal costs. But, unfortunately, very often Oracle best practices are sacrificed when fulfilling certain customer requirements. For example, system tables are sometimes changed directly through the database, which is not fixed in the Siebel repository. Or they change user keys (UK), dimensions and type of standard columns of standard tables, which Oracle strongly recommends not to do. This makes it impossible to automatically rebuild the table during the migration to the productive and will require many manual manipulations with tables and data. In addition, changing the standard keys and columns may affect the performance of new processes developed for the new version of Siebel.
Therefore, it is important that the system is implemented under the supervision of certified professionals with extensive implementation experience.

However, the most important thing in the upgrade project is the competent planning of the process, during which it is necessary to solve several issues at once.

Solution infrastructure

• Who will configure the infrastructure:
  
  • deploy servers
  • set the OS
  • configure RBS
• Description of the update environment. Where will we do IRM?
• Description of the testing environment. How will we test (including external systems and integration)?
• Description of the deployment environment. Will we update the current product or set up a parallel production environment?

Detailed project plan (taking into account the distribution of responsibility between the customer and the contractor)

• It should be noted that it will be necessary to “freeze” the work on introducing new functionality to the productive.
• Including you need to consider that you will need to reinstall all the functional packages that went into the productive after the start of the upgrade project.

Test plan

• It is necessary to draw up regression test scripts.
• Identify those responsible and determine the team of testers of both CRM and external systems.

Implementation plan

• Make a checklist of the work on introducing an upgrade into a productive.
• Make a rollback plan (yes, yes !;), in case an accident occurs during the upgrade.

Separately, it makes sense to conduct a full audit of the system (or even order it from a vendor) in order to find out what violations of the methodology and technical errors of implementation were made by the developer. The audit is conducted by certified Oracle specialists, the results are recorded in the form of "proprietary" Oracle Siebel protocols:

1. Configuration Report (Errors or Violations in Business Logic Configuration)
   
2. Integration report (errors or violations in integration objects)
   
3. Script report (errors or violations in programmable modules)
   
4. Errors in processes (errors in workflow and automated functions)
   

The fact is that errors may occur in the modified functionality. At the stage of regression testing of the combined solution, it will be necessary to understand exactly what error appeared as a result of the combination, and which was originally.

The most significant issues when upgrading Siebel

Latest IRM, or How to upgrade to the latest Siebel (IP19)

Over the past 2 years, large changes have taken place in the Siebel system, which have also led to a change in the approach to updating the system.

Key changes are related to the release of IP17 in 2017 and its subsequent updates.

• The system data model was reworked, the vendor refused the SRF compilation files used at server startup. A Runtime Repository has appeared, which allows you to make changes to the system configuration without rebooting it.
  
• Siebel Web Server has become a standalone Siebel component, from now on, components like third-party IIS and Apache are no longer required. Siebel WebServer called Application Interface (AI), it runs on the basis of Tomcat-container. All connections to AI are made only via HTTPS, i.e. all traffic is encrypted by default. AI has full REST support for both incoming and outgoing requests (REST technology gives great flexibility in installing improvements to the system and in the process of upgrading repositories).
  
• The Gateway component has been upgraded (now it is called Dynamic Gateway). Of particular note is the redesigned internal inter-component balancing. The Gateway (Gateway Elastic Load Balancer) is now responsible for it, which makes the load balancing system more flexible - previously this function was performed by the application server.
  
• The system officially supports the Oracle 12 database (support for the Oracle 11g database is complete).
  

In 2018, Oracle changed release policy for Siebel CRM

• All future innovations and corrections will be delivered as updates, that is, patchesets installed from the distribution kit to the current version (starting with IP17). They will contain innovations previously indicated by the vendor in the system development strategy.
  
• The names of the patchset will become more clear, because versions are released monthly: for example, the number 18.4 will mean “April 2018”.
  
• The new delivery model will begin with version 18.4. The latest version of the old model was 17.6. To go from 17.6 to 18.4 you just need to install the distribution kit (as a patch, and not as an IRM upgrade). Subsequent monthly updates may contain functionality for which you need to download a small package of changes through a special utility. Moreover, all updates will be cumulative.
  
• Due to the change in the model, clients who switched to IP17 will no longer face the problem of the lack of a patch for their version of the system. At the same time, the process of upgrading the system is greatly simplified, the cost of support is reduced, and the introduction of innovative functionality is accelerated.
  
• To upgrade, for example, to version 19 from earlier versions of Siebel (up to 17), it will be necessary to implement a standard upgrade to version 17, and then using the new update model.
  

Changes in the approach to upgrade to IP17 +

When designing infrastructure and conducting sizing, you need to consider the new server infrastructure IP17. The requirements for iron will be increased, because Runtime Repository requires more resources. Fail-safe balancing of new Application Interface and Gateway components recommends 3 components instead of 2. You will need to review and migrate your server configuration and enterprise server profiles to the new IP17 architecture.

You will also need to transfer all web artifacts, such as HTML templates, JS, CSS, etc., to the new Application Interface web server. By the way, all web artifacts will eventually move to the system repository.

The next steps are updating the operating system and the database to supported versions (you need to check the Siebel software certification tab for Oracle Support) and issuing the correct HTTPS certificate.

Finally, you will have to start IRM for the last time, and further version updates will go simply through the installation of patches.

If in parallel with upgrading to IP17 + you are developing new functionality on your current version of the system, then it will be necessary to re-test and update the accompanying documentation. And developers and administrators are trained to work with Workspace technology, the Migration Tool and the new Siebel infrastructure management management console.

You can determine the approach to the upgrade, which depends on your current version, from this table:


*** For more information on SEA and SIA Siebel CRM releases, please refer to My Oracle Support article 1514115.1 .

Morality

Obviously, such projects require the involvement of experienced consultants (well, without them) who are able to anticipate and bypass pitfalls, competently plan such an upgrade process in which the customer will not be overwhelmed. Those. minimize and even eliminate the risks of prolonged system downtime, data loss, critical errors in business processes after an upgrade. For example, the wrong choice of a table key can entail a large-scale processing of processes in the system - and then a simple update risks turning into a project for several months.

Maxim Chugunkin, head of the group of systems architecture, Jet Infosystems