Additional Blogs by Members
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
0 Kudos

"App" or "Application" development?

 

"mobile apps are in!", there is no doubt regarding this statement - everybody is mobile, you cant even walk down a street without passing some guys focusing concentrated on their mobile devices. So there seems to be a huge target audience to mobile solutions, the question is just whether there is a need as well...as I neither want to follow the philosophic track within this article nor want to get into the "Gartner track" such as "we have analyzed that 79,3% of 30% of all people aged between 24 and 32...." I will simply come up with some common thoughts and results we discovered while we took our first steps entering the mobile SAP market and would like to share these common thoughts.

Let's focus on technical aspects of mobile SAP applications first before we switch to business related thoughts. As you might know there are several tools and frameworks around which enable you to "mobilize" your SAP system, on top of these the powerful Sybase flagship. Basically the Sybase approach enables you to focus entirely on business aspects of your application, we will not get into details of Sybase platform within this article but chalk out the major benefits of using Sybase Unwirde Platform: Sybase provides a powerful IDE, the IDE can be used for UI creation as well as UI wiring to BAPIs/Web Service/database etc. - all based on drag & drop without writing a single line of code. But Sybase is much more than mobile application development "only", Sybase provides a full stack of enterprise related features such as app distribution, device management, offline scenarios, security etc.. Previously listed features are exactly the major difference between "App" and "Application" devlopment, as Applications should provide the following features (besides the core business aspects):

 

  •  security (a web service being access from within a DMZ always needs to be secured!)
  • offline capabilities (what if the network goes down while entering data? Re-entering data is not an option...!)
  • device management (manager has different data view than employee)
  • automatic distribution(manager does not want to browse the App-Store)

If you do not require these features you can head for "App" development which is in nothing but exposing BAPIs to Web Services and accessing these Web Services through native mobile clients (iPhone/Android/Symbian etc.). Exposing BAPIs to Web Services is a default feature available within any SAP system so the workload is shifted to client development.

So when to chose "App" development and when to head rather for "Application" development? Is there kind of checklist which could be used chalking out whether an App or an Application is required? Unfortunately there is not but there is an easy path which could be followed, Resource AG uses this path for a couple of months and we would like to share our experinces right here: Chosing Sybase as implementation framework usually results in licence fees and a very huge consulting project as Sybase Unwried Platform is nothing which simply gets installed and configured, creating your application based on Sybase Unwired Platform will result in a project > 6 months, therefore you will benefit from all features listed above.

So customers need to think well about this decision, there is always big danger of using a sledgehammer in order to crack a nut - on the other hand there is a lightweight approach which results in client development only and could be used after couple of days iPhone/Andorid client development, so customers as well as consultants are facing the issue of over/undersizing cutomer requirements. That's exactly the point which is misunderstood as there is no decsion such as "either or", it's much more about following both tracks: customers should never start implementing based on Sybase Unwired Platform directly: usually requirements for mobile applications are pretty foggy as there is not much experience within this topic (compare to Java apps: did you ever join/launch a Java project without requirements changing during project implementation? I guess ou never will, even Java is very etsablished and well known...).

So the first thing you should always do is creation of prototypes mirroring the requirements of your application. You can do these prototypes based on the lightweight approach as this approach enables you to create results instantly and provide thes to your customers/employees. Next you can figure on aspects such as offline capabilities and figure out whether you really need these: it's much easier to decide about this based on a running prototype which can be passed to a field service engineer in order to determine whether he is actually facinf offline situations or whether these never occur and in consequence should not be implemented. If so, you can follow the lightweight approach, if not you should switch to the Sybase track: your benefit from switching at this point is that your screens can be reused! Sybase (currently!) does not provide iPhone client development which means you have to create the client on your own within the XCode development IDE - so this step is required for "App" as well as "Application" development so there is no need to wire this step to Sybase / lightweight development; but as setup of a complex Sybase landscap takes time and experience you should simply start creating an application without any Sybase technology and switch to the Sybase track as soon as you are facing a need which can not be covered following the lightweight approach. Several Resource AG customers noticed during development following the lightweight approach that this approach would cover and adress all of their requirements, others noticed they would require Sybase for several reasons, but you should never decide about the technology (Sybase or custom?) directly without creating a lightweight prototype! Chosing Sybase as this is what SAP recommends and pushes is not an option, you should always decide based on a technology base instead of marketing papers which results in the followin decision steps:

 

  1. create a prototype based on core Web Services and native client development
  2. check whether you really require sophisticated features by testing the prototype
  3. decide about technology (custom or Sybase)
  4. start implementation...

We recommend these steps to any customer or conulting company, if you should have further questions on our prototype concept dont hesitate and get in touch with us directly, info@resource.ch or Florian.Mueller@resource.ch.

 

Cheers, Florian!

2 Comments