Next, learn about ESBs. Not the specific products (yet), but the technology category. Leverage resources like our ESB Q&A paper and ESB Evaluation Framework. Think about your own integration scenarios. Does an ESB make sense for you? What are your most important requirements? Use our ESB Evaluation Framework as the basis for an RFI/RFP and/or a product scoring system. Assign weights to the evaluation dimensions that are most important for you.
For both educational pursuits, find resources that match your learning style: reading, instruction (Webinar, seminar) and/or hands-on (tutorials, reference implementations). For hands-on learning, leverage open source projects to get full product access without time constraints and sales calls.
3. LEARN ABOUT THE PRODUCTS. With a solid problem definition and a good understanding of the technology, it is time to engage in the normal product evaluation tasks in order to generate a short list. Scan the market for solutions. Read vendor-supplied documentation and whitepapers. Gather industry insights from independent research (our bus rides), blogs, and message boards. Attend product-related Webinars and seminars. Invite vendors to respond to your RFI/RFP, and give an on-site demo. Talk to references and industry peers. Finally, be sure to download evaluation software and perform the tutorials. If the product isn’t available for your evaluation, it is typically a bad sign.
From the above, score the products against the criteria you deemed important in our ESB Evaluation Framework. As a result of the scoring, identify two or three products you’d like to exercise in your bus rides.
4. PLAN AND CONDUCT YOUR BUS RIDES. At this stage, you want to exercise two or three products in your environment, resolving a sampling of your key integration scenarios. There are two legs to the bus rides. The first leg is a vendor-executed run-off. In the vendor run-off you are asking a vendor to come to your site, install their products, and resolve the integration scenarios you supplied ahead of time. This is a very effective way to see the product in action. But keep in mind, for the vendor, this is a race. They want to resolve your integration scenarios quickest. So, while you will have the opportunity to observe and absorb, you won’t have an opportunity to interact with the product.
The second leg is an internally-executed proof-of-concept, which is your opportunity to interact with the product. Work from the software installation and deliverables from the vendor run-off. Execute additional scenarios. Add integration tasks to the vendor-built scenarios. Get a feel for the product in design time, development, and runtime. Include runtime tests for problem detection and correction.