Wednesday, August 15, 2007

Siebel - Potential VPN Solution

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 resolution 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 1 0
3.1.1 Ability of multi participating of given MSISDN in several VPNs 1 0
3.1.2 Ability of cross compound products validation 10
3.1.3 Potential user's experience complexity 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

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 Billing[1]
* Appropriate pricing
* Activation ability[2]
* Participation to existed VPN ability[3]
* Inactivation ability[4]
* Elimination from existed VPN ability[5]
* Asynchronous processing support (order status)
The further analysis assumes the following assumptions:
* Root VPN is product[6]
* 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 oob[7] 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.
2 Potential solutions
2.1 Different 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 VPN[8], 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
* 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 Billing[9] - 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 ability[10] - treated by usage of Action field at Order item's level and common order submission process
* Participation to existed VPN ability[11]- - treated by usage of Action field at Order item's level and common order submission process
* Inactivation ability[12] - treated by usage Asset's entity Modify functionality, Action field at Order item's level and common order submission process[13]
* Elimination from existed VPN ability[14] - 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 process[15]
2.1.1 Dual 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.
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_REL[16] intersection table).
The statement mentioned above supports an ability of multiple Billing Accounts per each VPN's line item[17].
2.1.1.1 Advantages
* Prevents possible mistakes in Billing Account pick up action by previously defined relationship[18]
* Allows unlimited number of Billing Account per each Order item, without any representative action
* Prevents undesired database growth[19]
* Efficient when allows selection of Billing Account just by choosing Service Account (functionality based on primary billing account field)
2.1.1.2 Disadvantages
* No presence of such a field in Siebel's oob application
2.1.2 Dual 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.1 Advantages
* Supported by oob application
* Efficient when allows powerful restriction ability applied on retrieved record set
2.1.2.2 Disadvantages
* 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.3 Dual 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.2 Different VPN and VPN Item products plus Network approach
The following ERD diagram defines relationships between the following entities: Order, Order Items, Asset, and Product
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 field[20], in addition to the classification the Premises entity may be used in order to populate fields like CLLI[21], LATA[22] 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.
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.1 Dual Billing – Several Billing Accounts
The implementation the same as described in ‎2.1.1
2.2.2 Dual Billing – Several Order Items with Billing Accounts
The implementation the same as described in ‎2.1.2
3 Conclusion
As the preferred solution among described above is VPN & Agreement – Entitlement concept the following risks must be considered[23]
3.1 Potential Risks
3.1.1 Ability 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.2 Ability of cross compound products validation
The implementation of such ability is problematic due to indirect relationship between VPN and its participants[24].
3.1.3 Potential user's experience complexity

4 Indexes
Account, 2, 4, 6, 7
Agreement, 2, 4, 5, 10
Asset, 4, 5, 8, 9
Asynchronous, 3, 5
diagram, 2, 4, 6, 7, 8, 9
Dual Billing, 2, 3, 5, 6, 7, 9
Entitlement, 2, 4, 5, 10
ERD, 2, 4, 6, 8
functionality, 3, 5, 7, 10
intersection table, 6, 8
mechanism, 2, 5, 8, 9, 10
oob, 3, 6, 7
Order, 2, 4, 5, 7, 8, 9, 10
Order Items, 4, 8
Product, 4, 8, 9, 10
skeleton, 4
solution, 1, 2, 4, 6, 7, 8, 10
VPN, 1, 2, 3, 4, 5, 6, 8, 10

[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
[8] The values can be treated as properties or as attributes of order item
[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.
[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
[20] For further information look at Siebel Tools, Internal Product business component
[21] Common Language Location Identifier
[22] Local Access and Transport Area
[23] No technical risks (out of CRM) have been observed
[24] The functionality still can be achieved by using previously described Compound Product verification mechanism which is activated during Order verification process.






Sunday, July 29, 2007

Siebel - Common System Parameters

1 Abstract 4
2 Analysis 4
3 Design 5
4 Conclusion 6
4.1 Usage Examples 6
5 Appendixes 7

Figures
Figure ‎2‑1: System parameters ERD.. 4
Figure ‎4‑1: System parameter - RetrieveCustomSystemParameter 7

Tables
Table ‎3‑1: System parameters module's layers decomposition. 5

1 Abstract
This essay takes as its purpose analysis and design of custom system parameters module. The meaning of custom system parameter is data that shared across all sessions within the Siebel enterprise.
The module provides an ability of data retrieval and its appending.
2 Analysis
The system parameters module must give an opportunity of shared data management, when the main purpose of such data is not a run time globals or any parallel concept, but information without time boundaries,
The following diagram presents entity relationship diagram of needed business layer:
Figure ‎2‑1: System parameters ERD












The module must include several elements from database, business, and graphic user interface layers:
Applet
View
BC (Business Component) – contains several methods and based on custom table
BS (Business Service) – contains several methods delegated by underlied business component
Table
3 Design
The analysis can be handled using a single stand alone module definition. The module will include several elements from every one of three application tiers:
* Graphic User Interface Layer
· View – System Parameters View
· Applet - System Parameters List Applet
* Business Layer
· Business Object – System Parameters
· Business Component – System Parameters with methods
- NewEntry() – creates new log entry
- RetrieveCustomParameter() – searches across the log table and retrieves data
· Business Service – System Parameters BS[1] encapsulates delegated methods of Business Component
* Database Layer
· Table – CX_SYS_PARAM
The following table demonstrates those elements per layer:
Table ‎3‑1: System parameters module's layers decomposition






4 Conclusion
Current essay provides a new sight over the old problem, how to store cross sessions parameters and effectively use them during the sessions of system users. The pattern can be used in many applications like CTI phone book, XSLT etc.
4.1 Usage Examples
The following figures demonstrate proposed solution examples:
Figure ‎4‑1: System parameter - RetrieveCustomSystemParameter


5 Appendixes
* "Workflow usage best practices" (Roman Agaev)
* "Common VBC paradigm" (Roman Agaev)
* "Common error handling mechanism" (Roman Agaev)
[1] Cacheable business service

Monday, July 23, 2007

Siebel - Common Redirection Mechanism

1 Abstract 4
2 Analysis. 4
3 Design. 5
4 Conclusion. 5
5 Appendixes. 5

Figures
Figure ‎2‑1: Redirection mechanism - high level diagram.. 4

1 Abstract
The main goal of this document is trial of giving an additional level of potential client redirection within Siebel application after his/her authentication and primary authorization done using standard authentication adapters/mangers, responsibility and visibility features.
The analyzed module must provide:
Additional client side redirection
Additional authorization
Additional redirection logic
2 Analysis
The module in general must answer on requirement that declares the neediness in some circumstances the client redirection within the Siebel application.
The server side redirection may be achieved using GotoView method of Application global and has no ability to be exposed in different way from within Siebel business layer.
The client side redirection in opposite can be realized using standard Siebel business layer. Within the business layer the ability of inline html/script injection can be used on order to achieve an appropriate redirection.
The following diagram describes the system's high level:
Figure ‎2‑1: Redirection mechanism - high level diagram




3 Design
The functionality can be achieved using Field Retrieval Type property of Siebel applet's control. The values of that property that are relevant for the current discussion are:
Symbolic URL – used just for Siebel web site decomposition
inline
iframe
control (activex solves the problem of window object access)
form request – raises new window
Field Value – straight html/script injection[1]
The design will include several approach adaptation steps:
Common parameters mechanism for html/script storage
Siebel business component – new calculated field with html/JavaScript rounded by quotes
Siebel applet – exposition of previously defined calculated field using Field Retrieval Type populated as Field Value
4 Conclusion
The approach described in current essay permits another level of authorization and mainly can be used in order to redirect an unauthorized user from sensitive information to the appropriate web page for further authorization process.
The implementation is very simple, accumulates several approaches like common system parameters[2].
5 Appendixes
* "Workflow usage best practices" (Roman Agaev)
* "Common VBC paradigm" (Roman Agaev)
* "Common error handling mechanism" (Roman Agaev)
* "System parameters paradigm" (Roman Agaev)
[1] Document object should be used instead of window object, because of frame complexity within Siebel web site exposition
[2] For additional information regarding the topic refer to "System parameters paradigm" from Appendixes section of the document.

Siebel - Common Global Parameters

1 Abstract 4
2 Analysis 4
3 Design 5
4 Conclusion 6
4.1 Usage Examples 6
5 Appendixes 7

Figures
Figure ‎2‑1: Global parameters object 4
Figure ‎4‑1: Global parameter – SetPrameter, FindParameter, ResetParameter, GetEntirePicutre 6

Tables
Table ‎3‑1: System parameters module's layers decomposition. 5

1 Abstract
This essay takes as its purpose analysis and design of custom global parameters module. The meaning of custom global parameter is data that shared across all processes within the user session, in addition the information can be written to the database.
The module provides an ability of data retrieval, its appending, and its flushing.
2 Analysis
The global parameters module must give an opportunity of shared data management among the processes within the user session, when the main purpose of such data is being a run time parameters.
The following diagram presents object diagram of needed business layer:
Figure ‎2‑1: Global parameters object



The module must include several elements from database, business, and graphic user interface layers:
  • Applet
  • View
  • BC (Business Component) – contains several methods and based on custom VBC[1]
  • BS (Business Service) – contains several methods delegated by underlied business component

3 Design
The analysis can be handled using a single stand alone module definition. The module will include several elements from every one of three application tiers:
* Graphic User Interface Layer
· View – System Parameters View
· Applet - System Parameters List Applet
* Business Layer
· Business Object – System Parameters
· Business Component – System Parameters with methods
§ SetParameter() – creates new entry
§ FindParameter() – makes a search across parameters in order to find out the appropriate parameter that answers on search specification
§ ResetParameter() – resets the data of given parameter
§ GetEntirePicture() – retrieves the entire picture of populated parameters as hierarchy. The hierarchy can be presented within the appropriate applet.
· Business Service – Global Parameters BS[2] encapsulates delegated methods of Business Component
The following table demonstrates those elements per layer:
Table ‎3‑1: System parameters module's layers decomposition




4 Conclusion
Current essay provides a new sight over the old problem, how to store cross processes parameters and effectively use them during the session of system users. The pattern can be used in many applications like CTI phone book, XSLT etc.
4.1 Usage Examples
The following figures demonstrate proposed solution examples:
Figure ‎4‑1: Global parameter – SetPrameter, FindParameter, ResetParameter, GetEntirePicutre




5 Appendixes
* "Workflow usage best practices" (Roman Agaev)
* "Common VBC paradigm" (Roman Agaev)
* "Common error handling mechanism" (Roman Agaev)
[1] For further information please refer to "Common VBC paradigm" in Appendixes section of the document
[2] Cacheable business service

Tuesday, July 10, 2007

Siebel - Account structure approach (Telco)

Account structure approach


Contents


Figures
Figure ‎1‑1: ERD of involved entities. 5
Figure ‎2‑1: Schematic diagram of account hierarchy disposition (Billing & Service account) 6
Figure ‎2‑2: Schematic diagram of account hierarchy disposition (Customer account) 7

1 Abstract

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.

Figure ‎1‑1: ERD of involved entities



2 Potential solutions

2.1 Service & 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.1 Advantages

* The support of data model and oob[1] functionality
* The existence of several functional point that are supports existing of defined profiles in oob applications

2.1.2 Disadvantages

* The approach leads to undesired growth of account hierarchy
* The approach leads to computational and as consequence time complexity




Figure ‎2‑1: Schematic diagram of account hierarchy disposition (Billing & Service account)








2.2 Customer 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.1 Advantages

* Dramatically 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

2.2.2 Disadvantages

* In some circumstances simplifies to much an existed reality

Figure ‎2‑2: Schematic diagram of account hierarchy disposition (Customer account)




The following section of document is coming to analyze two different approaches and prove the statement of analysis.
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 gui[2] development.
As consequence of computational complexity the predicted time complexity of first solution much heavy than the parallel one of the second solution
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.
Two approaches have the same ability of scalability.
Two approaches have the same ability to be provided to a market as soon as possible.
The second approach wins within this criterion, because it simplifies the concept.
Two approaches own the same contiguity to oob.
Table ‎4‑1: Solution/Criterions matrix



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.
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.
* Siebel bookshelf

[1] Out of the box
[2] Graphic user inerface

Siebel - Application definition and design approach

Application definition and
design approach

Contents





1 Abstract 4
2 Database layer analysis & design 7
2.1 Information adaptation 8
2.2 Siebel data model comparison 8
2.3 Siebel data model extension 9
3 Business layer analysis & design 9
3.1 Data access layer 11
3.1.1 Data access information adaptation 11
3.1.2 Analysis of Siebel's data access layer 12
3.1.3 Siebel's data access layer adaptation 12
3.2 Business logic layer 12
3.2.1 Logic information adaptation 12
3.2.2 Analysis of Siebel's standard logic 13
3.2.3 Siebel's logic adaptation 13
4 Graphic user interface layer analysis & design 14
4.1 GUI adaptation 15
4.2 Analysis of Siebel's standard GUI 16
4.3 Siebel's GUI adaptation 16
5 Integration layer analysis & design 16
5.1 Interfaces adaptation 18
5.1.1 Inbound interfaces 18
5.1.2 Outbound interface 19
5.2 Analysis of Siebel integration layer 19
5.3 Interfaces Adaptation within boundaries of Siebel integration layer 19
6 Conclusion 19
6.1 Discussion 19
7 Appendixes 19
8 Indexes 20





Figures





Figure ‎1‑1: Siebel Entity Relationship Diagram example. 5
Figure ‎1‑2: Analysis & Design Waterfall 6
Figure ‎1‑3: Analysis & design waterfall - integration layer 7

1 Abstract


The main aim of the document is trial of discussion regarding the way of structured analysis and design within Siebel environment.
The purpose of the document will be achieved when such a way will come to its most effective realization, through usage of object oriented analysis and design standard techniques.
Siebel platform is coming to expose object oriented environment based on relational databases, using definition of strong, reflected, and extremely generalized object model. Siebel's object model elements interact within the boundaries of system using provided frameworks defined by application servers that are functioning within enterprise server. The interoperation became to be available thanks to definition of unique interoperation protocol which works over HTTP named SISNAPI. Siebel object model defined within several members/components of application server. Those components are application object managers that provides multithreaded environment using predefined multithreaded servers. Siebel enterprise can accommodate several application servers, when each of those has only one listener (Siebel Connection Broker component) that works simultaneously on application server's machine.
The most significant elements of Siebel object model are:
* Business Object
* Business Component
* Business Service
The Business Component represents an entity based on several tables from within Siebel data model that are joined by appropriate join definitions[1]. Those entities present information that has been gathered during interaction with database layer. The entities within Siebel applications may be related to each other in different ways within different Business Objects that provide ability of entities relationship definition using predefined links. Those links in fact present a parallel concept to join but within Business layer.
Siebel environment has capability of entity relationship definition which in fact presents an ability of effective way to design Business layer through the analysis phase.





Figure ‎1‑1: Siebel Entity Relationship Diagram example








The following diagram presents a proposed way for waterfall styled analysis & design phases. The proposed way provides an ability with less resources to handle a bigger work front when allows unidefined way of iterative progress started from data model adaptation through several phases to integration layer adaptation.
It must be realized that there is no shortening ways within the analysis phase only fulfillment of each key step as defined within diagram permits proceeding to the next one.
The diagram consisted of nine phases when integration layer is not represented there. It will be presented separately due its uniqueness in analysis and design.




Figure ‎1‑2: Analysis & Design Waterfall








The interfaces layer analysis & design presented by the following diagram.



Figure ‎1‑3: Analysis & design waterfall - integration layer




2 Database layer analysis & design

Database layer consisted of complete definition of bounded tables list, their constraints (user keys, data types, physical length, and foreign keys), and their indexes. Siebel database layer supports all of those standard mechanisms and provides several additional capabilities like denormalization path, predefined list of values (part of multi lingual list of values definition), accommodation of tables from different datasources within single data model.
The following are most significant emphasizes of the current issue:
* Determination of all main tables that are going to be used within the application
* Determination of all relationships within the boundaries defined by previous step, and as consequence determination of all foreign keys within each table
* Determination of possible normalization level (1NF[2], 2NF[3], 3NF[4], BCNF[5], 4NF[6], 5NF[7]), when generally Siebel application's data model is designed as 4NF.
* Analysis of possible drawbacks of defined data model in terms of performance, and as consequence definition of denormailzed columns within defined tables
* Adaptation of defined data model within Siebel's predefined data model
* Analysis of gap between those two data models
* Possible change of Siebel data model without impact in terms of non appropriate usage of predefined tables, normalization and performance.

2.1 Information adaptation

The phase is taking as aim a trial to realize needed data model in non Siebel terms. The external data model must be critically reviewed and different representation of current data model must be done a moment before the information adopted within Siebel's data model.
The result of review must be well normalized (according previous decision) model of data with all necessary constraints, and indexes.

2.2 Siebel data model comparison

Previously defined data model must be critically compared against existed one. During this process the gap must be defined as well as possible ways for its elimination.
The main assumption which must accompany the analyst through this process is that Siebel's data model probably contains all needed tables and relationships. This approach can lead in some cases to change previous decisions that had been made within adaptation process which's been done before, so two visions must come to their common through the current phase of analysis & design.
The result of the process is unidefined data model described by Siebel's terms and adopted within its boundaries by unidefined appropriate technical descriptions.

2.3 Siebel data model extension

As result of previous two phases within Data Layer analysis & design section the appropriate changes may be needed for the Siebel's data model.
The proposed changes are:
* Additional extension tables with 1:1 relationship
* Additional extension tables with 1:M relationship
* Additional stand-alone tables
* Additional intersection tables
* Additional fields for the already existed table
* Additional indexes
* Additional denormalization paths
The usage of extension table against additional fields must be considered in each occurrence of such a dilemma. It must be realized that not in every case the usage of any of those concepts will lead to the best performance.
The usage of denormalization paths within the Siebel data model definition provides an ability of slight denormalization and thereby performance increasing. The performance affected using decreasing number of tables participated in sql statement that underlies given entity (Business Component).
The result of the process is final data model fully adopted within Siebel boundaries.

3 Business layer analysis & design

Business layer consisted of two sub layers: data access layer, business logic layer. Data access layer combines capabilities of database interaction including: sql statement definition, transaction management, and external systems interoperation.
* SQL statement definition - the statement prepared according Business Component definition its base table, joins, search & sort specifications etc.[8]
* Transaction management – completely encapsulated from developer.
* External system interoperation – the interoperability allowed using VBC (virtual business component) and different supported transports within the Siebel system (HTTP transport, MQSeries transport, MSMQ transport, JMS transport etc.)
Business logic layer combines capabilities of process flow management, server & browser side scripting, and predefined functionality managed mainly by user properties of several object model elements.
* Process flow management – Siebel's provides capability of process flow management when defines and allows usage of workflow processes. The workflow processes design within Siebel environment and in fact expose an ability of high level programming using high level declarative bounded programming language. The workflow process paradigm supports SOA concepts using unconnected and unrelated methods and functional point for final purpose achievement[9].
* Server & Browser side scripting – Siebel environment provides several capabilities of additional script appending. The script may be placed in the following object model elements: Application, Applet, Business Component, and Business Service. It must be realized that usage of browser side script must be minimized due to its high intensive impact on client/server networking. The main usage of browser side scripting is field's value or static state checks mainly handled using regular expressions.
* User properties – the object model provided by Siebel exposes predefined functionality based on class functionality of the following object model elements: Applet, Business Component, Business Service (mainly used within Business Component and Applet).
The following are most significant emphasizes of the current issue:
* Mandatory usage of Entity Relationship Diagram designer within the Siebel Tools
* Determination of all strong/weak entities that are going to be used within the application
* Determination of datasource per each entity within the application.
* Determination of all relationships within the boundaries defined by previous step, and as consequence determination of all links[10] related to each entity
* Adaptation of previously gathered information within Siebel's business layer boundaries
* Determination of all possible combinations of entities within the application using Business Objects definition (relationships defined by links[11])
* Determination all needed fields within each among defined entities, the step includes possible definition of joins and multi value link[12]
* Determination of all pre/post default values for each appropriate field
* Determination of gathering behavior per each field using the following properties: Force Active, Link Specification
* Determination of list of values per each appropriate field using picklist[13] concept of Siebel environment.
* Determination all needed calculated fields per each entity
* Review of predefined user properties.
* Determination of all appropriate functional points per each entity including their definition[14]
* Definition of Business Service proxy per each strong entity, for delivering its functionality possibly out of internal implementation.

3.1 Data access layer

The layer is responsible for database interaction.

3.1.1 Data access information adaptation

The phase is taking as aim a trial to realize needed data access layer. The data access layer must be critically reviewed and possibly different design of current data access layer must be provided a moment before the information adopted within Siebel's data access layer.
The result of review must be an entity relationship diagram consisted of every defined entity that consisted of fields populated by physical columns from within sql statement produced by the entity or by calculated value.

3.1.2 Analysis of Siebel's data access layer

The phase is taking as its aim an analysis of already existed entities environment within the Siebel system and trying to find out whether entity relationship diagram suits currently existed environment.
Siebel environment supports many different relationships and provides an ability to see by different view angle in many cases, different relationship picture.
The result of this step must be full realization of Siebel environment capabilities in terms of its suitability to entity relationship diagram defined within the previous step.

3.1.3 Siebel's data access layer adaptation

This phase is coming to compose the results of two previous phases by adaptation within Siebel business layer boundaries. The result of such an activity can be decision to extend data access layer by addition other entities or in opposite way just to change existed ones.
In case of data access layer changing the need of changes within database layer may raised up. In such a case database layer design need to be reconsidered and all related steps need to be performed as described by Figure ‎1‑2: Analysis & Design Waterfall.
The result of this phase must final definition of appropriate entity relationship diagram within Siebel boundaries and its complete design including possible extensions or changes supported by database layer.

3.2 Business logic layer

The layer is responsible for internal business logic.

3.2.1 Logic information adaptation

The phase's main aim is complete definition of all needed logic regarding the implementation. The logic definition needs to be gathered from every possible source in order to avoid further problems of miss leaded solution.
The gathered functional points must be collaborated and generalized in order to design an effective logic mechanism that will answer on basic object oriented analysis & design criterions: reliability, availability, extensibility. Moreover the potential design needs to compose several significant characteristics like encapsulation, generalization, overtaken execution, unidefined strong types. The design must consider the data access layer designed during previous step.
The result of this phase must be thorough definition of needed business logic and its potential design in terms of object oriented paradigm considering Siebel environment restrictions.

3.2.2 Analysis of Siebel's standard logic

This phase deals with Siebel internal functional ability in terms of its suitability to previously defined business logic. During this phase the gap must be assessed and trial to overtake it within the Siebel boundaries must be taken.
The result of this phase must be fully realized and determined gap between business logic provided by Siebel environment without any interference and needed business logic defined and designed during previous step. The gap in fact may be handled and assessed in terms of computational and time complexity and as consequence translated to actual/real schedule and work front. It must be realized that without any reliable assessment of potential development phase, the work become to be adventurous and potential risky without any justification. It must be realized that under some circumstances the needed business logic may lead to some changes within data access layer..

3.2.3 Siebel's logic adaptation

The phase's aim of this step is to translate previously assessed functional gap in actual Siebel system design using appropriate system tools, in other words to perform an adaptation of previously defined and designed business logic.
The adaptation of the business logic must include definition of every functional points per each entity within developed application, moreover it have to show how the process flows will be treated, how the general functionality will be used, how the elements of object model are going to interact within the application.
The following key elements must be supplied:
* Business Component logics
* Business Component's proxy logics
* General Business Service definition
* Common Error Handler definition
* Common Messaging Engine definition
* Common Logging definition
* Application logics
The result of this phase must be final and full composed design of technical solution in order to achieve an appropriate functionality/business logic defined by previous steps. The design must be based and supported by data access layer and its entities. It must be realized that business logic mustn't be defined and designed separately from data model and data access layer definitions, because of their mutual influence.

4 Graphic user interface layer analysis & design

Graphic user interface layer consisted of complete definition of every appropriate GUI elements. Those elements are listed below:
* Screen
* View
* Applet
* Tool bars (mainly based on JavaApplets)
Siebel applications provide two different approaches of application running framework:
* Web thin client
* Web dedicated client[15]
Siebel applications provide two different approaches of application exposition:
* High interactive[16]
* Standard interactive[17]
The following are most significant emphasizes of the current issue:
* Determination of all needed Screens within the application. When the Screen composes logically related groups of entities (for example Accounts, Contacts, Orders, Quotes, Opportunities, Agreement, Products).
* Determination of all needed Views within the application. When the View based on Business Object and potentially exposes the relationships defined within the Business Object using Applets and their basis Business Components, when the last are related to each other by relationships reminded above.
* Determination of all needed Applets within the application. Each Applet based on Business Component and represents the data retrieved from database through database and data access layers within the boundaries defined by relationships of its Business Component inside the Business Object that underlies the current View.
* During the previous step the need of data access layer changing or extension may be raised up. In this case all appropriate steps from Figure ‎1‑2: Analysis & Design Waterfall must be taken and evaluated again.
* Determination which of defined Applets from previous step will participate in each of predefined Views.
* Determination which of defined Views from above steps will participate in each of predefined Screens
It must be realized that Siebel system exposes its Web application using its own web extension. The extension (.swe) uses the SWE plug-in within the Web Server for interconnection with Siebel Application Server's SWSE plug-in using integration layer. The SWSE produces the content of the Web site using Siebel's own markup language. Siebel does not provide any tools for effective work with web templates that written in reminded above markup language.
The information above is reasoning that mainly no web templates changes are acceptable[18].

4.1 GUI adaptation

The phase's main aim is gathering all needed information in order to define and perform a prior design for a graphic user interface.
During the define phase there is no need to take in considerations Siebel application constraints and functional restrictions. The main purpose of this step is full and deep understanding of application's desired graphic user interface, including all possible features.
The result of the phase is defined GUI, when all features considered and integrated within the definition. It must be realized that Siebel system is not a development platform and there is no reason for such a relation to it.

4.2 Analysis of Siebel's standard GUI

This phase is taking as its purpose an analysis of Siebel standard graphic user interface and its suitability to the definition of GUI that has been done during previous step.
During the work related to the step, a need for change or extension within data access layer may be raised up. In such a case all needed steps according Figure ‎1‑2: Analysis & Design Waterfall must take a place in order to handle cascade adaptation of all redefined structure to a new reality.
The result of this phase must be compared analysis of needed GUI against existed one and as consequence a gap needed to be handled by adaptation step. It must be realized that GUI must not lead the design phase and in fact just represents predefined data access layer using standard Siebel's object model elements.

4.3 Siebel's GUI adaptation

The main aim of this phase is performing an adaptation of previously defined GUI. During the adaptation all needed technical solutions must be considered in order to achieve an appropriate appearance defined within previous steps.
It must be realized that Siebel environment has its own tools for GUI implementation, and main course is staying within the boundaries that Siebel provides by those tools.
The result of this phase must be final design of new application, consisted of database layer, business layer, and graphic user interface layer.

5 Integration layer analysis & design

The integration layer is maybe the most sophisticated layer from technical perspective. Its effective implementation relies in many aspects on well defined and designed data business layer, when not just data access layer is important, but functionality across involved entities has its own inevitable influence on integration layer.
The main aim of integration layer design is trying to stay within the thesis that integration layer can operate using the same business layer like graphic user interface. In many cases the thesis fall down under the pressure of reality that dictates different process flows within GUI and integration layer.
Within integration layer the following types of interface can be distinguished:
Inbound interfaces
Outbound interfaces
When in their turn the inbound interfaces can be categorized as following:
Inbound gusty interface[19]
Inbound on-demand interface[20]
The following are most significant emphasizes of the current issue:
Determine all needed interfaces against every external systems
Determine among those interfaces, those that will participate inbound interfaces group, and those that will take place in outbound interfaces group.
Determine within inbound interfaces group those interfaces that demand an answer in synchronous manner and those that demands it in asynchronous manner.
Choose the integration mechanism architecture for outbound interfaces[21]
Choose the integration mechanism architecture for inbound interfaces[22]
Define per each interface appropriate communication protocol in terms of in/out message[23]. In case that integration middleware is existed the common object modeling paradigm must be used in addition the intermediary must be used in order to delegate transformation and redirection duties from Siebel to the that intermediary.
Analyze Siebel integration layer in order to find out whether needed integration layer can be implemented using standard and common mechanisms predefined within the Siebel system. If during this examination the need of business layer has been raised up, the appropriate steps in order to handle cascade change of whole application design must be taken before actual proceeding.
Design every interface separately considering every restriction of Siebel and external systems. The main purpose is to stay within predefined unified approach.
Design any needed infrastructure based on Business Services, Workflow Processes, and Business Components in order to simplify, generalize, and unify the uture development[24].

5.1 Interfaces adaptation

The main aim of this phase is collaboration of information regarding any needed interfaces within the boundaries of future system. At this moment the design is ready and analysis of future interfaces can rely in some aspects on work that has been done before, but still the process of gathering information and definition of interfaces on basis of information reminded before will be done without any considerations in terms of Siebel's future application architecture.
The result of this phase is full list of all needed interfaces divided on two parts: inbound and outbound. Each of those interfaces definition must include its nature (synchronous, asynchronous), destination and source systems, and structure of expected messages for request as well as for response.

5.1.1 Inbound interfaces

Inbound interfaces can be handled using several approaches:
* EAI object manager framework. The framework provides an ability of standard typeless HTTP request usage as well as Web Services[25].
* MQSeries receiver[26]
* MSMQ receiver
* JMS receiver
* External DLL functions plus Blob (binary big objects)[27]
* CORBA architecture[28]
* Custom repeated job with wrapped JMS client (using Siebel Java Business Service)
Recommended approach is most standard and most reliable approach – EAI object manager plus Siebel Web Services.

5.1.1.1 Interfaces on demand

Depends on nature of interface: synchronous or asynchronous.
The synchronous, on demand interfaces in fact provide a response immediately during the integration session. The asynchronous mainly provide just a job id or any other process identification in order to be able to tie future response with the request.
It must be realized that approaches like HTTP request and Web Services can be used for asynchronous integration also[29].

5.1.1.2 Interfaces without demand

The inbound gusty interfaces suppose to work against EAI object manager framework or any other server's receiver component that implements monitoring/poling paradigm.

5.1.2 Outbound interface

The outbound interfaces implemented using one of available transports within the originating system.

5.2 Analysis of Siebel integration layer

The main aim of this phase is analysis of currently provided by Siebel capabilities in order to find out whether defined in previous steps interfaces are suitable and may be implemented within the Siebel future application using standard Siebel's tools.
As result of reminded analysis the change within already defined and designed business layer may be raised up. In such a case appropriate steps in order to handle cascade change across whole application definition and design must be taken according Figure ‎1‑2: Analysis & Design Waterfall and Figure ‎1‑3: Analysis & design waterfall - integration layer.
The result of this phase must be the gap assessment if existed between needs and system capabilities considering future system definition and design

5.3 Interfaces Adaptation within boundaries of Siebel integration layer

The phase takes as its purpose final design of all predefined interfaces. At this moment every interfaces defined, and found suitable to predefined business layer.
The main activity through this phase is mapping of defined interfaces with predefined business layer.
The result of this phase must be final design of every defined interface.

6 Conclusion

The phases of definition and design in many cases have very smooth boundaries. This contiguity in many cases leads to mistakes within the stage of analysis and design, especially when the environment is not thorough object oriented and there are no undefined layers within the environment.
The process of analysis and design must be managed and planned very carefully, no jumps and parallel work suggested. If those conditions will preserve it is possible to perform an analysis and design with less resources, but more effectively.

6.1 Discussion

The stage of project where the future system first time gets its conceptual fullness is the stage of analysis. The analysis of future system requirements sometimes may bring analysts in front of in a good case very heavy problem and in a worst case the problems without the solution in given circumstances.
The reasoning above leads to conclusion that analysis must be performed top-down, when the meaning of that statement – system requirements in each of its layer need to be generalized and per each specific need the analysis will to go down through the general to the subject itself. When the thesis is that within several points of such an analysis the previous points will take part of it and at end the full analysis will able to accommodate a reasonable change within conceptual boundaries of the system without any impact and almost without any further analysis.
Design stage in many aspects very similar to analysis, but the biggest difference between those is that design never can lead the analysis, but analysis always leads the design.
It must be realized that sometimes development/system environments (like Siebel, .NET, J2EE, SAP) set up the boundaries of its capabilities, especially when the system is not clear development resource like Siebel, in such cases design will influence analysis, just because not everything is possible within the environment.


7 Appendixes


* "Workflow usage best practices"(Roman Agaev)
* "Common guidelines" (Roman Agaev)

8 Indexes


analysis, 2, 4, 5, 7, 9, 12, 13, 15, 17, 19, 20, 21, 22
Business Component, 4, 9, 10, 11, 14, 16
Business layer, 2, 5, 9
Business Object, 4, 15, 16
Business Service, 4, 10, 11, 12, 14, 19, 20
Database layer, 2, 7
design, 1, 2, 3, 4, 5, 7, 9, 10, 12, 13, 14, 15, 16, 17, 19, 20, 21, 22
diagram, 5, 7, 12, 13
Entity Relationship Diagram, 3, 5, 11
environment, 4, 5, 10, 11, 12, 13, 17, 21, 22
Graphic user interface layer, 2, 15
GUI, 2, 10, 15, 16, 17, 18
HTTP, 4, 10, 18, 19, 20
integration layer, 2, 3, 5, 7, 16, 17, 18, 20, 21
interaction, 4, 9, 12
JMS, 10, 18, 20
MQSeries, 10, 18, 19
MSMQ, 10, 18, 20
normalization, 8, 11
object model, 4, 10, 11, 14, 17, 19
object oriented, 4, 13, 21
performance, 8, 9
Siebel, 2, 3, 4, 5, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22
SQL, 10
SWE, 16
SWSE, 16

[1] There are only two options regarding tables joining within Siebel environment: inner join, left outer join. Another significant remark is that joins can be implicitly or explicitly defined.
[2] 1NF – There is no duplicate rows in a table, each cell is single valued, entries in the column are of the same kind
[3] 2NF – 1NF plus if all non-key attributes are dependent on all of the key
[4] 3NF – 2NF plus if it has no transitive dependencies (A transitive dependency is a type of functional dependency in which the value in a non-key field is determined by the value in another non-key field and that field is not a candidate key)
[5] BCNF (Boyce-Codd Normal Form) – 3NF plus if every determinant is a candidate key
[6] 4NF – BCNF plus if it has no multi-valued dependencies
[7] 5NF – 4NF plus if every join dependency in the table is a consequence of the candidate keys of the table
[8] Search & Sort specifications may be provided through the GUI definition also.
[9] For more information regarding workflow processes please refer to "Workflow usage best practices" from appendixes section of the document
[10] Link – Siebel object model element, in fact the element is enabling override of entities combinations/relationships within an application previously defined by database layer using foreign keys and normalization concept.
[11] Mainly link must be based on database layer and its foreign keys including cascade behavior
[12] Multi value link (MVL) is the second option of combining entities together using link definition. Highly usable within integration processes
[13] Picklist is presentation layer of predefined business component. The picklist allows population of several fields within an entity through the pick action of one of its available entries. Mainly based on List Of Values business component.
[14] Mandatory being within boundaries determined by Common guidelines document, please refer for additional information to appendix section of the document
[15] Web dedicated client – application and web server instances are running locally. The application's data source not relevant and can be any available choice.
[16] High interactivity – the meaning is that web site uses interactive elements downloaded to a client machine in order to improve user experience and standardize client/server interconnection using common events paradigm.
[17] Standard interactivity – the meaning is that the web site works as standard web site using html stream which is coming regarding client's request from server side. The approach has many disadvantages when the major one is user experience.
[18] In each rule there are exceptions, here every exception must be proved as inevitable.
[19]The interfaces just arrives to the predefined virtual directory that points to the EAI object manager server component.
[20]The interface that in fact the following step of previously initiated outbound call. The result of such a call may be provided in synchronous or asynchronous manner, when the emphasize deals with the second option.
[21] There are many different ways to get connected within the enterprise, when the most significant ways are: HTTP request, Web services, JMS, MQSeries, MSMQ
[22] It must be realized that any other choice except EAI object manager framework, must be proved as inevitable solution because of it's being not standard
[23] It must be realized that any other choice except XML won't be the main stream/standard choice.
[24] The reminded elements of Siebel object model are not affecting already defined design. They must be part of infrastructure additional resources.
[25] Siebel Web Services are fully compliant with common WS standards provided by WWW consortium. Siebel Web Services supports usage of SOAP, XML, WSDL, WS-Security, RPC binding, Document binding, WS ports.
[26] Background Siebel component instance that enables checking of predefined queue on predefined server and invokes an appropriate Business Service or Workflow Process.
[27] Usage of Blobs and their descriptors enables integration without XML data representation. The same has been used by .NET framework (for 1.1, 2 versions, and WCF for further version) for Remoting concept design
[28] The most complicated architecture, demands additional several components within Siebel application server.
[29] Every interface must be defined carefully with full considerations regarding every possible and impossible restriction.