Thursday, 23 February 2017

Data driven selection of mobile development platform for organizations

Introduction


Look at the word cloud

Native, PhoneGap and Apache Cordova, Angular JS, Bootstrap, Titanium , Xamarin, React Native, IBM MobileFirst Studio, Oracle Mobile Application Framework, Kony, Rhomobile, Sencha Touch, Telerik, Out Systems


Problem statements and horror stories


  • Intimidating technology cloud.
  • Which technology should be chosen?
  • Is my developer biased and prejudiced towards ABC mobile platform? Can I rely on his judgement?
  • John Doe who joined architecture team recently has told horror stories about XYZ mobile platform in his previous organization.
  • Already burnt fingers with XYZ mobile platform. Can’t risk job with another wrong decision.
  • Company ABC is migrating its flagship app from Hybrid to Native as Hybrid platform was not scalable for their app. 

Millions of dollars are going down the drain due to wrong platform choice. Choose platform scientifically through data driven evaluation. This requires lots of hard work but accurate platform selection after this exercise.

“Without hard work, nothing grows but weeds” - Gordon B. Hinckley


Step 1: Inventory of App ideas


Define inventory of apps you want to develop over the period of next few years. Check out Identifying app ideas and business cases for organization.

Data output from this exercise:
Data 1: Finalized inventory of apps with all the features planned for next couple of years. More exhaustive the feature set, more accurate the platform selection.

Step 2: Backend readiness

Prerequisites: Data 1 (Finalized inventory of apps with all the features planned for next couple of years)
  • Are your back ends ready for mobilization?
  • What back end integrations are required?
  • What are end points for these integration? – REST, SOAP, Database, CSV, FTP etc.
  • What is cost of changes to back end for mobilization?
Data output from this exercise:
Data 2: Changes required to existing systems, cost for these changes. 


Step 3: Organizations technology stack


Prerequisites: Data 1 (Finalized inventory of apps with all the features planned for next couple of years)
  • What is the primary technology stack of your organization? Ex: Oracle, Microsoft etc.
  • Does your tech stack have ready mobile platform? Microsoft has Xamarin, Oracle has MAF
    • Create a list of 3+ developers who can be trained for mobile platform (Data 4)
  • How mature is this ready mobile platform? Rudimentary OR Advanced
  • How many apps from app inventory (Data 1) can leverage ready mobile platform.
    • Mobile platform has ready app: Ex: Your organization is an Oracle shop and your app ideas contain Approvals and Inventory. Oracle already has these ready solutions.
    • Mobile Platform has ready components: app A can use Sync Server, app B can use security components, and both apps A and B can use Push Notifications etc.

Data output from this exercise:
Data 3: Inventory of ready apps vs app ideas, inventory of ready components vs app ideas.
Data 4: List of existing developers who can be trained internally.


Step 4: First Elimination Round


Prerequisites: Data 1, Data 2, Data 3 and Data 4

Create a check list similar to boxes below. And let us select some of the suitable mobile development platforms.




Now that we have four data points we can select few technologies and knock off others. The position of tick marks on below checklist is an example. Let’s see what scenarios made me make my choices.
  • I work in banking and insurance, Kony has ready apps for banking and insurance. This decision is influenced by Data 3.
  • My organization uses Microsoft stack. I can train developers throughout my IT to learn Xamarin. This decision in influenced by Data 4.
  • 50 % of features in two apps from inventory of app ideas require native development. Third party APIs are being used in these apps, third parties are providing native SDKs. This is influenced by Data 1.
  • Make sure you have at least one MBaaS and MADP in your list. We need to do cost vs benefit analysis during final selection.  



House rules for this elimination round, how technology selection should not be done.
  • “I don’t want to compromise on UI responsiveness and don’t want to have feasibility issues in future.” This decision is not influenced by any data point.
  • “My friend does not like a particular technology.” At the point of being repetitive - This decision is not influenced by any data point.
  • “I like Technology XYZ. Their sales pitch was good.” Never get influenced by sales pitches. Sales guys will always tell you their platform is best. Listen to all of them. Ask them all the data you require and make an informed decision.
Data output from this exercise:
Data 5: finalists. Technologies which are still in contention


Step 5: Calculate Infra, Development and Operations cost for next 3 years


Prerequisites: Data 1, Data 2, Data 3, Data 4

We now have three contenders for gold medal. We are almost there…
  • Create an estimate for apps planned for next three years on selected platforms.
  • Estimate should consist of
    • Resourcing cost for development and support for three years
      • Include effort for enabling mobilization of existing systems and back ends -  Data 2 
      • Software licences for next three years
      • Infra cost – Hardware, hosting etc.

Data output from this exercise:
Data 6: Infra, Development and Operations cost for next 3 years.


Step 6: Finals


Prerequisites: Data 5, Data 6

After all the hard work, this is easiest part

Take a deep breath and look at finalists and estimates and choose your winner.


Revisiting Problem statements and horror stories

  • Intimidating technology cloud.
  • Answer: You will agree, cloud is not so intimidating now
  • Which technology should I choose?
  • Answer: You know how mobile platform is chosen
  • Is my developer is biased and prejudiced towards ABC mobile platform? Can I rely on his judgement?
  • Answer: Data and numbers are key, prejudices don’t matter
  • John Doe who joined architecture team recently has told horror stories about XYZ mobile platform in his previous organization.
  • Answer:
    • Show John Data 1, Data 2, Data 3, Data 4, Data 5 and Data 6.
    • John will be convinced by your platform selection as you are showing him numbers and data. Everybody respects number crunching.
  • I have already burnt fingers with XYZ mobile platform. Can’t risk my job with another wrong decision.
  • Answer: This is tricky situation, Organization has lost faith in you and will ask a third party to vet out the platform selection. Be truthful and tell them you failed first time. Be patient and show them all data points and hope that decision makers are convinced
  • Company ABC is migrating its flagship app from Hybrid to Native as Hybrid platform was not scalable for their app.
  • Answer: Wrong platform selection is the biggest mistake mobile teams are doing worldwide, you now know how scientific data driven platform selection can be done.


Conclusion


Choosing a mobile development platform for organizations is not easy. It requires lots of serious number crunching and data evaluation. This methodology of tool selection has tangible outputs which can help IT teams understand all the facets of mobile projects:
  • Technology
  • Cost
  • Plan for three years
  • Peace of mind


Aftermath

9 months after you have chosen your mobile development platform, a brand new app idea or requirement has come which is not suitable for your chosen platform.
  • If new idea is good to have – scrap it
  • If new idea is must have – choose a different technology for this one app. Outsource development of app to third party. After development, minor support changes can be done by internal team with basic training. For big changes go back to third-party again.

Friday, 17 February 2017

A Primer: Mobile app development technologies and platforms

Look at the word cloud



Native, PhoneGap and Apache Cordova, Angular JS, Bootstrap, Titanium , Xamarin, React Native, IBM MobileFirst Studio, Oracle Mobile Application Framework, Kony, Rhomobile, Sencha Touch, Telerik

Intimidating!!!!! 

“I'm not confused. I'm just well mixed” - Robert Frost


Below definitions are very high level architecture descriptions. These definitions are for audience who want to understand the crux and more advanced architecture can be found respective tool web sites.

What’s native?


  • Native development is done using SDKs provided by OS vendors – Apple, Google, Microsoft etc.
  • Native Applications run directly on CPU or VM


What’s cross platform?


  • Cross platform applications are developed in various programming languages provided by cross platform tool vendors.
  • Basic objectives are common code for all mobile OS and leverage existing skills to develop mobile applications. Ex: You can develop Android and iOS apps using C#, Java Script etc.
  • Cross platform applications do not directly run on CPU but have conversion engine in the call stack. For obvious reasons these conversion engines are closely guarded by tools vendors.
  • Cross platform are further divided into Native cross platform and Hybrid cross platform
  • Most popular cross platform tools are PhoneGap(Cordova), Titanium, Xamarin and Native Script.
  • Most of these tool vendors claim that their SDK for new OS releases is released within a day of general availability release of actual OS vendor.


What’s Native Cross Platform?


  • These applications run directly on CPU through a thin layer of FFI(Foreign Functional Interface). This is similar to a JVM(Java Virtual Machine).
  • These tools provide direct access to Native components – both UI and hardware.
  • The final App is as good as native Apps except thin layer of FFI in the call stack.
  • Earlier these tools were buggy but now they have stabilised.


What’s Hybrid Cross Platform?


  • These applications run on Browser Engine, All OS platforms provide a component called Web View which has access to hardware and other native components. This is leveraged from tool vendors to develop Hybrid containers.
  • UI is developed using HTML5 libraries and allied tools like Sencha, JQueryMobile, Bootstrap, Ionic, Angular, TypeScript and JavaScript etc.
  • Hybrid containers are comparatively slow as compared to Native and Cross-Platform Native.


What’s MADP?



  • MADP(Mobile Development Application Platform) is End to End development platform for developing a mobile solution – app, middleware server and integration components.
  • MADP tools claim are they are Omni-Channel i.e.; they run as mobile web, desktop, mobile app, tablet app etc. Not all MADP are Omni-Channel
  • They provide pre-built applications. Ex: Kony provides ready Mobile Banking Application which can be customized, Oracle has 150+ ready apps at https://play.google.com/store/apps/developer?id=Oracle+America,+Inc.&hl=en
  • MADP’s provide ready components for Security, Sync etc.
  • Select MADP’s provide MDM (Mobile Device Management) and MAM (Mobile Application Management) suite for deploying apps to private Appstores. 


What’s MEAP?



MEAP (Mobile Enterprise Application Platform) was precursor to MADP and this term is no longer used by analyst firms.
  

What’s mBAAS?


  • MBaaS (Mobile Backend as a Service) is a combination of SAAS and BaaS (Backend as a Service)
  • Developers need not worry about Infra, software installation, maintenance and scaling.
  • mBaaS provides object based databases, push notifications, integration layer etc.
  • Metered billing based on number of API calls.
  • Most of MADP platforms also provide metered billing through their cloud platforms. Ex: Oracle Cloud and Kony.
  • MBaaS space is crowded and is at a nascent stage, Wait for a year or two till leader emerges.
  • Popular mBAAS providers are Oracle, AWS and Kinvey.
  • Popular mBaaS tool Parse was shut down recently and option was given to existing developers to install Parse in-premise.  Large number of start-ups had to move the Parse in-premise defeating the purpose of mBaaS.     


Conclusion



All these platforms have their own advantages and drawbacks. Organizations which are new to mobilization should choose the platform carefully which is best suited for their needs.

Thursday, 16 February 2017

Identifying app ideas and business cases for organization

Introduction


As a business owner and IT manager do you have questions in mind?
  • What are app ideas that can be mobilized?
  • How are ideal app ideas identified?
  • Will these applications be successful?
  • What happens if these applications fail?
  • Data Security?
  • What about ROI?
  • More questions.....

“The biggest risk is not taking any risk. In a world that changing really quickly, the only strategy that is guaranteed to fail is not taking risks” - Mark Zuckerberg


Identifying app ideas


  • Create app ideas which will excite the business owners and users. 
  • Each of these app ideas should have a ROI (Return on Investments). ROI is not just return on expenditure, ROI can be saving time, customer satisfaction, better compliance etc.
  • Come up with an inventory of applications for each department and LOB (Lines of Business) in your organization. 
  • Remember that these app ideas are for encouraging business owners to think mobility in their respective department and are not final app ideas. 
  • Take these app ideas to respective departments.
  • They will usually have their own ideas. Add these app inventory.
  • Prioritize app ideas along with business owners.
  • Pick up three app ideas
  • Start developing these ideas

Return on Investments (ROI)


Any system without ROI are a bane to organization. ROI metrics and measurement should be defined for all app ideas before going further. 

ROI = (Revenue – Cost)*100/Cost

There are more ROI parameters apart from above calculation. 

  • Branding
  • Productivity Improvement
  • Customer Satisfaction and Delight
  • Compliance
  • Lead Generation
  • Lower cost of customer acquisition
  • More metrics…….

Measurement should be done at regular intervals to calculate ROI. 

Define MVP (Minuscule Viable Product)


MVP (Minimum Viable Product) is for web, MVP (Minuscule Viable Product) is for mobile applications. Define MVP


  • Choose three features in each of these three apps which will excite users to download app.
  • Do not choose more than three features in each app. If users don’t adopt, you will be left in lurch. 
  • Each app should go live in two months.
  • Use existing infrastructure (servers, web services etc.) to get these apps developed.
  • Do not use expensive tools for your initial development, use free platforms like Native, Cordova, and React Native for these first couple of apps. You can get into advanced commercial platforms after you get a hang of mobility in a year.

User Acquisition and Retention


Having the app out on Appstores and MDM’s will not serve the purpose. Driving the user acquisition and retention is a continuous process. 
  • Mail Blasts: Send regular mailers(spam) to users to increase acquisition
  • Keywords: Take your time in creating meta-data on App Stores. Title and description of the app should be easy for bots to index.  
  • Deep Linking: Apple and Google have started basic deep linking in apps. Though preliminary, this will get enhanced for full-fledged indexing.
  • Mobile app analytics: Analytics is best feedback we can get from user’s without compromising on their privacy. Look for the usage trends and adjust app accordingly.
  • Crash reports: Always be on lookout for crash reports, Each crash is minus one user.
  • Feedback: Look out for Appstore and in-app feedback.
  • Incentivise the app usage, provide brownie points for app usage.

Continuous addition of features


  • Add new features
  • Remove redundant features users are not interested in
  • Improve customer experience
  • Keep your fingers crossed

Application Sunsetting


After all the hard work, if there is poor user acquisition or ROI, Kill the app and get on with new ideas. Never get attached to your app ideas. 

Conclusion


There is no magic wand to identify successful app ideas for your organization. Approach should be to create miniscule viable product and then enhance them through user driven feedback. If user acquisition does not increase, sunset the application.