To be honest I think this helps me understand how business thinks in their use of enterprise IT systems. Businesses don’t spend money lightly – certainly not on IT systems. And when they do they need to buy the right ones and run them for a decade or more. That is what is in my mind as I review our product portfolio. I know there is a certain school of thought that subscribes to the ‘good enough’ practice. Helping to justify what may not be the best long term solution – but good enough for right now. That might be good enough for grabbing lunch when you are hungry – we have all done that when we are out and about – but sometimes had cause to regret it.

If I had a tight budget and was running an IT environment, I am not sure I would be putting in place a ‘good enough’ environment. I would want to be sure enough of the value of the project to the business that I wanted to get the right system for the job. Not just the right one for right now.

From a vendor’s perspective I think we have to recognize this – and to do our best to reflect the real value of our offering to address the customer need and deliver real value. being able to do that is almost as important as building the right product to begin with. That is certainly what I will be trying to do with WebSphere MQ

I immediate had to get involved in many key decisions and activities both tactical and strategic, as well as having to build strong relationships with many of the key players in the WMQ space. It has been a wild ride for the last couple of months and it continues to this day.

Hopefully I will have time to do some externally focused activities. Earlier this year I did a series of ‘podcasts’ or recordings with Andy Piper – a highly skilled colleague – and it would be nice to be able to do a few more of those as time and resources permit. Funnily enough we recorded them in the stable in my garden which is converted to a home office, so I have suggested we call them “from the horse’s mouth” – but as yet no one lese agrees. I also attended the Gartner AADI Summit in London in June. I think that was my 4th year in a row. As good as ever to talk with Gartner Analysts, attend some sessions and chat with customers.

Obviously there are many things that occupy my day to day task that I can’t share yet. However watch this space. Recent announcements include a new release of WebSphere MQ File Transfer Edition and also a new offering WebSphere MQ Hypervisor Edition. Our development teams remain busy!

When I get a few days off I will be finishing the latest book I am reading – The Bible of the Dead by Tom Knox. Then on to Spook Country by William Gibson. Looking forward to it.

So anyway – books. On the whole I have enjoyed the books I have read – mostly gripping, and entertaining. Well thought out – etc. Worthwhile purchase and a good read. Just one niggle with most of the books is the ending is generally unsatisfying. The rest of the book has been really good – lots of plot twists, characters to believe in and sympathize with, but then the ending always seems unsatisfying and rushed. Surely there should be more attention paid to this part of the book – and not rush it to actually bring the story to an end – any end?

Maybe it is just me – but I would like a bit more exposition to bring the story to a more satisfying conclusion. I understand the dichotomy of building up the excitement of the plot and not dragging out the conclusion – reaching a crescendo and then ending on a high – but what if it is not satisfying – after the initial rush of finishing you get a slightly bad taste in the mouth.

So what does this have to do with product management – and maybe specifically WebSphere Message Broker? Well as a product that has been out and evolving for 10 years it is fair to say that there is plenty of function in the product – but we continue to add content and function. But what can we learn from novels and plots? I think we need to think more of our ‘readers’ or users – and the uses to which they put our offering. In the same way that novel writers need to think about their plot and how to satisfy their readers, we need to think more of our customers and how they are going to use our products. In that way we can ensure that the products don’t just satisfy the customers with core functionality but deliver more of what the customers will find enduringly useful as time goes on.

For anyone interested – here are the books I have read recently

Tom Knox – The Genesis Secret; The Marks of Cain – both interesting and entertaining – and well researched – if gory but with endings that seem to be rushed. I really enjoyed both books but felt the ending was perhaps unsatisfying after reading – in the sense the the excitement that built up was not quite fulfilled. I will however be looking forward to his next book – The Severed Men

Vernor Vinge – Rainbows End – a really interesting book with some great concepts – but the whole plot was perhaps a MacGuffin. there was all sorts of technology forward thinking – with localization and augmented reality – and perhaps plot had maybe less thought than the technology. And I just also got frustrated with wanting more about Mr Rabbit….

Dan Simmons – The Terror – Maybe this book is the equivalent of WebSphere Message Broker – incredibly detailed – I learned a lot about the Franklin Expedition to find the Northwest Passage and the ending of the book had a lot of detail to it – delivering a satisfying conclusion.

Was good talking a bit with Gartner earlier in the year on a couple of occasions – and hearing all the customer interest in cloud – not an area that will be going away in a hurry I think.

It has been very stimulating to work on strategy for both extending current offerings and looking at the opportunity in new segments. Lots I could say here but clearly not going to in public!

I plan to talk to some customers in Istanbul next month as part of a Hursley Comes to you event and there will also be more customer interactions in 4Q which i am looking forward to. All this while trying to get through all the Product Management day to day pieces of work – which I had better get back to.

Focus and prioritization are becoming the watchword….will try to write something more soon

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!

At times it has been tough going trying to tell the story, but then things drop into place. Sometimes it doesn’t require much change to make everything work. And mostly it seems to come down to one common answer. If you are telling the right message, the right story, it should be clear and simple. Telling it, building it, explaining it should all work. And trying to change it, improve it, should be difficult. Just as A-level Maths had you work out proofs for formula, and it would all work out neatly, or you knew you had done it wrong. If we can’t tell a compelling story in marketing, then we probably need to change our approach if not what we are trying to say. If marketing is done right, it should be obvious and we shouldn’t feel the need to change it.To some extent I think that is why SOA has been successful. SOA is actually a simple idea. People had already been doing it for years. Just formalizing it, and calling it SOA allowed everyone to agree, and now of course it is accepted, and has won the argument to all intents and purposes. Also it was probably the reason WebSphere MQ was successful. It was a simple idea, simply executed, allowing for a simple message…2+2=4 if you like.

So am I there yet with my latest marketing…not quite…but I think I have the basis for the proof, now I just need to follow it through, and show my working in my neatest handwriting. Fingers crossed for a good grade!

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.

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.

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

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