Ron Schmelzer from ZapThink hilightes the difference between data mashups and process mashups as the different answers to the requirement for different levels of situationality and levels repeatabilty, with process mashups deemed more appropriate for repeatable processes that require some level of situationality. At its core, process mashup are about introducing a level of agility into the process of stringing together services into an application, or SOBAs as Ron calls them:
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.
At Corizon we have introduced this approach to support agile development of user facing application. In this approach user requirements are met by stringing together UI Services into User Processes, as discussed here in detail. For this, a new architecture is required, one that is built to support easy rewiring of UI functions, without rebuilding the UI.
Different types of mashups solve different problems and each of these require different architectures. So when you're embarking onto the Enterprise Mashup journey, make sure you pick the right tool for the right problem.
Labels: architecture, data mashup, process mashup