Bookmark and Share

Wednesday, 25 February 2009

Data vs Process Mashups

In a recent blog Deepakalur from JackBe proposes a new tier for Enterprise Mashup. In this architecture an additional logical layer is introduced, the mashup layer, which sits between the business and presentation logic: Assuming that the presentation logic includes the application logic, this architecture makes sense for the types of mashup he is discussing, i.e. data mashup. It isn't however applicable to all types of mashups.

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.

In this architecture the, different user groups can combine UI functions as they see fit, without having to create many variations of the same UI. This is critical for the succesful deployment of a process mashup.

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: , ,


Post a Comment

Links to this post:

Create a Link

<< Home