This document proposes two approaches to account structure: 1) having separate service and billing accounts represent a customer, and 2) having a single customer account represent a customer. The single customer account approach decreases complexity and prevents unnecessary account growth while still supporting necessary functionality. However, it may oversimplify some real-world scenarios. The best solution may be a combined approach using customer accounts for private customers and separate service/billing accounts for corporate customers.

1. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Account structure approach
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 Service & Billing Accounts represent the customer........................................4
2.1.1 Advantages............................................................................................4
2.1.2 Disadvantages........................................................................................4
2.2 Customer Account represents the customer.....................................................5
2.2.1 Advantages............................................................................................5
2.2.2 Disadvantages........................................................................................6
3 Criterions.....................................................................................................................6
3.1 Solution complexity.........................................................................................6
3.1.1 Computation complexity.......................................................................7
3.1.2 Time complexity...................................................................................7
3.2 Reliability.........................................................................................................7
3.3 Scalability.........................................................................................................7
3.4 Time to market.................................................................................................7
3.5 Simplicity.........................................................................................................7
3.6 Contiguity to OOB...........................................................................................7
4 Solution Matrix...........................................................................................................7
5 Conclusion...................................................................................................................8
5.1 Discussion........................................................................................................8
6 Appendixes..................................................................................................................8
-2-

3. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Figures
Figure 1-1: ERD of involved entities.............................................................................4
Figure 2-2: Schematic diagram of account hierarchy disposition (Billing & Service
account)..........................................................................................................................5
Figure 2-3: Schematic diagram of account hierarchy disposition (Customer account). 6
1Abstract
The 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.
-3-

4. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Figure 1-1: ERD of involved entities
2Potential solutions
2.1Service & Billing Accounts represent the customer
The 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.
2.1.1Advantages
The support of data model and oob1 functionality
The existence of several functional point that are supports existing of defined
profiles in oob applications
2.1.2Disadvantages
The approach leads to undesired growth of account hierarchy
The approach leads to computational and as consequence time complexity
1
Out of the box
-4-

5. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
Figure 2-2: Schematic diagram of account hierarchy disposition (Billing & Service account)
2.2Customer Account represents the customer
The 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.
2.2.1Advantages
Dramatically decreases complexity of account hierarchy
Prevents undesired growth of account hierarchy
The approach supported by data model and oob functionality
-5-

6. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
The existence of several functional point that are supports existing of defined
profiles in oob applications
2.2.2Disadvantages
In some circumstances simplifies to much an existed reality
Figure 2-3: Schematic diagram of account hierarchy disposition (Customer account)
3Criterions
3.1Solution complexity
The following section of document is coming to analyze two different approaches and
prove the statement of analysis.
-6-

7. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
3.1.1Computation complexity
From 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 development.
3.1.2Time complexity
As consequence of computational complexity the predicted time complexity of first
solution much heavy than the parallel one of the second solution
3.2Reliability
Two 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.
3.3Scalability
Two approaches have the same ability of scalability.
3.4Time to market
Two approaches have the same ability to be provided to a market as soon as possible.
3.5Simplicity
The second approach wins within this criterion, because it simplifies the concept.
3.6Contiguity to OOB
Two approaches own the same contiguity to oob.
4Solution Matrix
Table 4-1: Solution/Criterions matrix
Solution Comput Time Reliab Scalab Time to Simpli Contiguity Total
Criterion ational Complex ility ility market city to OOB
Comple ity
xity
B&S 0 0 1 1 1 0 1 4
C 1 1 0 1 1 1 1 6
2
Graphic user inerface
-7-

8. Roman Agaev, M.Sc, PMP
Owner, Supra Information Technology ltd.
5Conclusion
The 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.
5.1Discussion
The 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 combination
In 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.
6Appendixes
Siebel bookshelf
-8-