Sunday, August 03, 2008

Close to the Standard

"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 or Core Consultant Course 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.

4 comments:

Anonymous said...

I take exception to the statement that Business Service are well documented (or out of the box workflows for that matter).

@lex said...

Hi anonymous,

there are definitely exceptions, you are completely right. Many splendid business services are undocumented and would deserve a little more discussion in the documentation (like the Read CSV File used in the Marketing Workflows).

There are also positive exceptions like the EAI business services (EAI Siebel Adapter, EAI XML Converter and the like) which have their own chapter in bookshelf.

I think we are all waiting for a single bookshelf guide to business services and out of the box workflow processes.

I found that many workflow processes are described in great detail but the information is dispersed among different guides (Example: Order Management or Communications).

I also find that bringing the information together is a very time-consuming task but after you plunge in you get out again with more knowledge than before, even about subjects you might have not touched on the first hand.

Have a nice day

@lex

Anonymous said...

@lex,

Sorry I was not able to complete my earlier post, since I was in a hurry.

I've always felt that Siebel is not very forthcoming with the documentation on BusSvc and Workflows. Maybe its just bad organization like you said.

I contrast this to programming in the VB environment, where I always feel I can find components that already does what I need, am usually ABLE to find them and have the confidence to use these components without worrying (too much) about surprises.

I also understand that Siebel's main focus is not on pleasing programmers like me, but rather make the product appeal to CIO and Business Decision makers. But my mistakes and lack of knowledge on their out of the box services will reflect poorly on Siebel the product too. Investing in developers and tools for them really helps assure the long term health of the Siebel product (my livelihood for one depends on it, I want and need them to succeed).

@lex said...

anonymous,

I completely understand what you feel, because having been educated and worked as a programmer I know it is all about "know thy libraries".

Business Services (and their orchestration in workflows) are the libraries of Siebel. However, their documentation is spread across bookshelf, Siebel Tools, metalink3, blogs and forums.

I agree with you that having consistent documentation and unsurprising functionality would be a great benefit for the quality of both the product and the customizing.

@lex