Read part one
I would say both. We did a real large piece of work on the 5,700 customers garnering what we could from their learnings. I think at one of our user groups we had up to 700 customers just talking us through what they had learned and more importantly what they wished they had known when they started. That's the whole theme of this launch. We call it Smart SOA because making it a smarter way to approach to SOA based on customers' learnings. My father always told me: "Learn from someone else's mistakes, so you don't have to go through those mistakes. It will make your life much easier." I think the same is true here. Learn from what other people have learned and it will make your life easier as you move through SOA adoption. In terms of best practices are these things developers can learn by going to a Web site and reading documents, or do they need to work with consultants, or actually sit in a classroom?
You always learn the most by doing. You can remember this growing up. You learn not by reading or watching somebody doing it. You learn by doing it. If you remember at the Impact [conference in May] we announced Innov8, which is actually a simulator gaming tool. And you know, my daughters and most of the kids I work with at the MBA schools, they love gaming. They love simulators. So one of the ways we try to implement the skills and the learning is through things like that, simulation and gaming technology so customers can learn faster. The other thing we try to help them with is things like our SOA Sandbox. What's the SOA Sandbox?
Our SOA Sandbox is a place you can go as a developer or architect, our target audience. We have full versions of our software trial code. We have online hosting that is available so they can try the code out. This is all based on the SOA entry points of people, process and information, reuse and connectivity. We have decision guides, tutorials, architectural guidance. All this is done as a hosting environment for free trail codes that developers and architects can get their hand on. The value to them is it gives them examples of best practices. It provides a low-risk, hands on way that they can understand what we have to offer. So the Sandbox gives them a chance to get their feet wet in SOA?
Yes. We tested it out on our user group and it went over amazingly well. So we've got it set up and it will go live on Oct. 7th. It will be available at http://www-306.ibm.com/software/solutions/soa/. When you go off to the Sandbox, it's much more than "here's some free code, go off and have fun." It gives you access to people so you can ask questions. The decision guides help you decide how granular should your service be. It includes solution cookbooks and a quick start guide. It's sharing those best practices and free material, along with best practices embedded in the products. Typically where do customers begin their SOA project?
When you think about some of the common areas that customer have started with, one of the most common is: "I have a set of applications already in my environment. I need to be able to reuse those. Whether it's an Oracle app or an SAP app, I need to be able to reuse what I have." This is an area that IBM is really good at, the heterogeneous environment where we can extend the value of your legacy and packaged applications by service-enabling those functions. So we've come up with a complete configuration, installation guide, architectural guidance, documentation, and the adapters that allow you to streamline service-enabling those particular parts of your applications. It has recommended solution patterns. It has guidance on the assembly of the business solutions using processes, adapters, mediation. It has information on the integration of existing applications with Web services. How you would transform it around messages. And there's guidance on how to abstract the data and information from a packaged app. So it takes all the best practices and packages them if what you're trying to do is reuse a package or a legacy app. So legacy application integration is still a starting point for SOA?
Most of the early adopters of SOA were service-enabling their IBM applications, their SAP applications, and their Oracle applications. This was one of our common configurations.
Web 2.0 is particularly exciting to me because Web 2.0 allows you to extend the reach and the value of SOA by making it simpler to use, more consumable. It does that through user created applications, the rich user experience, and also making it simpler to access the services or Web accessibility with the REST standard. So it's accessibility to services using the Web, using the Web to expose services, simplifying the whole model for accessing and using those services. I think this is really powerful.
If you look at what we're announcing [this week] we have a set of products that now put into the hands of a business user what they need to do a mashup when they need it. Ajax is one of the critical elements there. So our portal now has Web 2.0 capability. Ajax capability is now in the Web 2.0 feature pack. Web 2.0 capabilities are now in our commerce portfolio that allows you to unlock content and leverage Ajax, so users can create their own experience. And on the simple to access side where you're now providing RESTful development or SOAP and WSDL based development, we've now got enhancements to WebSphere Application Server, WebSphere MQ and IBM DataPower, so users now have access to content and the ability to reuse assets that are done in RESTful development and done through SOAP-based development as well. To me this is very interesting as we see these kissing cousins of Web 2.0 and SOA being used together in the marketplace. Can you give us an example of the way you see SOA and Web 2.0 coming together?
One example is what happened when Hurricane Katrina hit. People needed to have access to resumes of people who could help with the recovery effort. It needed to be done fast. It couldn't wait on the normal development pattern. IBM teamed up with several vendors in New Orleans and created a front end mashup, a portal that had a series of mashups or portlets on it that were deriving data from different job banks and search engines to allow people to search needed jobs based on skills. The whole backend of that was based on an enterprise service bus that handled the entire backend integration. So it was a case of "I've got to get something up quick, but because of the numbers it also needed to be scaleable and reliable." So this leveraged SOA and Web 2.0 in a nice way.