CIO: What are you using on the embedded devices? How are you developing the embedded applications?

Ciurana: Some have a custom operating system that right now escapes me. The others are UNIX based. We're a big UNIX shop up and down the stack, from the hand-held devices all the way to our back-end servers. We have some Solaris for some mission-critical stuff.

CIO: And what application development platform are they using to actually build the applications that they're running on these embedded operating systems?

Ciurana: I am not sure exactly how that whole thing is built. I have very little contact with them. There are three tiers for this, so let me try and explain. The hand-held tier, I'm pretty sure, is a combination of C and C++. Then there's a PC tier that you use to connect devices to your PC. We have something we call "the PC app," which is easy to do on the Internet, and lets you do some account management if you have multiple children and what device is for whom, etc. It runs on Windows. All the Web applications are tested and tested again to work with all versions of Internet Explorer (IE), Safari, and Firefox. The systems infrastructure tier is a combination of Java, a little bit of the Google Web Toolkit (GWT), and some JavaScript for the Web part. But we're mostly a Java shop in the server infrastructure.

CIO: And then what are you using on the database side? Is it MySQL or some open-source database?

Ciurana: We're using a very large commercial database.

CIO: Can you say which one it is?

Ciurana: Um, no. I cannot say directly who they are, but they have an office in Redwood City [laughs].

CIO: It sounds to me like the embedded device actually interfaces with the PC app, and then your PC app would be what actually interfaces with your Web applications ... and I'm guessing you have some sort of Web services communications layer between the PC app and the back-end infrastructure?

Ciurana: That is correct. In broad strokes, that's how it works. The actual Web services communicating between the layers, between the PC app and the back-end system; we have several variations of that. Most of it is SOAP. We have some calls which basically just help the server get or post something and that's it. And then we have a number of Web services for other operations. We have a mechanism for uploading data from other devices. That one is just a straight form post with an attachment to a server, and then the server does something to store it.

CIO: The design and development process: How do you start this? How do you govern this? How are you moving this from concept to code?

Ciurana: I don't think we're like any other company that's building consumer products out there. We have a BRD—a Business Requirement Document—that eventually becomes a Product Requirement Document. All the development teams participate into making decisions that figure out what needs to happen to execute on those plans, and then we get up and running. When we come to the actual execution, we have several different teams that are working on Web engineering.

We have my team, which consists of infrastructure. We are responsible for the overall system architecture, and that includes the connective product and the Leapfrog.com store. Then we have our data services organization. These guys are super smart at doing data modeling and data services and so on. And then the Web team does content management and all the core Web stuff, Ajax, GWT, etc. So those are the three major components.

Now, when it comes to the execution, because of the time constraints we had, we were looking at how do we do this quickly and cheaply—right?—because when you restructure, you don't want to have a lot of money floating around. And we looked at, again, the commercial outfits that have helped us in consulting, software, and development. We found it was too expensive, and they didn't have the skills we needed. So we decided to look at alternatives. We ended up choosing open-source technologies, and talking to the guys running the open source projects. We had them come in and work on a consulting capacity, and help us build the system.

We are actually getting much better hourly rates than we were getting with any of the big outfits that, you know, starts with an "A" or starts with an "I"—OK?—much better prices, and we're also getting much, much better expertise. So, for example, if we want to do GWT, we hire one of the guys who is super active in the GWT community. When we came to databases and how do we structure all this stuff, we got one of the guys who authored one of the best-selling books on SQL to work with us.

At the end of the day, we have assembled one of the best teams in the world. We have some of the Mozilla Foundation guys working with us, helping us build this thing really, really fast. It's actually cheaper than doing it through another outfit, and we're getting a lot better service and a lot better turnaround time than we would have otherwise. I think that covers the first part of your question.

CIO: Yes.

Ciurana: Then wasn't the other part something about the architecture?

CIO: Yes. How is the architecture structured? You talked about development teams all over the world. Can you sketch out how the development organization is structured, what responsibilities are being dealt with where, how are you communicating on and agreeing on what aspects need to be exposed as interfaces, how those interfaces are going to operate, the governance of these interfaces, the development and governance of these interfaces?

Ciurana: Okay, so basically the architecture is set up in such a way that we have distinct layers. The first layer is the PC app that's done by the PC app group; super smart, super sharp guys working in Windows and Mac and so on. Then we have the Web layer. That is locally done. The whole thing is done in our offices, but we have consultants from open-source projects working with us.

Then the next layer we call the backbone, which is a cluster of ESBs that are acting as a switchboard between all the communications coming from the outside world, whether it's Web, PC apps, our partners, data consolidation, etc.; it's all going through an ESB. And then we have our services layer that we call the "tailbone" or the "back-end," which is another cluster of ESBs and servers that are providing the actual implementation for a lot of the services. The backbone provides switchboard capabilities, workflow, and transaction. And the tailbone does all the heavy lifting and implementations for each individual service.

In terms of how the development teams are organized, I would say about 40% of the development team has their offices in California. The rest are consultants that are based out of Colorado, Mexico, Canada, Belgium, Malta—we've got people working on this from all over the world. Our QA environment is also set up in such a way that we work on stuff here in California, and at an operation in Vietnam. Our monitoring is done in California. We also had an organization in Australia working with us on that. So we're globalized in terms of how we are managing this environment.