Hi, my name is Christopher Lochead from Mercury, and todaywe're going to talk about SOA, and specifically how we optimize for SOA. Now,as you know, there's lot of benefits to SOA. However, today's solutions canrapidly turn into tomorrow's problems. So, let's talk about the pitfalls over that,and how we avoid them.
If you think about what SOA is really about, we used to havea paradigm where people built very big chunks of software applications, kind ofmodel after the client server apps. What's happening is applications today arefragmenting into small reusable components, so that we can get faster time tomarket, more interoperability, better integration and ultimately, use of theInternet. All that's a very good thing. However, it's changing the way peoplethink about the software development life-cycle. In a traditional approach,what you did with the SDLC is, you had design up here, you had development overhere, and that's where all the attention was in R&D. Then, you had deliveryover here, which is all about quality and testing, and then you had managementin production. In the old world, that it's kind of a joke one of our customersat Mercury shared with me is that, over here in design and development, peopleget drunk and over here in operations, they get the hangover.
Now, what's about to happen with SOA is the amount ofdrinking over here as we compononize apps is going to increase the throughputor the rate of change in terms of new pieces of functionality that get ruledout here. So, what's going to happen is today we have 30,000 changes a day inIT operations, new applications, new databases, etc., as we fragmentapplications, the number of new pieces, components in SOA apps that go throughproduction are going to increase. So this rate of change is going to go up.
So the question is, how do we deal with this? What peopleare talking about doing is creating if you will, an optimization layer toreally govern the approach to a couple of critical things and that's really allabout quality. It's about performance, and it's about availability, and if wecan govern those things to make sure that we engineer quality in, we dorigorous performance and quality testing in pre-production, and mostimportantly, we manage all of these SOA components in production against thisset of business service levels, then we can make the big shift that's requiredwhich is simply stated from making stuff to making stuff work.
