Enterprise Mashups: Agile development in SOA

Although not fully embraced by everyone, it is undeniably true that agile development methodologies have a number of advantages over more traditional, waterfall approaches. The key is the “release early” & “release often” mantra, allowing for continuous feedback between the analyst, end-user and developer. The end result is an application that does more of what the user needs, and less of what others think the user needs.

SOA brings together the best practices of 20 years of software architecture and design. Admittedly, none of its components are new, but never before have all these components been put together into a single open architecture. Combine this with the ubiquitous http network, and you end up with design patterns and a base technology that can make a difference in the way the business can profit from its IT.

At Corizon, we have added the UI Service to this mix: a UI Service provides the means to discover and use UI as one would when accessing data or process services. The service enabled UI, unlike gadgets, widgets and portlets, provides enough metadata and structure to allow the consumer to easily make modifications to this UI, e.g. hiding elements, moving elements or seamlessly combining two elements into one.

These three ingredients open the door to agile development of fit-for-purpose Enterprise Mashups to the end user that wasn’t possible before:

• More agile : Using UIServices the solution developers don’t have to concern themselves with the problem domain of the underlying business processes, but instead can focus on the needs of the end users, reusing the prefab UI components, and assembling them into a solution.
• Fit-for-purpose: The prefab UI components are built and maintained by the domain experts. This guarantees the highest quality of “raw materials” for the consumer. In addition by providing the UIService consumers with the capability to modify the UI to fit their needs, the solution developer is able to deliver an application that is fit-for-purpose.

Without UI Services, this agile development of fit-for-purpose Enterprise Mashups will require too many compromises, resulting in a slower release cycle and a far from ideal user interface.

Faceless SOA

Recent coverage under the heading “Corizon sets new SOA perspectives” seems to have caused some consternation. It triggered a letter from Tim Holyoake at SoftwareAG in the December print edition of Information Age (seemingly not available on-line) complaining that

“[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.

Welcome to the Corizon Blog

Corizon has been helping our customers to mash-up sophisticated, scalable composite applications for years. When we started, there wasn't an accepted term for what we were doing, but that didn't stop us helping forward-looking organisations like BT to assemble and tune business-critical solutions for thousands of users.

As we’ve gone along we’ve figured out some things that work and some that don't. We’ve certainly developed some strong views on how "mash-up" technologies should be built and applied to make a fundamental impact on business performance. For example, we think that

• 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.