Friday, December 16, 2005

SOA and the IBM product stack

Tempted though I am to weigh in on the recent post by Rich Turner of Microsoft UK on the perceived differences in style between IBM and Microsoft, particularly in the consulting arena, Richard Brown seems to have it covered with his usual mix of good humour and sharp perception. Suffice to say that I believe Richard is absolutely right in saying that we don't all work for Global Services, and that MCS and IBM Software Services have very similar missions. I'll come back to this point later.

So instead I want to talk about the series of articles on The Register by Phil Howard of Bloor Research. The final entry in the series suggests that IBM has a problem with the SOA message - we just have too many products.

I heard this same statement from a customer earlier this week. Here are my thoughts on the matter:

  • Sure, we have a number of products which fit in across the whole swathe of an SOA. Let's talk about at a few of the development tools, for example: Rational Software Architect, Rational Application Developer, WebSphere Integration Developer, WebSphere Business Modeler. These are all based on the Eclipse platform (as are all of our tools), and provide functionality appropriate to their target audience: architect, J2EE developer, ESB integration developer, business analyst. The look-and-feel is consistent. If necessary they can be combined into a single workbench. What's so scary about that? You can choose the products you want, and combine them as you wish.


  • IBM is strongly behind open standards, and we go out of our way to ensure that our products conform to agreed open standards wherever possible. We don't go around evangelising a rip-and-replace strategy. We know that many customers have a technology soup already, and there are heritage applications and platforms that aren't going to be going away any time soon. I've been with IBM for 4 years, working with our WebSphere integration products, and literally every day of my time with the company to date has been about applying our technology to integration problems that customers face. By following a strategy based on open standards, the ability of our products to interoperate with those from other vendors is greatly increased. Again, you can pick and choose what you need from our portfolio to fit in with the needs of your business.


  • What if we just had a single, "uber-product" for SOA? How much sense would that make? It just isn't reasonable, surely? And just how "simple" would such a product be? What we have is a set of software products which cover the challenges which customers are likely to face as they set about building an SOA. I also believe that we have a consistent message and that each of our software brands makes its own strong contribution as part of the SOA strategy. You need a development tool? Look at the Rational brand. You want to look at collaboration? That's Lotus. Monitoring, security, systems management? Tivoli products. We have excellent coverage; it doesn't matter which point you want to start from, we can help you to deliver an SOA.


The final point raised by the piece is that one of the really key aspects of implementing an SOA is that of the cultural impact, which I think we can talk about in terms of governance. Phil Howard argues that since this is more a business issue than an IT issue, it is outside the domain of IBM Software Group. I agree with him up to a point; but this is where we dovetail neatly (I hope!) back into the point about IBM Software Services and IBM Global Services. IBM Software Group may not be able to cause a cultural change simply through the software that we release*, but as a Software Services consultant I certainly go out of my way to talk about the business impact of SOA. It simply isn't going to work if the business decides to build an ESB and then the IT development groups fail to use it - you miss out on the benefits. Strong leadership and governance is critical. As a consultant part of my role is to not only transfer technical skills to our customers, but also some of our experience and understanding of the cultural impact of SOA on both business and IT people.

* unless... we came up with some kind of mind-control software... interesting... I'll have to talk to the guys in the labs... :-)


Technorati tags:

3 comments:

Anonymous said...

The real challenge though that IBM faces, is not the complexity of our products, but the complexity of our customers.

If we were &Ampersand. small software company, or an organisation we could do just a single product and say "there, thats SOA/ESB" its great like it or lump it.

However, that wouldn't be much use for the millions of customers over dozens of OS's, and four hardware platforms, built up over 30-years, who want to embrace SOA. Sure, many of them can and will do it without our help. Heck, some of them even do it without our products ;-( but generally while we have often intimate knowledge and understanding of their systems, they still want a shopping list of options rather than just do what we say.

So, that leads not to complexity, but rather to completeness. Many products with interfaces to, and programability for services based applications and infrastructure.

As always, people would like a single message, a single voice, but mostly customers don't want a single product unless its the one they currently heavily exploiting. Even then they want something else to integrate to it, with it, or from it.

This is why open is key. Emracing web services, getting involved and implementing WSRF, WSDM et al. will pay off in the mid-term for both the customers and for IBM. The ability to implement applications around a services base, with a strong mediation engine, that participates in and can support a robust set of open industry standards is key.

Andy Piper said...

Thanks for the comment, Mark - nice to know I have another reader. Completely agree with you here. As James Governor has said over in the mainframe blog, IBM makes it clear in the marketing that SOA is hard. We recognise the myriad of systems that customers have, and (since I've been here, at least) we've always been about helping to integrate them. Open standards can only make this easier.

I like the way you rephrased this, too - it isn't complexity of approach, it is completeness. That's great. I'm going to use it in conversation :-)

Anonymous said...

glad you picked that up in your response to the response andy. i was worried i was being taken for granted