Eric D. Schabell: October 2008

Friday, October 31, 2008

Blog hit rate back on track in 60 days

Back on the 1st of August I lost my long running domain name (.com). I then was forced to run about and setup this new domain and migrate my site over. I documented the resulting plunge of site traffic a month ago with a graphic and posted a 30 day update awhile back.

Well, I can now say that at 60 days this blog is back on track:

The 100 hits per day average I had with my .com domain appears to have been regained. It might be a bit early to call it, but I think it is back up online with the recent boost from my jBPM postings and Open Source/Java speaking engagements pulling a lot of interest.

Sunday, October 26, 2008

Halloween 2008

As you might know, I am a big fan of this holiday and again this year we have put out the carved pumpkin assortment. We are lucky enough to get supplied with these pumpkins as a friend has a pumpkin farm in his family. They know I love to do this so he has dropped off an assortment the last two years.

My little girl and boy have gotten into the act this time with each working out their own pumpkin faces (Daddy does the carving still).

There was more than enough for some lovely pumpkin soup which I wanted to make a bit more tasty for the kids, so I added honey mustard this time. They seemed to enjoy this better than last years traditional version.

Happy Halloween!

Friday, October 24, 2008

jBPM process rework replies

I wanted to put up some more information based on the questions placed on my first article on our jBPM process rework project. I think I need to put a few details in perspective and then I will try to answer the questions posed.

A bit of background first. I am the technical lead on this so the technical details are my playground. I am required to work within the Architecture guidelines as handed down by the department of the same name. These restrictions will be mentioned below in my replies as I encounter them. I will provide the plans I outlined for clarity here:

My plans:
  • Business logic is being encapsulated into services and pushed down into the SOA layer.
  • Transitional actions are being brought up into process steps
  • Core process steps are being black-boxed so that you can fill them with any eventual project specific sub-flow definitions as needed.
  • Migrating almost all process nodes to state nodes to facilitate a proxy between the process instance node and the service layer (calls)
  • Looking to add a custom jBPM class loader with maven like functionality to facilitate multiple projects running with different service versions (why we need this is an infrastructural problem)
My expansion on these bullets will include a response to the comments in the previous post (handled in order):
  • I wish we were using ESB, but we are not allowed. We use a mix of POJO in jBPM with service calls mixed in (services being pure unreliable SOAP messaging over HTTP) PS. I loved the demo, wish I had the ESB property editor, I have to dig through code (handlers) to see what is going on with service calls in a node.
  • Yes, this lack of visibility combined with the extensive java coded logic being processed in some of these transitions bothers me greatly in my situation. I just want future projects to be able to estimate new implementation efforts within this process flow a little easier. Best way is to make everything in the flow a bit more visible.
  • An architectural limitation is that this project is part of a longer strategic plan that locks us into the 3.1.4 release. It would be of great interest to me to be able to dynamically select a sub-flow at run time. I was just planning to decision node right before selection of the sub-flow needed.
  • No, you are missing something and it is not you! It is a long story and involves a reference project (we try our best!). Due to lack of ESB like solutions for reliable messaging, we are left with a very unreliable HTTP communication for services. On top of this we have asynchronous non-transactional back-end systems. All due to these architectural limitations, we hope to improve process resilience with a proxy between the process node and the service call (treat each call as an external system basically). It will call the service, provide some extra tricks to handle specific problems with back end systems, and signal the state-node with the results (good or bad). Not the classic use of a state node, I know, thoughts?
  • Again, I have no option for 3.3. In the above mentioned reference project we did pirate some functionality (migrated some classes over to improve auto par generation), but think that class loaders are a bit harder to hijack back down to 3.1.4 versions. We are just interested in pointing to different service endpoints for different jbpm processes (not within a single process). We have failed on class loading issues when trying to deploy these service jars within the par files for a process. It should be pretty straight forward to use a maven like construction to always look for all process related classes (jars) inside a single directory within the deployed process. At least we think/hope so.
Basically the architectural limitations have crippled all nice solutions I have seen in the jBOSS stack

I chatted with Mark Little a bit when he visited here in the Netherlands, but we did not get too deep into jBPM. I do follow your comments extensively on the various jbpm jboss lists (user, developer, forums, issues, commits).

I do like what is coming down the road with jBPM (PVM, GWT console). I would love to setup the new GWT monitor for my older jBPM setup, but I am assuming that would not really be possible.

Member of the Computable Expert Panel Open Source

I have been added to the Computable Topic Open Source panel as one of the Experts in this area. The idea is to provide articles, opinions and basically just keep this area of the site interesting and lively.

From time to time they ask for input on some subject (already have a request for some input on a topic in the order of 300 words). They would also like us to submit white papers or interesting articles as we encounter them.

Sunday, October 19, 2008

Pegasystems BPM job offer

This was of some interest as I have been working with BPM rather intensively for about a year now and my first targeted BPM job offer has popped up. The mail contact went like this:

Your name has been recommended to me with regard to a position I am recruiting for currently.

I am currently looking for a Senior System Architect to work for my client who is a leader in the BPM field. They are looking for people with a good technical understanding and the attitude to be able to communicate with customers and turn business requirements into technical solutions. Having looked at your profile you look like a good match for the role and I would like to discuss this in more depth with you if possible.

Would you be kind enough to get in touch? My contact details are below. I am happy to give you a call if you can reply with a mobile contact number.
 


 I generally do not reply to this sort of head-hunting, but curiosity got the better of me and I wanted to know who was behind this. Turns out it is one of the larger BPM tooling organization in the business, Pegasystems Inc. based in the USA. The job offer was for a Senior System Architect, which means:
 
"As lead member of a project team ensures that the business and technical architecture of the delivered solution matches customer requirements. Responsible for providing high quality consulting services on all project assignments. Demonstrates a broad knowledge of either a target vertical industry or functional area (e.g., CRM, deployment, etc.). Travel Requirements: more than 75% travel."


Ouch on the travel... but I am not really looking anyway, I am having too much fun at my current job to want to move off into some other corner of the world!

Friday, October 17, 2008

jBPM process rework in progress

My current project has provide me with the chance to rework a rather a monolithic jBPM process implementation. It is my third time working through this same process flow and I want to do something about it before it gets any worse. It consists over over 59 nodes (decisions, task-nodes, nodes, but not a single state) and has all business logic intertwined within the individual nodes. Even some of the transitions have handlers that are providing business logic functionality which mystifies me to no end.

When the applications business logic is not placed in a service layer then I would expect that it would be kept as visible and above water as you could make it. The idea being to facilitate maintenance and future development within/upon the process flow. I was wrong. I won't get into the long story about how we got to the point that we can rework this process flow, it is not very interesting and I imagine it is par for the course in most large software development organizations.

All in all, it has provided a very interesting first step in my current project to start working on this problem. I am currently migrating as much logic possible from the transitions back into the process steps or even creating new process steps to bring this functionality into the light. Visibility is the key here. My plans:
  • Business logic is being encapsulated into services and pushed down into the SOA layer.
  • Transitional actions are being brought up into process steps
  • Core process steps are being black-boxed so that you can fill them with any eventual project specific sub-flow definitions as needed.
  • Migrating almost all process nodes to state nodes to facilitate a proxy between the process instance node and the service layer (calls)
  • Looking to add a custom jBPM class loader with maven like functionality to facilitate multiple projects running with different service versions (why we need this is an infrastructural problem)
This should keep me busy for the rest of the year as it is not a small task. More on this migration should any interesting experiences arise and feel free to provide input should you have some thoughts on these points.

Friday, October 10, 2008

Blog hit rate climbing out of the basement

Back on the 1st of August I lost my long running domain name (.com). I then was forced to run about and setup this new domain and migrate my site over. I documented the resulting plunge of site traffic a month ago with a graphic and a promise to report back the results over time.

Well here we are a month later and things have slowly started picking up:

 
 Google picked up my new location and the search hits turned up the .org links pretty fast. I was surprised. You can see the daily hits are slowly getting back up towards an average of around 35-40 per day, nothing like the 100 I was pulling previously but better than I personally was expecting inside of a month. I am slowly climbing out of the basement...

JFall 2008 - Full Scale STP with jBPM

I sent in a paper for the JFall 2008 Dutch Java conference and have been accepted. I will be presenting an Industrial track talk on my first attempted BPM paper at SNS Bank.

My talk will be a bit more focused on the Java aspects of course, but it remains a practical experience that is now over 9 months in production. I will be hinting at the effects of the 'credit crisis' that we have all been reading about and should be able to provide up to date empirical evidence of the success of our implementation. My talk details as submitted are partially in Dutch, but will put them here for reference.

Abstract:
As one of the larger Dutch financial institutions, SNS Bank in the Netherlands has made a strategic decision to empower her customers on-line by automating her business processes. The ability to facilitate the customer is achieved by applying BPM techniques in her existing selling channels. Both the publicly available and internal processes are being revamped to provide the customer with full scale Straight Through Processing (STP). This paper takes a tour of the latest BPM project at SNS Bank, provides empirical evidence that this move has already allowed SNS Bank to reap the benefits of BPM, and discusses the remaining challenges for both business and IT.

Overzicht:
Deze presentatie is een praktijkverhaal van de SOA/BPM implementatie bij SNS Bank. Deze implementatie loopt al een jaar in productie. Ik zal onze ervaringen toelichten en onderbouwen met verzamelde metrics van de afgelopen jaar.
Ik begin met een introductie van de Open Source invalshoek van SNS Bank die naar Java/STP/JBPM heeft geleid. Daarna komt het marketingverhaal dat 'Straight Through Processing' toelicht en waarom dat van belang is bij SNS Bank. De implementatiearchitectuur zal kort toegelicht worden met focus op onze eerste ervaringen met het implementeren van SOA/JBPM bij SNS Bank. Daarna presenteer ik onze samenwerking met Atos Origin om een BPM-referentieproject neer te zetten. Als laatste stap, kijken wij naar de lessen die wij uit de laatste jaar kunnen halen en wat de toekomst zal brengen voor SNS Bank op het gebied van SOA/BPM.

This talk is related to my session at Linux World 2008.

UPDATE: you can get the PDF presentation here.