|
|||
|
|||
Oracle Clears Path for Mobile Enterprise
Posted August 22, 2002
The promise of wireless access to enterprise applications might be compelling, but the path to that future is littered with failed attempts. Oracle's mobile development chief, Jacob Christfort, thinks he knows why. Companies have sought to extend their existing applications to wireless devices instead of building new applications that are designed for mobility from the ground up. Java Pro Editorial Director Dan Ruby and FTPOnline Editor-in-Chief Tim Haight spoke with Christfort, chief technology officer for Oracle Mobile Products and Services, about development strategies for the wireless enterprise. Business Models and Standards Christfort: We've seen a significant change in the interest level in enterprises. It seems that enterprises are increasingly talking about how to go about it rather than whether to do so. That's also supported by recent research, such as a Yankee Group report showing that enterprises are getting smarter about mobile applications. E-mail was no longer perceived as the single most valuable application area. Now, the most important desire is access to legacy databases. Q: This is not the first time there's been a focus on wireless data for the enterprise, and earlier efforts turned out to be premature. Why is it more real this time around? Christfort: Wireless Access Protocol (WAP) was an example of the hype we had a couple years ago. I think the biggest problem with WAP was that it was focused on the consumer. You have to be realistic about a value proposition that would make a consumer spend $300 on a phone, plus $50 a month in service fees. The enterprise is where you're going to see wireless take off. All the big companies in Silicon Valley were built with money coming from business use of computers, and only later did the technology become sufficiently mature and low-cost that you could start selling it to consumers. I'd argue that wireless technology is more appropriate for high-value applications in businesses and the military. We have a lot of military customers who have extremely high-value applications for mobile networks and mobile applications. Q: That certainly was true of computing, though not necessarily of the Internet wave. If you're right, why are the carriers and handset manufacturers and everybody else focused on ring tones and games as opposed to enterprise applications? Christfort: What has been successful in the Web-consumer space are things like ring tones and short messages—capabilities built into the handset. There was no incremental cost to the consumer. That differs from the case for WAP, which had huge incremental costs. The next generation of services rolled out will be much more like SMS. Enter multimedia messaging (MMS), which I expect will be offered as standard services. Consumers will pay for the air time, but they won't have to buy new equipment or a fixed service. This is the reason that companies like OmniSky failed with some of their services. They had this high-fee, high-equipment model, and they tried to sell it to consumers. But consumers don't invest, as a basic rule. On the other hand, enterprises are used to investing. Q: Do you think the trend toward the real-time enterprise that we've seen in software and services is going to find a reflection in the wireless market? Christfort: The nature of the investments required is such that it makes sense for enterprises, because there's value associated with making that investment. But I don't think it's yet appropriate for consumers to make that kind of investment. It's easier to attract consumers when you've built infrastructure. Once all the operators have put in 3G networks and those costs are sunk, it's going to be attractive and simple for them to turn around and go to consumers with a price point of zero and then just get consumer use through extra air time, as well as advertising and one-to-one marketing revenues. That's more natural when you have a network with sunk costs and a lot of excess capacity. Right now, you have very little excess capacity, and you need to pour money into building capacity. To do so, you have to find a funding source, and you can't fund it through consumers. But you can fund it through the enterprise and then turn around and do the consumer play. Q: But enterprise applications are more demanding regarding security and quality of service. Christfort: Yes, mobile is different from previous types of computing in that you need public network collaboration. In the mobile world, even if you're an enterprise, you're going to have employees using a variety of different devices. They're going to be operating through networks you don't own and you don't control, and they're going to make their way in through the firewall and run against your service. That means you have other players that must be synchronized with your IT strategy, which is not something CIOs are used to. CIOs are used to buying equipment and software and hiring people to install and operate it. Here, you have to coordinate with different players to maintain a certain level of security and service. That's complex, and it means that IT vendors have to work together with operators to create preconfigured components that enterprises can manage effectively. It's what I call the "mobile ecosystem." Q: Cross-industry consortiums are trying to address these issues. How significant is the newly established Open Mobile Alliance (OMA)? Christfort: I think it's a milestone. To make all this work, you have to mix public and private networks, coordinate the device manufacturers, and tie in the back-end enterprise and the software and services that run there. It's all kinds of devices with all kinds of different operators in different regions, which must be synchronized into what we call a mobile ecosystem. The problem is that standardization has not followed that principle. Standardization has been W3C focusing on the IT-vendor space and things that run in the J2EE server inside the firewall. You've had the WAP people working on that specification, but completely unsynchronized. And you had people in the device-manufacturing space, like Palm and Mitsubishi, doing their stuff, also completely unsynchronized. When you started gluing all of them together, it was problematic. With the OMA, we are creating an architecture framework that enables us to consider how these standards, all meaningful in different areas, should be synchronized. The goal is an end-to-end architecture that would allow an enterprise to buy IT from an IT vendor that's implementing on it, network services from an operator that's implementing on it, and devices from a manufacturer that's implementing on it, and have them always work together so you get all the benefits we talk about. That is difficult to do today. Q: And it did pull together a coalition of other groups, such as WAP, that are now part of the OMA. Christfort: Not only are we making sure these different standards are connected and can interoperate, but we also discover in that process—no surprise—that there are complete redundancies, work aimed at solving the same problem done in different forums and a different context. So we can eliminate redundancies as we scoop up discrete standards into the OMA framework. WAP was one of the first. We have memorandums of understanding with SyncML, as well as with Wireless Village in the messaging area, and those are on their way into the OMA framework. It's going to be an interesting effort. The decisions are made democratically, so we'll have long discussions of everything, but we are getting to the heart of problems we could never address before. Q: But the OMA is still establishing its workgroup structure, and after that there will be an agenda in each workgroup to define the standards-making process. We're probably talking about several years here. Christfort: Yes, but this does not necessarily stall work that's already going on. It's not that you can't wirelessly enable your enterprise. What we're addressing with the OMA are the more advanced features—things like m-commerce and micropayments—that have been sticky issues. Basic enterprise access to e-mail or doing an inventory look-up from a two-way pager are things that can be done today. Wireless Enterprise Applications Christfort: People often think about just mobile-enabling their existing applications, so you can access them from a mobile device. A lot of companies sell tools and middleware that lets you do that. You have things like AvantGo, which scrapes pages and caches them for access by Palm devices. But that sort of defeats its own purpose, because when you look at enterprise applications, mobility is not just about accessing existing screens and applications from a new device; it's actually about new business processes. My favorite example is the inventory application, which typically has been operated by the office clerk. The warehouse guy with a mobile device is a completely different user from the clerk. So extending the clerk's application to a mobile device and giving it to the warehouse guy is not going to work. You have to think about enabling a new part of a business process that was manual before. You need to look at the warehouse guy's clipboard, not the clerk's desktop. Q: In addition to inventory and warehousing, what other areas are promising for mobile applications? Christfort: I would argue that there are virtually no businesses or industries that don't have mobile business processes. Even with ERP and strictly back-end systems, you're going to find activities that are application areas for mobile. With accounting, it is expense reporting, because nobody wants to do expense reports after the fact. Field service is an application that's almost 100-percent mobile. Applications like that are so blatantly mobile that eventually they won't even have back-end parts. But the back-end systems will also have mobile components. So in my view, it's not helpful to ask which applications have mobile aspects, because the answer is: every single application. Let's try to do the reverse and ask what applications should not be mobile. Can you think of any? Q: Maybe not, but is there a distinction between applications that require occasional connectivity vs. constant connectivity? If you're going to do expense reports, you're probably not going to do them three times a day. You might do them when you get back to your hotel. Christfort: You can argue that you could organize your work to do it in bulk using a desktop. It's a little like batch processing vs. real-time manufacturing. Batch processing is OK if you don't have advanced technology. But any manufacturing guru will tell you that the optimal speed and quality of production occurs when you are able to synchronize your process such that everything occurs in real time. That's because you're operating on the most accurate information, you don't do redundant actions, and you don't carry a lot of inventory. Q: So when you leave a restaurant, you could put in the check amount and not have to enter it again on a separate expense report. Christfort: Actually, the restaurant would present the bill through Bluetooth. You would accept it and pay with your credit card, and it would already be in general ledger through an authentication point. Q: That would be cool, but is it compelling for corporations? In the current climate, people are looking for hard return on investment. Christfort: We have to remember that the business benefits are sweeping and compelling, and businesses are trying to understand that. The efficiency improvements from back-end automation are starting to taper off, so people are increasingly looking at this untapped opportunity to improve employees' productivity when they are away from their desks. I saw a study that showed that 40 percent of employee hours in the average business is not spent at a desk. That means if you want to make your enterprise more responsive and make better decisions faster at low cost, which is what it all whittles down to, then mobile is increasingly seen as the only technology that can get you further ahead of your competition. A few years ago, e-mail was not pervasive in many industries. Large companies that ran e-mail had an advantage over competitors who didn't. But today, every business runs on e-mail, and there's a parity of competitiveness around decision-making. You have to jump to the next thing to stay ahead. Companies that went to e-mail first might be the same companies that use mobile access first. Oracle Product Strategies Christfort: Our Oracle9i application server has built in something called the Wireless Option. It's not an add-on component, but an integral part of the product. It's an option in terms of licensing; you pay for it if you use it. It's important that the Wireless Option is integrated into our application server. In the beginning of wireless, people were selling wireless middleware boxes and servers as separate things, but we think these should be part of an application server's functions. And most analysts agree that from a technology-strategy perspective, it's the right way to go. That's one reason we've gone, in two years, from competing with 50 companies to competing with just a handful. It's almost impossible now to sell a wireless-only middleware box. Basically, all of those companies are either out of business or heading there. Q: So the new competitive space is the J2EE app server market? According to analysts, Oracle has made significant progress in that market. Christfort: We made a determination starting several years ago that this was a market we needed to be strong in. One thing we discovered was that we had too many products in the middle tier. Wireless was one of them, but we also had separate servers for various other functions, and we discovered the whole middle tier of the app server market was fragmented. IBM had also done something they called an app server, but it was really 150 different products. So we saw an opportunity in being the first to create an integrated app-server product. We could see why many customers would have trouble buying all these components and building them together, because it's not simple. So we did that for them, and then—for our 2.0 app server release—we bought the fastest J2EE engine on the market and integrated it, because we consider that as the commodity part of it. Q: That was Orion? Christfort: Yes, Orion, a Swedish company, had a fast J2EE engine. In our first version, we had built our own, but we found out that's not where the competitive market was today. We were better off buying a fast one and then adding the value by integrating all the other stuff, which is not trivial to do. Anyone could have bought an Orion J2EE engine and an Apache Web server, and that would have been faster and certainly cheaper than what we would sell them. But when people did that, they had a problem when they needed enterprise-grade authentication, system management, document management, portal integration, content management, access control, and other functions. So we licensed Apache and bought Orion, and then built all the other stuff on top of it, pre-integrated and ready to install. That was the premise, and it has gone extremely well with buyers. Q: Likewise, on the development side, your JDeveloper has been well received. Christfort: Here's the strategy with JDeveloper. We think it's an excellent tool that offers lots of benefits, particularly if you do database-oriented programming. However, we also know that people might have other development environments, so we have a standard J2EE application server that allows you to use our tools or other tools. Q: And that allows you to play in the big market? The rap against Oracle in the Java market is that it owns its captive database customers but is not fully competitive in the rest of the world. Christfort: Yes, that's a perception and it's up to us to change that perception. If you have an enterprise requirement, and you're looking to get everything out of the box, pre-integrated, there is no other application server that will do the same job for you. If you go to something like BEA, you'll also have a quick J2EE engine and good basic Web-server functionality. But BEA has virtually nothing for wireless. Or take IBM: It has some wireless components, but they're not integrated. You can't even download the product. It exists as components, and if you want to get the product, you literally depend on IBM consultants to come and install them. The cost of ownership of the IBM product is completely mind-numbing. Q: What does Oracle Mobile Studio offer the wireless developer? Christfort: To run mobile applications as elements in your infrastructure, you need a WAP gateway, an SMS gateway, and a voice gateway. What we built was a hosted instance where that infrastructure is already in place. There's a toll-free number where you can dial in and get voice-gateway capability. What you can do now is build an application onto your own app server, then go to the Studio and create a connection between the Studio-hosted infrastructure and the application on your application server. You don't have to install a voice gateway, a WAP gateway, or an SMS gateway. You just leverage all of that in the host node, yet the actual database that you access is inside your own enterprise. Q: Is that how you think most enterprises will do it? Christfort: We think it's attractive because enterprises don't like the idea that their databases would reside with a hosted provider. We offer that as well, but the reality is that enterprises prefer the comfort of having their treasured information assets in their own data center. But they're not at all excited about getting into the cost of ownership of running all these gateways. Q: How do you price the hosted model? Christfort: First of all, development is free. You get a certain volume of test messages and voice access, but you can do your prototype product and proof of concept totally free. Then when you decide to go live with this model, you have some interesting choices. You can continue in the hosted mode, in which case you pay a hosting fee, which is basically equivalent to the licensing fee of an equivalent amount of AS Wireless Server licenses, plus a small management fee. The hosting price depends on your usage. It's not a simple pricing model, but it also means you pay only for what you use; you don't have any slack capacity. But some enterprises might want a license to run it all in-house. Then you can just buy the licenses and you're ready to go. You will already have been through the proof of concept. You've seen the work. You've justified the project cost. That's interesting because you have all these wireless service providers with a great ASP offering, but they don't have a shipping product. Then, you have IBM, which has a shipping product but no hosted service. One of our differentiators is that people can use the Studio, get comfortable, even prove it internally, and then have free hands in terms of whether they want to run it inside or continue hosting. Q: One of the things you seem to be promising with Oracle9iAS Wireless is the ability to have one application-development effort that would abstract to a wide variety of wireless devices. How is that possible given the state of standards today? Christfort: One of the big barriers to building an application is that you have different evolving standards—you have to build a VoiceXML application, a Palm application, an iPAQ application, a BlackBerry application, a WAP application, an SMS application, and so on. Pretty quickly, you find you're building 10 different applications. We don't think that makes sense. It's better to abstract it so people build a standard J2EE component that outputs an XML schema, then we take care of the adaptation to the different devices as they evolve. Basically we created an abstract interface—a user-interface mark-up language—and then from there, we translate to the different standards. It's compelling. You can run one application—for example, the e-mail application or calendar application that ships with our app server—and that same code implements a well-formed WAP application and a rich-interface PDA application. You can also call into it with voice recognition or SMS and check your calendar and e-mail. So the same application gets better and better. Q: Are customers building these kinds of multichannel applications? Christfort: It's a hard problem to solve, but it's pretty magical. Barclays Bank has millions of users running mobile banking on its server. Barclays took our server and built it for WAP, then came back to us and wanted to know what effort would be involved to build it for PDAs. We told them it was no effort, because it was already done. However, there are some things you like to do a little differently on PDAs than on phones. That's no problem because we have the capability to alter the application conditionally based on the device. We have switches in our mark-up language that let you tweak the five or 10 percent of the application specific to the device. But you have only one JSP. So the total cost of ownership—of building, deploying, and maintaining all the versions—is as if it were one application. About the Authors About Jacob Christfort
|
