Saturday, December 23, 2006

Tagged...

I got tagged - Todd Biske got me. Which means I have to expose 5 things about me that are not commonly known (at least by the people that read this blog), then tag some other unsuspecting bloggers. So here goes:
  1. I spent 12 months traveling in South America. I knew that I was reasonably proficient in the language when I could argue with taxi drivers that chose to drive the 'turista' the expensive route.
  2. I used to play tenor sax. I was probably terrible but would love to have learnt how to play the instrument with some subtlety.
  3. I think I must be the only person in Massachusetts that doesn't own a car.
  4. I'm a pretty good skier. I'd love to be in Colorado right now up to my knees in snow. Unfortunately I'm writing this because I'm sitting in a ski house in the North East US watching the rain out of the window. Global warming makes me unhappy in so many ways.
  5. I enjoy playing football (soccer) despite being pretty awful when the ball is at my feet, but I'm fast and have good stamina so I make a decent defender. I miss the intra-office games that we played when I first starting working, as there is nothing like running out some work frustrations by kicking at your boss's ankles in a competitive setting.

Sorry guys, its the holiday season, so I'm having a little fun - you're tagged: Bruce Silver (a great source of thought provoking BPMS discussion) and David Rudolph (my new found colleague blogger). Happy Holidays/Happy Christmas!

Technorati tags:

Improving applications upsets users?

As many bloggers go quiet over the holiday season it gives me a good chance to catch up some reading on blogs I have missed over the last few weeks while working through the recent product release at Global 360.

A nice series of posts on Tyner Blain caught my eye: Going Agile, 10 Mistakes. Its interesting for me since unknowingly, the R&D groups I work with are so experienced and have so much background working together that agile techniques are implicit to much of what they do. They are ideally placed to head away from the 18 month major product release cycles they have been tied to in the past and towards a more incremental enhancement program.

The interesting challenge would be how customers react to products that can constantly deliver more benefits and features. On the web, product constantly update and expect their users to keep up. In the corporate world, users gain much of their effectiveness and efficiency from complete familiarity with the software applications they use.

I wonder if anyone has experience of this. Can the constantly improving world of the web translate to corporate applications? Do small incremental improvements help users adapt gradually to changes, or do they constantly unsettle and upset?

Technorati tags:

Thursday, December 21, 2006

Exposed as a blogger

And this is why any blogger should follow essential rule "would I cringe if my mother read it?": yesterday I had the pleasure of having this blog passed by email to a group of colleagues. I have been exposed as a blogger amongst my peers!

The whistle-blower? A blogging colleague, David Rudolph on Good Karma for Enterprise Software. And his is a nice blog too, talking about a range of enterprise software issues.

So, thanks David! Now I have to be less careful about making my mother cringe and more about a Global 360 salesman asking me whether our products have all the things I talk about in this blog. Of course, standard smallprint still applies: "None of the views expressed here represent those of my employer, they are mine alone.". In short, unless I state it directly, my colleagues should not infer the existence of anything in Global 360 products from my blog. That's why we have sales collateral, and very soon new website content that I'm writing between sips of coffee!

Technorati tags:

Tuesday, December 12, 2006

Preparing to release

I haven't disappeared off the face of the planet... Blogging will resume once I have shepherded the upcoming major release of Global 360's Case Manager BPMS product through to GA.

Its an exciting product, and this release really sets it up to be a leading human-centric, content-enabled and service-oriented enterprise BPMS. I can take no credit for anything in this release of the product, beyond the occasional powerpoint presentation and some typical product management administration. So, to the amazingly experienced set of development and QA engineers here in Hew Hampshire - keep it up, and thanks!

Technorati tags:

Wednesday, December 06, 2006

Process Analytics - separate is better

When it comes to sales scenarios, customers typically ask BPMS vendors for evidence of their built in process reporting and analytics capabilities. For many process deployments, having built in tools is desirable, since they typically come with canned reports that show the generic information a process manager could need. What I'm recognizing is that there is considerable value in having analytics tools that are completely separated from the BPM engine and able to provide information across a range of systems and processes.

My previous post included a discussion about why process analytics is more than just analyzing the process. Even in a BPMS that has a 'full-bodied' view of process data that includes descriptive business metadata, built in analytics tools will probably struggle to present more than just basic business and process information. This is partly because built in tools tend to work directly off of live data as standard SQL queries, and partly because they are still limited to the data within the system, however broadly defined that may be.

It seems that separating out the business process analytics tool from the BPMS has some advantages:

  1. Analytics is complex - separate tools are more specialized and capable
  2. Analytics should look at more than the process - separate tools are designed to access integrated BPMS and third-party information systems
  3. Analytics is processor intensive - avoid overloading the production system
  4. Analytics should be incorporating your SOA strategy - analytics can provide a more complete performance view if it can provide and use SOA based information

1, 2 and 3 are fairly obvious. Specialized business process analytics tools can provide analytical information broader, better, faster. I didn't include 'cheaper', as there is a cost attached, and this will be greater if a tool is selected that requires specific custom integration (or a lot of configuration) with the BPMS. Pre-integrated BPMS + analytics tools, although separate packages, will almost always be more manageable in the long-run than a custom integration.

So what about the SOA strategy? Here I will sidestep the SOA v. BPM debate about where they intersect. How ever you look at it, SOA presents several challenges and opportunities to process analytics. First, how do you make use of the data and process that overlaps from human BPM into the SOA orchestrated process, and second, how do you design an SOA that enables access to analytics tools?

The first point acknowledges that there is a large overlap between SOA and BPM. Imagine a human-centric business process that also consumes business services and orchestrates integrations - for example, a loan application process that receives electronic applications from a business partner, and coordinates a process involving human assessments, automated decisioning and updates of the main banking system of record and CRM system. Embedded BPMS analytics tools can easily provide a range of analytical information within the bounds of the human-interactive process. The problem is how to gain value from the systems interactions, in terms of:

  • business data - for the business
  • technical performance - for IT
  • cost - for B2B interactions
Using a BPMS that can seamlessly orchestrate service invocation and integration alongside human-interaction will greatly assist in providing the appropriate information for process analytics, since much of the data will be made available in one place. If this is not the case, the analytics tool must be able to look inside service requests and integrated systems and be able to reconcile the information it finds. If the analytics tool is open and extensible then this will be an option.

In many cases it will make sense for the analytics to focus on purely systems-based business services in the SOA. An example is an online loan customer inquiry. In a call center environment, process analytics would typically focus on attributes like the time to answer, abandon rate, loan value, type of request, all divided by class of customer. In an online world, similar information should be provided to the business to assess the effectiveness of their website, marketing and backend application processing, but the website analytics may not be the place to most manageably gather it, especially since much of the required information would not be exposed at this level.

By tying process analytics into the system that orchestrates real-time request services, valuable analytical information can be extracted from business information. This again is made simple if the BPMS that handles the human-centric backend processes also orchestrates and publishes the services used by the website. Even if the human and systems orchestrations are handled in separate systems, using a process analytics tool that is not trapped inside either engine will simplify access to the required information.

I'm really starting to understand the value of having true process analytics existing outside the process systems, enabling it to look across any information it requires. In the converging BPM/SOA space this makes more and more sense to me, though I'm sure that as I start to dig into this further with real tools I'll find out that I need many refinements to my thinking.

Technorati tags: