Posts Tagged ‘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!


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.

More on Tough Questions from ESBCON8

August 28, 2009

So following up on yesterday’s first Tough Question from ESBCON8, lets move to the 2nd question

Question 2:Today’s ESBs are more business-aware, supporting critical events  (with EDA, CEP, even BPM).   How are your customers using these benefits?

First off, do I agree with the statement, aligning ESBs with Events? I would have to say yes – we have seen our customers use WebSphere Message Broker for many years as a mechanism to detect and respond to Events passing through it, making use of the processing and aggregation capabilities it provides. Although this was very powerful and a great advance to increase visibility and agility, its use tended to be restricted to more technical events. The addition to the product line of WebSphere Business Events enabled business users to determine the critical events they were interested in, greatly extending the usability of Business Event Processing. This move to an event driven architecture very much builds on the existence of an ESB, across which all data flows. This assumption of the presence of an ESB is what we discussed yesterday in the first Tough Question.

So on the basis that an ESB exists, and business is now able to see and respond to events as they take place in real-time, how are customers using these? The event processing delivered by WebSphere Business Events allows businesses in many cases to take the step step towards BPM, allowing their businesses to leverage their existing IT infrastructure to rapidly deploy business changes, streamlining processing, increasing automation and reducing bottlenecks, all while gaining better insight to what is actually happening in their business to help drive further improvements. Some customers already see this success.

As Event Processing builds on the Connectivity of an ESB they are likely to already have, they are able to quickly see benefits and then use further tools such as ILOG for Business Rules to adapt and respond to changing needs.

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

ESBCON 8 – Looking ahead to a great event

August 20, 2009

Later today the most recent ESBCON event will go live. This long running multi-vendor virtual conference takes some leaders from the major ESB vendors and has them give brief solo presentations, as well as putting them on the spot asking them 5 tough questions.

For IBM we have Jerry Cuomo, WebSphere CTO, presenting. Other vendors Sun Microsystems and Progress Software also have their CTOs presenting at the event.

After the event I will look to give my own thoughts on the 5 Tough Questions. However as a lead in lets look at some of the Tough Questions that could have been asked but didn’t make the cut to the Final Five.

Some of the initial thinking could have included questions such as:

  • What benefits do ESBs with SCA (Service Component Architecture) offer users? What skills does IT need to tap into SCA benefits?
  • How large can I scale an integration/SOA project with a single ESB?
  • Discuss technologies and patterns for scaling ESBs, in terms of traffic load, number of nodes or even multi-site integration?
  • Discuss trends in real-time visibility and management for IT and business users?
  • How does your ESB manage integrations end-to-end (include support for Remote Integration, High-Availability, Governance, Auditing or Identity Management)

Now some of these questions got adapted to end up contributing to the actual questions asked, but they do reflect important points, even with duplication and the different technical levels being probed. The questions on scaling are clearly important – after all who wants to deploy an ESB which if successful will undoubtedly require the ESB to handle increasing traffic loads and be physically and logically deployed and managed more widely across the enterprise.

Also important is the aspect of real-time visibility for both IT and business users. This is growing in importance, with all traffic moving through the ESB it becomes easier to understand how and where to track business data as business events take place, and also for the IT side of the business to track and control the use and performance of systems. This visibility aspect is one of the key unsung benefits that can be seen from a successful ESB deployment. I will make a point of saying ‘successful’ there as it is easy to think of an ESB deployment to meet a singular need that is then not used further to extract that data that can so enrich a business.

It will be interesting to see how the CTOs fare on the real questions, and I will look forward to reviewing that after the event

Sensors, events, automation and what-not

July 21, 2009

Just time for a quick update before my next phone-call. I have been working a lot on various decks looking at industry solutions that use or leverage WebSphere MQ and ESB solutions from IBM. A number of them, certainly in engineering industries such as Chemical and Petroleum, or Energy and Utilities, already use solutions like WebSphere Sensor Events or have the potential to use them in the future. And there are also clear benefits to other industries like Retail or distribution. All sorts really – at Impact I sat in a very good session talking about how Airbus uses RFID sensors to keep track of the parts of planes they are building. After all it is so easy to lose an Airbus A380…

We have referred to this as the Internet of Things. There is a great example of this from Andy Stanford-Clark and his house that Tweets. But the more I read about this, the more interesting I can see this getting. Clearly this requires some level of investment from businesses to leverage, but the greater the connectivity throughout their infrastructure, the more opportunities will arise. The economy today drives businesses to look to cut costs and drive growth. Extending connectivity through these devices and increasing business awareness truly looks to be transformative. I will look to give more examples and cover this more going forward

Reuse, cross charging and the Cloud

July 1, 2009

One of the big topics of discussion at the Gartner SOA event in London last week was, unsurprisingly, Cloud Computing – it is everyone’s favourite hot topic this year. One session by Yefim Natis really focused on some of the implications of this – and before he started I made a couple of notes to myself to test as to whether he would answer them.

The first was whether Cloud could solve the cross-charging issue (I will explain this in a moment) and the second was whether Cloud would present a good opportunity for WebSphere Service Registry and Repository. Both of these issues were items that were nagging at me from listening both to clients in the Vendor showcase and also to other Gartner analysts.

The big one was cross-charging – Massimo Pezzini had addressed this as a critical issue to the future of SOA. There was a conflict of interest for those parts of the business who provided services. For the good of the business they were encouraged to make the business services they provided as reusable and shareable as possible. However then as their reuse grew as the uptake of SOA spread in an organization, who then was responsible for the costs associated with not just the initial work to create a reusable service but also then the increase in traffic as it became a fundamental part of multiple composite applications. The service providing department would become a cost center, faced with ever increasing costs and demands for improved SLAs. This could drive future work to be made highly specialized to avoid this issue, impacting the ability of SOA to really be successful.

Now in IBM we have always been keenly aware of the cross-charging issue, as this has always been important to our mainframe/System z customers. Our products such as WebSphere Message Broker, which functions as a highly capable ESB,  have therefore included capabilities to identify and charge users for their use of the environment. But of course in a Cloud – an elastic shared use environment – it is explicitly designed for resource allocation and tracking the user and use. Yefim in his session then proposed that deploying these shareable services in the Cloud, with its ability to track and charge for use could lead to these service providers being seen as profit centers instead of cost centers. Now being a profit center when providing internal services is one thing – moving money from one pot to another within a business does not a profit make. But combine shareable services in the cloud with a move to more dynamic multi-enterprise B2B, sharing the costs with partners, and some of the investment decisions can make sense, as well as streamlining your business connections and processes. A good thought for the future.

The other question I had was around WebSphere Service Registry and Repository (WSRR). I had talked to quite a number of clients at the show who were deploying, or starting to deploy assets connected to one or other of our ESBs – and they were trying to figure out whether this truly made them more dynamic. Of course it does simplify your connectivity to use an ESB but then are you just swapping one change regimen for another? I got a good response talking to them about using WSRR to hold each service step, and to search for the service location through WSRR rather than defining its location in the ESB flow – this allows for very simple updates and changes to services without any disruption to the running processes and ESB flow.

Now of course when the services are defined as ‘in the cloud’ this is the ultimate requirement for flexibility – they will never have a fixed location or definition  anywhere other than the cloud so use of a registry to store and locate these will be essential, as well as the other facets it provdes such as identifying rogue services and enforcing business policies. This says to me that when we are talking to our clients about using the cloud, we need to be sure to discuss the use of ESBs and also WSRR.

Lots to do. Should be interesting!

Attending the Gartner SOA/ADI event in London

June 29, 2009

It was nice to get out of the office/home office routine last week to visit the Gartner SOA/ADI conference – this was the second year I have been to this show and it is always worthwhile. The event seemed to be very busy with the keynote sessions pretty full and some very interested customers from all over Europe and beyond attending to listen to the sessions and also talk to the vendors attending – of whom IBM was one – as a premier sponsor. At pretty much the start of the event there was a vendor panel from the premier sponsors who participated in a quickfire session to review their thoughts regarding a number of Gartner predictions for the future – there was broad agreement with many of the thoughts, although there was a level of scepticism regarding whether the scale of uptake for some of the technologies would be as high as was contended. The state of the economy was judged to be a likely factor in IT change decisions – which is of course to be expected.

The other Gartner sessions I attended were certainly very interesting. A theme which seemed to run through the 2 days was the coming growth in multi-enterprise B2B driven by the need for e-invoicing. And the complexity and business risk associated with this will also drive the need for strong SOA Governance. SOA Governance was one of the key starting points for companies starting SOA implementations, but by far the most common starting point was an ESB – which of course makes a lot of sense as an ESB is a great boon to business whether it is part of a larger SOA deployment or simply looking to improve connectivity.

We had a great stream of different businesses coming to the IBM stand in the Vendor showcase. Due to the focus of the show, all were highly knowledgable about middleware and many were already WebSphere customers, involved in projects, either at early stages or deploying. I had a number of discussions with almost everyone about whether they use FTP as a part of their existing infrastructure, and whether the new WMQ File Transfer Edition product could be of benefit to them – we got some encouraging interest.

Also a popular discussion topic was our WebSphere DataPower appliances – they of course have many uses throughout the enterprise and I had involved discussions about what benefits they provided depending on the type of deployment and where they were being used. And finally an interesting topic for discussion was the brand new WebSphere Cloudburst appliance – there is huge interest in Cloud and this seems a very timely and innovative solution for customers. Hopefully next time we will have a box on display!

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.

The linkage between ESBs and IT asset Modernization

March 24, 2009

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.