Justifying Java

Java isn't for everyone - or is it? Here, AMR Retail Research Director Paula Rosenblum joins Java POS provider Triversity's Colin Haig, director of product management, and Terry Bissonnette, CTO, in a conversation about where Java fits and where retail technology platforms will go from here.

1. What retail environments are Java POS systems best suited for?

Bissonnette/Haig: The real advantage is in flexibility with respect to software deployment choices and lower TCO [total cost of ownership]. With J2ME, or "micro," J2SE, or "standard", and J2EE, or "enterprise" editions, the Java platform is broad enough to offer value to almost any retailer, even those who currently own legacy low-end terminals. Java also has a lot to offer on the server side, both within the walls of the store and at an enterprise level, where Java 2 Enterprise Edition [J2EE] technology really shines. In fact, most high-end e-commerce solutions are J2EE-based. Multi-channel retailers can really benefit from the enterprise approach, powering applications for POS, call-centers, kiosks, and wireless handheld devices.

Rosenblum: Java is best suited for retail environments that want to extend what they do at the POS. It's for any retailer wishing to drive applications beyond standard checkout functionality to the POS terminal. Java enables apps like Internet access and employee information portals for HR [human resources] functions to run across multiple operating systems.

There are some shops that are really intrigued with, and others who are just really pleased with, the ability to run applications across multiple operating systems. J2EE gives you the advantage of platform and operating system independence. But in the end, POS is about four things for retailers: stability, stability, stability, and checkout speed. At the end of the day, most retailers simply want to have processed as many customers as they could, as quickly as possible, without system failure.

2. Retailers won't change platforms without being assured results. What kind of theoretical result statements could a typical retail customer make a year after deploying Java POS?

Bissonnette/Haig: Retailers embracing Java POS are realizing cost savings in operating system licenses per store, as well as cost savings in hardware per store, with the possibility of delaying new capital expenditure in certain circumstances. The estimated cost of administration for code upgrades and maintenance per store will also be reduced. Throughput numbers for real-time and centralized services will improve. More can be done in the data center with less done in the stores, which translates to cost savings for large retailers. Less equipment and less data to maintain within the stores, combined with less code to deploy to the stores, translates to a lower cost of ownership. We speculate retailers will see benefits in fewer than 24 months.

Rosenblum: A retailer can expect flexibility. This is important in an industry where businesses are constantly merging and acquiring one another. Let's say the company you picked up happens to run 4690s, and you're running on PCs and cash drawers. You can still run your Java application on both machines, and that's a big deal. To be honest, the reason retailers are changing platforms is that their infrastructures are getting old. Java is not necessarily driving the change. Retailers won't change their POS systems because there's a cool new product. They won't upgrade unless they have to.

3. What are the three most important features any retailer should look for in a POS solution? How does Java/J2EE enable these features?

Bissonnette/Haig: One of the key issues is reliability. Retailers must always carefully manage risk in their search to improve solutions. No matter what, the solution is mission critical and, for many retailers, must work 24/7/365. Appropriate trade-offs must be made between business resilience and cost of implementation. J2EE is expressly built for this purpose. Each application becomes simpler with fewer moving parts, because systemic concerns are pushed down to middleware infrastructure layers. Operating systems like UNIX and its Linux variants may be used. Security concerns are managed at the platform level, instead of at the application level. This makes reliability and manageability less of a concern, because it is pervasive and a fundamental ingredient in the J2EE solution set.

Another key point is ease of integration, as POS hardly exists in a vacuum, this being especially true at the enterprise level. Standards, both platform-oriented [Java and J2EE] and domain-specific [retail industry], enable this integration. J2EE provides a host of integration building blocks including support for generic enterprise messaging using Java Message Services [JMS], high quality of service back end links using Java 2 Connector Architecture, and the emerging support for Web services through XML [extensible markup language] and SOAP [simple object access protocol] JAX [Java API for XML] standards.

4. Where's the cost justification for moving to a Java POS solution?

Bissonnette/Haig: In summary, reduced licensing cost, preservation of existing equipment, not being beholden to one vendor, and commodity solutions mean the retailer can play multiple suppliers off each other to leverage the best deal possible. The support available in the open source community brings real tangible benefits by adding more choice and giving low cost alternatives. Finally, the cost equation now looks like Total Cost = Total Cost of Acquisition + Total Cost of Integration + Total Cost of Ownership. Java really drives down the latter two and its consequent increase in platform and vendor choices can drive down the first.