Close to the Standard Siebel

"Once bitten, twice shy"

If you have the opportunity to observe some of the Siebel CRM projects (or any other standard enterprise software project) across the globe, however small or large they may be, there is a familiar pattern:

1. Phase of enthusiasm
   
2. Learning phase, along with the assurance to "stay close to the standard"
3. Pilot phase during which most of the requirements become clear (and complex)
4. Land of oblivion (where the first thing to be forgotten is the promise of 2.)
5. Regression to coding (believing that writing custom code can solve all problems faster and easier than standard functionality)

These are some typical phases (hope you also note the satirical aspect) that a typical project goes through.

However, we are talking about standard software, which means frankly that the customizing developers at the customer site find themselves in a race against time and hundreds of developers in the Oracle offices who are determined to create another splendid version (Siebel 8.1 is just around the corner these days).

So when a project has matured and all requirements are solved, the upgrade project typically comes next. And it is during the first attempts to upgrade the more or less customized application to the newest version when the whole thing seems to blow up (# 5. of the above list being reason #1 for the blow-up in most cases).

So we can add to our list

6. a phase of frustration
7. the vow to stay closer to the standard after the upgrade, which is immediately followed by
8. the requirement to upgrade the application (which is complex)
9. The land of oblivion... - we had that before ;-)

To cite a customer: "What does 'close to the standard' mean? How can we solve our very complex requirements if we are not allowed to add custom code? How can we customize the applications and remain upgradeable?"

The answer to the first question: "Thoroughly observe and clearly understand the standard functionality and metadata and when you implement solutions, let your developers behave the same way the developers at Oracle do."

Let's elaborate on this using the Siebel CRM Repository as an example.

Since Siebel 7 was brought on the market in 2001, we can observe that any new module (e.g. Siebel Loyalty in 7.7, Customer Order Management in 7.8), however complex its functionality may be, can be dissected into the following:

1. The basic objects

Metadata objects like applets, business components and tables which allow users and EAI processes to create, read, update or delete data needed for the new module. The Siebel Essentials ---> http://education.oracle.com/pls/web_prod-plq-dad/show_desc.redirect?dc=D46318GC10 or Core Consultant Course ---> http://education.oracle.com/pls/web_prod-plq-dad/show_desc.redirect?dc=D49247GC10 teaches how to create and modify these objects and how they refer to each other.

The following is a chart familiar to those who benefited from these courses

Summing up, we can say that adding or modifying objects of these 10 basic types is "close to standard" because this is exactly the way how the standard application is created.

OK, we now have nice views and applets and they allow us to read and manipulate data. But how does the additional functionality come in here? The answer is:

2. Business Services

These are metadata objects which (since Siebel 2000) serve as globally accessible capsules of functionality (i.e. code). So whenever an Oracle developer is asked to implement some functionality that is not available in the current application, he or she will write code and place it in the repository as a business service.

This is in fact the answer to the second question: You are indeed allowed to write custom code, but you should have it written as a business service" and - being a loyal Oracle University instructor - I would add "And your developers can learn how to do this in the Siebel Scripting Workshop."

A quick look at the current standard Siebel CRM repository (SIA 8.0) reveals a rich library of more than 1000 highly reusable and well-documented (along with many not-at-least-documented - keep your fingers off those) business services.

List of business services in Siebel Tools

OK, so we now have the data access and reusable services, but what if I need to call these services one after the other and combine them with my custom code. This leads us to the 3rd ingredient of standard Siebel CRM applications:

3. Workflows

Siebel Workflow allows developers to combine classic Siebel operations like creating or updating records with standard or custom business services along with decision logic and exception handling. Siebel Workflow is highly scalable and tests have proven a very high performance (outdoing scripted code by factors).

The tool of choice of Oracle developers to orchestrate reusable services into, yes, yet another service (that's what a workflow really is: just another service which you can call from literally anywhere) is Siebel Workflow.

Open the list of standard workflows in Siebel Tools and see for yourself. The current version (SIA 8.0) comes replete with more than 1000 standard workflow processes for literally any kind of functionality such as pricing, integrating with SAP, marketing or customer-facing processes such as quote-to-cash or forgotten passwords.


Example for a standard workflow

Summary (= Answer to the third question and I will make this short):

Focus your customizing investment on the 10 basic objects, business services and workflow and your project is close to the standard and therefore easily upgradeable.