By Phil Wainewright on December 20, 2008
A thoughtful piece of analysis by ZapThink's Jason Bloomberg last week dissected the enterprise mashup under a distinctly offputting title: Balancing Repeatability and Situationality with Process Mashups. That's awfully impenetrable language, but lurking behind it is a nugget of invaluable insight.
What Jason explains in the article is that there are two types of enterprise mashup. Most people focus on the data mashup, which combines data feeds from several different sources in order to meet a business need (as mentioned in my previous blog post, I moderated a webinar on just this subject last week). There are quite a few tools around that aim to help business people construct this form of enterprise mashup, because they often need to combine data quickly and they often can't be bothered waiting for someone from IT to do it for them (or don't command enough budget to fund the work if someone else does it). Mashups created in this ad-hoc way are often called situational applications, because they're a response to a specific circumstance.
Jason then goes on to dig into the other type of enterprise mashup. This is the process mashup, which affects both the information and the workflow surrounding a business process that cuts across several different applications. He cites the example of a call center application, where a manager is often fine-tuning business processes to maximize the efficiency of call center agents. He hesitates to use the term situational applications here because, although the mashup is presumably in response to some new event or analysis, it's not intended as a one-off. Indeed, it would be a waste of time automating it if it were. Here's that nugget of insight as presented by Jason:
"Situationality, therefore, is not always a priority with mashups, as situationality is less important than repeatability for most automated processes. After all, the reason you'd want to automate a business process in the first place is because you expect to run the process many times, otherwise automation would never be cost-effective. Situationality and repeatability, however, are two ends of a spectrum; the interesting processes from our standpoint are the ones that fall in the middle somewhere. Such processes have a level of variability that requires a measure of situationality to the applications that implement them, while being sufficiently repeatable to warrant automation. It is such processes that process mashups (and SOA in general, for that matter) are particularly well suited for."
Incidentally, Jason also mentions that the ability to perform process mashups is not something you want to spread around as liberally as the more harmless and transient data mashups. Which brings me back to the sentiment in his article that sparked my headline:
" ...putting mashup capabilities into the hands of a business user means empowering that user to create the application as they use it. Sounds good, but how often does IT really want users of applications to be responsible for creating and modifying those applications as well?"
Jason sets out a couple of important rules for process mashups:
"First, governance plays a critical part of the story, as the organization has policies as to what capabilities different individuals have. Business empowerment, in fact, requires governance, as there's no way IT would provide increasingly powerful tools to the business unless there were a flexible way to manage the use of those tools.
"Secondly ... [o]nly a relatively small number of people in the organization would ever have mashup interfaces, and even then, they would only be able to make certain changes via those interfaces."
Do you agree? Or does empowerment mean delegating more freedom to business users to innovate process automation? I'd like to know what you think - post your comments below.
