I’m going to use this post to record the discussion that generated during the Impact 2008 SOA Jam for my idea about “Too ManyESBs, Skill Spread too thin”. Now that Impact is over, I’d like to keep a copy of it’s point in time, and also allow any future readers to add comments.
ESB: Too many products, Skill spread too thin
Dan Zrobok 10 Apr 2008
Abstract
If you want an ESB you can use: WAS, WPS, WESB, DataPower, Message Broker. Based on my selection, I have to find deeply skilled resources on that specific product. Is IBM spreading the community too thin?
Comments
IBM ESB portfolio: The Smart SOA starts here (2 Replies)
While having various ESB solutions may sound like an overwhelming experience, please note that each IBM ESB solution is designed to meet a different goal. It is also designed to meet different customer budgets. To learn what each ESB can do for you please check this tri-fold brochure:
ftp://ftp.software.ibm.com/software/websphere/2008_ESB_Portfolio_Trifold.pdf
ESB portfolio
Yes, IBM has several options for building a message communications backbone. But every customer has a different environment, with different constraints. One size does not fit all!
Yes, the product set has niches
But look at it from the point of view of a company that wants to adopt one of these products while minimizing cost. If IBM has 5 products in the space, then the total pool of employees is cut in fifths. If there was a single product, you have a larger pool. I’m going to make the assumption that a larger workforce pool to select from is cheaper than a smaller one.
From a tooling-UI point of view, they’re all doing the same task. It’s the runtime that differentiates the products. Why do I have to know how to map a message from one format to another 5 different ways?
IBM SOA, BPM, and skillsets
I agree with the comments here. IBM really does not get it from my perspective. Although many of the products are sound by themselves you have to have one specialist for each product. Other SOA suites are integrated and require less development, test, and support resources. IBM needs to run their own product development as SOA and not such fragmented products that require specialists, they make it so costly to implement their products to their customers.
Agreed: IBM needs a consistent SOA framework (1 Reply)
I strongly agree that IBM SOA products are too complex and fragmented. While they are robust individually, IBM could reduce the complexity of support and improve the community adoption of their SOA products by establishing a consistent framework over the top of these solutions so that both infratructure and programming personnel could interact with their capabilities in a consistent style and manner.
Speaking as an Architect, CTO/CIO, and former IBM Product Manager, I know this is possible, but historically something IBM does not perform well at, witness the multiple operating systems IBM has.
You first have to plan and build it
IBM has very excellent consistent tools and products to build (establish) and run SOA frameworks.
For skill have a look at the IBM SOA Curriculum (see IBM Education Services and their partners).
Not from the developers point of view
Yes, they all Share WebSphere in common at some point.
But tools and concepts and user experiences are so different amongst those products, that they are effectively inconsistent.
But here is our experience…
Because of this (what you said) we placed a task for a scientific study within a German University and we could prove a totally roundtrip with all this stuff.
But the absolut key success factor was a well and special educated user (engineer) for this tools and this brings us to the reality. The problem is (mostly) the missing budget for training/education and at least in the beginning the missing curriculum..
Which one is right for me (1 Reply)
Didn’t have a chance to check out the link,, was looking for quick to select which is right for an organization
James, you link didn’t make it
I’m not sure what link you are referring to. Repost?
IBM needs single toolkit
I agree that multiple ESB products make it very confusing to especially Managers or decision makers. Technical people such architects/developers do understand product differences to some extent. On the flip side its not possible to include all ESB funcationality in one product. That will make the product very complex and will have performance issues and will almost need very high capacity servers which would be big obstacle. So the interoperability between mulitple products from different vendors is very important. But at least IBM needs to find way to develop using a single toolkit for different ESB products. That can ensure better use of developer resources in and organization as it takes time to get used to with an IDE and if you have to go back and forth between multiple IDE’s then you loose all the agility.
ESB message confusing for prospects (0 Replies)
I agree that the IBM ESB message is confusing for customers and prospects. Part of it is historical given the large legacy IBM has, part of it is poor product marketing and management – how could IBM have launched the ESB product to ‘replace’ WMB, only to have to reposition WMB as Advanced ESB? The practical answer in the short term is to promote a Federated ESB approach, making room for a mix of ESBs that conform to a set of corporate usage and governance standards. This should buy some time to fix the perception issue.
One size does not fit all (1 Reply)
The challenge is in meeting the requirements of a broad range of customers and use scenarios. These range from simple…a drop in appliance such as DataPower….very highly complex……Message Broker. There are a broad range of scenarios that call for both very complex integration to hundreds or even thousands of programs to relatively simple contained flows with a modest number of program connections. We chose not to force a one size fits all approach. Most of our customers applaud that. The obvious criticism is that it leads to a more complex portfolio. The various ESB options do work together and conform to a consistent set of standards
One Tool to rule them all
When I originally posted the idea, I was thinking that both runtime and tooling could be unified. As the SOA Jam as continued and I’ve read the responses to my idea, I realize that the server level isn’t the best way to attack the problem.
What I do believe though, is that a unified tooling platform would be the better way to go. Your development resources can remain proficient with a single programming model while the administrators can remain focused on the multiple products.
I like to think of my scenario as using a tool like WebSphere Integration Developer, and all it’s pre-existing editors to create something that very closely resembles an assembly diagram or a BPEL process. When I target it for deployment to DataPower, it converts that design-time model into runtime artifacts (XSLT transforms). I could them retarget the same development artifacts to message broker and get a runtime consumable for it. Etc.
As a developer who is already in a runtime abstracted model (WID+SCA) adding more runtime types seems appropriate.
competition from lightweight (0 Replies)
I know of at least one major financial services organisation that has been in an 18 month procurement process for SOA with all the major vendors in a dog and pony show. in the meantime they just downloaded MuleSource ESB are started building apps. The first one is now in production, and they have just started paying Mule for service and support.
Sales and complexity can be a bottleneck, for sure. Of course, to Steve Mills point the Big, Complex projects can have high payoffs… for customers, but also, clearly for vendors such as IBM
disclosure: Mule and IBM are both clients
Status (0 Replies)
Status changed from “1. Peer review” to “2. Accepted by a catalyst”.
Status (0 Replies)
Status changed from “2. Accepted by a catalyst” to “2. Accepted by a catalyst”.
ESBs more a hindrance than a help (0 Replies)
Part of the challenge is that there’s no broadly accepted definition of ESB. May people use the term to mean whatever infrastructure you need for SOA, while others think of an ESB as an architectural pattern. The fact that you could use different IBM products to implement ESB capabilities reflects this confusion over terms.
The most important thing to remember is that the business should drive the architecture, and the architecture should drive the technology. Don’t let the technology drive the architecture!
Jason Bloomberg
jbloomberg@zapthink.com
ESB: Too many products, Skill spread too thin (0 Replies)
Harry says – Yes I think so. Each of these ESBs are very different in functions and tool kit. We will need several very skilled technicians if we use more than one.
More thoughts on the skills side (0 Replies)
There are some great comments from here. James Governor points to “consumability”; Jason Bloomberg points to the need to start with the problem, and have that drive the architecture, then have that drive the technology. There are many other good comments here too.
The really interesting thing here from my pov is the debate around the availability of skills and it’s interesting because I don’t hear enough talk about it – vendors and analysts often gloss over these issues. The original point was, I think, not (or at least not only) about the complexity of the portfolio of IBM products – but about how to cost-effectively get people in who can help with a technology.
We often think of standards from the perspective of runtime interoperability or design-time integration – these are primarily technical issues. But standardisation is also really really important in terms of the “user experience” – whether that’s at development time or runtime. If we can start to build more standardised ways of engaging with technologies that fulfil common functions, that will really help companies find people from broader skill bases.
This is something that – whether we like it or not – Microsoft figured out quite early on. A big developer community means high availability of skills and competition to provide skills, which makes it easy to tap in and get the right people at the right price.
Are you doing it backwards? (0 Replies)
Too many times, we see companies making the ESB decision before they even know what Services to build and, even worse, which problem they are solving!
Don’t succumb to “vendor-driven architecture”. Start with the business problem. use this to refine / define your architecture. Use that to define / refine your Services. Use your Services to define your infrastructure. Not backwards!
Learn more at a Zapthink LZA Boot Camp (http://www.zapthink.com/lza.html)
More on skills (1 Reply)
There are already lots of comments in the thread around the “product management” aspects of this question, but I wanted to comment further about the skills issues. IBM has implemented some new capabilities internally (called Professional Marketplace) that is intended to dramatically improve our ability to locate the best skills for our client’s needs. We do have deep skills within each of our ESB technologies, both within IBM and at our partners and we should not be in a situation that we cannot fulfill client needs for skills. Nonetheless, I believe you are onto an important point that we dilute the depth and breadth of these skills when individuals have to develop deep skills in too many technologies.
Tooling idea to help skills issue
Would it easier to source skills if the interfaces (Development and Administrative) were similar(common) in all products?
For example, you start WebSphere Integration developer and create a mediation module which will request you define a targeted runtime. This targeted runtime would expand or limit the function that could be used with this targeted runtime, however all of the graphical components would be the same for Message Broker, DataPower, ESB, etc. So an HTTPInput Node(WMB) and SCA Import HTTP Binding (WESB) would have the same graphic component look with similar location in IDE for a subset of common properties with additional tabs or areas based on the targeted runtime.
For deploying to a runtime, you would start the defined server (WMB or WESB) and add projects to server. The tooling could do what was needed differently to deploy to the targeted runtime. The developer would not need to know whether it is a bar or ear file that is being deployed, just deploy the project to the runtime.
–Tom
That’s my take on a ‘solution’
Hi Thomas,
Yeah that’s where I’ve arrived in my thinking of what can be done to ‘solve’ the problem. There’s been a ton of work on supporting open standards for models, communication methods etc, but has there ever been any work on a standard UI model? Obviously one UI can’t do everything without being clunky but one ‘standard UI’ for something like mapping seems very reasonable.
Pingback: (Not) Live from IMPACT - a blogger wrap » Smart (Enough) Systems, the blog