“[The article] gives the impression that Web 2.0 user interface concepts are a panacea for delivering effective and usable applications to end-users. … The consideration of application users' interface needs to form part of the whole, not an alternative. The key message is that one crucial point must be considered when the SOA delivery approach is chosen, regardless of whether Web 2.0-style user interfaces are deployed or not: effective SOA governance must be in place from day one.“

Absolutely! Effective architectures need a well thought out and implemented approach to governance.

The question to ask is this: if software services underpinned by governance are key to allowing re-use and agility with control, why don’t those concepts need to apply to the user interface? An SOA that only talks in terms of services that provide data and logic puts the creation of UI fully in the hands of the consumer, with every chance of the poor results summed up by Geek and Poke...

UI must be built each time it is needed, with no possibility of re-use, consistency or control and all existing investments in UI must be thrown away. That doesn’t seem like making UI “part of the whole” in terms of SOA.

The Corizon vision is to close this gap, allowing services to provide re-usable self describing UI as well as their more familiar data, in a secure, safe, governed fashion. So we agree, it’s just that we think governance and re-use need to go further.

• Frequently cited uses of enterprise mashups - "mopping up the long tail" and building "situational" applications - are great, but if that’s all there is to mashups then a huge opportunity is being ignored. The processes that businesses rely on need people. Those people need transactional applications that support them as they work through their tasks. Look in any call centre or back office and you will see that even after years of investment in application development, customization and integration, the IT they have to work with is anything but streamlined or joined-up. Boosting performance by giving these users fit-for-purpose productivity applications in a responsive, agile manner is where a mashup style approach is desperately needed. Of course, focusing on this problem space also raises the bar for enterprise mashup functionality, scalability and robustness!


• Contrary to a lot of the hype currently circulating, end users don’t have the skills, time or inclination to build or maintain more than the simplest mashups; shop workers, outsourced back office staff or call centre agents probably shouldn’t be spending time reconfiguring the applications they use every day! Rather enterprises need to put process owners and analysts in charge of the construction, deployment and improvement of the applications their teams use.


• The combination of complex functionality and simple assembly needed by Enterprise mashups needs re-usable UI to be available as a service. Just as most mashup builders wouldn’t think to build their own mapping UI, and naturally re-use one from Google or Yahoo, so enterprise mashups need to be able to combine functional UI building blocks that service difference functions (billing, service management, account management etc) into a new application. That way application developers and owners can “produce” common business functionality for re-use across the business while “consumers” can customize and combine it into new applications without the skill or knowledge that the producers need. This kind of production and consumption isn’t available in most SOAs and mashups, which might explain the some of the disillusionment that can be found in real world projects.

At Corizon we’ve created technology that acts on these ideas. Now that enterprise mashups are getting more attention, we want to share our ideas and what we’ve learned more widely, and we’ll use this blog to do so. Let us know what you think and keep an eye out for future postings.