Business Transactions, Exciting Stuff!

Last week, I had an opportunity to listen to some of our top solution spokespeople here at Progress Software present, watch the audience respond, and then drink with the sales people who are tasked to sell our solutions in what could be the worst economy in recent history. I made a note to myself about a topic to blog on and am really excited that Jason Bloombergat Zapthink beat me to it!!

My note was simply:

"Process Mashup = Business Transaction"

In the Zapthink post, they talk about "data mashups" solving the "swivel-chair integration problem." They make a whole lot of talk about SOBA this and SOBA that, but at the very end, say something pretty interesting:

"From a business perspective processes always involve information, and there's no way to get value out of information without doing something with it, and when the business does something, that activity constitutes a business process." (Run on sentence is theirs, not mine.)

I think an important generalization can be made...

From a business perspective, there's no value in infrastructure unless it directly relates to what the business is doing. And, measuring the value requires the ability to directly relate it to the business.

Earlier this week, I mentioneda customer of ours who had 98% up-time but their largest customer was without data for over 3 weeks. Another example is a customer of ours - a large cable company. They have business owners of their "products" -- including cable, Internet phone, cable-Internet.

They use Actional to monitor the provisioning process for these services, and then share it with the appropriate business owners through browser-based dashboards. The first thing these managers do in the morning is bring up our console and look at how their business process is doing.

The important thing is that even though there is a mesh of underlying support systems for each of these products, as well as the famed "triple-play", they don't care about the infrastructure. They care about the results to their business.

Underlying this all is a Process Mashup which, is just a fancy way of saying "multi-product, multi-vendor integration to implement a solution." They've taken the component processes (provisioning, ordering, credit-checking) and made it into a single Process Mashup that helps them understand and deliver an outstanding customer experience. Importantly, the person responsible for the process doesn't really care about how it happens, as long as it does. But from an IT perspective, it's important to know when it's not happening and why.

For example, take FedEx (not a customer). They ship me a package and it arrives on time. I get an email and all is good. If it doesn't arrive on time, I call for help, and someone drills into the step-by-step tracking of where it's been to figure out where it is. At that point, they see which distribution center it shipped from, how it got routed, what the weather conditions are, and so on. Of course, ideally, they'd tell me (rather than have me call them) there's a problem, but... the important thing is that there are many steps in the process. We can police the end-result and use policies to warn us (ahead of time or after the fact) when things don't go as planned. We can also get all the detail we need to assure those important business processes (or Process Mashups as Jason and I like to think of them) keep the business optimized.

SOA What? Well, I find this exciting because we can start to really talk directly to the business in a way that shows hat we (as IT people) understand what's happening. We can talk about results the business cares about (the customer can watch cable tv in two hours from the time they sign up) and speak to results no one cares about, except when they have to ("There it is, the request to provision them got stuck in the queue. Yeah, that happens sometimes. Why were you waiting for it to finish?").

I'm very aware, that in addition to being a brilliant technologist, I'm also the check-out guy at Home Depot (where I always choose to self check-out), I'm a travel agent (book online, don't call the airline, they charge you more), and even a bank teller (using an ATM - just today I found out I don't need to fill out a slip to make a withdrawal from a teller... it's been that long since I've spoken to one!). In all those cases, it's quite easy for me to switch providers and completely opaque to companies as to why I would. And, I will switch if service is promised and not delivered. If a service provider doesn't communicate in terms customers can relate to, and then assure those processes using the benchmark the customers understand, customers will go to service providers who do.

Comments

[David Bressler]

Jason -

I see your points, and totally agree with your second point. That was an oversight, or rather, I had assumptions in my mind that you expressed better. I made the assumption that the services in a process mashup are available for consumption, whereas integration doesn't really make that assumption. That's a nice delineation.

In my mind, it becomes a "mashup" when someone, analyst, developer, or otherwise, takes services from various places (in particular when the developer doesn't own them) and puts them together in a way that serves new functionality. It could be temporary (as you discuss, I forget your exact word, was it transient?) or permanent. I think IBM has some nice technology in this area, which makes it easier for mortals to mash things up, and therefore easier to do things more on the temporary side, whereas, if it takes a developer, the likelihood is that it would be something of a more permanent nature. But, that's a slight tangent.

I do think, that a composite of services that implements a process is a process mashup... though, we could just be using the same word for two things. I think, you are just specifically using the word mashup for UI implementation, whereas, I'm using it for an equivalent to the word "composite". In particular, a process mashup is the "opposite" of a process created in an orchestration server (like those from TIBCO, Lombardi, etc.).

David

[Jason Bloomberg]

Dave --

Thanks for the link! Remember that a composition is only a mashup if some subset of the users of that composition create or modify the application as part of the functionality of the application, and do so in the context of a rich Internet-based user interface. If not, it's a Service-Oriented Business Application, which is a composition of Services that implements a business process -- but not a mashup.

Also note that a Service-Oriented Business Application is more than a "multi-product, multi-vendor integration to implement a solution" as well. What makes such an integration Service-Oriented is that the integration is a byproduct of the composition of Services, rather than connections that are implemented before the Services are available for consumption.

Hope this helps!

-- Jason Bloomberg