Leapfrog jumps into SOA

The team leader's mantra: "Anything that works"

Cue the Western music, because the coding cowboy hasn't ridden off into the sunset just yet. And as this case study demonstrates, perhaps we should make sure he doesn't.

In fact, despite all the industry big-think about how SOA requires strong governance, months of front-end BPA and modeling, baked-in standards (WS* this-and-that), ESBs and registries or repositories and mile-high SOA-savvy integrated vendor stacks, some development teams are building a SOA the old fashioned way: fast.

And it's working. That's the case at Leapfrog, one of the world's most successful makers of educational electronic toys. The company is nearing the end of an ambitious effort to make its consumer product lineup Web-savvy.

When Leapfrog's new devices connect to the Internet, they are transformed from toys to solutions. They become the front end of a sophisticated SOA that integrates embedded devices, legacy systems, e-commerce and a bevy of reusable services that power features, functionality and, ultimately, sales.

You won't find a bunch of business analysts and programmers sitting in a room mapping out requirements and design. In fact, you won't even find a room. The system is being built virtually, using what could be called a modified agile development method. The developers are scattered around the globe, communicating with e-mail, Microsoft Word documents and Internet relay chat.

The programmers can use any tools, techniques or technologies they are comfortable with, as long as the resulting components meet spec. And the team leader, who you'll meet here, is maximizing productivity and quality by hiring consultants who are key players within the open-source community; the people responsible for developing the open-source platforms being used.

Can you build in 18 months what some organizations can only design in 18 months? Eugene Ciurana, director of systems infrastructure at Leapfrog Enterprises, is proving you can -- and for just 30% of what it would have cost, he says, had Leapfrog used commercial products and a more structured approach.

This interview was originally planned as a podcast; however, the audio quality was poor due to an error on my part. As a result, I had the interview transcribed and present it here.

Tell us about Leapfrog. What does the company do?Leapfrog is the largest independent producer of educational products in the U.S. We have a presence in 35 countries, and we're a public company. Most people who have kids between the ages of 4 and 10 probably have heard of us. Basically, our mission statement is "helping kids to learn how to read."

Tell us a little bit about what you do as the director of systems infrastructure. My charge is to come up with and execute direction for all Web systems that Leapfrog Enterprises will roll out, and which will have a lifetime of about five years. We're on the first year of our five-year plan, and every single [consumer] product that we'll probably be launching this year is Web-enabled.

Basically, your kids can play games and learn things like math and reading and writing and spelling, and all the 3Rs, and so on. And then you can connect the device that they're playing with to the Web via your computer and download software titles from there. Or you can track the progress of your child in terms of how well he or she is learning whatever topic you're working on, using something we call the Learning Desk, which is a Web-based console.

You can come in and check on your kid's program and see how she is doing, and eventually, you may be able to share that information with her teachers. So we have this infrastructure that has to support many of the devices that talk to each other over the Internet, through our servers. Plus we've got partners that provide us with other services, like community Web sites and so on. And we have to make all of that look like a seamless experience to the user.

What was the IT environment, the infrastructure, like when you came on board, and what has driven the decision to bring somebody like you in? And what moved you in the direction of a service-oriented architecture? Leapfrog Enterprises went through a major restructuring sometime in late 2006. At that point, the company went from "we're only making devices, handheld consoles, plushy toys and so on and so forth" to "we're going to things that are Internet-ready."

We want to be able to leverage the Internet to share information between teachers, parents, children, etc. That became the value proposition for the company. In 2007, we decided to run with the IT side of the project once the business side was set up. Management hired a bunch of us from other universes, where we had been doing SOA and things like that, and they said, "Great, we need to build this huge system. How do we go about it?"

When I came in, we started communicating with a lot of people in the open-source community. We told them what we wanted to do, and we started looking at what kinds of technology we needed to build the system. The Leapfrog business plan called for a complete revamping of the Internet infrastructure in a period of roughly 18 months. Now, we have an established IT infrastructure. They do mail, they do servers, they do the back end, they do Oracle stuff, and so on.

Our charge was not to tinker with the IT infrastructure, but rather, to [work] with a systems infrastructure that supports our electronic devices. When we saw the business plan, first we said, "Holy cow! That's a lot of work for 18 months!" And we started trying to figure out how we can get where we need to be the fastest.

Complicating matters is the fact that we have two major projects going on in parallel. One is the Leapfrog.com e-commerce site, which generates quite a bit of money for the company annually. We need to make sure that that's working very well.

The second part was to set up the infrastructure for all disconnected devices. We knew that by the end of 2007, we would have millions of new Internet-capable devices out there. These devices did not exist in 2007 when we started, so we needed to start figuring out how we make all this stuff work together. What services do we develop? How do we develop the services in a very quick fashion? And that's when we started looking at SOA, and what was available commercially and open source to design, build, manage and govern a SOA.

What are you using on the embedded devices? How are you developing the embedded applications? 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 handheld devices all the way to our back-end servers. We have some Solaris for some mission-critical stuff.

And what application development platform are they using to actually build the applications that they're running on these embedded operating systems? 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 handheld 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, Safari and Firefox. The systems infrastructure tier is a combination of Java, a little bit of the Google Web Toolkit and some JavaScript for the Web part. But we're mostly a Java shop in the server infrastructure. And then what are you using on the database side? Is it MySQL or some open-source database? We're using a very large commercial database.

Can you say which one it is? Um, no. I cannot say directly who they are, but they have an office in Redwood City [laughs].

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? 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.

The design and development process: How do you start this? How do you govern this? How are you moving this from concept to code? 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 & 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.

Yes. And the second part was: Can you sketch out how the development organization is structured, what responsibilities are being dealt with where? OK, 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.

1 2 Page 1
Page 1 of 2
7 inconvenient truths about the hybrid work trend
Shop Tech Products at Amazon