Cloud Platform Webinar Series

Insider's Guide to Mobile Apps


Building mobile apps that can transform business is on everyone's 2015 to-do list, but how do you avoid common pitfalls?

In this webinar, Pivotal’s Dormain Drewitz asks Farhan Thawar, VP of Engineering at Pivotal Labs, what they have learned in their decade-long experience building great apps for all industries.


  • Common mistakes in mobile app development
  • Best practices of (and from) leading mobile app developers
  • About the secret weapons: PaaS and Agile development practices can support mobile app development

Dormain Drewitz
Director, Product Marketing, Pivotal Big Data Suite

Dormain Drewitz is Director of Product Marketing for Pivotal Big Data Suite at Pivotal. Prior to Pivotal, she was Director of Platform Marketing at Riverbed Technology. Prior to Riverbed, she spent over five years as a technology investment analyst, closely following enterprise infrastructure software companies and industry trends. Dormain holds a B. A. in History from the University of California at Los Angeles.

Farhan Thawar
Vice President, Engineering

As Vice President of Engineering, Farhan is responsible for engineering and client engagements in Pivotal Labs Toronto office where the company’s clients work closely with Labs to deliver mobile and server applications using highly disciplined agile development processes.


Dormain Drewitz: Good day, and welcome to today’s webinar for the Insider’s Guide to Mobile Apps. My name is Dormain Drewitz, and with me today is Farhan Thawar.

A couple of housekeeping items before we get started. Go ahead and put your questions into the Q&A box. We’ll be getting back to those as quickly as we can. We’ll also be monitoring Twitter for tweets with the hashtag mobileapptips if you want to join us there.

A couple of questions that often come up I’ll go ahead and answer now. The first is whether a replay will be available, and the answer is yes. You’ll be getting an email shortly after this broadcast with a link to the on-demand replay. Also, we often get questions about whether slides … will be available, and those will be made available on With that, let’s go ahead and get started.

Your presenters today, again, myself, Dormain Drewitz and Farhan Thawar. Farhan comes from Pivotal Labs, which has built over 500 mobile apps and has taken on a new role leading the mobile services for Pivotal Cloud Foundry.

Just a little bit of background on Pivotal Labs. Pivotal Labs has been around for a number of years as one of the leaders in agile development and as you can see, has been delivering a really world-class experience around mobile app development.

Farhan, first question for you is why is agile so important for mobile app development?

Farhan Thawar: Yeah, thanks for having me, Dormain. I think one interesting thing about mobile is that it is such a fast-paced industry with not only devices changing all the time but operating systems and the types of things you can do on mobile is very rapid. When you think about a fast-changing ecosystem and hardware landscape, you have to think that how are you going to keep up on the application development side? How are you going to enable your customers and employees to also iterate at the speed that this ecosystem is moving at? Agile allows you to do that.

What agile allows you to do is, say we have a high-level piece that’s around what we want to build, but as we’re building it, we want to include all the information around our environment, changes, things our customers are doing, maybe things our competitors are doing and incorporate them into the application development lifecycle.

Agile development is, I would consider it to be crucial because you think about a waterfall process, let’s say a six- to eight-month release cycle. What we are talking about now is a completely different landscape of operating systems and hardware, and you’re never going to catch up, so agile really allows you to deploy and write applications so you are frequently giving an update to your users.

Dormain Drewitz: Yeah, that makes a lot of sense. We’ll see in a moment with some other examples why that rapid iteration is so important.

Another question for you before we move on and dig into some of these best practices is also just around how has Pivotal Lab’s experience with developing mobile apps and mobile app projects, how does that inform the Pivotal software portfolio as well?

Farhan Thawar: What’s interesting is because we’re seeing our customers want to become agile, we work with all sizes of customers from start-ups to enterprises. What they’re seeing is they don’t want to work with us just to help them build some things. They want to work with us to help build something and change the way that they work, and what we’ve noticed is that as we work with these companies, we help them move their methodology to agile, they’re running into barriers on the infrastructure side.

What’s been amazing that’s happened at Pivotal is that Labs have been able to inform other areas of Pivotal, mainly cloud foundry and data to say, “You know what? We have these enterprise customers who want to be agile, who want to deploy, who want to do new things and create new businesses, but they don’t have the infrastructure or software to enable it, so they’ve now got agile methodology but they can’t deploy except to go through IT, that takes two months, or they’ve got all this data and they can’t gain insight from it.

Really, Labs has enabled us to go full-circle, help create development culture and environment to move rapidly, incorporate features and changes quickly, and then deploy continuously to their customers and employees, and then also gain insight and then go around the circle again, so gain those insights and then make changes again to those applications and those features, so it really is a full-circle experience.

Just one more point before you move from the slide. You know what’s cool about this quote is that Shutterstock went on to win Best iPad app of the year at the Webby Awards when we released it.

Dormain Drewitz: That’s fantastic, and yeah, I think there’s a lot to be said about being able to take those best practices and really automate them with software.

One of the first things, just before we dive into some of these great insider tips that you’ve helped put together is just the backdrop of what’s happening as we start 2015. Here we are in early January. This is a data point that I really liked from Gartner that found of the organizations surveyed an overwhelming percentage, 79 percent, were planning to increase their spending on mobile app development by a huge number, by 36 percent.

That’s something that, to me, looks like one of those classic tipping points. What’s interesting is when we were going into 2014, a data point there was just that internet traffic, at least in the U.S., had just changed over to being driven more by mobile apps than by laptops and desktops, and so I think the number was 47 percent of internet traffic, and so here we are a year later and the investment in mobile app development is really kicking up.

I was wondering, is there anything in particular you think that’s driving this increase in spending?

Farhan Thawar: Yeah, I think it’s a couple of things. One nuance point here is that many years ago when we talked about mobile, folks really looked at it as just something on the side, so it started off as being potentially an avenue for marketing to acquire new customers or to get to their customers, and then a few years after marketing with spending time on mobile, then the product teams got interested because folks were using it more and more, not just as a distraction, but as a primary tool to get work done.

Then now what we’re seeing is IT coming into the fold and saying, “You know what? It’s not just marketing and product, IT really needs to embrace mobile and we need to change the way our infrastructure is set up, so that’s what the nuance point around what departments we saw driving the spend.

The reason for the spend is pretty clear. I’ve been doing lots of talks over the years and I used to ask this question. I’d say, “Hey, how many people here have a Smartphone?” I wouldn’t see any hands going up, because it was probably only me who had a Smartphone, probably six, seven years ago. Now it’s impossible to ask that question. You can ask maybe, “Who doesn’t have a Smartphone?” You won’t see any hands. Just the amount of time spent on these devices from the consumer angle, the employee angle, is why companies need to spend time here.

They started off as, it was all consumer, consumer, consumer, but employees are expecting the same level of interaction and service from the companies they work with and the companies they work at, and they’re expecting to be able to do their jobs from their mobile devices, and so that’s why we’re seeing the increased spend, because people know if you can help your employees get what they need done on mobile, they’ll be able to work more effectively, more efficiently, because they’re using the device that they want to use.

Dormain Drewitz: Yeah, this is really becoming a critical and one of the primary channels for communicating with both your customers and your employees, so with that, let’s go into the first tip [nov 00:08:29], which is to go native, and so tell us a little bit about why it’s so important to go native and what does this mean for your approach to your website as well, or what do you mean by go native?

Farhan Thawar: Yeah, so what I mean by go native is when you’re trying to build out very premium UI-flexible and performance experience. You have to use all the tools available with you. Then in many ways, you want to go right to the device, and so what we’ve seen is if we take the opposite approach, what we’ve seen is in a small five websites for mobile or in these cross-platform toolkits, is that they abstract away too much of the environment because they’re trying to make things easy across devices or form factors or across operating systems, and what happens is you lose the reason that folks are actually using the device in the first place.

An example, maybe you want to enable push notifications with your application using those types of toolkits, this makes it very hard to have a great experience, because you can’t enable push notifications, or let’s say you want to have the UI be very tailored to a certain device.

One thing we’ve learned over time is when we work with our clients, they might have, let’s say, Android and IOS apps. One of the questions I get asked often is, “How do I make sure my Android and IOS apps look the same?” I always considered this an interview question, it’s they shouldn’t look the same.

Of course they should both adhere to your brand, but Android apps should be designed with Android users in mind. They’re a very different segment than IOS users, and so the cross-platform toolkits don’t really allow that type of customization, don’t allow the performance, and your users will notice. They’ll notice it and they’ll say, “Well, this brand doesn’t care about my experience.” That’s why we always recommend building out an amazing experience for your users, which means going native.

Dormain Drewitz: Got them. Now, just to dig into that a little bit more, these were a couple of the reasons that we pulled together and I think they’re really important, but I think there’s also something to be said for not abandoning the notion of a mobile first since if you have a website out there, it’s going to be trafficked from mobile devices as well, so it’s really about having a balanced approach but embracing native, so where do you think is the right place to start for going native? How does someone tackle which platform they should try and focus on first, et cetera?

Farhan Thawar: The way I think about it is, I totally agree. Your website is going to be crawled by mobile phones, so you do need to have an experience there. I think the way to think about it is, your first bet, right, is make sure your site works on mobile devices, and by mobile, I mean it could be tablets, it could be phones, it could be Google TV, it could be all those things. I think that’s the first step.

Then the next step is to figure out those one-to-three use cases that your customers are coming to you for. If you’re a bank, likely your customers are coming to check a balance. Potentially after that, they might want to check transaction history, potentially after that they might want to pay bills, so I think you want to come up with a prioritized ordering of what you think your customers are working through and work with your product team to help figure that out. Then what you could do is you could create some native, compelling experiences for those use cases.

They don’t have to be huge. Mobile is very good at doing a few things extremely well and deep, so you could have a mobile app that literally just checks your balance. You could pay bills on it and check your transactions. That would be a pretty compelling app for folks if you don’t have a mobile experience [today 00:12:44].

The way to figure out what operating system to use is take a look at your demographics. It’s funny, when we talk to some of our clients and they always just think, “Well, let’s build IOS first, then maybe Android, then look at tablet. It’s not cookie-cutter. It’s not that every app has the same demographical users. We’ve definitely worked with some clients where we looked at their user base and we looked at the types of devices hitting their web page, and you might be surprised it’s by seeing Windows Phone or BlackBerry as something that’s very highly used by their user base versus just IOS and Android.

I think it’s something to take a look at before just diving in and my advice is, build out a great native experience on just one platform first, see the adoptions, see the type of things your users are trying to do, get feedback before you start building on other platforms. I’m not saying it’s impossible to build on other platforms in parallel, it’s just one approach could be if you’re trying to figure out mobile, build on one and then expand, so dominate on one platform in the next band.

Dormain Drewitz: That makes a lot of sense to start and learn from there and then move on and expand, and it brings us a little bit to our next point, which is to update often. This is our next tip. I’m just going to actually quickly go to the next slide, because it’s another key data point that I think is really interesting, this one coming from Forrester about how brands with the most highly-rated consumer mobile apps are really [seen 14:18] eight to 12 times a year.

I’ve heard from other analysts, frequency of releases, being every three to four weeks, which generally speaking is a lot more iterative than what we’ve experienced in the traditional web app world, and so especially when you think about really getting a handle on starting with just one platform that you’re deploying a native mobile app on and then adding to there, this really starts to multiply out to being a lot of releases to manage, and that really, I think, becomes a forcing function for organizations to look at how they’re managing their software release cycles, so I wanted to see what ideas you have that can help folks, [say 00:15:04] what helps people adapt to this type of release cycle.

Farhan Thawar: Yeah, so you need a few different things. One, and we talked about some of these at the beginning, one is you do need an agile development approach because what’s happening here is, you’re gathering requirements, you’ve got a hypothesis around something you want to build, you’ve gathered those requirements, you’re writing the code, you’re testing it, you’re designing, and then you’re pushing it out and you’re getting feedback, and then you’re iterating on that.

If you look at the [fat 00:15:31] here, eight to 12 times a year, those are not long release cycles. Those are not six months long, those are weeks, and so in order to do things on a week’s timescale, you have to have an agile methodology.

Now if you have an agile methodology but don’t have the supporting software in your infrastructure, you can’t achieve this. If you have to go to IT to get a new server provision or to make a change to a back end API, or to get access to some back-end data, and it takes months. Again, you can’t achieve eight to 12 releases a year. You need both sides of the equation, and then once you’re mature enough to be able to deploy eight to 12 times a year, you have an agile methodology. Now you want to actually gain insights from all the data you’ve collected.

If you don’t, again, have the tools to store and reason over that dataset, you’re again not able to come up with these hypotheses to determine what should I be building in my next release cycles.

You need all the components. There is a ladder to get there, versus you need probably need agile development, you need to think through some software on the PaaS side, then you need to think about Big Data, but if you don’t have all those things, you’re not getting the benefit of being able to do this.

It’s true, the best brands do this, especially now with all the mobile operating systems allowing background updates. You literally open an app and see a new experience or see a better performance or see a better design on a very frequent basis, and you are expecting those things to get better over time.

Remember there was a newspaper article about, I think it was a fast food chain or a higher-end fast food chain which had released the mobile app, and then I think in ’08, and then didn’t release an update until 2013. It made headlines, because they’re like, “Well, how much do you care about the brand if you waited five years before you deploy your next version of your app?”

Dormain Drewitz: Yeah, that’s definitely not the best practices that the analyst and that that we’re seeing in our work with our customers, and I think you have a really important point about that back-end infrastructure, so just to illustrate that a little bit, that process of releasing the software really needs to come into focus. An example, just here, looking at the manual steps involved with traditional app deployment and the back-and-forth between developers and operations in order to get a release out, and then thinking about stepping back and thinking about the entire lifecycle of that application, you end up with a process that is minimally automated in a lot of cases and requires a long time to get a release out.

This isn’t specific to mobile apps, but if this is the environment in which your developers are working, you can see how this is going to be a problem when you then try and apply some of these mobile best practices.

I don’t know if there’s anything you wanted to add specifically to these couple of examples here around that process and why it needs to change?

Farhan Thawar: Yeah, the process needs to change, but I think you need both sides of the business to change. I was literally on a call before this with a customer who said, “Oh, I get what you mean. We should have a pad because that allows us to deploy faster, but you really need to talk to my IT folks about that.” I was like, “I get that. It’s an IT infrastructure conversation. However, if the business, the engineer inside these enterprises, are not asking for this, are not saying, “Hey, in order for us to be successful with our customers and employees, we have to be able to rapidly respond to what’s going on in the marketplace or in corporate feedback or fix a security issue or respond to a customer, a competitor threat.”

If they won’t ask that of IT, then IT’s never going to have their feet to the fire to say, “Well, we have to do things in a different way.” They might just say, “Well, that’s just IT and I’ve lived with it, and it’s fine. We’ve figured out ways around it,” and I don’t agree. I don’t think you can figure out ways around 140 days to land an app in the app store. There isn’t an approach that the approach is, “Take less risks and experiment less and respond less frequently,” that’s not the solution.

I think you really have to think about it as, “Hey, we want to be forward-thinking. Our company is going to rely on technology in software as a competitive differentiator, so let’s all move forward as a business and hold our IT to a higher standard, and then IT has to say, “Yes, we want to also allow more control by our application development team. Let’s also move forward on using a PaaS plus agile development plus then eventually Big Data to enable these better experiences to have a better interface with our customers and our employees.”

Dormain Drewitz: Indeed, I think that’s definitely an important conversation to have, and there’s, for what it’s worth, some of the things that probably will help that are thinking about some of the benefits that also accrue to IT, and so what I like about this quote is that talking about using cloud foundry, which is a PaaS, and how it not only reduces the time and resources, but also reduces the risk, and that’s something that I think will really help that conversation between the business of trying to get an app out and IT that’s trying to manage things like cost and risk, and how they do it, and so for what it’s worth, I think that this is something that can be really helpful for folks to remember, that there are solutions that help both sides of that conversation.

Farhan Thawar: I like the quote as well. What’s cool about the approach is that IT really becomes a champion in the organization. Some people originally will look at it and say, “Well, IT is like a barrier to get through, to get things to production,” whereas this moves them to be an enabler for the technology. They’re like, “Wow, they’re really forward-thinking. They’ve given me these resources,” and now IT has a real critical role, IT being like, “Hey, we’re going to use technology and IT to be a competitive differentiator.”

They really take a forefront role, not a background role, in enabling these things. That’s what I’m most excited about.

Dormain Drewitz: Absolutely, so let’s just move on to our next tip here, which is to build for compulsive scale. I’ll explain what I mean by compulsive scale here, because I came up with it a couple weeks ago, and so one example is to think about it in the context of a particular business. To use banking as an example, you have, in the olden days, you’d get in your horse and buggy and clippity-clop, ride down to your local bank branch on payday to deposit your paycheck and maybe take care of some other business while you’re there.

Then in the online world, you could move to, “Hey, I don’t have to balance my checkbook. I can just go online and check every day,” and so that increased the frequency of interaction between a bank and their customers in the consumer world, certainly, by a huge order of magnitude, and this is what became the notion of consumer scale.

It’s very difficult to achieve reality, but then what we have in the mobile world is this behavioral shift to folks who are checking, and I use “Compulsive” because I think there is actually some evidence out there that behaviors do change when folks have access to these devices on their person, in their pocket, 80-plus percent of the time, and banking customers we’ve spoken to have noted, “Hey, on payday, we have folks checking their mobile app 20 times a day to see when that deposit hit.”

Could they have done it in the online world? Yes, but for some reason they didn’t. What they’re doing is now that it’s in their pocket, they’re able to do it, and there’s actually some interaction with the dopamine and our ability to pay attention and why we do this a little bit, and I don’t think that behavior’s going to change, but the reality is that this leads us to basically having to build for another order of magnitude greater in terms of the volume that folks have to be able to build for in the mobile world, and just an example of what happens when this scale manifests.

This is something, Farhan, you had sent over to me when, just after Black Friday, and found that they attributed the shutdown of their site to mobile traffic, so what is the takeaway here from your perspective in terms of how do you avoid this scenario, and what do you have to think about in terms of building for this compulsive scale?

Farhan Thawar: It’s super-interesting to me, because I think the traditional approach again to this is one that everyone’s used to using and [few 00:25:03] people feel that it’s still the right approach, which is build for the peak, which is let’s just have infrastructure to enable what we think is going to be the highest amount of traffic we have per year, and then every year we’ll increase that by 10 percent or 20 percent. We’ll just have all sorts of utilization at close to zero percent, and then when Black Friday hits or your sports and it’s the playoffs or the Super Bowl, we’re going to have our peak traffic at that time and we’ll just worry about those events and just build to the peak.

I think what we all know is one, it’s super inefficient, and two, you might underestimate how much demand you’re going to get, and in those extremely important moments, you won’t have the scale.

Black Friday is the biggest shopping day of the year and Best Buy had to take their site down. That’s insane. The amount of lost revenue there is something that I’m sure somebody’s there going, “There has to be a better way.”

The better way isn’t to then just say, “Well, I’m going to now just 10X my infrastructure and build again for peak,” because it’s just too expensive, so the approach here is, again, I’m going to go back to a PaaS, building your infrastructure, especially with mobile. If folks are having a debate in their mind about whether they need PaaS for traditional infrastructure, which I don’t think is debate, but it’s still not clear, mobile is very clear.

If you’re going to go from, in the banking example, checking your bank account from once a week to 20 times, in some cases my customers, I see 40 times a day waiting for a check to be deposited, you can’t use the same infrastructure you have. You need something new, and that new can’t be 10X of what I already have.

What a PaaS allows you to do is say, “Well, let me take this same infrastructure I have and use it more effectively. Let me abstract a way, an architect thing, to allow me to scale and let it be something that the developers don’t have to care about besides just building the app in the right way. A PaaS really lets you do that because you could have microservices architecture with an app that allows you to say, “Well, let’s up the instances of this from one to 100 or to 200 or 300. We might even be able to have it autoscaled and not have to see this type of message from a BestBuy.”

That infrastructure translates very nicely to web, to mobile, and the PaaS is the only solution to get you there. You can’t build to peak.

Dormain Drewitz: I think there’s also something that you mentioned earlier about how mobile has been in the past often treated as this thing on the side, and that’s something that is starting to come into focus where it’s no longer a pet project tucked away in one corner of the business. It’s becoming much more pervasive, many different departments looking to go down the route of building mobile apps, hence the uptick and investment.

The reality that they’re also now all sharing a lot of this infrastructure, that actually takes us to our next tip pretty well, which is about managing APIs, and I think this is also a place where, back to the notion of that conversation between the lines of business and IT and the different roles they can play to enable this, this is something that IT has a great opportunity here to really provide a lot of value around API management.

We’ve got the Farhan’s Mobile API Top Tips, and so maybe we can go through a couple of these and I’d love to get your explanation on what these mean and why they’re important.

Farhan Thawar: I’ll go into some of them. I think the idea in a high level is that the APIs you have today, some customers we talked with are pretty forward-thinking in their approach of writing web apps, and they say, “You know what? We have web services for a web app, so in theory we should be able to very easily just reuse those for mobile.”

I love the thought that we could reuse what’s already there, especially because it’s been architected, it works, we don’t have to change the back end, and then what we realized when we dived deeper is that they were definitely abstracted and designed, but they were really focused on web and not on mobile, and there’s a few things in mobile, this is just a sampling of some of them, where if you don’t listen to reason on some of these approaches, your app will not perform well on mobile.

One customer example I had was, they had a big sports brand, they had a successful web presence. They wanted to build an iPad app, and every API call that we would hit from the mobile app would return four meg of data. That’s maybe a lot, even for the web, but the website performed fine, or even if it’s a one meg of data, maybe the website performed fine, but the mobile apps, even over Wi-Fi, will not perform well because the phone has much more limited resources. You probably are not displaying one to four meg of data on the mobile app, so one of the boxes there is a single API [palper screen 00:30:28] is. What we try to do is actually, to have a great experience, see if we can aggregate the data in a way that allows us to only make one API call per screen so we’re not actually waiting for five different API calls from a mobile device to build a nice experience for the next screen for the user. That ties into the low latency.

You want to be able to actually just say, “Here’s the next screen. Give me the data I need for the next screen,” and maybe it’s 4k of data, and maybe it’s displayed in a nice interesting way on the mobile app, but it doesn’t have to be megabytes and megabytes.

Things that you don’t have to worry about in the web world as much, right, is retrying. If you have a crappy connection, one thing that I’ve noticed a lot with engineers is that when your phone goes from three bars to two bars, every engineer originally would just think, “Oh, things are just going to get slower,” it’ll still work, it’ll just take longer or be slower. In mobile, sometimes those apps will crash when you go from three bars to two bars, so you have to approach things in a much different way.

Again, building things in a microservices architecture with a PaaS in the back end, while amazing for a web app, is also going to be crucial for mobile apps. A lot of these things make a lot of sense to those who have heard about 12 factor apps and microservices. They’ll look at this and say, “Oh, these are all obvious in this new architectural approach,” and we’re agreeing. We’re saying, “Yes, you need those things, and especially for mobile you need those things.”

Dormain Drewitz: There’s definitely good practices all around, but they really become critical. One just quote here from an analyst over at 451 group is really about how critical it is and the need for the ability to integrate with corporate back ends, which is something that I think a lot of folks sometimes don’t think about in the mobile app world, where there’s a lot of focus on what does the client side interface look like and everything, but this issue of how you connect back to the back end systems which are then shared across many parts of the business are really critical.

Farhan Thawar: This is like this is my team now, this product, Pivotal Cloud Foundry Mobile Services, actually has something called API Gateway, which literally lets you not have to touch the back end, can aggregate across ABIs, can distill and filter just the needed data for the mobile device and really allows you to take advantage of microservices and of PaaS without having to go through a year-long rewrite of your back end.

Dormain Drewitz: You’ve mentioned the idea of the microservices a number of times, and I think that actually comes into play with this next tip that we have as well, which is keeping apps focused, which it may not be obvious at first how do microservices have to do with keeping apps’ focus of them. Let me explain, just a moment here.

That really comes back to this notion of app [um 00:33:29] bumbling and multi-app strategy and how this is happening, and it really actually makes sense from a strategic perspective, but there are implications to how you’re then going to manage your architecture for not just one app but now thinking about multiple apps, and this is even, in addition to what you were referring to before, where it’s gone from a marketing department project to a product department project and now an IT department project.

Last year Facebook made a pretty big splash out there when they unbundled their messenger component from their core app, and so basically taking one particular function out of their app, a task that people had, a lot of folks use their Facebook message inbox as their primary inbox. I run into this a lot with my younger cousins who, this is their inbox and I’m old school because I use email.

Then the other factor is also different types of users. Here’s just an example when you look at a company like WebMD who have half a dozen plus apps available in the app store, and because they recognize someone who wants the pregnancy app versus the allergy app. They’re just totally different audiences.

What this means, though, is that now you’re starting to, whether it’s your first mobile app or you have one and you’re thinking about how you’re going to improve upon it, make it better, you have to start thinking about how you’re going to be supporting multiple apps. It really compounds. A lot of these issues we’ve already been talking about, and so I think this is where those microservices and that [repurposeability 00:35:23] really becomes important.

Where do you think, this can be a little bit overwhelming, so I wanted to see what your thoughts were in terms of how folks should go down the path thinking about multiple apps and where’s a good place to start and how can they approach this strategy with minimal missteps, and what do you offer for that?

Farhan Thawar: I think one way to think about it is that mobile apps in general are really good at a few things, so one thing about the web is that it allowed us to do many things, and when you’re thinking about a corporate website or some sort of SAS infrastructure, like a Salesforce or other SAS tool, if you want to add a new feature, you can just add another link to some page and add a whole new feature and capability.

In some ways, users are okay with that because they’re used to seeing lots of links or lots of menus and sub-menus, but in mobile, the real compelling use cases are simplicity, getting to reward within less than three clicks, and you might only have somebody for 60 seconds. They might be in line waiting for a coffee at Starbucks, so you won’t have five or 10 minutes, in some cases.

The idea that you can only do a few things really lends itself nicely to this app constellation strategy, which is have more than one app for your brand focused on just adhering to what that user needs at that moment.Facebook’s a good example. [With 00:37:05] I want to message somebody, why was I going into Facebook and letting the newsfeed load, and then having to click over to the messenger tab, having my friends load, and then try to find my friend. It was just a long way to get to communicate with someone to just say, “Hey, I’ve just arrived,” or “I had a question for you,” versus Messenger’s very clear. It’s just so focused on messages, and they go back and forth if you can click on some of the profiles in the Messenger app and it will take you to the Facebook app, but it’s really focused on that micro-reward approach.Now that really lends itself to microservices because you can say, “Okay, I can build my infrastructure to microservices [ways 00:37:42] so then I can aggregate just these components required for Messenger and I’m only going to talk to those. If Messenger really takes off, but newsfeed’s not taking off, I can increase the number of instances and replicate those across, if you have a PaaS infrastructure, very easily across the PaaS without having to increase the infrastructure for the rest of the components, in this case newsfeed, because the PaaS allows you that level of isolation versus, let me just build to the peak, and if Messenger takes off, I’ve got to rebuild that entire Facebook infrastructure on every machine, and I’m really not utilizing things in an optimal way.

The two combined, having a microservices approach at the back end and then building out multiple apps on the front end, may make sense for your business. My approach there would be to create one to two to three core experiences for your users on those singular use cases. First, see what traction you’re getting before you build others, so you don’t have to build, again, even on mobile, a monolithic mobile app. You can build just the one to two to three use cases on a mobile app, see what resonates, get feedback before you can building.

Dormain Drewitz: I think going in with that mindset is really going to change the way folks think about their mobile app strategy, and know that you’re going to, even if you just start with one, know that you’re going to be taking on most likely multiple apps in the future. They’re going to change the way that you build that first one, and I think about this when IT starts to think about taking a huge ERP application and carving out certain tasks like vacation requests. That could be an app on its own, not somewhere buried in a giant app that’s supposed to replicate anything you can get in your ERP system, stuff like that.

Farhan Thawar: That’s a great example.

Dormain Drewitz: Let’s move on to the next tip … which is around using sensor data. You alluded to this a little bit earlier, and when you were talking about being able to collect more data from your app and then using that to feed back into your mobile app development and go around the cycle even faster. Just to elaborate a little bit on what is driving that, if you look at the latest Smartphones that are coming out, you see some that have upwards of 17 different sensors.

This, by the way, I think also goes back to that first point about going native, which is since you do have such a variety of the types of sensors available, you can take advantage of a lot more when you’re building more natively, since you know what types of sensors are available, but things like heartrate are, and some print sensors are started to get added, and this opens up a whole new level of granularity that you have to understand your customers, to be able to build better services and products for them, but there’s an impact on your architecture as well, so what should folks do to think about not letting this data fall on the floor and how to take advantage of it?

Farhan Thawar: It’s interesting because we do a lot of work with clients where six months after launch they might have a hypothesis about something or they might say, “Well, it would be great if we knew at the time where all our users were when they were performing these functions,” or what the gyroscope was saying, or were they walking, there’s all sorts of things that you might want to query later.

What we always tell our clients is, “Let’s store everything. Let’s store all the sensor data, let’s use analytics to store what’s happening in the application [lay 00:41:35]. Let’s store everything, even if we don’t think we have a use case now to think about why would you store that, because what always inevitably happens is six months later you’re going to come back and say, “Well, I wish we had stored that data to make that determination,” so really what I was alluding to here is once you have agile development and you have a PaaS, you probably are thinking, and in some cases a lot of companies are already have these solutions where they have a way to store and reason over these large data sets.

Mobile, again, is a completely different use case than the web. You’ve got many more sensors, much more usage, much more engaged users. You have this compulsive scale effect where people are just using your app 20 times a day instead of once a week, so all sorts of data is being stored.

What do you do next? You have to have somewhere to store it, and you have to have some way to reason over that data to then get insights to then make changes to your application, so the cycle is only completed once you have access to the data and are able to query it and look at it.

You don’t have to think about it in terms of only knowing today what you’re going to look at, but you have to store it today to then six months later say, “Well, let’s go back and validate this hypothesis,” because you stored all the data.

Dormain Drewitz: I think there’s also something in the notion that has also, certain analysts have commented on, which is that when you’re starting to build the mobile app, you often don’t know and it’s hard to get a good definition out of even your target user base of what they want. People often don’t know what they want, and so you’re going to have to be doing a lot of refining and you’re going to need input to do that refining.

This really just comes down to a classic Big Data problem, storing all this data, doing it in a cost-effective way since you’re not sure how valuable it’s going to be, and so this just gets us to understanding how do we move forward on Big Data challenges?

This is a quote from the CEO for GE Aviation. It’s another example in the internet of things realm which is very closely related to this problem where you have new types of information coming at you, since it’s sometimes a sensor data that’s not in traditional formats and whatnot, and being able to use it, and so the power of the internet of things is really not actually that far off and futuristic. It’s something that can be achieved today, so even though they’re really looking at this, I think, for the turbines, for the jet engines that they build and service. It’s the same process applies in the mobile world.

We’ve got one more tip. I just want to remind folks also that they should be putting in their questions into the Q&A Chat and Twitter with the mobileapptips hashtag, but this last tip is around rethinking testing, which has a couple of different layers to it.

The first data point that I think really can crystalize a big part of this is around just the huge volume of different devices and configurations that exist out there, and the impact that this has on your testing processes, and so I just, to play around with some numbers, just looking at Android alone, you’ve got over 4000 different types of devices and configurations. If you spent just five minutes trying to do testing for those, you’d have 333-plus hours of testing, and so this is an overwhelming task.

There’s a couple different things beyond just how do you automate this. You and I have talked about before, so what are some of the things that folks really need to think about when it comes to testing in the mobile app world?

Farhan Thawar: I think one thing to think about is that agile and QA go hand-in-hand. I know I’ve met some folks who are like, “Well, we have agile, so because we’re releasing all the time, we don’t need to think about QA or automated testing, because we’re just able to rapidly iterate. I think in the mobile world that’s not true, because the hardware requires a level of testing as part of your agile process.

I’m not saying there’s a waterfall QA [step 00:46:19] after it, it’s just as part of agile, it’s part of releasing. You should have QA and that could still be on the order of daily, weekly release cycles.

The way to think about it is that if the core component to make sure your app looks and feels and works as designed on the hardware, and so there is multiple things you can do. There are QA tests which you can run on the mobile devices, and we encourage folks to use an automated approach. Three hundred thirty-three hours of testing, imagine you’re releasing weekly even to internal stakeholders. It is just something you can’t do manually. You want to be able to have some sort of regression that goes across the entire suite.

We work with a sports brand that, imagine we made a change and we have to check that there was a hat available for every sports team across every league. That’s not going to be something that we could do every single time we make a small change to the application, but something that’s very easy to test on a mobile app in an automated way.

Another example is the touchscreen. It has an infinite number of combinations that you could interact with it in. You could have multiple fingers on the phone and you could touch in different areas. You could touch in unexpected ways. We have tests that also test those things to make sure that the app is completely stable over a longer period, so I think that people do need to think about QA and need to think about it in terms of the agile context, not in the traditional waterfall model.

Dormain Drewitz: I think there’s a couple of different ways that you can break this problem down, and the automation can really help with some of those, this is the expected behavior and we just want to test to make sure it’s working, and then there’s the unexpected behavior, which just requires some amount of on-device testing, which brings in the idea of having some way to facilitate that and especially when you’re talking about the type of iteration and release cycles on the order of eight to 12 times per year that we noted earlier.

There’s something that’s just this morning, or this week at least, where we’ve announced the app distribution as a service for cloud foundry, which allows folks to have this repeatable methodology for getting the development build onto devices for testers in a way that scales, and so this is another part of the holistic approach to rethinking testing that needs to happen.

Farhan Thawar: Don’t forget, if you’re doing eight to 12 releases a year, you’re doing many more internally, and that’s why you need something like this. You want to make sure that you have the surface area covered in terms of folks playing with the app plus automated testing, and you can’t do without a service like this, especially when you’re also comparing bills to previous bills, if you’re looking for something. This is also something that’s mandatory.

Dormain Drewitz: It’s something that you may also want to control more in-house as well, and so comes back to using a PaaS-based approach for running this service where with the volume that you’re actually doing internally, it just makes more sense to keep it in-house, whether for security or just simplicity reasons.

We’ve talked about a number of different elements that are actually, touch on the Pivotal portfolio in addition to just the logical best practices to think through, so I wanted to just spend a couple minutes before we close out here on what the Pivotal portfolio is, in particular how it pertains to mobile and mobile apps. One, there’s a lot of different places you can start, but we’ve talked about the notion of a PaaS and having a platform that supports continuous delivery and agile development.

That’s really where cloud foundry, which we mentioned earlier in this call, and the Pivotal release for that, cloud foundry being an open source project, is the Pivotal Cloud Foundry. That of course supports continuous delivery and really cutting down on that friction between developers and operators in order to accelerate the cycle for releases. Then on top of that, we have these mobile services. You’ve mentioned a couple. We talked about the new app distribution service and that those embrace this microservice approach for a very repeatable way for you to build and support multiple mobile apps. That’s another best practice we were talking about.

Then moving around is the notion of also what are you doing with the data that you’re able to collect from these mobile apps? That’s where the Pivotal Big Data suite comes in, offering a very cost-effective way to store huge amounts of data, but then also more importantly, be able to go back and analyze it using especially familiar SQL-based tools that can help come to those insights better instead of having to, six months down the road, realize a) you haven’t been storing the data, and b) if you started today, do you have a way and the skillset internally to be able to mine that data for insights?

That’s also where Pivotal Data Labs then can help provide the data science services to understand and start to harvest that data.

That comes in finally with Pivotal Labs, which is, in terms of building out those apps and embracing an agile methodology, and of course you’re far more of an expert than I am here, but bringing that full circle to close in terms of making sure you have the knowledge in-house and the practices in-house and the knowledge transfer that occurs between Pivotal Labs and your own internal developers, so [crosstalk 00:52:42] …

Farhan Thawar: [crosstalk 00:52:42] I think the way to think about it is that you’re going to do some custom development, web and mobile, whether with labs or on your own. You’re going to test some hypotheses and you’re going to then collect data around that.

You look at that data, you want to analyze that data and say, “Hey, did we actually affect our customers in a positive way or our employees in a positive way?” Then you’re going to get feedback on that and you’re going to go again and then build a new feature or make a change and then look at that data and analyze it again.

The way in which you can go around the circle quickly is using a PaaS like Pivotal Cloud Foundry, and so using Pivotal Cloud Foundry to go around the circle allows you to say, “Let’s build custom apps, let’s gather data from them, let’s store the data, let’s analyze the data, and then let’s make more changes to those apps, and using Pivotal Cloud Foundry allows us to go quickly. That’s how you get to that eight to 12 releases a year and maybe even more frequently, but it really allows you to be responsive to your customers and your employees.

Dormain Drewitz: There’s just a whole new set of challenges in the mobile world that support this approach, so with that, I wanted to thank you for your time and everyone who’s joined us today. We’ve been trying to get back to you on the questions coming in in the Q&A Chat. Feel free to continue to have this coming in and we will be releasing a replay as well as the slides on our Slide Share site,, and so with that, thank you very much for your time.

Farhan Thawar: Thank you, Dormain.

Dormain Drewitz: Thanks.