CIO:How are you managing the teams? Where are you documenting your interfaces, your APIs, for want of a better term, how are you coordinating application development requirements? Give us a sense of the software tools and methodologies you're using to keep everybody on track to get this thing done in 18 months.

Ciurana: Basically, we are following, again, an open-source model. Like I said, we have a Business Requirement Document and a Product Requirement Document, and from there we have a number of specs. Everything that needs to talk to the outside world has a spec that describes the protocol, data exchanges; things like that. That is shared among all the participants, and that is usually some kind of [Microsoft] Word document. Then, when we start coding and putting it all together, we have a number of development and QA environments set up, so we are always rolling out.

We have a very aggressive rollout schedule. Every few weeks we're rolling out either something new to production or a patch. And that's ongoing. So, for example, in the last two weeks one went into production. That was last Thursday. This Thursday we came in with a patch for some bug we found in production, and additional functionality. And we're continuously rolling out. So the rule is, release early, release often, fix what you've got, and just try to work out all the protocol communications issues as soon as possible. That is one of the reasons why we settled on the SOA and Java technologies, because they enable us to let people work with whatever tools they want to use personally, but come into the environment with well-understood protocols and well-understood mechanisms.

So, in terms of the development team, we are very flexible. We believe that if you're a developer and you're a professional, you know better what makes you productive, so I don't care how your stuff works, how you build it, how you make it, as long as it meets the spec, as long as it builds when we check it into the source library, and as long as it works with everything else. That helps us keep things moving quickly.

CIO: You talked about building using an open-source model. But how would you describe the development methodology? Would you describe it as an Agile development methodology? When you start with an 18-month window and the organization says, 'This is what we need to get done in 18 months,' in some ways the antithesis of Agile, which says we can only build this or that in 30 days. In a way, with Agile, what you're able to build defines the timeline, not what you want to build. Feel free to disagree with me. And I'm not saying that Agile is right or wrong. I'm just asking the question, how would you describe your development methodology?

Ciurana: Basically we have Agile with a little special sauce. We do try to do Agile. We do peer programming. We do a lot of peer review. We argue a lot. Essentially, it's Agile with a flavor of, "We do whatever needs to be done and we just get it done."

Some corners of the software I am sure are not as well-structured and pretty as they would be if we had more time to build them. But on the other hand, we have a working system. We already have hundreds of thousands of devices in the last couple of months that are actually using our systems. And we have Leapfrog.com that has been in production since October [2007].

So the methodology is, let's build it, consult, figure out, work on the prototype, and release a lot. And that works really great. Part of what we have used for coordination is Internet relay chat [IRC], which is a chat protocol used by a lot of university kids. But it's also often used by open-source projects. It's like WebEx, but it's on 24 hours a day, it's free, and there are many free clients for it. So we [use IRC to] do a lot of the coordination and discussion, especially with the remote guys and the guys who are building the contracted parts of this.

I think our combination of these things is what's helping us deliver quickly, and the methodology is a little bit of, "Let's just get it done." I wish I had a smarter answer than that. But basically, that's what we do. That creates some friction, by the way, sometimes, with other parts of the organization which are more structured, more corporate; the IT guys and so on. That's normal. They want more control, more governance stuff, etc., whereas we're in the mode of, "Holy smokes! We've got to get this done!" So we're going to do whatever we need to do.

CIO: Yes. You know, my job here is not to try to find examples of some perfected notion of how to develop service-oriented architecture, but rather, to bring to the readers of CIO, the listeners of these podcasts, insight into what's really happening where the rubber meets the road. And the best part of this job, from my perspective, is I'm talking to a lot of folks who do what you do. And everybody is doing it differently. I think that's one of the beauties of a service-oriented architecture, in that what's behind those interfaces that are the touchstones, the connecting points between these application services and applications overall, is it doesn't really matter. As long as the bolt is able to go into the nut and you can screw it down, things are going to work.

Ciurana: Absolutely. At the end of the day, if we look at what it costs us to build the stuff that we needed in 2007, and what it costs us to build what we are doing in 2008, we've spent about 30 percent of what we would have spent otherwise if we had gone with the more structured approach, or if we had brought one of the big consulting firms, or if we had gone with commercial products or their ESBs of the app servers and so on. We spent a lot less money, and we're delivering a lot faster than we would have otherwise.

Look, the numbers don't lie. We're 30 percent of the cost, and most of that went to one big commercial product in this whole mix that's about 20 percent of the total cost. Everything else has gone open source, and developed as quickly as possible. And it's working.