Leapfrog jumps into SOA

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

1 2 Page 2
Page 2 of 2

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

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

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. 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% of what we would have spent otherwise if we had gone with the more structured approach, or if we had brought [in] 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% of the cost, and most of that went to one big commercial product in this whole mix that's about 20% of the total cost. Everything else has gone open source, and developed as quickly as possible. And it's working.

So you're doing "DIY SOA." No commercial SOA stacks, emphasis on open source, emphasis on agile? 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.

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

Let's talk just for a moment about your relationship with Mule. What drove you to bring Mule into your architectural mix, how are you using it, what benefits do you feel you're getting and what challenges have you encountered with it?That's a loaded question. Basically, I was working for this very large retailer. I was commissioned with other people to build & the next generation of e-commerce systems for those guys. At the time we were building our stuff, we identified that we needed some kind of ESB technology. We ran a number of proof of concepts with every vendor you can imagine, both open source and commercial. We set up a couple of SOAP servers for them and said, "OK, here's everything. Here's what we need. Here's the time frame that you have. Let's see what we get."

During that evaluation, we learned a lot. We ended up liking the Mule product, and we really liked one of the commercial guys. The difference is the commercial guy, just for the basic licenses, was going to cost something like $350,000 [U.S.]. We said, "Forget it. Too expensive."

We decided Mule was the way to go, and we ran with it. Eventually I wound up [leaving the retailer and] going to Leapfrog. And when I got here, I decided to do another SOA. Mule looked good, and by then they had a real company behind it. They had the ability to provide support and training. So we brought them in, first on a limited basis, with a couple of servers. We got what we expected, or better, so we decided to go for the enterprise license and make a big commitment. In general, working with the Mule software has been both exhilarating and frustrating. The implementation has always been its weaker link.

So explain to the readers the role that Mule serves in the architecture, and then give us an example of an implementation problem that you encountered that you needed to get resolved. Basically, Mule connects everything -- our back-end systems, databases, partners; all of our connective product, absolutely everything that's happening in the Web environment, is going through Mule. Everything. If two boxes, two systems . . . talk to each other in any shape or fashion, that's going through Mule. So if something breaks, that means that my whole environment dies. I mean, that's mission-critical, right?

So one of the things that we had a problem with -- this is going to get a little technical -- in one of the protocols that we were passing through, the front end and the back end, we found that some of the bits were not working. I mean, this is pretty obscure. I got on the phone with MuleSource at roughly 4:00 in the afternoon, and I said, "We just found the problem. We need to fix it. I need to have it fixed by 8:00 in the morning tomorrow because this needs to go to staging. We're pushing it out the day after tomorrow. So I need it now." And, sure enough, within an hour, I had one of their consultants working with us. By 9:00 we had found the issue was caused by a combination of something they did in the product and something we did in our code. By 11:30 at night we had fixed the problem. By 8:00 in the morning we were able to push this [to] staging. Everyone is happy.

Great. I really appreciate the time you spent talking to us today, Eugene. It's been really interesting. I'll check back with you at the end of the 18 months. [laugh] Well, the end of the 18 months is October 3rd, so . . . you'll actually be able to see the finished product.

This story, "Leapfrog jumps into SOA" was originally published by CIO.

Copyright © 2008 IDG Communications, Inc.

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