Java ME Luminary - Randy Busch of Tira Wireless

Print-friendly Version

You come up with a great idea for a mobile application, you research extensively and conclude there's a big market for it. You design it carefully, code it skillfully, and test it exhaustively. Now comes the hard part: adapting your implementation to thousands of combinations of handheld platforms and network operators.

To say that this task is non-trivial is to trivialize the word "non-trivial." Randy Busch, VP Products of Tira Wireless, believes his company is your best friend at this stage in the product development cycle. Tira designed its Jump Product Suite to help developers and publishers manage code and other assets, optimize their applications for the platforms and networks they choose to support, meet the certification requirements that manufacturers and operators impose, and control the workflow through a bewildering number of builds.

Randy leads the continuing development of Jump. He spoke with the Java Mobility site in a phone conversation from Tira's headquarters in Toronto.

Brian Christeson: We all set to go?

Randy Busch: I am. [Sighs]

BC: [Laughs] Don't sigh. It'll be okay - really.

RB: [Laughs]

BC: You're Vice President of Products for Tira Wireless?

RB: Just "VP Products."

BC: How long have you been in that position?

RB: For about a year.

BC: What were you doing at Tira before that?

RB: I was VP Product Marketing here, responsible for product management as well as the product-specific marketing.

BC: What did you do before you joined Tira?

RB: Before Tira, I was with a venture capital company called Brightspark for a while. Tira was actually founded inside that organization, and I came over to join here. Prior to that I've done a number of things with different organizations, primarily Internet-based customer relationship management solutions, and then before that I was in electronic forms and workflow management.

BC: That background seems to fit in with what I've learned about the Jump Product Suite so far - that a big part of that is management of process workflow.

RB: Absolutely.

BC: Switching to Tira Wireless now: What's your "elevator pitch"? How would you summarize what your mission in the world is?

RB: We're here to bridge the gap between development of an original piece of content and deploying it across multiple operators on multiple handsets.

BC: I've found that interesting because, like many people, I've had an idea for a good application in mind, and just been totally daunted by the sheer complexity of bringing it to such a complex market.

RB: I don't think people who are new to the market understand that complexity, and they often get surprised by it.

Publishers like JAMDAT and Gameloft have been around for a long time, and they've built some internal experience and tools to help them deploy their applications and understand the market today. EA obviously saw a lot of value in understanding this marketplace, enough that they paid a pretty good premium to buy JAMDAT.

That's your only choice: Either you adopt a technology that builds a lot of this intelligence in, or you buy somebody, a company or an organization that already has it. But for you to invest two or three years to get on top of the industry the way JAMDAT or Gameloft or somebody like that has - it's a long time to become successful and fully understand this market.

We're trying to level the playing field, on the deployment side of things anyway, for new entrants into this market, to give them access to the knowledge and the experience and the understanding of the market that people who've been around for a few years have. We do that in the Jump platform by building the business and process flows into a solution for our customers.

BC: Would you describe Jump as a turnkey system? You install Jump and all of a sudden you can just build the adaptations of your app, and to a great extent ignore the worst hassles of deployment to so many platforms?

RB: I wouldn't say it's gotten to that point. It's not "turn the switch and everything's done," but I guess it's a supply-chain management kind of solution.

When the market's young and there's not a whole lot of content, you can get by using pick-and-chisel kinds of tools: spreadsheets, whiteboards, things like that. As the market matures and it becomes a real business, you need to start adopting tools that help you manage your business. At that point, rather than having a team of people internally who build your own solution for you, you go license things, like SAP. You license different applications to help you with common business processes. And that's really what the kind of thing Tira does is becoming in the mobile space. It's becoming a necessary part of the business. Deployment is a process that really can be automated.

BC: Just looking at meeting all those certification requirements imposed by operators and device makers alone, having help with that...

RB: Yeah, that's the thing. To have every organization that wants to be in this business do this, go out and build a team the size of Tira, essentially, to stay on top of this stuff? It just doesn't make sense. What you want is to be able to productize it, to embed it in a set of processes that you can just license and use.

BC: I cribbed from one of your media updates some key facts about Tira. I'd like to run through them quickly and then ask whether you want to add anything.

RB: Sure, go ahead.

BC: "Provider of mobile content deployment solutions, selling to mobile content publishers and mobile operators. More than 90 employees based in Toronto, with sales offices in Los Angeles and London..." Here's one you can explain to me: "Compelling software as a service with a scalable transaction-based financial model."

RB: What we mean there is, it's more like - are you familiar with Salesforce.com?

BC: No, I'm not.

RB: Salesforce.com is a customer relations management solution. In the past you'd license your CRM software. You'd install it on your own servers, and you'd pay continuing maintenance year after year, and you'd do your upgrades, and so on. Salesforce.com came into this market and said, "Okay, rather than you installing the CRM software and having your own IT guys operate it, we'll host the servers, and essentially you just subscribe to the service."

Our deployment management solution is like that. We did the same kind of thing in this environment because the knowledge about devices and about operators and operator requirements is changing constantly, and growing constantly. To update different systems deployed inside organizations all over the world becomes very difficult to do. You never know that you've got the latest version, of a plug-in for a specific device, for example. By hosting the knowledgebase at Tira, we can keep it fresh, so that, minute by minute, you always have access to the latest and greatest information. It's software as a service, essentially, as opposed to installing the software in your own environment. We run it from our environment and you get access to it.

BC: And people pay by transaction, then?

RB: It's a user-based subscription model, and then a transaction if they're using the adaptation.

BC: I see. A little like buying milk instead of keeping a cow.

RB: Yeah, to some extent.

BC: The last bullet I'm looking at in this media update is "Customers include more than 40 of the leading mobile-content players - and it mentions specifically THQ, Sega, Disney Mobile, I-play, Warner, and others. Those are the content players. I assume you have a similar list of network operators that are clients?

RB: We have a couple of operators that are actually clients. We run certification programs for T-Mobile in the US, and for Telus in Canada. But we have a lot of relationships with other operators as well, so that we can get information about the devices, and about their programs. I wouldn't call them customers, though. They're more like partners. They're providing us with information, as opposed to us licensing them access to our platform.

BC: I see. All right, any points you'd like to add to the list: key facts about Tira Wireless?

RB: I think it's sounding to me to be a pretty complete list.

BC: Well, you should be happy with it, because it's your list.

RB: [Laughs] That's true, I guess! If we hadn't thought about it before we gave it to you, shame on us.

BC: Sun tends to be very formal about product designations. Does Tira insist on "the Jump Product Suite," with caps on the P and the S, or can we just say "Jump"?

RB: Formally, the whole name is capitalized, but we often shorten that to Jump - and when we talk about people who execute the transactions or who are doing the adaptations in Jump, we refer to them as "Jumpers."

BC: [Laughs]

RB: [Laughs] Which can be positive or negative, I guess.

BC: My key question, and I'm sure I've phrased this in a way that will give you ample room to take off, is: What do you believe is the biggest challenge facing developers of mobile content today?

RB: [Takes a deep breath] Okay, it really is understanding what it takes to deploy your content on a broad scale. I don't think people, certainly people new to the business, understand that so many of these devices - I won't say every device, but certainly a broad majority of the devices that you want to get onto - are different. So your content needs to be adapted to many different devices.

And it's not even as simple as just saying, for instance, "I need a version for the Samsung N400." Actually you need a version for the Samsung N400 on Sprint, and you need a different version for the Samsung N400 on Bell Mobility, and so on.

So there are very specific device issues you need to understand -and it's not just what's documented by the manufacturers. If you're actually deploying content on these devices, you need to understand their undocumented issues, things we've learned through experience. For example, you need to understand that, on a Sony Ericsson T610, the draw-art command in an application will bring the processor to its knees - and then you need to understand how to deal with that problem. If you've never ported to that device before, you're learning about it through the school of hard knocks. The Motorola V3oo has issues that are particular to that device - that family of devices - that you need to know about: how it handles memory, how it deals with sound. And these aren't documented in any spec sheet. You need to go and experience them and understand how to deal with them.

BC: Or - work with somebody who has.

RB: Exactly. Or adopt technology, and here's where we believe we add a lot of value. We create our Jump platform, but in that we also include plug-ins for specific devices, where we keep all these specific idosyncracies about these devices. And it's not just the knowledge about the devices. It's also how to fix them. And in a good majority of those cases, how to do it in an automated fashion, using our platform.

Now besides device differences you also face network differences. You need to understand, "Fine. I can get my content on onto a device. Now I need to understand how I submit this content to the channel" - whether it be a portal or an operator directly. One operator may want the JAD and JAR you submit named a very specific way. They may want the manifest to contain very particular information, different from what another operator demands. That's a very simple high-level difference.

There may be other differences. For example, Vodafone has three waves of devices that you need to support. When you first submit content to Vodafone, you need to support all the devices in the first wave. You also need to support seven or eight languages. You need to submit three screen shots, and an AVI file, and a text description for marketing purposes as well. And you need to understand and know about all this information just to have a successful submission.

Plus, you need to understand the operator's certification requirements, or they won't even put it up on their deck, and those change from operator to operator: specific requirements, and their testing and certification programs. Some have a very full certification program that you need to pass. Others have a much lighter touch. Some use Java Verified, while some have their own certification organizations that run different programs. You need to understand what these are - and what limitations they place on content. Some will take games that have bombs or blood in them, for example; other operators won't.

So you need to understand all this before you go through the expense of submitting, and then finding out you have to change your application, submit again - and in many cases, pay a cost to do that.

BC: You mentioned "three waves of content." What did you mean by that?

RB: What I mean is... when you submit to Vodafone? They have 40 or 50 different devices they make available to their subscribers. Some of these they don't even make available any more - but they want to continue providing content to customers who still have these devices. So they chunk off in waves the devices you need to support. In the first wave there are 16 or 20 devices - what I guess they would call their high-volume platforms - they want you to have your content on.

They want you to submit all that stuff for all devices in the first wave at the same time. because they want to deal with all the content at once, rather than dribs and drabs coming in. Then, they have a second wave, and as soon as you can support all the devices they need you to support in that second wave, you can submit another package of content to them. They don't want you to submit for one device at a time. It's really all about their submission process, so that they can manage it more effectively.

BC: If you're worried about your own ability to keep up with all that, can you say, "Well, I only want to support the devices in the first wave," or do you have to commit to all three?

RB: Again, it varies from operator to operator. For one of the operators in China you actually have to commit to time frames to submit to their different waves of devices. If you support only X number of devices, some operators will say, "Okay, then we won't do any marketing for you," or "We won't give your application premium deck placement." And some just won't accept it at all.

BC: That's scary right by itself.

RB: Yeah, well it's a big issue for the operators, if you think about it, because they get the phone calls, not the publisher or developer of the content. It happened early on with an application in North America, where - I believe it was on a Motorola T720 device - one of the operators came out with an exclusive game, and they promoted the heck out of it. Then they started getting all kinds of calls into their call center, saying, "I've got a Nokia 7210. Why can't I get that game too?" Their promotion just completely backfired on them, and they had to try to get that game onto these other devices very quickly.

They just want to make sure they've got as broad a coverage as they can, so that they don't get those calls - certainly if they're going to market the content.

BC: The bigger the promotion, the bigger the number of complaints you're going to get from people who say "I want it too!"

RB: Yeah, exactly.

BC: In a presentation made in 2005, Tira's VP of Product Marketing, Wayne Seifried, reported that game revenues in Europe are nearly triple what they are in North America. What do you see causing the difference?

RB: I think that that's starting to change, but I think Europeans and certainly people in Japan and Korea are more used to walking around with that phone held in front of them, typing on them while looking at the keyboard, whereas North Americans still tend to hold them to their heads and talk into them. It's a bit of a cultural thing. We're more of a PC-connected, Internet kind of society, whereas I think they moved to mobile sooner than we did.

BC: Wayne mentioned that North America has three network types and two mobile game platforms. I inferred that, by contrast, in Europe there's only one of each?

RB: That's true. GSM is the predominant network type in Europe, and there are different rules there as well. The operators aren't allowed the same kind of control they have in North America. They're actually not allowed to lock down things, so developers and publishers have a lot more flexibility in Europe than they do in North America.

In North America the operators have a lot more control over their networks and who can deploy content on them. In Europe, you'll find there's a lot more available simply because you can go off-portal. You don't have to get content for your Vodafone device from Vodafone. There are Jambo Mobiles and all kinds of other places you can go and get mobile content.

A single network certainly makes a big difference in the compatibility of the phones. There are also many languages over there, which complicates things somewhat, but -

BC: Yeah, but they seem to be getting around that, if that volume difference is any indication.

RB: Well, as I say: I think they were using SMS much more broadly than we were in the first place, so they were already looking at the screen. They were already used to that whole data aspect of things, and North America was certainly behind the curve on some of the data programs that were rolled out.

BC: So they just got a head start, and got used to being ahead.

RB: Yep.

BC: Again I'm quoting one of your company's presentations; you say you "sell to mobile content publishers and mobile operators." How do you serve those two kinds of players differently?

RB: To the content providers we do two things: We provide a service to help them get their content ready for deployment or we license technology, and that's really the biggest focus of the business: to create the technology and the process and the knowledgebase that allow these organizations to manage and control their own deployment processes. The workflow, the asset management, as well as the adaptation of content.

BC: I see. And mobile operators?

RB: For mobile operators we do some of that. For example, when Telus launched their first program, we adapted a bunch of content from the big publishers for them, for their specific devices, so they had all the content they needed when they launched their Java program.

BC: Wow. So they could hit the ground with a...

RB: ...good bunch of content across all the devices they were launching. We also provide the certification services, as I mentioned, for T-Mobile and Telus.

We provide feedback on devices and Java implementations to a number of the operators that we work with as well. And that's just something we offer to them to get access to their devices and information about their programs.

BC: Do you work directly with developers of mobile content or only with publishers and operators?

RB: We do work with the developers, but primarily through their publishers. As the content's being created for a publisher, or if a developer is publishing the content themselves, then we work directly with them. We also, though, have a site where we provide information about how to build portable applications, the Tira Developer Network. We have information there about devices, and a forum where we communicate with developers about how to build good portable applications - what to avoid, what not to avoid. And through that we make available guidelines about how to go and build a good portable application. That's something we've been speaking about at JavaOne as well, for the last three years I think.

BC: Thinking now specifically about each of the services you make available, for example the Jump Workflow Manager, can you give me a capsule description of each of those?

RB: Sure. In the Jump Product Suite there are essentially three broad areas of functionality.

Figure 1: The Jump Product Suite Vision

At the lower level we have the Jump Transformation Engine, where we keep information about devices and the operators and their requirements. That's the knowledgebase that gets updated on a regular basis, and also has the technology to perform the automation in the adaptation process. Things we can automate are handled through the Jump Transformation Engine and the plug-ins and the device knowledge we have specifically.

On top of that we have a client, which is essentially a plug-in to the Eclipse IDE, which we call our Jump Developer Desktop. That's where the engineers actually execute the Jump process to do the adaptation - adapting a basic or existing program to run well on a new device-network combination. It includes a suite of tools that help engineers optimize the application as needed. We do that through a series of actions we've created for a number of different things, like managing sound, managing memory, things like that. Then we also have in there our Jump Adjust Library - we call it JAL - for very specifically fine-tuning apps and writing code, if you need to, during the adaptation process.

BC: That late in the process?

RB: Yeah, and just so you understand... all the changes we're making to a Java applet are done on the bytecode. We're not actually working with source code. The JAL allows us to make changes we need to at the bytecode level.

Then there's the workflow manager, and asset management. We call that the Jump Workflow Manager. In it we manage all the assets you need, for example your reference build of an application, source code if it's needed, any specific documentation, all the marketing assets you want to include when you submit your application. That's all tracked in the workflow manager, stored there and managed there.

Along with managing assets, the workflow manager also helps you understand what you need, to get to the channels you want to get to. For example, if you decide you want to do a North American and European launch of a specific title? What you can do through our workflow manager is essentially to create a work order. By creating that work order we help you map and understand, first of all, what reference versions of your content you'll need to get to all the devices you want to get to. Do you need a mid-range and a high-end? Do you need a mid-range, low-end, and high-end as your reference builds? What builds do you need as reference content; reference versions of your application?

We also help you understand how all those devices relate, that you intend to support. For example, if you want to go to North America and Europe, we understand what the devices are on each of those operator channels or other channels you may want to go to, and we understand the relationships between the devices.

We understand that maybe the Motorola V300 is the same on Vodafone and O2 and Cingular, but there are other devices that aren't. We can map all that out for you, so you're not duplicating your adaptation process, you're not building more versions for the Motorola V300 than you have to. We also map that the build for the Motorola V300 works on about eight or ten other devices, so that you don't have to go and regenerate those builds. You may have to package them differently for a particular operator but you don't necessarily have to rebuild them all. We map all those relationships for you, so you know that if you've already got a build for the V300, it'll work on all these other builds for all these other operators.

BC: I assume the workflow manager or the customer is tapping into the knowledgebase at that point.

RB: Absolutely. At that point you're using the knowledgebase. Then when you've built the work order, that list of all those builds you need to create, we allow you to assign those as tasks to users of the system, so you can start the actual workflow: send it off to an engineer who does the actual adaptation process. Then it moves on to a QA engineer. If there are issues, you can throw it back to an adaptation engineer, back through QA, on to certification - we just map that whole workflow for you, automating the workflow process. And, obviously, through all that, reporting, so you can always see what the status of all your projects is, and know exactly where they are.

BC: Terrific. And the Automated Verification Server, and the OTA servers?

RB: The Automated Verification Server, what it does is, for specific devices, it does the first level of checks before any manual QA is performed - costly manual QA. It runs through a whole series of tests, MIDP compliance and things like that, to make sure that the application will at least work at the base functionality, and that you're not using any illegal APIs, and everything complies with MIDP. Some operator compliance can be dealt with there also, as well as some device-specific tests that we can run. Once an adaptation passes all that, then we can allocate it to a QA person to do the rest of the functional testing.

BC: And that would be the point at which they'd load applications over the air from your server?

RB: Correct. They can load it into all the different emulators as well. You can run the application in an emulator first, and then download to an actual device from the OTA server. They can also load it directly into a device. The emulators aren't perfect, so we certainly recommend that engineers at least load the application on a device and test it.

BC: Again, something I cribbed from a Tira presentation: Principal benefits of JPS include: "better quality and consistent content versions" - boy, could I see that being a huge benefit right by itself! - "increased control over deployment process and assets, continuous access to critical information and know-how, and faster deployment and optimization - "

RB: That's something I should mention. When you're going through the process of adaptation, we have a feature we call "mentor in a box." [BC laughs] When you're working on a build for a specific device, we can, in one of the windows inside Eclipse, actually have our knowledgebase sitting there. All the information that's available from that knowledgebase is context-sensitive, so it's specific to the target device. If you're working on, say, a Motorola V300, all the information that's in this pane of your IDE is specifically about the Motorola V300. If you're actually on an action that pertains to heap issues, the "mentor in a box" window has all the relevant information right there, the topics from the knowledgebase that specifically relate to dealing with heap issues on that specific device.

It's all right there at your fingertips, helping you get through the process as quickly as possible.

BC: You mentioned the name Eclipse... this is the IDE developed by IBM?

RB: Yeah. They've put it out into the open source community now, so it's a free download.

We thought we'd have to support a broad range of different IDEs, but it turns out that the vast majority of people we spoke to were either using Eclipse or willing to move to it. And y'know what? They've done a really nice job. It's very popular, especially in this mobile space.

BC: When did Jump become a released product?

RB: Q1 of 2005. We had been using it internally for a while as a server, and to drive our services organization, when we were writing it for deployment.

BC: Is that where you were - you had consulting clients and you developed the product to help you meet their needs, and then you realized, "Hey, we've got something we can sell, or license"?

RB: Well, we really are a bunch of product people here, so from the start we were out to build a product. Building the product gave us the experiential knowledge we needed to put into our knowledgebase and to build our structures, while we were providing services - and we continue to provide services today to make sure that we can keep our platforms smart.

What we do is we take on the difficult projects, the first 3D projects, things like that, so we can take that knowledge from our services organization. Essentially we use them as a lab, and bring that knowledge back into the product. We're not building a huge service organization to compete with our customers, or with the ecosystem that we're building out there using Jump, but we do have an organization that we continue to maintain at about the same size it is now, to work as a lab - as I say, to keep our product smart.

And that's another thing I should mention, about even the workflow manager, and the asset management side of things: It really is built to work with a whole ecosystem. For example, if I'm Disney, and two or three other shops that are helping me with my adaptation and porting are on the Jump platform as well, I can actually assign the tasks directly to them, and manage the tasks, view them, and see what's happening inside my own environment. I have complete control over the process, complete visibility into the process and where we're at.

Some of the problems we were getting were the same ones our developers and publishers were reporting. They were passing work off to be done in China or India or some of these lower-cost environments, but they had no visibility into how the work was going. They just didn't know when they were going to get it back. It became particularly important if, for example, a movie launch was coming up, and they wanted all their content to be ready in time for the launch. They were finding they were late, they were missing dates - because they had no visibility.

BC: No sense of the progress being made - and the workflow manager gives you a window into all that.

RB: Yeah, and the ability to move a project from one place to another easily. Let's say, for example, your Indian shop wasn't able to get hold of a device, but somebody in North America could. You could actually move that project from one shop to another, or swap projects around.

BC: An increasingly important capability in a world that's getting to be more and more global.

RB: Yeah, and on top of that, there's the asset management. Take a look at JAMDAT. When they launched their version of Tetris, they had a thousand different versions of that application. To manage all those assets so you can do a global launch of that application becomes a very complex challenge.

You wouldn't believe how many times - even with some of these big organizations that we work with, who have been publishing content for consoles and PCs for a long time - how often we get a call saying, "You remember that build you sent me a couple months ago for this?" or "Did you send me this stuff last week?" They have no idea. They can't keep track of all these assets because they're trying to store them in directory structures, or in makeshift systems, in their own offices, and they're losing track of these things. If we can get an organization on Jump, it can track all those assets. It knows exactly where they are and can go get them any time it wants - and more importantly, it knows how they relate to other devices in the market and from other operators, so it doesn't have to re-create them unnecessarily.

BC: Sounds fantastic. Now that the Jump suite is an available product, how does your client list for services change, or does it still maintain that kind of lab -

RB: Yeah, it still maintains the lab function, but, to be honest, our services often generate licensing business as well. When we do services work for customers they're quite impressed with the results, which obviously gives us the opportunity to tell them about the Jump platform, but we actually can give them a view into what we're doing for them in particular. We give them a seat of the workflow manager, so they can see what our services group is, and how it's performing. When they see that it,s just kinda like "Yeah! I gotta have myself one of those." They become licensing customers, or subscribing customers. Our services work really is a lead generator for the product side of the house.

BC: That's interesting. I could see marketing a product like that and then selling the services as an added value - but it really turns out to be the opposite here: You market the product, but the service side drives customers to it.

RB: Yeah, and Jump gives them a bit more control: They have their own engineers and their own people working on it. But they then can use us for overflow as well. They don't have to staff for spikes and valleys. They can staff at a reasonable level, where they keep their own people busy all the time, and when they get to a spike they can call on us or somebody else in our ecosystem that's using Jump, and say, "Okay, here's the reference build, it's already set in Jump. Pump them out for me."

BC: Terrific. What kinds of content do your clients deploy? There seems to be a large emphasis on games.

RB: Yeah, from the application side of things, games certainly constitute the largest group right now. They're the most popular, but we're starting to see more and more of that change. There are more business-productivity and lifestyle kinds of applications, not just games and entertainment anymore. So it's starting, but games came first.

BC: Well, the very people who get entranced by the gadgets are the people who love games anyway.

RB: Yeah, exactly.

BC: So it was a natural way for everybody to start having some fun and making some money.

RB: Right, and I think most new technology markets are probably generally driven by pornography and gaming or entertainment. [Laughs]

BC: [Laughs]

RB: We stuck with the gaming and entertainment side.

BC: That's not unique to this technology. If you go back to the beginning of the automobile industry, a lot of it didn't have to do with getting from here to there. It had to do with "Wow, a new toy to play with!"

RB: Right.

BC: So you see a growing future for more - for want of a better word - serious applications?

RB: Oh, absolutely. And just think of what the marketing potential of these devices is. Unlike a TV or a PC that's attached to the Internet, that you can take into a Starbuck's and get connectivity or you have to plug in somewhere, you've got this device with you everywhere you go. If people are starting to watch less TV, and starting to use their PCs on the Internet less than they used to - which all the studies are saying - marketers are going to need to find new ways to get out to consumers through this new vehicle. It's not going to be as spam-based as I think the Internet and email is. There's going be a lot more opt-in types of applications, or sponsored applications, that you know the Coca-Colas and folks like them are going to want to get into. Or even - suppose you're a Starbucks lover. You may decide you want to opt into some kind of Starbucks program that - once you get location-based services - allows them to contact you at certain points of the day if you happen to be within X distance from a Starbucks.

BC: "Hey, come in for a cup of coffee!"

RB: Yeah, "Here's a 50-cent discount or whatever. Come on in!"

BC: [Laughs] Show your screen to the person at the counter. "I just got this 50% discount." "Oh, certainly, sir, click-click-click. Here, hold your handheld up to our cash register."

RB: Well, yeah, exactly. A bar code comes up on your display, and they run it through the scanner and away you go."

You know we're projecting out, but that's certainly the kind of thing we can see happening in this market. The ad agencies and things are going to have to figure out how to get involved, and how to help their customers take advantage of these new devices.

This is an exciting market. It's certainly growing, and I'm really looking forward to the future. I see great things happening, and I can hardly wait.

It was interesting - I was at a mobile conference put on by Gartner. One of the guys from Gartner got up and, essentially, said, "Okay, all you IT folks out there? One thing you're going to have to understand about this mobile market is that your management's going to be coming to you, and they're going to be saying, 'Y'know, this application I've got on my PC right now, this functionality? I want it on my mobile device?' And, by the way, they're not going to say, 'I just want it on this mobile device?' Theyre going to want it on two or three mobile devices, because they'll have one device they use during the week, in their normal business, but they'll have a different device they take to the cottage or wherever with them on the weekend, and they'll want the application on that device as well." He went on to say, "Get ready for this wave of mobile and what you're going to need to support in order to make it happen for your team."

BC: I'm going to shift gears here. While our readers are interested in the mobile computing community as a whole, naturally enough our emphasis is on the two Java mobility platforms, ME and Java Card. How important is Java technology to your business model?

RB: Oh, it's critical. Everything we do is - I mean our systems are all built on the Java platform. But the content that we're adopting is all Java-based right now as well, and it's certainly the most ubiquitous platform. You take a look at the number of programs that have been rolled out by operators and the number of devices that support Java and it's huge. It's a market you can't ignore.

That being said, we are developing our platform to support other types of assets: ringtones, wallpapers, video, things like that as well.

BC: You support developers working on both the Java and BREW platforms.

RB: Correct. BREW we're just in the process of launching, so that's just new. Java is where we were, even as a services organization, for the last number of years.

BC: Why the expansion into BREW? Is that just, "Well, there's a market"?

RB: Well, yes, there's a market, but it really didn't come down to "Okay, how much money can we make off BREW?" It was more an issue of "How difficult is it for our customers who want to deploy content if they can't manage BREW in our environments?" If they have to buy one system to manage their BREW, and another to manage their Java, and another to manage their music assets, it becomes a real pain in the butt for them. If they're multi-content providers to the mobile space, we really believe we need to offer them a system that can manage all that content for them.

BC: You think of BREW and Java as platforms for applications, and then ringtones and wallpaper and things like that as separate from applications, but all of them can be managed through a single workflow manager?

RB: Correct.

BC: Do you assist developers working on the Java Card platform as well as Java ME?

RB: It's primarily Java ME.

BC: Okay, [laughs] after you've mentioned some of the limitations that you run into on phones running Java ME, getting it all down to something that can run on a smart card sounds like "Well, okay, that's one we'll tackle a little later, when the cards get bigger."

RB: [Chuckles] Yeah. A little early yet.

BC: Do you see both Java and BREW continuing to grow? Or do you see one replacing the other, eventually, down the road?

RB: I think for the next year to two, they're - I think they're both growing. It'll be interesting to see what happens. Speculationwise, now that QUALCOMM has acquired ELATA, and they've talked about wanting to provide other types of content... I'm not exactly sure what that means, or where that's going to go yet. We'll have to see what happens, but certainly Java has the lion's share of momentum and support in the market.

BC: Okay, shifting gears again: What do you see your own role at Tira to be?

RB: To drive the vision for the product. Making sure that we continue to meet and exceed the expectations of our customers and users.

BC: What was your role in the development of the Jump suite?

RB: Primarily - well, managing the teams that are building the product, but setting the vision for it, and working with people here, obviously, to do that. And then making sure that we're staffed appropriately to deliver that, and managing the time frames for the delivery, and the specifications for what that product needs to be. So the product management and development people all report up through me.

BC: What do you use mobile technology for?

RB: I'm not a hardcore action gamer. I like the different puzzle kinds of games, so I'll absolutely use those. I've got one little shooter game, but for the most part I prefer the more puzzle-oriented games.

BC: Yeah, I'm the same way. I tend to like games like Sudoku. On the desktop I'm a Myst junkie.

RB: Oh, are you? I guess I'm just not a big console gamer or PC gamer. I play games with my children but I'm more of a puzzle guy myself.

BC: Well, I think the thing that attracted me about the Myst series is that it's puzzles, but then it's in this really neat environment...

RB: That's true, very true.

BC: ...and for that I really like my 21-inch monitor, so I can see it all.

RB: [Laughs] Understood. Yeah. Very different if you try to put that onto a little tiny screen. That could be an issue for some people right now, although... some of the games that are coming out now? I am very, very impressed with the graphics and what people are doing with them now.

BC: Yeah, I'm dazzled by what people can do on such a small screen.

RB: Considering where they started, with rip-offs of Frogger and Tetris and stuff like that a couple of years ago, to where they are today, it's very impressive.

BC: What do you like to do when you get away from the office, besides sneak off and solve puzzles?

RB: I'm a sports nut. I like to play hockey, and I coach my son's team as well. I don't get to do it enough, but I really enjoy sailing. We've got a little Laser at the cottage that I love to get out on. My son has a blast on it.

BC: Oh, yeah! I sailed a Laser one time. A bit tricky when it's gusty, but fun to drive.

RB: Yeah, they're a lot of fun. I haven't got the stamina my son does. He's ten now, but he can go out for just hours.

BC: And in a boat like a Laser, that's hours of really sailing all the time. I like a slightly bigger boat, where you can kick back occasionally, put your foot on the tiller, and pop open a brew.

RB: [Laughs] Right.

BC: Whoops! I'm Java, not BREW.

RB: [Laughs]

BC: Pour a cup of Java.

RB: Yeah, there y'go.