Troy first got into mobility as a systems integrator for SAP. He cut his teeth on mobile applications for warehouse and inventory management over a decade ago. SAP developed a lot of barcode data collection applications using rugged handheld computers like the LXE.
I asked Troy about his thoughts on mobile micro-applications and MEAPs (mobile enterprise application platforms). He said that mobile micro-applications are very useful, especially for simple forms-based mobile applications, but he would advocate that mobile micro-applications should be developed using a MEAP and supported by a MEAP. That way there is a standard way of developing, integrating and supporting them. MEAPs should provide a rapid and agile development environment for both thick client applications and mobile micro-applications.
I then asked Troy for his thoughts on the role of thick mobile clients and thin mobile clients. He responded that thick mobile clients are less important when there is 100% connectivity, but there are many cases where rugged working environments do not have connectivity. In such places being able to operate in a connected or disconnected mode is important. He added that he prefers the term “Intelligent Mobile Client” over the term thick client. Intelligent Mobile clients typically have more computing power, on device databases, document management, and data collection capabilities that thin clients.
“What about MEAPs?” I asked. He listed the core features he felt a MEAP should have:
- SDK to provide tools for rapid and agile mobile application development.
- Interface management to protect the integrity of the SAP transaction and ensure it happens and is completed in SAP.
- Data modeling, data profiling and data synchronization.
- Device management, which is important so errors and support issues can be discovered and resolved quickly.
I followed up by asking, “How do you tell the difference between a good and bad MEAP?” He answered:
- The MEAP must be very flexible, because SAP is very flexible. The SAP user must be able to rapidly customize their mobile applications to match any customization they do in SAP.
- The MEAP must support both pre-developed (canned) mobile applications and custom mobile applications.
- 100% of Sky Technologies’ customers have requested some level of customization. That is why the MEAP must support this capability.
- SAP is a transactional management system, and because of that any mobile applications integrated with SAP must also be compliant as a transactional management system and provide complete end-to-end visibility to these transactions.
- SAP interface management is critical. SAP must have visibility into mobile transactions and be able to monitor them from inside of SAP.
- SAP scales up to tens of thousands of users. The mobile enterprise application platform must also scale up.
I asked Troy about Sky Technologies’ strategy of using an SAP “Innerware” architecture for their MEAP. He responded that Sky Technologies was given a namespace inside of SAP by SAP to integrate their SkyMobile MEAP. It was then certified by SAP and enables SAP to have complete transactional visibility to mobile transactions. The “innerware” strategy also enables them to utilize and maximize SAP’s integration technologies including SAP NetWeaver. Many other mobile software companies choose to duplicate SAP functionality in external third party middleware which adds unnecessary layers of complexity.
I learned a new term from Troy – “short pants.” This term refers to youngsters or pretenders, those that lack a complete understanding of an environment. He used that term to refer to mobile software companies that do not have deep knowledge and experience working with SAP. I have now added that term to my vocabulary.
When asked his opinion on SAP’s current mobility strategy, Troy answered that he agrees with SAP’s partnership strategy for delivering mobile applications. He said the market and technology is moving too quickly for a large software company to keep up. They need to support the innovation that can come out of their smaller mobility partners.
In response to the question, “What should SAP do differently?” He answered, “Clarify the licensing strategy and price for mobile applications.” He shared that some of his SAP customers had run into confusing licensing issues around mobile devices for SAP, and this caused some grief.
The last question I asked was, “What should an SAP customer ask a mobile application vendor before purchasing?” Troy answered, “Where is the master system? Is it SAP or a third party database or middleware application?”