Business Process Improvement

While thinking on the subject I thought I'd update the status of our project. We rolled out the final of our four releases (code named "Bread & Butter" and the most complex since it handled all types of money relationships including making payments on sponsorships, setting up new sponsorships with credit cards etc.) at the end of July and experienced a bit of a bumpy ride. After the rollout we were in a hotfix mode for roughly 30 days where we made incremental releases to various components every few days in order to handle issues that were not evidenced by our user acceptance testing. Unfortunately the release schedule was heavily influenced by some external business realities that the team didn't control and which forced us into the tradeoff situation we found ourselves in.

At this point however, the infrastructure has handled over 125,000 business transactions and 3.5M service invocations with system exceptions under 1%. The interesting thing, and the most important of course, is that 70% of the business transactions now go down the happy path and do not involve human interaction. That 30% that do require human interaction, however, are ripe for process improvements and additional incremental automation that will allow that number to shrink dramatically. There are two interesting aspects that came out of this however.

First, when you're implementing a business process management solution like this you should probably educate the business that there will be some low hanging fruit that comes out of the statistics generated after the release. As a result, they'll probably want to budget some resources for addressing these things in a final phase of the project. In our case, the project team is set to disband and the resources were not allocated and so the low hanging fruit will have to wait for another project. When that will exactly be is yet to be determined.

It's extrememly important to define before the project both the strategy for collection and the kinds of metrics you want to collect. The obvious reason is that these metrics will embody the questions that the business will ask and therefore point to where the process improvements can take place. In our implementation we did not do a thorough enough job of either collection or understanding and as a result there are some holes in our ability to ask the right questions. We're attempting to address some of this in a followup project but as you can imagine it's more difficult at this stage than it would have been if integrated into the early iterations of the project.

Fun in Omaha

Having a great time this morning at the Heartland Developer's Conference at the Qwest Center in Omaha Nebraska. Later today I'll be giving a session titled "Real SOA: Implementation and Best Practices" that discusses many of the topics found on this blog along with the experiences of the team over the almost 18 months since I came on board at Compassion as a Solutions Architect.

In short, the talk is broken into seven sections that highlight mostly what went right but also a little of what went wrong or things we could have done better. Those sections and the major point for each follow:

#1 Define a Services Platform
IT buy-in and support is critical

#2 Define Messaging and Schema Standards
It’s not just about coding standards

#3 Consider Cross Cutting Concerns
Build it for the long haul

#4 Consider Logging and Monitoring Up Front
Loosely coupled messaging is hard to tie together

#5 Build a Reference Model
Don’t jump in to business development

#6 Build a Reusable Framework
Budget time to help the rest of the organization

#7 Don’t forget business activity monitoring
Think about questions that will be asked at the end of the day