Changing the Face of Software

Lightweight or Enterprise Grade?

2008-06-02T10:21:00.004+01:00

There has been a lot of talk around mashups and SOA recently, and how they do or do not fit together. One view is that mashups enable IT to visualize the SOA to the business. Another is that mashups have no place in the enterprise due to the lack of governance over what gets built, how it gets built, and who gets to use it.

In an ideal world, one would be able to provide a face to SOA in a controlled manner, a UI that has all the good things of a service: discoverable, manageable, secure, whilst providing the consumer with the ability to modify and recombine pieces of this UI as they see fit. At Corizon we have built precisely this capability: the UIService. A UIService implements a lightweight RESTful interface which provides structured access to UI elements, extending the SOA pattern to the UI:

enables service producers to provide a UI with their business services
enables service consumers to discover, consume, modify and mashup the pre-built UIs
provides central IT with the required control

The UIService is the ideal marriage of lightweight technology and enterprise grade capabilities. To learn more about them, see http://www.corizon.com/Products/ui_services.php .

Componentization vs. Service enabling

2008-05-22T10:50:00.002+01:00

One of the big attractions of a SOA is the ability to connect to and consume running (web-)services, without having to worry about how to deploy, run, and manage these services. This wasn't always the way people thought of allowing reuse. In the not too distant history, these business services would have been built as reusable binary components, which would be shared between IT projects in the business. This type of component based reuse had several drawbacks. Here are a few of them:

Updating a component required rebuilding and redeploying an application
Components had design, build, and runtime dependencies, making them more and more fragile and complex to use
Unforeseen differences in runtime environments caused unpredictable behaviour of these components that were difficult to debug and fix
Components were development environment specific, e.g. VB components wouldn't be reusable in a Powerbuilder environment
Components could, and often would, tie the consumer into vendor specific libraries
Access to the binary components allowed the consumer to reverse engineer the code
Access to the binary component put more requirements on security of the component internals
No visibility on the use of the component

For these reasons, it made sense for businesses to move to an IT infrastructure that promotes the runtime sharing of services.

With this in mind, it is interesting to see the current approach to UI reuse. Several IDEs and frameworks are creating an environment in which UI component will be shared across the business at the binary level. This will create the exact same issues as we have seen with binary reuse of business components. The only way around it is to enable the runtime reuse of UI. The technology that allows this is called a UIService and is exactly the technology we have built at Corizon.

Enterprise Mashups: Agile development in SOA

2008-02-20T13:58:00.003Z

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

2008-01-21T11:26:00.000Z

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

2008-01-21T11:11:00.001Z

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.