The linkage between ESBs and IT asset Modernization

Having done webcasts recently on both ESBs and Modernization I have been thinking a lot about how these 2 subjects are related – and how businesses can make the most out of any efforts they put into either of these areas. At the core here is the issue around reuse and simplification. Reuse has stumbled for many years – lack of awareness, Not-Invented-Here and so on. However if there was a desire to reuse assets it was generally prevented by the sheer complexity of the task. The natural progression for many IT systems is to become chaotic. Just keeping them running is a challenge, never mind trying to reuse the same code in different parts of the system.

Businesses have been trying to fix this through architectural practices for many years – Going back 20+ years ago, CICS administrators and developers would deploy Application Owning Regions, File owning Regions, Terminal Owning Regions – all to give some separation between types of function that would then allow specific tasks to be less complex and intertwined. However the move to SOA – which despite the claims of some supporters is not actually that revolutionary or new – merely an architectural template finally supported with well integrated tools covered the lifecycle end-to-end. It is the support of these tools which has been enabling business to measure SOA deployment success, and one of the key parts of the solution is the ESB. True it is not alone – other products such as a registry/repository also play key roles in a true SOA, but the ESB can really be said to enable the SOA runtime to be effective and efficient.

Clearly one of the central abilities provided by the ESB is to simplify the application interfaces of those assets connected to it. This helps through the simplification of those assets and thus promoting both reduced costs for maintainance as well as the promise of easier reuse if possible. By increasing the number of assets connecting through the ESB, this increases the savings and improves the chance for future componentization – thus driving the modernization aspect we first mentioned – by simplifying assets it makes it easier to maintain them and to extend their useful life and value – something all businesses need to focus on today.

This use of ESBs for modernization is not just an end in itself – it can also be a useful platform for other benefits – such as improving asset management and governance, even helping to streamline processes. But we will cover that in another post. The key first step is to promote the widest possible use of the ESB across every part of the business, driving all applications, services and other assets to connect to it.

Does this mean that there must be one single mega-ESB deployed across the business? Have we replaced the tyranny of choice with the tyranny of a single inflexible monolithic layer? Fortunately no. IBM believes that a range of ESBs is required to truly meet the needs of businesses – and has three different ESB offerings which provide common, and in many ways shared capabilities but targeted at different markets and offering different deployment options.

The ESB requirements for integrating a wide range of heterogenous and legacy assets have to be different to those integrating mainly standards based newly developed assets. That’s not to say you couldn’t build a single ESB to do so but for some situations it would be overcomplicated and using a sledge-hammer to crack a nut. So IBM believes in ESBs to address these different sweet-spots – designing them to match the needs and skills.

The ESB choices for IBM are as follows:

WebSphere Enterprise Service Bus
WebSphere Message Broker and
WebSphere DataPower Integration Appliance XI50

WebSphere ESB is ideal for customers who have other solutions on WebSphere Application Server, Portal, or BPM platform. Customers may achieve efficiencies in skills, cost, and time-to-value across middleware products in adding WebSphere ESB to their standards-based IT environment.

On the other hand, for customers whose primary challenge is integrating a wide range of non-standard applications into the standards world, as well as those who make heavy use of WebSphere MQ – they will value the flexibility and depth of capability provided by WebSphere Message Broker.

And for those who value the simple experience of drop-in installation and admin-based configuration, and require security at the message level, network level, and device level, WebSphere DataPower Integration Appliance brings that in an integrated solution.

It is the power and flexibility of these ESBs working individually or together with each other that means that IBM has the most complete and powerful solution set to meet any customer need in the ESB and Messaging space.

There is obviously more to say – as to whether all environments need an ESB, and what contribution to a deployment is made by management and governance tools….but we will save those for another entry.

Advertisements

Tags: , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: