Configuring Siebel Business Applications > Configuring a Siebel Application > Developing an Implementation Plan >

Developing a Configuration Strategy

The major goal of configuring Siebel CRM is to develop an application that meets the look, feel, and functional requirements of your organization and your users, and that is easy to maintain and upgrade.

To develop a configuration strategy

1. Use the following guidelines in the plans for your configuration project:
   • Make as few changes as possible.
   • Use predefined Siebel application functionality. Never create a new object unless you cannot modify a predefined object to meet your requirements. If you follow this principle, then your Siebel application is much easier to maintain and upgrade to future Siebel product releases. For more information, see Reusing Predefined Objects.
   • Standardize configuration development.
   • Achieve acceptable system performance. For more information, see Siebel Performance Tuning Guide.
   • Build a consistent and intuitive Siebel client. For example, if you create a new form applet, then make sure it uses the same general look and feel as other form applets in your Siebel application.
2. Plan Siebel CRM design starting at the top and working downward:
   1. Design the user interface for the Siebel client.
   2. Create the underlying business logic.
   3. Create the data objects layer that is necessary to support your configuration.
3. Develop a plan to configure Siebel CRM starting at the bottom and working upward:
   1. Modify objects at the data layer.
   2. Modify objects at the business object layer.
   3. Modify objects at the user interface layer.

      This technique helps you to make sure the correct values for all required object properties are available as options. For more information, see Figure 1.

4. Use one of the following techniques to structure the development work:
   • Assign the development role for a complete functional area to a single developer or group. This technique typically allows different groups to work in parallel.

     For example, one group or an individual person can develop a Web page and the logical business object definitions and data object definitions that are required to support the page.

   • Assign a single developer or group to a specific architectural layer.

     This technique takes advantage of the specific expertise of developers. For example:

     • The RDBMS specialist defines extensions in the data objects layer.
     • The system architect defines the business object layer.
     • The user interface developer defines the user interface objects layer.

       TIP:   Use a web template, which requires each group to complete some work before another group begins.