Bpel 4 people / Bpel 4 newbees

One of the main goals I’m trying to reach is to advise customers on how to start implementation of SOA in their organisation by using a coaching approach instead of implementor approach.

In other words, guide and coach the development teams of each customer in getting familiar with SOA concepts and getting their hands dirty ;o))
The developers themselves are tought BPEL, Web Services, XML and XSD through basic hands on session, workshops in a practical way and then they start designing bpel processes.

What’s very important is this process is that each person needs to do the brainwork, in other words always start from scratch, don’t define a synchronous or asynchronous process, no define an empty process and build it up yourself.

What’s very interesting when guiding and coaching people in becoming a SOA expert, is understanding the way they think and handle functional requests and problems in a SOA Technology. This gives me the opportunity and possibility to focus more on how to better advice and guide people in learning SOA, e.g. BPEL.

The most interesting points to consider and think about when being a teacher in SOA or being a student are the following:

Being a teacher:

  • be passionate, patient, non technical, use metaphors and most don’t use abbreviations or buzz words, this ain’t cool ;o)

Basic knowledge before starting BPEL/ESB/OWSM/Mediators … Integration:

  • Web services (synchronous versus asynchronous)
  • Xml and xsd (how to define, how to work with xml data (xquery, xpath, …)

You need to be able to understand following principles:

  • Fault handling
  • Compensation handling
  • Transaction handling

Following abbreviations mean something to you:

  • JCA, JNDI, EDA, SOA, WSDL, WSIF, SOAP, JMS, RPC

How to get started when designing bpel processes:
One of the interesting tricks I’ve learned when guiding a customers’ developer in learning bpel was that he defined an empty bpel process where all needed activities where pseudo-coded.

In other words when you need to define your first bpel process using the use cases defined and described by your analysts, you just design the bpel process using empty activities which describe each needed task/action in your process.

This empty process is deployable and can then be iteratively implemented by the designer when the visual flow is checked upon with the functional developers. => THIS IS A GREAT INSIGHT and WAY OF THINKING and a very visual approach to enabling business processen (thanks to Yves for the tip !!!)

The most interesting part when starting with SOA development is that everyone that’s involved in this process is learning; it’s a learning organization where every person’s knowledge and expertise is augmented!

OOW – Day 4 – Leveraging SOA to maximize your applications

This session was handling the effect of SOA in an organisation and the challenges each organisation faces today and how you can address these using SOA.

The main keynote that was mentioned here: There’s no way to avoid SOA because SOA Components will be backed inside each software package a company purchases.

So what are the challenges each company is facing today?

  • Reliable batch interfaces
  • Lack of reliabilit
  • Customization of code, rebuilding of code
  • No standardization

How are these challenges addressed using SOA?

  • Modular approach
  • Reusable components which are developed in a granular approach
  • Standards-based (XML, XSD, JCA, WSDL, …), nothing proprietary is being used
  • Focuses on orchestration of services instead of monolithic applications
  • Reduce overall testing effort when re-using services

Why choose SOA?

  • Need for multiple user-friendly applications
  • Complex workflow not delivered in ERP
  • Reuse of services for same business functionality
  • Centralize business rules
  • Give more insight into business

Considerations:

  • Buy-in, you need to discuss the initial investment with the different stakeholders and discuss the ROI
  • Retrain your staff and invest in training, coaching
  • Explain how roles will change in as well functional as technical departments
  • Initially development will be slower because of the steep learning curve

When discussing and talking about SOA, you will always be addressing these kind of problems and issues in any organization. SOA is just a way of thinking and doesn’t mean you need to purchase different kinds of products to make the integration happen.

What the Oracle SOA-product stack will give you is ease of development; declarative environment to work faster, more efficient; common problems are being addressed using design patterns; rich user interfaces can be developed using drag-and-drop functionality; composite designers will enable you to integrate your existing business processes with any legacy system your company has purchased in the past … in other words …

To give a company an insight in it’s SOA awareness and to give them free advise on how to get started, Oracle offers the ‘Roadmap to SOA’. Through different roundtables the customer will get insight in it’s SOA readiness and how they can start with a modular approach.

What are you waiting for … Let’s start integrating !

Some guidance, coaching, product overviews and of course demo’s that show and prove to you that ease of integration … let’s start blogging ;o)