This document analyzes potential solutions for implementing a VPN in a Siebel environment. It discusses two main approaches: 1) Using different VPN and VPN item products consolidated using agreement and entitlement entities, and 2) Classifying existing products using a network element type field and using premises to populate fields. Both approaches leverage out-of-the-box entities and data models. The preferred solution is the first approach using agreements and entitlements, but it presents risks regarding a user participating in multiple VPNs and cross-product validation.

1. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
VPN solution
Author: Roman Agaev
Date: Monday, May 14, 2007
-1-

2. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Contents
1 Abstract......................................................................................................................3
2 Potential solutions.......................................................................................................4
2.1 Different VPN and VPN Item products & Agreement-Entitlement approach. 4
2.1.1 Dual Billing – Several Billing Accounts...............................................5
2.1.2 Dual Billing – Several Order Items with Billing Accounts..................7
2.1.3 Dual billing implementation proposition..............................................7
2.2 Different VPN and VPN Item products plus Network approach.....................7
2.2.1 Dual Billing – Several Billing Accounts...............................................9
2.2.2 Dual Billing – Several Order Items with Billing Accounts..................9
3 Conclusion...................................................................................................................9
3.1 Potential Risks................................................................................................10
3.1.1 Ability of multi participating of given MSISDN in several VPNs.....10
3.1.2 Ability of cross compound products validation..................................10
3.1.3 Potential user's experience complexity...............................................10
4 Indexes......................................................................................................................10
Table/Diagrams
Table 2-1: ERD of VPN-Agreement-Entiltlement solution...........................................4
Table 2-2: ERD of appropriate Account entity instances and their relationships..........6
Table 2-3: ERD of VPN - Network solution..................................................................8
Table 2-4: Schematic diagram of Compound product verification mechanism............9
-2-

3. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
1 Abstract
The main course of the document is analysis of possible solutions for a VPN
implementation in Siebel environment, when emphasize is on full contiguity to a
customer requirements:
Root VPN
VPN's line item
Dual Billing1
Appropriate pricing
Activation ability2
Participation to existed VPN ability3
Inactivation ability4
Elimination from existed VPN ability5
Asynchronous processing support (order status)
The further analysis assumes the following assumptions:
Root VPN is product6
VPN's line item is product
Dual Billing ability may be achieved by several different approaches
Activation, participation, inactivation abilities are achieved by application's
internal functionality
Asynchronous processing achieved by application's internal functionality
Two different approaches are deliberated below, when the main difference is in a way
of VPN items cross-relationship. Both of those approaches uses oob7 entities and as
consequence oob data model, the point is very important in matter of staying in oob
data model and an ability of oob functionality usage at least as skeleton for different
functional points.
1
An ability of dividing recurring charge between several associated accounts (billing accounts)
2
An ability to activate a new VPN
3
An ability to participate to previously defined/activated VPN
4
An ability of VPN deactivation
5
An ability of VPN's subscriber deletion
6
There is ability in addition to regular definition create a network and define the root VPN as network
compound product, see the following analysis
7
Out of the box
-3-

4. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
2Potential solutions
2.1Different VPN and VPN Item products & Agreement-
Entitlement approach
The following ERD diagram defines relationships between the following entities:
Order, Order Items, Asset, Account, Agreement, Entitlement, and Product.
Table 2-1: ERD of VPN-Agreement-Entiltlement solution
The main idea in this approach is consolidating VPN's line items by Agreement and
Entitlement entities concept, when an Entitlement entity indirectly represents a VPN
by related Asset/Product. Agreement entity represents a contract against some account
and the entitlement represents its consequence (indirectly VPN). The approach allows
easy population of appropriate fields in every order item by default values that
potentially can come from previously defined and activated VPN8, in addition the
approach allows easy monitoring and as consequence validation of order, order item,
asset statuses etc.
Root VPN – treated by the order item in an order with root corporate account as
service account, when as consequence of success during the activation process
the VPN will be associated with an Agreement that has been previously set up
and activated
8
The values can be treated as properties or as attributes of order item
-4-

5. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
VPN's line item – treated by the order item in an order with root corporate or
subscriber account as service account, when per each order item an
Entitlement will represent the VPN in which the current VPN's line items has
been participated
Dual Billing9 - treated by changing an billing account for an order
Appropriate pricing – treated by usage of price list and different pricing
mechanism assembled by Siebel Pricer
Activation ability10 - treated by usage of Action field at Order item's level and
common order submission process
Participation to existed VPN ability11- - treated by usage of Action field at Order
item's level and common order submission process
Inactivation ability12 - treated by usage Asset's entity Modify functionality,
Action field at Order item's level and common order submission process13
Elimination from existed VPN ability14 - treated by usage Asset's entity Modify
functionality, Action field at Order item's level and common order submission
process
Asynchronous processing support (order status) – treated by several gate points
for a process15
2.1.1Dual Billing – Several Billing Accounts
The ability of "dual billing" may be provided by standard Siebel's data model but
without the boundaries of oob application. The following ERD diagram shows related
entities and their relationships.
9
An ability of dividing recurring charge between several associated accounts (billing accounts)
10
An ability to activate a new VPN
11
An ability to participate to previously defined/activated VPN
12
An ability of VPN deactivation
13
The main idea is definition and design of common submit process, that will be used by in every
possible case
14
An ability of VPN's subscriber deletion
15
The Submit process potentially asynchronous one, the fact leads to a several possible gates to a
process from different points.
-5-

6. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Table 2-2: ERD of appropriate Account entity instances and their relationships
The solution states that the new field underlied by Siebel's data model illustrated
above will provide an ability of holding several Billing Accounts per each given
Service Account. In each given Service Account there will be primary Billing
Account (one of these who are connected to it through S_ORG_REL16 intersection
table).
The statement mentioned above supports an ability of multiple Billing Accounts per
each VPN's line item17.
2.1.1.1Advantages
Prevents possible mistakes in Billing Account pick up action by previously
defined relationship18
Allows unlimited number of Billing Account per each Order item, without any
representative action
Prevents undesired database growth19
Efficient when allows selection of Billing Account just by choosing Service
Account (functionality based on primary billing account field)
2.1.1.2Disadvantages
No presence of such a field in Siebel's oob application
16
The intersection table of Account entity base table S_ORG_EXT
17
The intention is for a multi value field usage, when in fact the field is only in business layer and its
data retrieval underlied by Siebel's data model
18
Actually there is no need for any interference, the Billing Account will be retrieved automatically
just by previously defined Siebel's data model
19
The growth occurs when billing account associated by foreign key with order item and order item
must be multiplied in order to achieve a multiple billing account
-6-

7. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
2.1.2Dual Billing – Several Order Items with Billing Accounts
The ability of "dual billing" may be provided by standard Siebel's data model within
boundaries of oob application.
The case states that per each Billing Account, the new order item will be created. The
diagram for this case is useless, because no relationships are used and there is simple
field's population at the Order's line items level.
2.1.2.1Advantages
Supported by oob application
Efficient when allows powerful restriction ability applied on retrieved record set
2.1.2.2Disadvantages
Causes to undesired additional step of Billing Account selection
Causes to undesired multiplication of order items in order to achieve a multiple
Billing Account
Permits only hierarchical forward only search based on database foreign keys
2.1.3Dual billing implementation proposition
Common solution must be considered. The solution states that the multi value field
will be used by side with original Billing Account Is field, when the last one will
represent a primary Billing Account among available Billing Accounts which are
related to a given Service Account through described above S_ORG_REL intersection
table.
2.2Different VPN and VPN Item products plus Network
approach
The following ERD diagram defines relationships between the following entities:
Order, Order Items, Asset, and Product
-7-

8. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Table 2-3: ERD of VPN - Network solution
The main idea of the solution is simple classification of existed product by using
Network Element Type field20, in addition to the classification the Premises entity
may be used in order to populate fields like CLLI21, LATA22 as consequence of
Service Address field population at Order's line item level.
The main disadvantage of this approach is definition of network, node and connection
as different products and as consequence undesired creation of order items that
represents node products.
The mechanism allows usage of Compound products verification, as shown in
following diagram.
20
For further information look at Siebel Tools, Internal Product business component
21
Common Language Location Identifier
22
Local Access and Transport Area
-8-

9. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Table 2-4: Schematic diagram of Compound product verification mechanism
The Compound Product Validation Engine allows you to create rules that operate on a
projected future state of a compound product that includes the current quote and any
open orders on the existing assets. This future state is created and stored in the
Projected Asset Cache object.
The Compound Product Validation Engine operates independently of a customizable
product definition. Furthermore, the engine only validates the top level component
and its immediate attributes. This point will affect modeling of Network products.
2.2.1Dual Billing – Several Billing Accounts
The implementation the same as described in 2.1.1
2.2.2Dual Billing – Several Order Items with Billing Accounts
The implementation the same as described in 2.1.2
3Conclusion
As the preferred solution among described above is VPN & Agreement – Entitlement
concept the following risks must be considered23
23
No technical risks (out of CRM) have been observed
-9-

10. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
3.1Potential Risks
3.1.1Ability of multi participating of given MSISDN in several
VPNs
The implementation of such ability is problematic due to the fact that the MSISDN is
property of order item, when the last one represents VPN's line item and MSIDN may
be activated at the same time only for one product instance (order item, asset).
3.1.2Ability of cross compound products validation
The implementation of such ability is problematic due to indirect relationship between
VPN and its participants24.
3.1.3Potential user's experience complexity
4Indexes
6, 7.............................intersection table 4, 6, 7.......................................Account
5, 8, 9, 10.............................mechanism 4, 9.......................................Agreement
3, 5, 6, 7...........................................oob 4, 5, 7, 9........................................Asset
4, 5, 6, 7, 8, 9, 10.........................Order 3, 5..................................Asynchronous
4, 7......................................Order Items 4, 5, 7, 8, 9................................diagram
4, 7, 8, 9, 10..............................Product 3, 5, 7, 9.............................Dual Billing
3...............................................skeleton 4, 5, 9..................................Entitlement
1, 4, 6, 7, 8, 9............................solution 4, 5, 6, 7, 8.....................................ERD
1, 3, 4, 5, 6, 7, 8, 9, 10...................VPN 3, 5, 6, 10..........................functionality
24
The functionality still can be achieved by using previously described Compound Product verification
mechanism which is activated during Order verification process.
- -
10