Potential Solutions Co Existence

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

Siebel co-existence

Date: 17/01/2010


Table of Contents

1Abstract............................................................................................................3
2Potential solutions............................................................................................3
2.1UAN – Universal Application Network...................................................3
Integration Description........................................................................4
2.2WBI – Websphere business integration................................................4
2.3Siebel Integration Layer.........................................................................5
2.4Siebel Master Data Applications...........................................................6
2.5Third party custom application..............................................................7
3Criterions..........................................................................................................8
3.1Solution complexity................................................................................8
3.1.1Computation complexity..............................................................8
3.1.2Time complexity..........................................................................8
3.2Closely coupling....................................................................................8
3.3Reliability...............................................................................................8
3.4Scalability...............................................................................................8
3.5Time to market.......................................................................................8
3.6Simplicity................................................................................................8
3.7Failover ability........................................................................................9
4Solution Matrix.................................................................................................9
5Conclusion.....................................................................................................11
6Appendixes....................................................................................................12
6.1Process/Module diagram – schematic level........................................12
6.1.1Description................................................................................12
6.1.2Discussion.................................................................................12
6.2Module diagram – Siebel side schematic level...................................13
6.2.1Description................................................................................13
6.2.2Discussion.................................................................................13
6.3Inbound diagrams................................................................................15
6.3.1Description................................................................................16
6.3.2Discussion.................................................................................16
6.4Outbound diagrams.............................................................................17
6.4.1Description................................................................................18
6.4.2Discussion.................................................................................18


1Abstract
The main aim of the document is discussing possible ways of co-existence of
two quite different versions of the same product.

There are several assumptions:

•First data migration will be performed by EIM (Enterprise Integration
Manager) process execution.

•Data must be integrated in real time

•The solution must achieve the aim within minimum efforts.

2Potential solutions

2.1UAN – Universal Application Network1
Universal Application Network (UAN) is an integration solution that provides a
library of prepackaged, industry-specific business processes that span
multiple applications within and across the enterprise. These processes are
primarily focused on customer interactions and reflect industry best practices.
UAN is built based on open industry standards such as Extensible Markup
Language (XML) and Web Services-enabling enterprises.

The solution uses abilities that are delivered by Siebel. Those abilities in fact
are bounded by previously done configuration. The main idea in UAN is
making different systems to talk the same language using common business
object and application independent cross-system business.

1
The solution requires integration middleware like BizTalk, TIBCO, WBI

Table 2-1: UAN logical structure

2.1.1Integration Description
The Siebel Master Data Applications deployment uses the Universal
Application Network (UAN) framework and architecture to synchronize
account, contact, prospect, and household data across disparate systems.
Each application on the UAN can act as a source of new and updated
customer information and can also receive new and updated information from
other applications. The UAN Customer Lifecycle Management suite provides
integration business processes that route customer profile changes through
the Siebel Universal Customer Master Application to provide cleansing,
matching, and data enhancement. The Universal Application Network can
also synchronize customer information between Siebel Master Data
Applications and Siebel Business Applications (including previous versions).
The current UAN Customer Lifecycle Management integration business
processes are used primarily for scenarios in which multiple applications-
including Siebel Business Applications, back-office systems, and legacy
applications-store a copy of the customer profile and require Siebel Master
Data Applications to act as the primary registrar to determine the validity of
new and updated customer information. The UAN provides a reusable
integration solution with Siebel Master Data Applications.


2.2WBI – Websphere business integration2
The solution uses abilities that are delivered by WBI. Those abilities in fact are
bounded by previously done configuration and dedicated server components
of Websphere. The main idea in WBI is making interface to the Siebel easy
and fast for an implementation without heavy interruption in the internal
processes of it.

Table 2-2: WBI logical structure

Monitored actions in monitored business components will store an event row
in previously defined and created table in Siebel's database using previously
defined and created support business layer.

WBI Connector Agent monitors the table mentioned above by using JDB and
if needed retrieves a row from Siebel's database according key stored there,
the retrieved message propagated to an MQSeries queue and peeked from
there by another Webshpere module (connector controller running in
Websphere ICS) that propagates it to the WBI Connector Agent that
processes given data by appropriate action.

2.3Siebel Integration Layer
The solution uses internal abilities of the Siebel.

2
The solution requires several Websphere components installed and previously configuration added to
the Siebel

Table 2-3: Siebel Integration Layer logical structure

Simple propagation of information through an integration middle-ware to the
endpoint, for easiness the transformation may be applied on every side. The
main point is usage of general and conventional tools provided by Siebel
environment.

2.4Siebel Master Data Applications3
The solution uses applicative behavior of an applications like UCM (Universal
Customer Master) and abilities delivered by those applications including
markup language CRMML.

3
The solution uses CRMML (Customer Relationship Management Markup Language)

Table 2-4: UCM logical structure

As illustrated in Table 2-4: UCM logical structure, an inbound business
process flow starts with a Receiver Server Component, such as the MQSeries
or HTTP Receiver. The Receiver runs in the background, continuously waiting
for messages to arrive from external applications. After receiving a CRMML
message, the receiver then invokes the workflow process configured to
handle and process the data.

2.5Third party custom application
The solution uses predefined interfaces like COM, JDB, and ActiveX.

There are several ways of integration, for example usage of JDB or COM
objects inside of source application that updates destination one by direct
updates, or usage of integration layer from outside, for example business
service or workflow execution through the URL request.


3Criterions

3.1Solution complexity

3.1.1Computation complexity
The criterion is about an ability of making computation easy, encapsulated,
type oriented. In fact the main aid is making the computation of O (0)4.

3.1.2Time complexity
The criterion is about an ability of making computation fast5.

3.2Closely coupling
The criterion is about ability of different modules to exist independently each
from other.

3.3Reliability
The criterion is about ability of relying on work that is about to be done by
some module without monitoring or some other action of that type.

3.4Scalability
The criterion is about ability of growing. In fact the main aid is making system
that able to grow infinitely without any impact on functionality or some other
properties of a system.

3.5Time to market
The criterion is about of time from the beginning of work on a solution till the
end.

3.6Simplicity
The criterion is about difficulty level of chosen solution implementation, when
the aid is to make it easy as much as possible.
4
As a branch of the theory of computation in computer science, computational complexity theory
describes the scalability of algorithms, and the inherent difficulty in providing scalable algorithms for
specific computational problems.
5
The time complexity of a problem is the number of steps that it takes to solve an instance of the
problem as a function of the size of the input (usually measured in bits), using the most efficient
algorithm.


3.7Fail-over ability
The criterion is about ability to keep on working in case of partial fail and fast
recovery in case of entire system failure.

4Solution Matrix
The following section deals with an issue of comparison between possible
solution regarding provided criterions.

•Computational Complexity6 – UAN just like WBI talks about using of common
object and provides a set of tools that underlies the concept, UCM has a little
bit different approach when in fact here in place of common object we are
using common application, all of those approaches kindly difficult for an
implementation, even whether vendors are talking about time to market
advantage in real life the advantage is coming instead of flexibility, simplicity
and decoupling the solution become to be in many cases the real source of
administrative and development problems as well, in other words another
potential undesired point of errors. In opposite to approaches mentioned
above Siebel Integration Layer provides flexible, simple and very powerful
infrastructure that can be used for creation various types of interoperable
interfaces. The custom application in any cases will provide much complicated
solution than previously described ones.

•Time complexity – UAN, WBI, and UCM take us far away of straight forward
solution and became the way from getting input to providing output a multistep
one. Solution based on Siebel Integration Layer may be much efficient exactly
in places where those concepts may take much more time.7 Custom
application completely depends on efficiency of conceptual approach, but in
any case can't be much efficient than solution based on Siebel Integration
Layer.

•Closely Coupling –WBI makes applications be closely coupled in an
extremely way by using JDB fro integration purposes, UAN just like UCM and
Siebel Integration Layer solution much efficient and provide a high level of
6
Complexity theory deals with the relative computational difficulty of computable functions. This
differs from computability theory, which deals with whether a problem can be solved at all, regardless
of the resources required
7
All of those approaches must use integration middleware like BizTalk, Websphere, TIBCO

decoupling. The custom application can't avoid the coupling due to potential
usage of COM or JDB interfaces for an integration purposes.

•Reliability –WBI solution provides a good level of reliability when in fact saves
as events every action over integrated business components, but this is just
an approach and that's why may be implemented also in UAN and Siebel
Integration Layer solution without time or complexity impact. UCM provides
another, but still reliable approach (main database). The custom application
potentially has a least reliable approach.

•Scalability – UAN and WBI solutions provide a good level of scalability due to
modularity usage concept, the main difference of those approaches is an
implementation platform, then UAN "sees" Siebel system as a primary system
in a given environment and WBI in opposite way "supposes" that Siebel is
only one of numerous systems. UCM provides an extreme extension of UAN
vision. In fact UCM assumes that Siebel system is a dominant system in an
environment. Solution based on Siebel Integration Layer enough flexible to
provide a good level of scalability due to a fact, that the solution almost
entirely suppose to be implemented on Siebel platform which is scalable by
itself. Custom application probably will least effective and will suffer of various
administrative, development and deployment problems.

•Time To Market – WBI asserts short time to market parameter, just like UAN
and UCM the solution comes as product that underlies by well argued
concept, but consumes time for an understanding, deployment, and
integration and in many case changes that lead to an inappropriate usage of a
product. Solution based on Siebel Integration Layer provides an effective,
flexible and fast way of implementation, in opposite way custom application
probably will consume much more time and at the end will provide a worse
time to market.

•Simplicity – WBI, UAN and UCM very sophisticated and complicated
solutions that contain several undesired potential points of error. Solution
based on Siebel Integration Layer in opposite way much easy and potentially
may contain less such points. Custom application will be also sophisticated
and complicated.

•Fail-over ability –WBI provides a good level of recovering and fail-over ability
due to its modularity and "event driven" concept, UCM also provides a good
level of recovering and fail-over due to main "data storage" concept. UAN,
solution based on Siebel Integration Layer and custom application have the
same ability based on Siebel system's abilities.

Table 4-5: Solution/Criterions matrix

Solution Computational Time Closely Reliability Scalability Time Simplicity Fail- Total
Criterion Complexity Complexity Coupling to over
market ability
UAN 8 5 10 9 10 8 8 8 66
WBI 8 5 7 9 10 10 8 9 66
SIL8 9 8 10 9 9 9 10 8 72
UCM9 8 5 10 9 9 8 8 9 66
Custom 7 5 5 8 8 5 5 8 51

5Conclusion
According the information provided above:

•UAN – is an overkill solution that conceptually provides solution for a different
need much wider than ours case, moreover the solution takes a step forward
and instead of integration middle-ware declares on common object model. In
fact the declaration assumes Siebel system as primary system in an
environment.

•UCM – is an overkill solution that conceptually needs to be based on
infrastructure provided by UAN and powers it by providing CRMML language
definition as a language for interoperability needs.

•Custom application – heaviest way to a solution, probably in some cases
seems to be easiest and most flexible one, but without any doubt to
adventurous.

•WBI – is a second best solution due to its conceptual contiguity that entirely
applies to ours needs, but the solution still much sophisticated and potentially
has much more points of error

8
Siebel's integration layer
9
Universal master data application

•Siebel Integration Layer solution – the best among discussed solutions,
provides complex of characteristics that support it due to its simplicity,
flexibility, time to market and reliability.

6Appendixes

6.1Process/Module diagram – schematic level
Picture 6-1: Process/Module diagram

6.1.1Description
The main approach assembles in a term of using physical field that holds
integration id from foreign system. The integration id field will get by default
value of primary key field and in case of integration error the value will persist
to be the default one. The errors handling mechanism will gather all of the
rows with same values in primary key and integration id fields and perform an
appropriate action.10

In above figure described schematic structure of proposed solution, when the
main details of the scheme are integration middle-ware, transport layer of
Siebel environment, application layer of Siebel environment and database.

10
The value in integration id field will always be a primary key of the last updated row in an entire
environment.


6.1.2Discussion
Within an assumption that integration middle-ware should not by closely
coupled with any application that's exposed its API through the middle-ware
the environment becomes to be strongly layered and fulfills OCI model.

Application layer of Siebel application encapsulates application, presentation
and session layers of OCI model and allows powerful user experience within
an application. Transport layer of Siebel application encapsulates transport
layer of OCI model and exposes user-friendly application programming
interface for sockets usage.

Integration middle-ware contacts peripheral systems like Siebel by its own
application layer that's been designed and exposed by other agents, when the
main aim of the middle-ware is information transportation from one to another
agent (system) with possible data transformation.

6.2Module diagram – Siebel side schematic level
Picture 6-2: Component diagram

6.2.1Description
The above figure represents modules that are interconnected and
interdependent by proposed solution boundaries.


6.2.2Discussion
Proposed solution includes several modules:

•Application Object Manager (AOM) – foreground multi-threaded component
that allows simultaneous invocation of several application instances.

•Workflow Process Manager – background multi-threaded component that
allows simultaneous invocation of several workflow instances.

•Workflow Policy Monitor – background singleton component that allows
monitoring and appropriate invocation of jobs tracked by workflow policy
definitions.

•Enterprise Application Integration Object Manager (EAI) – background multi-
threaded component that allows simultaneous invocation of several
application instances.

•Siebel Web {Server} Extension (SW{S}E) – two complement modules that
allows interconnection between web server and application server. The
connection handled by session layer and uses SISNAPI network protocol.

•HTTP Module – exposed application programming interface that allows
usage of operation system abilities within context of TCP/IP communication.

•Authentication Manager

•Database (DB2)


6.3Inbound diagrams
Picture 6-3: Inbound state diagram

Picture 6-4: Inbound interconnection diagram


6.3.1Description
The figures above represent inbound request handling, when the first figure
describes the process from state-to-state transition and the second one from
interdependency perspective.

6.3.2Discussion
The inbound request handling must be implemented with very high level of
abstraction in purpose to allow easy expansion of current implementation by
newly defined entities without heavy administrative or design impact. Such
approach means that information regarding currently arrived message
reflected by its structure and encapsulated inside of it.

The usage of several multi-threaded components makes the solution highly
available and extensible thanks to resilient processing within an enterprise
server.

The arrived message goes through the strongly typed transformation
(integration object) and accommodation by EAI Siebel Adapter business
service11, in any case http response sent back in purpose to close an
integration circle.

11
Strongly typed transformation available thanks to common object model applied by integration
middleware.


6.4Outbound diagrams
Picture 6-5: Outbound state diagram

Picture 6-6: Outbound interconnection diagram


6.4.1Description
The figures above represent an outbound request handling, when the first
figure describes the process from state-to-state transition and the second one
from interdependency perspective. Attention need to be paid for a second
figure, when two different (black, blue) colors represent different routes of
outbound request handling and common parts of it have its own independent
color (green).

6.4.2Discussion
The outbound request has two different routes, when the first one uses
workflow policies (triggers) and the second one uses repeated component job.

The first route is the regular one when database change tracked by triggers
and handled by Workflow Policy Monitor12.

The second route is dealing with an errors occurred during an integration
attempt that's been done by the first route.

The message generated by EAI Siebel Adapter business service as a
sequenced step will be propagated to a destination using EAI HTTP Transport
business service13, according HTTP response from a destination system an
origin row will or won't be updated with integration id field value.

Attention need to be paid thanks to potential distributed transaction
invocation14.

12
The definition of Workflow Policy includes an action that needs to be performed in case of desired
conditions satisfaction.
13
Attention need to be paid due to potential Unicode or not trivial code-page data transportation.
14
The issue must be handled by complex approach that will include data restriction and error handling.

Potential Solutions Co Existence

More Related Content

What's hot

Similar to Potential Solutions Co Existence

More from Roman Agaev

Recently uploaded

Potential Solutions Co Existence