Ensuring Your Database Applications Perform Well in SOA Environments: Having Data and SOA Experts Onboard is Key

This podcast runs for 4:38. You can listen to the podcast by clicking on the following link: http://dataaccesshandbook.com/media/Rob8.mp3

From the Podcast:

Rob, what are some guidelines for data access and service oriented architecture, and why are both data experts and SOA experts needed to ensure success?

Rob Steward: Well I guess the primary answer to that is that what we’ve seen over the last four to five years – as people have started to implement SOA environments and roll them out into production – is that the people who are in charge of those environments and in charge of these projects, which are always very large projects, are typically your SOA experts. They understand what it means to take some bit of business logic, encapsulate it into a service, and then how do you expose that? How do you represent that to all the different application groups that may use that service? Those are the people who are typically in charge of these projects.

So what we’ve seen happen over and over is that these guys design the service, but when they design the services what they’re not experts on data access. So they design them with service orientation in mind, but not necessarily with what is the best and fastest way to access the data within those services.

Most services out there, probably 75-90% of the services out there, actually access some kind of data. Well within that service you write the codes to go get whatever the data is you need to process a return – and you’ve got the people who understand services writing that code, and not necessarily the people who know the best way to write that code to access the data. So what I’ve seen happen over and over is somebody will design a service, lets say to return a customer record, so they design this service to return a customer record, and typically services get rolled out originally due to an application that has a need for that particular service. So the first application that’s written – that is service oriented, that needs a service to return to customer – that group will typically write that services, with the help of the SOA architects. So they write this thing, they have an application that maybe 50 users use. The service goes out, the application’s using that service – it’s working fine for those 50 users – then, of course, under SOA guidelines another application comes along and needs a service that returns a customer.

Well under SOA the idea is to reuse that same service. So the second application hooks up and starts to use that returns a customer. Now instead of having 50 users of that service we suddenly have 150 users of that service. And then a third application rolls out, and a fourth applications rolls out, and all of a sudden a service that was originally working very well for those original 50 users all of a sudden have 500 or 1,000 or 10,000 users on it, and it’s not scaling well.

And over and over we’ve run into this, and as we start to look at these services, you realize: The data access code within that service actually is the bottleneck. The way that code is written, the way that data is accessed, causes that service not to scale as users are added to it.

So again, though the original service that rolled out for that original application might have been performing fine, as we start to scale up and add more and more applications, what we find out is that it wasn’t written optimally to scale up. And then we have to go in and fix those services and fix that data access code.

In places where I’ve seen SOA work and work very well – and I’m a data access expert so I concentrate on the data access code within those services – where I’ve seen it work really well is when you get in conjunction the data architect as well as the SOA architect to jointly design and implement those services. Because the data guys understand what it takes to build those services in a way that’s going to scale. And as the enterprise moves more and more into SOA, they’re going to have more and more users on those services. And where I’ve seen this be successful is where those service that access data were well designed up front, and understanding that it’s not just going to be the 50 users, eventually we’re going to have 1,000 or 5,000 or 10,000 users on there.