Co-existence of Siebel versions 6 and 7

Account structure approach

Author: Roman AgaevDate: Monday, May 14, 2007Contents1 Abstract32 Potential solutions42.1 Service & Billing Accounts represent the customer42.1.1 Advantages42.1.2 Disadvantages42.2 Customer Account represents the customer52.2.1 Advantages52.2.2 Disadvantages63 Criterions63.1 Solution complexity63.1.1 Computation complexity73.1.2 Time complexity73.2 Reliability73.3 Scalability73.4 Time to market73.5 Simplicity73.6 Contiguity to OOB74 Solution Matrix75 Conclusion85.1 Discussion86 Appendixes8

FiguresFigure 11: ERD of involved entities4Figure 22: Schematic diagram of account hierarchy disposition (Billing & Service account)5Figure 23: Schematic diagram of account hierarchy disposition (Customer account)6AbstractThe main aim oh this document is formulating and providing an approach for account structure. The common approach declares that we have several different types of account:Service

Service Aggregator

Board

Central Committee

Billing

Billing Aggregator

Customer

Decentralized

Intermediary

Insurance Company

Planner

Above types don't bound possible complexity of account hierarchy, but provide an ability of effective restriction for different entity instances to be used in undesired and unnecessary way (For example creation a billing profile for service account).Considering complexity of our case the following type are necessary for an implementation and will be used:Service represents an account who really uses an asset

Billing represents an account who pays for an asset

Customer represents an account who uses and pays an asset simultaneously

The following solutions for the account hierarchy are coming to cover any possible process within an implemented system.Figure 11: ERD of involved entities

Potential solutionsService & Billing Accounts represent the customerThe solution states that there is a necessity of having two account entries of different types tied together in order to represent one customer. The main reason for that is concept which is declaring, that billing account pays for an assets that belong to its service account. The approach assumes that every potential service account has at least one similar billing account, when the last one is holding the information regarding billing, financial, exemption, and payments profiles all together.AdvantagesThe support of data model and oob1 Out of the box

functionality

The existence of several functional point that are supports existing of defined profiles in oob applications

DisadvantagesThe approach leads to undesired growth of account hierarchy

The approach leads to computational and as consequence time complexity

Figure 22: Schematic diagram of account hierarchy disposition (Billing & Service account)

Customer Account represents the customerThe solution assumes that there is no actual necessity of having two different account entries in order to support concept of separation billing and service properties of the same customer and states that customer account can be used in order to achieve any required functionality. The data model provided at the beginning of this document states that there is a supported many to many relationship between two given account entries and the relationship supports an ability of multiple billing account per each account entry.AdvantagesDramatically decreases complexity of account hierarchy

Prevents undesired growth of account hierarchy

The approach supported by data model and oob functionality

The existence of several functional point that are supports existing of defined profiles in oob applications

DisadvantagesIn some circumstances simplifies to much an existed reality

Figure 23: Schematic diagram of account hierarchy disposition (Customer account)

CriterionsSolution complexityThe following section of document is coming to analyze two different approaches and prove the statement of analysis.Computation complexityFrom this point of two approaches quite different due to relationship overhead in first one. That relationship in some circumstances may lead to undesired and heavy sql statements during the gui2 Graphic user inerface

development.Time complexityAs consequence of computational complexity the predicted time complexity of first solution much heavy than the parallel one of the second solutionReliabilityTwo approaches have very similar ability to be reliable, but the second one in several circumstances can by less reliable because the solution covers less possible implications.ScalabilityTwo approaches have the same ability of scalability.Time to marketTwo approaches have the same ability to be provided to a market as soon as possible.SimplicityThe second approach wins within this criterion, because it simplifies the concept.Contiguity to OOBTwo approaches own the same contiguity to oob.Solution MatrixTable 41: Solution/Criterions matrixSolution\CriterionComputationalComplexityTimeComplexityReliabilityScalabilityTime to marketSimplicityContiguity to OOBTotal

B&S00111014

C11011116

ConclusionThe conclusion of the analysis states that the combination of two different approaches can be used in order to achieve an appropriate complexity and possible functionality, when the private customer will be represented by account of customer type, and corporate customer will be represented by service and billing account entries that in fact will represent different division within the customer.DiscussionThe state of conclusion paragraph is not mono meaningful, because none of proposed solutions wins in every defined criterions.The combined solution assemblies the approaches and gives an opportunity to every one of it to come to its meaning within the boundaries of the combinationIn any case the solution can be sophisticated or very simple, but must provide simplification in terms of its utilization/usage. Otherwise there is a possibility of getting not linear growth of computational complexity and all its consequences during the development stage of project.AppendixesSiebel bookshelf

Roman Agaev, M.Sc, PMPOwner, Supra Information Technology ltd.

- -