Léon Smiers Blog

Capgemini has been sharing the last couple of years quite a bit around Oracle BPM. I'll keep this post as an index towards these blogs and presentations.
Presentations

Presentation around the Stedin Work Management Case
2011, Léon Smiers/Björn Ampting, Oracle Open World

Oracle SOA and E2.0 Parner Community Forum, BPM
(2011 Léon Smiers)

Simplifying the Workflow Process for Work Order Management in the Utility Market
(2011, Léon Smiers, Oracle Web Conference)
Click on Partner Webcast 'Simplifying the Workflow process...'


Capgemini on Oracle BPM
(2010 Léon Smiers Youtube)

Blogs
Measuring the Human Task activity in Oracle BPM
(2011 Léon Smiers)


The importance of Data in Process Modeling
(2011 Léon Smiers)

Oracle BAM – Look before you leap
(2011 Martijn van der Kamp, Jan Willem Pas)

BPM or BPEL, that is the question
(2011 Léon Smiers)


Enhance your business with Oracle Business Activity Monitoring
(2011 Martijn van der Kamp)

Shifting towards ‘build-to-change’ processes, where’s the flexibility
(2011 Léon Smiers)

Oracle BPM Suite, The importance of sub-processes within BPMN20
(2010 Léon Smiers)

Oracle BPM 11g less is more
(2010 Léon Smiers)

Oracle Business Process Management Suite, the best of both worlds
(2009 Ajan Kramer, Ruben Spekle, Léon Smiers)

Hello,

Since last year I'm heavily involved in the Capgemini Oracle Blog and the CORA model. So if you'd like to find more of my blogs and material please go to these websites.

Léon

Oracle has just launched the 'new' Business Process Management Suite (BPMN). Though special as it is, it has just been announced as a patch set of the Fusion Middleware stack. There is a reason for that. Oracle has been working now for years to implement the vision of creating a product stack that is based upon Complete, Open and Integrated. Opportunity driven but still with this clear vision in mind, and aimed at supporting the Application part of Oracle. This resulted in a continuous stream of software companies being taken over and components added to the stack in order to complete this stack. In order to avoid a mess, Oracle continuously evaluates what product parts are strategic, and advocates reuse to the max. Reuse of components across the Oracle 11G Fusion Middleware stack, like for instance a Database Adapter, is essential. It improves stability and predictability of the solution. BPM just is one of the components plugging into the stack and reuses all other components. Compared to one of its predecessors, BEA BPM, the BPMN product is stripped to its core functionality, less is more!
What is the 'new' BPMN stack? The core of BPMN is based upon the BPMN2.0 specification. The goal is to give one integrated view from architecture all the way to implementation. For every role in the Process life cycle the BPMN stack contains a component, which is more or less connected. All these components can work in unison, but also act separately.

In this blog we’ll detail out the first two phases, Design and Build. In later blogs we’ll elaborate on the other process life cycle phases.

Oracle offers three tools for the design.

Design on Enterprise level is executed by the IDS Scheer ARIS Design Platform. There is currently no connection between ARIS and the rest of the (new) BPMN stack, but it can be expected that Oracle will provide this in the (near) future.

High level process flow design can be done within the browser based Process Composer (Business Analyst type of tool). The Process Composer adds the ability to discuss the shape and structure of a process in a Business user friendly way with a rich set of functionality. This has huge potential for usage in Rapid Design Visualization type of user sessions.

The design can also been done within JDeveloper BPM Studio, which is more suited for developers. Typically this design activity in JDeveloper BPM Studio is done when a solid functional design already exists. Processes and process templates can be shared between Process Composer and the JDeveloper BPM studio.

BPM process development in JDeveloper BPM Studio is created as part of a SCA Composite.
Every component within the SCA composite can be developed in isolation which enables delivery of components by different development teams. This is a big advantage compared to the 'old' BEA BPM tool, where everything was contained in one project. The JDeveloper BPM Studio is very GUI oriented, where you drag-and-drop components on the process canvas. Swim lanes enable to separate Human Tasks, as part of the process, over different user roles. Simulation can help give insight in the behavior of a process, though simulation is an art of its own.
In the next blog we will elaborate on the Build and Deploy phase.

Oracle BPM group Capgemini The Netherlands, Léon Smiers, Alexander Bijl, Gert Jan Kersten
(a repost from Capping IT Off)

Some 20 years ago Larry introduced the first hardware appliance with Oracle, the Network computer, which was aimed at the customer market, to replace the fat clients. As history showed, that was not a very big succes. Even though is was visonair sight twenty years ahead of time, look at the popularity of netbooks (I write this blog for instance on my Asus EEE netbook with which I'm very happy with).

In 2008 Oracle tried again hardware in joined cooperation with HP. The HP Oracle Exadata Server Grid and the Oracle HP Database machine was introduced. This hardware was not aimed at customers but at the high end back-end market. Data Warehouses larger then one Tera Byte get to the problem that the data traffic between the database and the storage server (for instance a SAN) slows down, there is a Data Bandwidth problem. The combined HP Oracle server reduces data going through the pipes, it passes query results and not data disk blocks. It has been tested at different sites with huge data loads, like Amazon, Yahoo and Telco's. In extreme data and processing situations this sounds like a good, and at first sight, cheaper solution. This machine is typically aimed at the large customer market, and therefore not sold in large amounts.

The credo of Oracle is Complete, Open and Integrated. In order to fill in the white space around hardware Oracle finalized last week the deal with Sun, see Oracle-Sun strategy for details. Oracle started some 30 years ago with developing their software on Sun software, so it's like a coming home experience. Oracle is aiming at selling solutions straight from the hardware factory, a machine containing hardware, operating system, database, middleware and applications aimed at a specific market. Oracle is starting with Telco-out-of-the-box. It sounds like an interesting experiment, but still this offer is aimed at the high end customer market. I hope the next move will be aiming at the more common market, selling out-of-the-box middleware or database box. If these machines can contain automatic updates of the database and or middleware, then I'll be happy.

This is a joint effort post from the Dutch Capgemini Oracle Technology team Léon Smiers, Ruben Spekle and Arjan Kramer on Oracle Business Process Management Suite.

Since the acquirement of BEA there has been a lot of discussion with clients around the topic of Business Processes Management or BPM. Oracle has now got two strategic components in this arena. Firstly the already existing component BPEL Process Manager (BPEL PM) in combination with the OEM-ed product Aris (Oracle BPA), and secondly the former BEA Aqualogic BPM product, now called Oracle BPM. On Oracle Open World, last October Oracle announced the unification of both products. What is the impact of this unification and when will this take place?

Oracle placed BPEL PM in its stack with the acquirement of Collaxa some years ago. In the years after the BPEL PM product was enriched with adapter functionality and a Human Task component. BPEL PM is aimed at the more low level process integration which is also known as orchestration. Because of this, designing a BPEL application is a rather technical process. For Business Analysts BPEL is too technical. In order to fill the gap for designing Business processes Oracle OEM-ed Aris and enabled the creation of BPEL models based upon Aris Business Process models. Aris is the de facto standard in the market for Business Process Management Modeling, and contains a huge stack of reference (industry) models.

In BPM creating Workflows is much easier, a Business Analyst models all the processes and creates the lines in between the process steps, based upon which run time components are created automatically. It is a complete framework for creating workflow type of applications. Besides the ease of creation of the workflow processes, BPM is very strong in the build-in mechanism for simulating processes. The designer (Business Analyst) sets timings for each step in the process and can simulate the process. Based on this simulation bottlenecks, like human tasks or asynchronous services can be easily spotted already in a design time stage, without even involving real services yet. During the runtime of a business process, audit information is captured and can be fed back to the process to be able to tune the process based on runtime information as well. This means a real roundtrip lifecycle for business processes. A third strong point is the versioning capability of components (processes, variables) within BPM which allow current versions to run in parallel. Oracle BPM hasn’t (yet) got as many adapters as BPEL, but integration with the use of Web Services works very well.

On Oracle Open World (October 2009), Oracle announced BPM, BPEL PM and Human Tasks will be moved into one Business Process Management Suite. During OOW there were possibilities to get hands-on with this new stack which looked really promising, the same excellent process definition functionality BEA Aqualogic BPM users were used to, extended with integration with BPEL, Human Tasks and other service components all combined in one single stack. In this process of unification predominately the BPM part will be changed. BPM will be based upon the BPMN 2.0 standard, the design time moves towards to both JDeveloper (the implementation part) and the Browser (Design time) and the run time will be based upon a shared runtime environment with BPEL PM. The BPEL PM product on the other hand stays rather untouched in the unification process.
In this architecture BPM, BPEL, Human Tasks and Aris support the following functionality:

BPM supports the Choreography type of functionality, and is more aimed at Business Analysts.
BPEL PM supports Orchestration, low level process integration, and is more aimed at technical people.
Human Tasks support the workflow component of a process, whether this is started from within BPM or BPEL PM.
Aris is used by Enterprise Architects and Business Analysts on a high level.
Unfortunately Oracle does not provide any dates when a version will be released and what functionality it will contain, but we can be convident that it will be available somewhere in the first half of 2010. In the meantime we still can use both separate Process Management solutions, with a preference for the BPEL over BPM, because of expected minor migration complexities towards future releases.

Léon Smiers is Oracle Solution Architect at Capgemini, you can follow him on Twitter
Arjan Kramer is leading an Expert group of Java based Integration Technologists and is thoughtleader on Oracle Fusion Middleware at Capgemini. Follow his thoughts on Twitter
Ruben Spekle is Oracle Solution Architect within Capgemini, you can follow him on Twitter

Soon to be posted on the Capping IT Off blog

Composition is all about combining functionalities exposed from different sources. Up until now SOA hasn't brought us the salvation of combining functionalities from disparate sources. There may be help on the way. Service Component Architecture or SCA offers a simple application model for wiring all functionality together.

Composition is about combining functionalities exposed within an application or from external sources. How is this implemented in programming languages:
Combining functionality within an application is standard practice in languages such as Java and .Net. The functionalities exposed and reused are fine grained, there lots of calls between objects and the communication is based upon a method type of call.
Remote invocations in the same language, from outside the applications, is hard to implement, it is error prone and mostly a lot of time is lost due to all connection and protocol complexity.
Crossing the border in a mutiple language environment calls for the SOA neutral language approach, typically done with Web Services. The usage model of a SOA type of call is completely different then in the case of combining functionality within an application. The exposed and reused functionalities are coarse grained, mostly the amount of calls between services is low and communication is based upon a document type of call. The implementation of Web Service invocation and handling, even though standard frameworks exists are still time consuming and all the error handling needs to take place within the application.
The complexity gets harder when the same service needs to be exposed with multiple communication protocols. Making a unified communication model based upon Web Services is unfortunately not the answer, due to the different usage model of the SOA and low level application type of calls. Web Services used for low level application calls, for instance, are killing for performance.

Service Component Architecture (SCA) offers an implementation model for combing functionality, from internal and external sources, into composites. It offers an environment which takes care of all the communication, or wiring, between the services. SCA is limited to combining application or data logic but is not aimed at the presention layer and the data persistency layer. SCA is a standard defined by the OSOA organization, and is backed up by the vendors IBM, SAP, Oracle (inclusing BEA), Iona and Sun.

Without going into detail here a short summary of SCA.
SCA provides four basis building blocks, Services, Components, Composites and Domain.
Service, Components and Composites are part of SCA Design Time environment, the Domain is the SCA run time environment.
The basic building block is the Component, this holds and implements functionality, which can be exposed via Services. SCA does not deal with with the programming part of the component, it only handles combining functionality together. The only thing which a developer needs to do is state in the component (for instance a Java Class) that at a certain point in the application external functionality is needed, this can be done via a Reference name added as an Annotation in the application.
The Composite is a virtual container (just an XML file) where Components are defined and wired together. Policies can be added to Components when specific requirements on the usage or communication are needed, for instance security or reliability.
SCA enables building applications easily just like combining Lego blocks. Components can be combined into composite. Composites can be reused into new composites. But be aware that the the chain is as strong as its weakest link. If anywhere in the composite there is component that is badly tuned, it affects the composite as a whole. Composites should therefore be accompanied by SLA's, what is expected of the Composite.
The run time environment of SCA is the Domain. Multiple composites can be contained into the Domain. The Domain takes care of all the communication handling and the policies. In contrast to the SOA principle of being vendor neutral, a Domain is based upon one language. This is based upon one of the lessons learned from SOA, that vendor neutrality for fine grained services is overkill from a design perspective and on run time can be resource intensive which can cause performance problems.
SCA uses a very pragmatic approach, when services and clients are written in the same language, there is no need for a language neutral representation. SCA handles all the communications between the objects, or wiring, in a way that is best suited for the language and the environment. When dealing in a hybrid distributed environment the communication is handled via Web Services.

What are typical use cases for SCA
(1) Data composites, in a SCA Data Composite, data coming from different locations can be combined into one composite and the composite returns the combined set.
(2) Application functionality Composite
(3) Process composites

SCA will be able to fullfill the promise of SOA as long as the basic principle, simplicity, will be preserved.

Looking at history, where networks are created and can collapse, we need to learn in IT what the risk are of our attempts to unite the IT landscape with Service Orientation (SOA) and Event Driven Architecture (EDA). Examples in the financial world and the utility market should be a warning for IT of what could hit us. This calls for craftmanship of people in our profession who have the ability to look cross borders and control by means of Governance, in Design AND in Run time.

One example of a collapsing network is the current ongoing subprime mortgage crisis which still creates waves of unemployments, closing of companies an costing a lot of money. It is caused by globalization of the financial world, a would be believe that house prices would never go down, the growing dependancies of markets and the lack of control. At one point is became clear that the fundament of the economic rise, the ever increasing house price, was not a certainty anymore, and the network collapsed.

Another example is in the utility market. On august 14th, 2003 a disruption of the energy grid caused a blackout in the North Eastern part of the US and Canada, and hit 10M people. It started as massive power fluctuation in New York state and, in no time, affected all the areas. Here one flaw in one part of the energy grid caused the collapse of a very large part of the energy grid.

In IT we come from silo based architectures, every functionality (or set of functionalities) is contained in one silo, which may have integration points with other parts in the enterprise but stands essentially on its own. When one of these silos goes down it can cause a major problem for the enterprise, loss of sales, the going down of an essential production process, and in the end money and reputation damage. But at this point, it would NOT cause a cascading domino effect on other systems or enterprises. The promise of the SOA and EDA is the network of applications where everything can be connected and reused. Especially the reuse part can be the risk part, reuse with no insight in the relations can cause Single Points of Failures.

We are creating the power grid of applications for the future, that makes us responsible for making the right choices now.
One of these choices is to know the dependancies of the system components, for both in Design and in Run time.
At Design time, we need to be able to quickly identify all the dependencies in our landscape. This includes both the application types like custom build (based upon all types of technologies), package based, legacy and integration components. With the ultimate wish to be able to create an impact analysis list based upon all the touched components with just one push one the button. Another decision which is made at Design time, is whether we´d like to reuse an existing component, elsewhere in the enterprise landscape or even outside, and what the impact is if that (reused) component goes down. Based on that risk analysis we can decide whether to reuse that component or build it ourselves.
At Run time we need to have insight in the inter relations between all deployed components, and identify possible risk areas, for instance a service which is used by an ever increasing amount of applications.

Where should we start? In most environments people start of with Excel sheets, which in no time are not usable anymore because of the complexity, which calls for the need for proper Governance tooling (or at the basis a dependancy tracking tool). When you start with a Governance tool the environment is, of course, empty. Loading all the components and dependancies in your environment is time consuming and costly. This is the major problem why dependancy tracking tool, (SOA) Governance tools and Service Repositories are hard to start with in enterprises. The Business case at start is way too costly, even though we all know that on the long term it is essential for getting a grip on you IT environment. A diffentiator in this market will be the option to load an existing environment into the dependancy tracking tool repository.