Dan Green, the creator of this fine site, had posted this “Resourcing Newsletter” some years ago:
[URL=“wmusers.com”]wmusers.com
Given the number of recent posts referring to webMethods as a product and that doing so is a personal peeve of mine, I thought I’d post an updated version of Dan’s article (still targeted to IT recruiters):
webMethods is a corporation, not a product.
The webMethods corporation produces many software products ([URL=“API Integration Platform | Software AG”]API Integration Platform | Software AG). The product names have evolved over the years but the current primary product is “webMethods Fabric.” It is an umbrella product which consists of four “key product offerings” which are essentially groupings of webMethods-produced components.
The complete list of more-or-less independent but integrated components:
webMethods Integration Server
webMethods Mainframe
webMethods Broker
webMethods Adapters (these usually have their own individual name)
webMethods Trading Networks
webMethods EDI Module
webMethods EDIINT
webMethods Servicenet
webMethods Monitor
webMethods Glue
webMethods Administrator
webMethods Modeler
webMethods Workflow
webMethods Manager
webMethods Optimize
webMethods Dashboard
webMethods Portal
These products are DISTINCT and DIFFERENT from each other. Some have dependencies on others (e.g. Trading Networks requires Integration Server) but they each provide unique features. When you ask someone if they know webMethods, you are exposing your technical ignorance. Asking someone how to do something using webMethods is like asking how to do something using Microsoft or IBM. It’s ambiguous.
When your clients tell you that they need people with “webMethods” experience, ask them “Which webMethods product? Integration Server or Broker? Workflow? Servicenet?” These are very different skill sets and a person proficient in one is not necessarily skilled in the others. This will help you present only qualified people for interviews.