Posts Tagged ‘WebSphere ESB’

WebSphere MQ, #uksnow and heating instead of plumbing

December 18, 2009

First, apologies it has been so long since I managed to find time for a blog entry. But now that I am here, what is it that I have to say. The origins of this blog topic go back to earlier in the year. We had a new wood-burning stove installed in our house – both for aesthetic reasons and to try to reduce our gas bills by heating the house using wood. Burning wood to heat your house is carbon neutral of course, and we could collect plenty of logs from the wood next to us.

So throughout the summer I have been slicing up dead trees and splitting logs, building wood sheds to build up our stock of wood, in the knowledge it would be cheaper than using our gas-fired boiler to pump water through all our radiators. Did I enjoy this? You bet I did – really makes you feel like you have achieved something, learned a skill – all that sort of thing.

And then we get to winter – and from September onwards we have been lighting the stove, and it has been great. Lots of heat – the house nice and warm. The fire looking good, and all my good work coming to fruition, with the added bonus of no heating bills with the heating off.

But then we get to proper winter as in the UK we get a cold spell with snow (currently filling up the twitterverse with the hashtag #uksnow). We found we needed the fire all day – and even though it is pumping out a lot of heat, and it sits in the center of the house, it can’t quite get all the extremities of the house warm – there are a lot of outside walls getting the heat sucked out of them, no matter how many logs we put in the stove.

So I started to think that maybe we would need to have the boiler on at least some of the time, and that maybe there was a reason that central heating with radiators has replaced fires (even efficient stoves). After all there may be a cost associated with central heating, but it is much less work, and it does ensure that the heat goes right where you want it, not spreading from one point.

Sure from an enjoyment point of view, it is less satisfying, but there is something to be said for progress, or at least a balance of solutions. And then it occurred to me that there was some similarity with the battles our customers have in deploying messaging middleware to connect and integrate applications. The programmers of course want to do it themselves, enjoy the task and it builds their skills. There is even some satisfaction at looking at what they achieve. But of course it can fail to scale up to meet the needs of the business. There might be a cost of buying WebSphere MQ, or an ESB like WebSphere Message Broker or WebSphere ESB, but the end result can be much less effort, and be more effective – at least in a number of deployment scenarios. And it doesn’t mean the programmers have to stop what they are doing – it just means that they don’t need to do all the heavy lifting – allowing them to get on with more tasks.

From a cost point of view, developers might say that it is a waste to buy a solution like WMQ, but in our heating analogy we are not talking about doing everything with the boiler, just taking advantage of its ability to heat the parts of the house the stove would find it more difficult to heat – much like WMQ can do things that roll-your-own solutions can find it difficult or complex to do. Does this seem to ring true?

In the meantime I need to put another log on the fire!

Advertisements

Catch up blog – closing on ESBCON

September 29, 2009

So it has been too long since I found time to write a blog entry. And we have a busy time with the Business Agility Now launch coming hard on the heels of the Smart Work launch. But before I cover some of the key areas these look at I feel I ought to finish off the last 3 tough questions from ESBCON8.

Here are the last 3 questions:

Discuss how your ESB supports SLA, zero downtime and cross-department integration ?

For current ESB users, can you detail popular second-generation projects with quick ROI?

How does your ESB accelerate ‘Design-to-Deployment’ with tooling, widgets, automated integrations, etc?

Lets see whether I can give my thoughts on these in a succinct manner. First what about SLA, downtime and cross-department integration? As ESBs become more pervasive and their presence is assumed, they need to no be seen as a problem – to become a utility…that is how they must be seen – as something to plug into and just work. Of course integration is about more than just the ESB – the connected applications must also be available and so the ESB layer must also be able to tolerate application and other failures well. In IBM solutions we are seeing this extension of always-on availability to include files moving through the ESB layer with the WebSphere MQ File Transfer Edition. This boosts the enterprise nature of the ESB solution, and the ability to exist in a Cloud or cluster environment where needed by the business is also a strong choice factor.

Second question = about second generation ESB projects for quick ROI. This is when an initial investment has been made in an ESB and subsequent integration projects in the business want to leverage this. Of course ideally project selection, from the first step would have been done based on business benefit – addressing the key needs first. A study like an SOA Healthcheck would be a good way to do this. However in terms of picking second projects, anything that reuses some of the investment already made would be a good idea. Once assets are available as services through an ESB they become reusable. This any other part of the business that needs them should be able to reuse them as a part of a composite application, accelerating deployment, reducing cost and boosting ROI. This may drive the selection of projects to enable greater reuse, driving ROI.

Finally how to accelerate design to deployment, with widgets, tooling and automation? This is a pretty broad topic to cover – one of the simpler answers would be that for some requirements, customers could deploy our SOA appliance – WebSphere DataPower XI50 as an ESB – this is exceptionally fast to deploy, simplify needing to be plugged in and configured. However other options, to be used with other ESBs, or with the appliance, would include using WebSphere Transformation Extender which can accelerate tricky integration deployments, including by using Industry packs to address key needs. These, and the best practices we can recommend can all really speed your deployment, again increasing ROI.

Tough Questions on ESBs from ESBCON8

August 27, 2009

So it has been a week since ESBCON8 went out. You can still register and listen to it here – I think you will find it worth the time. All three CTOs had a lot of interesting points to make – Although clearly the solo presentations are a core part of ESBCON, the section I enjoyed listening to the most is the “5 Tough Questions”. This head-to-head section covers a lot of different points and you get to hear a more impromptu set of answers. Lets review the first of the 5 Tough Questions from the event this time:

Question 1:Gartner recently released a study that says 70% of all enterprise SOA starts with ESBs. What do your customers find are the most popular reasons for using ESBs as a foundation technology?

Perhaps the most fundamental question for an audience interested in ESBs…The discussion today of SOA seems to be in a state of transition. Is SOA dead? Absolutely not. If anything the discussion has moved on from SOA, in the same way it moved on from the frenzy of discussion around ESBs in the last couple of years because there is no point to a discussion over whether SOA is useful or important. The answer is obvious and everywhere. SOA is now assumed – the question is what’s next?

IBM is already telling this story of what’s next – with Smarter Planet and Smart Work, all building on the solid foundation of robust reliable and agile business and IT alignment provided by SOA, with an ESB at the heart of the infrastructure. This is the reasons so many projects have an ESB as their starting point, is that an ESB is a fundamental, essential component for the infrastructure to whatever project you are looking to implement, so starting with this is a given, especially as so many parts of the business can make use of it, thus increasing time-to-value.

If projects don’t start with an ESB, they are likely to start with a Registry/Repository, trying to put SOA Governance in place before too many services escape into the wild. SOA does offer business the ability to see and respond better to events, but also provides the capability for just as much chaos as exists in architectures already.

So – SOA isn’t dead, and an ESB is fairly clearly an obvious place to start in enhancing your business infrastructure – putting in place the ability for you to Work Smart for a Smarter Planet.

I will take a look at the other Tough Questions shortly. And I am sure I will come back to Smarter Planet and Smart Work

ESBs and common industry issues

June 19, 2009

One of my key tasks this year is to take a look at our Smart SOA Connectivity & Integration marketing from an Industry perspective. Something I have been keen to do for a number of years to ensure that our sales reps can always provide the best and most relevent information to our clients about the solutions we have on offer. To start to do this I have been looking at some of the hundreds of references and case studies of IBM clients using our offerings – specifically for now those references that include WebSphere MQ, WebSphere Message Broker, WebSphere ESB and WebSphere DataPower.

Now you can easily review some of the references – or as they are described on the IBM website – Success Stories – for yourself, but as I have been going through them, industry by industry, some common themes seem to be jumping out.  I have to say that one of the most common motivators for our clients choosing to deploy solutions that include ESB Messaging and Enrichment is the need to be able to quickly add new or change existing offerings to rapidly address new market opportunities.

This makes a lot of sense to me – there seems to be a tremendous amount of evidence that without selecting messaging and ESB solutions for Connectivity, then infrastructure becomes highly complex, slow to change and costly to maintain. None of these results are good for businesses looking to save money, and respond quickly to changes. It follows then that a key reason to implement WebSphere solutions for ESB and Messaging Enrichment will be to address these – and a good business case to justify funding will be a new business opportunity to require these changes.

In many customer engagements in the current economic climate we are seeing it become harder for clients to justify any expense – maybe we should get them to discuss this problem with some of the UK Members of Parliament? 🙂 But on a more serious note, with businesses feeling the pinch they need to have clear justification that the costs associated with acquiring and deploying IBM solutions will deliver the expected return, and thus a demonstration that other similar problems have been soloed – and that IBM has the skills required to assist can be a major assistance to making that business case. It also helps that WebSphere MQ itself has a fairly strong cost justification anyway as opposed to hand-crafted point-to-point interfaces or standard FTP. You can read more about this cost justification and the risks of not using WebSphere MQ at this link.

Next week I hope to write another entry looking at some of the industry content in more detail – but it is friday night now, so that will do for this entry.