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


Tuesday, 24 February 2009

Innovation and conservatism in a time of recession: Enterprise mashups are the perfect blend

In its lead column this week The Economist states: “The world has not seen a contraction like this since the first oil shock in the 1970s”.
 
The impact of the downturn is unprecedented for our generation, and is the largest slump to hit the technology-driven economy. It’s damaging and yet at the same time progressive, in that it drives us to think about new ways to do business and to deploy technology to innovate, transform and survive.
 
Businesses understand the need to invest in technologies that cut costs, enable knowledge to be shared and provide an essential competitive edge. Innovation and process transformation are fundamental, but the unpredictable climate means this is no time for big-bang approaches.  They must find ways to transform their operations that require low – or no – capital investment and which produce positive, measurable results with a quick return on investment.
 
At Corizon, we see this philosophy in action. Enterprises that handle high volumes of customer interactions, for example, need to increase the efficiency and reduce the cost of their call centre operations while increasing the value of each customer interaction. They need to find a way to cut the cost of servicing customers – e.g. by offering customer self-service – that doesn’t involve abandoning their existing IT systems and buying expensive new ones.

This need to innovate without spending a lot of money is prompting businesses to explore better ways to improve their existing processes, applications and data. Enterprise mashups fit the bill perfectly, by allowing organisations to transform their business processes using existing applications and data in short project bursts with demonstrable return on investment.
 
A recent post by my colleague David Davies highlighted the staggering results that Homeserve has achieved from its use of enterprise mashups: a 50% increase in cross-sell with slashed call handling times, all using existing applications and processes.
 
Technologies such as enterprise mashups enable innovation to go hand in hand with conservatism. The businesses that will survive are the ones that can be conservative and creative at the same time. 


Friday, 20 February 2009

Clipping mashups and UI re-use

We’ve spotted an interesting post from Mashup Patterns author Michael Ogrinz on “clipping mashups” – techniques that extract, manipulate and reuse UI from web sites and web applications. These represent a useful, tactical approach to harvesting functionality from existing resources you may not control. It caught my eye, as this is one of the integration patterns supported by the Corizon Enterprise Mashup Platform

This mashup approach is more than a back door into hard-to-access assets. It’s an example of an important kind of reuse at the UI level that is essential for effective mashup building. Michael is spot on when he says: 

“Of course, if the … app already exposed an API, you could accomplish all of this by duplicating its interface and wiring all this up manually; but who wants to bother doing that?”

It’s a valid point. Application UI is valuable and it requires knowledge and effort to replicate. It embodies knowledge about the functional domain in question, about usability and it takes tremendous effort to write and test the code that puts that all into action. None of that is work you want to have to think about as a mashup builder. Rather, you want to be able to get the UI as a building block for your new application. 

So how do you do that? Standard data feeds, web services and networked APIs don’t help, as all this capability is ’above’ them. But two types of approach are available:

  • Service providers provide reusable UI (aka gadgets) that you can use in your mashup, Google Maps being the prime example. You don’t need to worry about building a mapping UI, you just add what you need to one somebody else wrote.
  • You use a clipping approach to effectively create gadgets, where none existed before, from somebody else’s UI.

The popularity of both is testament to the need for providers of "mashables" to deliver UI as well as just data, so that mashers can work free from the problems of UI implementation. 

The same ideas are needed in the enterprise context. For mashups to be effective, service providers and applications have to provide re-usable, mashable UI related to their functional domains, with the control, security and management capabilities required by the enterprise. 

However, for the enterprise, much of the tangible business case for mashups comes from supporting users as they work through processes and for that, the mashup needs to weave the mashable components into a seamless, process based application. That’s not possible with stand alone widgets or clippings – you need re-usable UI that the mashup builder can manipulate and combine as required. That’s why Corizon created UI services  as a kind of composable, self describing widget delivered in a controlled way and enterprise quality.