Where would you say most enterprises stand in terms of Web services projects? Are most still in pilot stages right now, and, if that's the case, do you consider this pace too slow?
'Early mainstream' is the way I would phrase it. Early adopters are before that. Gartner tosses around a number that upwards of 50% of all companies are doing something with Web services. Those include pilots or proof-of-concepts. But you do have companies like Nationwide Insurance, which is in production, Chase-Morgan, Merrill Lynch, Starwood -- all in production. So it really varies.
Read part 2 of this interview tomorrow.
For a lot of that, yes. Web services are the specifications or standards that give you the language to talk about how we build these interfaces and how we define the policies for quality of services. Frequently, Web services are used to wrap existing systems.
If we can repurpose existing systems that are working just fine with Web services and get more use out of them, that's really quite positive.
One of our customers, Merrill Lynch, a classic mainframe shop -- they had more than 23,000 mainframe applications. It's hard to believe that, but big banks -- that's what they've been running for a long time. They wanted to look at Web service-enabling a certain number of them. They took one as a pilot and said, "Let's size what it would take to rewrite it fully from scratch to make it connect into all of these things." They figured it would take about $800,000. They decided instead to Web service-enable it, which basically meant they would put a copy of Websphere sitting on SuSE Linux, they would build the connections to the back-end systems and they would build Web services. Instead it cost them $30,000.
It will vary from company to company because there are some applications that need to be rewritten because there is some creaky old stuff out there, but by intelligent choice of what you do and using Web services and SOA as the over-arching principle, it gives you more tools.
Anecdotally, Web services is about 4 years old -- and I'll date that back to when the SOAP spec was published. I've been talking to customers a lot, and when we talk about Web services, it's a lot about this spec or that standard or education or roadmaps. When we talk to customers about SOA, they say 'Yeah, we're doing that. We've been thinking about that for a long time.'
The characteristics of a service-oriented architecture are that fundamentally, we're dealing with distributed computing -- that is the things that we need to happen to really drive our business processes are going to be happening on various computer systems we have, but also are increasingly on systems at our customer sites, as well as [on] our partners' and suppliers' [systems]. To really execute the business processes we need, we have to have an IT infrastructure that's very flexible, that we can reuse and get redundancy out of.
A lot of [SOA] is driven by mergers and acquisitions. Look at the financial services industry, they're by far the leading industry to get into this. One bank buys another bank, suddenly you have two of everything. You have frequently wildly different systems that have been built over a period of years and because those banks were built by previous mergers and acquisitions. A lot of this is driven by the need to get these systems up and running and linked as quickly as possible so that they can keep making money.
SOA is driven by this notion of how can [you] reduce complexity in what is a heterogeneous collection of systems and information sources, like databases, so that we can make these things work together as quickly as possible. And not only do we need all this functional stuff -- the various parts of the individual companies to do what they do -- we need to make sure that certain service-level agreements are kept. We need a certain level of quality of service. We need to make sure that if we have to access this process from another part of the bank, that it gets back to us in 10 seconds, things like that.
With infrastructure, it's about how we hook these things up so that the actual communication happens quickly and reliably and securely.