Your SlideShare is downloading. ×
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Potential Vpn Solution
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Potential Vpn Solution

586

Published on

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
586
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
75
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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

×