CIO: So you're doing "DIY SOA." No commercial SOA stacks, emphasis on open-source, emphasis on Agile?

Ciurana:Well, for example, I've been using SOAP for a long time. And the more I used it, the more convinced I became that its main design was to help Microsoft and IBM sell consulting and tools. It's way too complicated. There are better ways of doing things that don't need to be that heavy for every application.

Now, the problem that I see sometimes is that people think SOA is SOAP or SOAP is SOA, and they push aside all the other things that have to go into SOA. So the approach we have taken at Leapfrog is best-of-breed. Let's quickly figure out what the problem is, let's understand what the business requirements are that we need to meet, and let's find the best thing that is going to help us to fix this problem. That's how we arrive at a means for having an effective mix of some commercial, some open-source, some home-grown, and some consulting. We just try to get the balance among those things.

So for a lot the things, like the connective apps and the PCs talking to the back-end systems and so on, we saw that SOAP made sense technically, and so we went with it. As we learned more about the system, we found there were other technologies for some of the requirements that were going to work better, so we started using those.

CIO:And what you're really making is an argument that even experienced people in this industry confuse the technology with the architecture. I've heard people say that SOA is a technology and, in fact, you're bringing out the point that SOA is not a technology, but rather, that you cobble together several technologies to accomplish a service orientation.

Ciurana: Exactly. It's about how do you provide services that are aligned to the business as quickly as possible, and design patterns that allow you to mix and match legacy systems and new technologies. That's really what SOA is about.

The vendors, of course, want to come in and sell you a stack. For example, I know a vendor that likes to come in and say, "Without this and that from us, your SOA just won't scale." What they're trying to do is lock you in. When you start using their products in production and integrating and so on, if you ever need to go outside their black box, you start having a lot of problems and costs—because vendor stacks in general often work well with themselves, and not very well with the rest of the world, regardless of what the marketing material says. That's one of the reasons why, when you are actually integrating all these types of systems, it makes sense to use things out in the [open-source] community that are intended to interconnect products from wherever or whoever they come from, over whatever protocol, and over whatever data mechanism that you happen to have, independent of a specific vendor's flavor of things. And if any issues crop up, well, you have the source code and can immediately troubleshoot, without waiting for a vendor to look inside their black box and report back to you whatever they find.