Thursday, 23 February 2017

What should Mobility Road map Cover?

Governance


End to end processes and tools are defined from ideation to BAU (Business As Usual) phase. Clear definition of entry criteria, exit criteria and approvals need to defined. Existing application development documents like BRD (Business Requirement Document), Design Documents etc need to be modified to fit into mobile development. Summary of governance model will look similar to below table

Project Phase
Entry Criteria
Creator
Work Products
Approver
Exit Criteria
Business Requirements
None
Business Team
BRD (Business Requirement Document)
Business Lead
BRD is approved
Software Specifications
BRD is approved
Analyst
SRD (Software Requirement Document)
Business Lead, IT Manager
SRD is Approved
Planning





User Experience Design





Software Design





Legal





Deployment





Development





Testing





Go Live





BAU






Tool set needs to defined for all these workflow approvals. Emails are primitive way of approvals and searching for approvals is a big pain. Imagine searching for an approval after two years.

 App ideas and ROI


Apps without ROI are a bane to any organization. ROI metrics and measurement should be defined for all app ideas. Read “Identifying app ideas for organization” for details.


Mobile Platform Selection


All app development platforms have their advantages and drawbacks. Read “Data driven selection of mobile development platform fororganizations” for details.


Selecting Mobile OS


At the present time, it’s easy to choose a mobile OS to support. Android and iOS have 98 % smart phone market share. If 2% of audience matters for your organization you can think about developing for Windows Phone also. Ex: 2% customers is important for e-commerce giants like Amazon. Thumb rule is if Windows Phone adoption increases to 10 % you can think about Windows Phone.

98% quoted above is worldwide market share. This may vary across geographies and demographics. To get realistic customer pattern, check analytics of your organization’s existing websites.

Selecting devices


Check the analytics of existing websites to get top ten device models users are using. Make sure development and testing is done for these top devices.

When it comes to company provided devices. Selection of devices is much easier
  • High end users will prefer iPads.
  • For low end users, go for Android tablets.
  • Ruggedized devices need to be chosen for heavy duty usage like manufacturing floor, mobile POS systems. These devices work in extreme conditions and are designed to withstand tumble, drop and temperatures. There are specialized vendors like Honeywell and Intermec who provide these devices
  • iPads are not preferred in countries and areas with security issues. An iPad can become reason for mugging and place user in dangerous situation.
  • If cost is the only criteria, Android is the choice.
  • Mapping of app ideas with devices should be also done to check the feasibility of app on a device. Ex: iOS does not allow access to local file system.

 

Security


Mobility has brought about big disruption in the industry. Data and information behind organization fire walls is now accessible outside firewalls over internet. Detailed plan need to be created to secure this information. There are different facets in security

  • Data security on device, ex: device database, files etc.
  • Data security on network. Sensitive information is floating around on web.
  • Infrastructure Management (IM) has a big play. Firewalls, Mobile Device 
  • Management(MDM) and MAM(Mobile Application Management) policies should be defined.
  • Application architecture needs to also change and comply to security standards. Ex: Middleware Server in DMZ cannot connect to data sources directly and has to consume Web Service.
  • Cloud systems provide security as service which can be leveraged for mobile development.


All these facets should be covered in security strategy. Security team needs to be part of strategy creation.

OWASP(Open Web Application Security Project) has a mobile security specification. All the vulnerabilities in this specification need to be addressed in the security strategy.

Remember, security strategy will make or break your organization’s mobility journey. Any breach of security will lead to privacy, compliance and legal issues.

Mobile Deployment Strategy


  • Infrastructure Management (IM) team needs to create deployment Strategy. Important facets are
  • Changes required to in-premise and cloud infrastructure to incorporate mobility
  • Firewalls, network and system  access.
  • MDM (Mobile Device Management) policies.
  • MAM (Mobile Application Management) policies.
  • BYOD(Bring Your Own Device) and COPE(Corporate Owned Personally Enabled) policies.


Marketing


Marketing team needs to create branding and best practices guidelines for organisation wide mobile apps.


Legal


Data and information behind organization fire walls is accessible outside firewalls over internet due to mobility. This has huge legal implications. All legal facets needs to cover from privacy, terms and conditions point of view.

Conclusion



Important facets of Mobility Road map are covered in this article. More advanced streams like Agile, Dev Ops can be covered in mobility road map.


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.