Advanced Siebel Integration - A SOA Review



A recent Oracle SOA review into one of my customers Siebel Integration capability, rated it as highly advanced. The innovative systems, processes, and tools that were put in place, evolved immensely over the years, and enabled the customer to build, deploy, test and maintain their interfaces quickly and with little effort.

In this organization, the Siebel team provided the front line EAI development, and supported a large portfolio of services across numerous touch points and multiple transport types including MQ, WS, File, HTTP. While adhering to architectural principles such as SOA, P2P, Pub/Sub, this Siebel system plays the role as a consumer, subscriber, publisher, and router of services.

The environment mix, architecture, and scale may differ in your organization, but there are some fundamental challenges that all Siebel Projects face.

High Level Challenges

- Simplify and standardize Integration
- Reduce Integration expenditure
- Agility and Time to market

Simplify and standardize Integration

From a high level, there are a variety of messaging requirements that we may encounter, including Request/Response, Notification, Async callbacks, Pub/sub, then we have various transports to handle, which may include HTTP, Message queues, file formats. We then have to choose between the various transformation options, and figure out how to generate our message with the correct headers, deal with message dispatch and error handling.

There are a variety of implementation options, and each developer will have their own approach to solving the above problems, which can lead to non standardized solutions, that overtime becomes difficult to maintain. Reducing the complexity, and standardising the way we implement integration requires a system that helps us to deliver a consistent solution to dealing with the above scenarios. 

A key component of this system is establishing a Siebel Integration competency centre (ICC), which acts to standardise Integration solutions. An ICC can be defined as team that is responsible for the Siebel EAI needs across different streams and projects. 

Another vital component is the integration framework. An integration framework encapsulates all common integration logic, implements standard design patterns, minimises customisation, coding, and minimize deviation from the standard design entry/exit points. A good integration framework provides the ability to integrate a lot of different technologies, and is instrumental in enabling projects to simply their Integration.

Reduce Integration expenditure

Some organisations approach integration on a case by case basis. The work is put together in an adhoc manner to achieve a certain result, and the grunt work is then repeated on the next project. Issues such as maintenance, error handing, and robustness, unfortunately is an after thought. This causes a lot duplication, waste, increases cost, maintainability, and risk.

An alternative approach is to look at introducing an integration factory. The concept of an integration factory, is not dis-similar to how car factories mass produce vehicles using standard core components, where robots perform the heavy lifting and mundane tasks on a production line, and engineers move in to perform the specialist tasks that require finesse and skill. This results in a consistent and quality deliverable, that is cost effective.

In the same way a Siebel integration factory, can delegate or automate certain integration chores, to free up the Siebel Integrator to perform more value added tasks. This factory consists of a set of tools and processes which allows projects to churn out interfaces using a cookie cutter approach to reduce integration build and test.

Under this approach, less experienced integrators can be used to safely deliver interface work, because the factory enforces a consistent approach to the build. Contrast this with an adhoc build approach, where a less experienced developer is provided with 101 ways to implement something simple like validation, and countless ways to trigger, and implement automation. We can imagine the outcome will be inconsistent, to say the least, and is likely to result in increase costs for the next project who has to maintain this work.
 
An Integration factory provides tools to work with messaging requirements, scaffolding for quick deployment of interfaces, and a controlled process to produce interfaces. Integration artefacts such as VBCs, Inbound, Outbound, Request/Response interfaces all have a certain flavour, and are produced with the same common components, and are orchestrated to meet a requirement. 

By applying standardisation, establishing reusable components, and using proven design patterns to solve known problems, we can reduce the cost and risk of implementing integration.

Agility and Time to market

Many Siebel projects need to support rapidly changing business requirements, and deliver on future initiatives at the same time. Integration is traditionally seen as risky, costly, and usually delegated to major releases, which limits the ability to be agile and deliver solutions quickly.

One of the keys to agility in Siebel is to keep logic out of the SRF, and fortunately Siebel provides a lot of options to configure EAI capability on the fly.

Client side business services

Client side business services allow Siebel customers to configure and deploy technical logic to a run time database. This capability allows project to change logic on the fly, and maintain a 24/7 application. There are customers that purely use Client side business service because of the agility advantages over eScript.

Siebel Workflows

Siebel workflows are the work horse of automation in Siebel, it provides a nice interface with a visual representation of customer logic. Workflows can be configured and deployed to a run time database, allowing projects to switch workflow definitions on the fly, and apply logic changes without downtime.

Business Rule Processor (BRP)

BRP was designed as declarative replacement for eScript, and allows projects to build application logic using a browser. These rules are then executed by a highly optimised engine that works beneath the Siebel BO layer to maximise logic execution. BRP rules can configured and deployed using the Siebel thin client.

Data Mapper

Datamapper is Siebel’s declarative engine that performs an object to object transformation. Data map transformations can be also configured using the Siebel thin client.

Runtime Integration Objects

Integration objects are representations of a model in Siebel, which is usually built using Siebel tools, and compiled into a SRF. However, with an appropriately connected thick client, Integration object definitions can be deployed to a run time database. When runtime Integration Objects are combined with the right mix of EAI technologies, Siebel customers can build and deploy interfaces without downtime.

XSLT

Siebel provides XSLT 1.0 as standard out of the box, but customers can easily implement an XSLT 2.0 engine to get access to an expanded set of transformation options, and speed benefits. XSLT provides a powerful declarative transformation alternative to eScript or Data mapper. 

The Siebel product has a solid range of construction tools out of the box, that allow for changes to be deployed without downtime. Siebel customers that make best use of these technologies, have the opportunity to be very agile and reduce the time to market for their solutions.

Summary

In this article we’ve introduced the high level challenges of Siebel Integration that organisations  face. This prepares us for the next set of articles, where we’ll dig deeper, go through real world scenarios, consider solutions that are aligned to the principles introduced above, walk through the features of a Siebel integration framework, and address the following low level challenges.

- Reducing technical burden
- Dependency on external interfaces
- Working in disconnected environments
- Working within constraints of Siebel product
- Reduce scripting and hard coded references
- Improving code quality 


Reactions:

5 comments:

  1. Just curious, was this project for GE Finance ? Because I had seen all these recommended solutions implemented on that project, including , lots of XSLTs.

    ReplyDelete
  2. Hi, I can't comment on individual customers, but it sounds like they are doing great things!

    ReplyDelete
  3. Hi Jason,

    Love your blog. Agree with frameworks and all, but XSLT is something you don't wish on your worst enemy, crazy syntax...

    Groet,
    Andres

    ReplyDelete
  4. XSLT is an important skill for the Siebel middleware developer. Its strengths are in producing/consuming complex enterprise messages, on the fly, without scripting.

    ReplyDelete
  5. Hi, Jason

    Love this blog.
    We are facing same challenge that you describe and we want to improve our integration within siebel.
    We recently created a Integration Group within our Siebel Delivery Center.

    I'm very interested in you experience.
    Where I can read more?

    Thanks

    ReplyDelete

Comments are open to all, please make it constructive.