Develop Mobile Apps with Clear Goals in Mind: An Interview with Shadi Saifan

Josiah Renaudin: Well, today we're joined by Shadi Saifan, the director of engineering at FIS Mobile, and a speaker at our upcoming Mobile Dev + Test event. His presentation is titled "Architect a Winning Mobile Application." Shadi, thank you very much for joining us.

Shadi Saifan: Thank you. Thank you so much for having me.

Josiah Renaudin: No problem at all. First, could you tell us just a bit about your experience in the industry?

Shadi Saifan: Yeah, absolutely. So, my experience with mobile in specific started back in early days of the year 2000/2001. That's when, you know, I would say the first building blocks of really mobile applications gained some popularity, and that was with the technology of WAP, the wireless application protocol, and the release of first version of WML which is the makeup language that went with it.

At that time, I was working at Hewlett-Packard in one of the IT departments there. I was lucky enough to get an opportunity of actually playing and trying to make a quick proof of concept. That was when I got a web-enabled device that was a Nokia device at that time.

I spent about two to three years working on different proof of concepts on the mobile technologies from connecting exchange and email to a web-enabled phone into experiencing with voice and voice xml and, you know, all the way into sending financial data to the phone. That was completely within R&D umbrella and not for or to be released at a larger scale. That's like in the early days.

Yet, what we have seen is about five or six years from the year of 2002/2003 where mobile completely gained a big shift in capabilities and what it can do. Back in the days when Windows Mobile was probably a dominant in the market we have seen, again, changes coming in with Apple and the release of iPhones.

During those years, a lot of my focus was mainly on the financial industry. I literally kept an eye on that and I finally made a decision of leaving my job at that time when I was in the consulting industry to work with a couple of other technology leaders in a start-up. That was back in 2007.

The focus was completely on the mobile industry with OMA, OMA-DM which was like the device management of Open Mobile Alliance to be a focus of what we wanted to do. That's when I got a start with the Windows Phone and Windows Mobile work by designing agents to set up email and to wiping data that includes contacts. Here in 2007, I got to learn the Objective C language and I was able to release my first mobile application into the App Store. The name of it was "Mobi-Wee," but it was literally a phone that would enable many of what became system-specific services that comes with Apple OS and Android OS services these days, such as backing up contacts, retrieving contacts, locating device, wiping data, locking phones, etc.

The focus and interest continued from there into taking the mobile app into the next level considered as part of a larger ecosystem simply because, yes, there is so much value in applications when you create them for games and for complete experience on mobile. But in my opinion, the automation, the collaboration, and the capability of being part of a larger ecosystem that includes servers was where there is largest value … we were fortunate to open up for many businesses outside of standard gaming and other things.

So that's when I started working on linking the mobile device into like a desktop Windows gadget or widget, if you will, being able to show SMS messages on desktop, etc. Unfortunately, 2008 came in with, you know, the whole economic problems and eventually I had to put a stop on that start-up for economic reasons. But I did pick a job with FIS Mobile. At that time it was a start-up called mFoundry that was literally on the mobile market for banking and payments.

That's where I spent more than five years of my time, and I'm still there, building different banking applications and payments applications at a massive level for small banks, credit unions, large banks, and large retailers. I got the honor to work on the first release of what I would consider the largest payment system or the first largest payment system that was cloud based. It was a Starbucks application.

Josiah Renaudin: And like you just said, you have a lot of experience in the mobile world, so it makes a lot of sense that you'd be going to Mobile Dev+Test and having a session there. So, when designing a mobile app, is it important to fully grasp exactly what you're making from the start, because without a solid foundation, can you actually create a functional product? It seems like a lot of people go into a mobile app having an idea of what they want to build, but maybe not this perfect picture. There are certain pieces missing. Would you argue that you need to have a stronger, clearer picture of what you want to make before going into it?

Shadi Saifan: You know, I definitely would agree and argue that understanding what the foundation is and what the options are would be extremely essential in building a winning mobile application. You're right about something. People can learn the language. They can read and Google different docs and how to it, and produce their first application, and put it in the marketplace or in whichever market for consumption. That app might be a great app to start with.

But what people usually don't think of on their first application is, what's after that? You have to think of maintenance, upgrades, support. You also need to think of … am I building an application that is secure enough? Am I building it with understanding of performance in mind? Did I actually pick the right technology to start with? This is like a very, very difficult question. I mean, I have seen many applications being built in specific technology and companies shifting back into something else, and even shifting again, you know?

Having a good foundation of what makes an app a really good app is important. But I also want to make a point here that sometimes there is no right and wrong divisions in technology. But there are the considerations. There are the pros and cons of going in specific directions versus another, investing time and effort in understanding your options. Planning right for what you're building would pay back eventually down the road and it's probably the best investment you can do before you think about releasing any application to the market.

Josiah Renaudin: Your discussion is about architecting a winning mobile application. But I think in order to understand how to make a winning application, you need also to understand what makes applications fail. So can you name a poor architectural decision that could sink a mobile app before it even makes it to the market?

Shadi Saifan: You know, this is a very good question. I can't think of any specific thing that would make it fail, but there are many divisions that can participate in that, meaning there is no one specific reason, but many things can participate into failing.

In my opinion, not thinking of the usability of your application is probably one big reason for any app to fail. You know, you can build an app thinking how you are going to use it yourself. But taking opinions and ideas of others and what they think about the usability of it is extremely crucial in that. Second is, and there are multiple, divisions … Second is, from a technology perspective. If you don't think of the performance of your application, how long it takes to make a request to a server and get response back, how large is that response, how long does it take for the CPU of your device to actually process that data?

If you don't start learning about that and making the right decisions about them, you application will fail. Add to that performance related to concurrent sessions and how many users will be accessing your servers the same time if you have a server side of it. You will have to account for different network speeds. For example, you cannot make assumptions that you will always have fast internet connection.

I mean, we know that mobile devices these days would switch between WiFi, 4G, etc. There will be times when people may have low connection or even no connection. How your application will respond to that is extremely essential. Of course, I'm not focusing on the main reasons from business perspective because I'm trying to think of technology here. But there are so many positions that people can do and can make them fail eventually, or can make their application fail.

I don't know if that provided a good answer.

Josiah Renaudin: No, it totally did. You don't want to hone in on every single issue that would make it fail. I mean, it's hard to understand that, but I think that was a good explanation of what could make it struggle before it reaches launch.

Now what are the differences between developing mobile browser-based applications and developing native apps?

Shadi Saifan: You know, this is a very good question and it's really in the heart of my job here at FIS. There is no secret here. In the mobile application for banking that FIS did, we went native and in the past five or six years, we have made decisions to switch between third-party framework, adding more HTML content to go back to native.

It's always an interesting situation to be in when you have options and you have to factor in so many things related to that decision. But in my opinion, the main difference between mobile browser-based applications and developing native is about experience and access to native features and functionality.

Today, if you build an iOS app or an android app or whichever technology you use, as long as it's native by default, you would have access to device features. GPS, cameras, capture ID, IUS, contacts, etc.

When you do a browser-based, you're basically making a trade-off. You're saying that I am not going to use a native experience and I will compromise some of the access that comes with native at the expense of using a technology that I would have people who are more familiar with HTML-5 or JavaScript.

All these technologies are very popular and easy to find that expertise in the market. Compromising that would build once and make it available on different form factors. It's really a trade-off. There isn't really a right answer or a wrong answer here. It just depends on what your business and technology goals of your applications. I would say that, if you go native, you're choosing a consistent native experience that the end-user would see on different native applications and you're using the route of accessing features that comes with device.

However, if you're building a browser-based application, then you're choosing the route of I want to do it quick, I want to be able to change it on the fly and I don't have to push an application to the marketplace, and I want to use a very common technology that I can see or I can find so many developers who would be able to do this for me.

You know, I would say these are like the main differences between the two approaches, if you will.

Josiah Renaudin: Like you had said earlier, there's never really one right answer for a lot of these questions and that kind of seems to be something that's a theme in mobile, because there's never one right answer because all the apps are so different. All of them have different needs.

One thing that I think a lot of apps, even all apps, need to consider is security. Security's become a big issue for large companies and small companies. What new security challenges has mobile development brought on that weren't as prevalent on standard PCs?

Shadi Saifan: Yes, a very good question. I think there are similarities and there are differences. Probably one of the major differences is that your mobile device is always with you. It's not a desktop or a laptop that you would keep at home or at work. It's mobile, it goes out with you. That by itself adds more into security related to device fingerprints, if you will, networking, as well as data storage, because you are more likely to lose your mobile device than losing your desktop or your laptop for that matter.

Add to it the natural differences in operating systems, on storage, etc. So that probably would be like the main difference between a desktop and mobile. However, there are similarities. I mean, in both cases you want to make sure that networking is being secured regardless of your accessing your server or application from a mobile device or a desktop. Data and encryption should be implemented there.

For the most part I would say the main thing to keep in mind when you talk mobile is the fact that your mobile device is something that you're more likely to lose. Because of that you would have to have more … you want to be more careful into making decisions related to securing data that goes on device, and securing the applications that anyone could get an access to.

Mobile banking is at the heart of what my company works on and for us, security is the great challenge, and continues to be a great challenge as we progress. Therefore, whatever you do, it's never enough. There is always a way, or hackers will always be racing with you in terms of finding ways to do things.

On the bright side of things though, we have to give credit to companies like Apple and Google who put security on top of their focus. You know, both platforms, for example, come with equate security features that would make the job of the architect, designer, and the developer much easier. It can get down into just learning how to take advantage of that and not have to reinvent the wheel and finding those security solutions.

Josiah Renaudin: Absolutely. There's always a need for new security solutions because of the fact that hackers and different groups are always advancing their technology, too. They're learning new ways to get into systems. Upgrading is something that's really important to mobile. There's always apps that need to be … every time you turn your phone on, like, your Facebook app is updating, your Twitter app is updating. How important is it to make mobile apps that are both simple and easy to upgrade?

Shadi Saifan: You know, this is actually extremely critical in many, many industries. I would argue probably every single app would have that problem. You know, like I said at the beginning of this interview, when people think about building their first application, they hardly think about maintenance and upgrades. It's extremely critical for a reason related to the business purpose of your application or for reasons outside of your control, like recently, Apple came up with requirements of 64-bit to be part of their application.

So there are, like, many factors, internal and external, that would require you to upgrade your application. Of course, aside of like releasing other versions or newer versions of devices and operating system. The importance of it is something that you cannot ignore as a developer, as a designer, as an architect, and as a business owner. Therefore, you will have to look back into what is it that you're building and what is it that you're releasing.

What people may not know is that what you are building is a complete black box of thousands of lines of code, so that may not be architected right. Yeah, it's the time of upgrade and maintenance when you will know that, okay, you know what? I should have done this in a better way.

That's why in different organizations that I've been part of and in the different releases of applications that we had, we always look into layering our applications. We're looking into, do we have the building blocks of framework available? Do we have different modules and layering between modules that would somehow create a layer between UI and between the service that will support it because that's always become important when you come into upgrading, you know?

Sometimes you will need just to make a minor change here or there and you don't want that process to be a lengthy process. You don't want to be rewriting your code as part of that process. So it's completely critical that you think of that. You know, add to it the QA and the testing of your application. Everytime you make a change to your app you'll have to account for the QA effort that goes with that and, therefore, upgrade can become very expensive.

It's extremely critical that you plan for your upgrade and maintenance ahead of time. You architect your application in a way that is modular, in a way that, when you need to make a change to speak to an upgrade, is that you make it in a place where you don't have to touch so many places of your code which will eventually make it cheaper, faster, and more efficient as you do this upgrade.

Josiah Renaudin: Fantastic. Well, I have one more question for you, Shadi, and this one is not as closely related to your discussion, but more of a personal one. What about the future of mobile apps has you the most excited?

Shadi Saifan: You know, this is a great, great question. What gets me excited is the fact that we're not only talking about mobile phones. I like the way, you know, you said mobile apps. Mobile apps can run on other than phones. Can run on glass, on a watch, on a camera, on a mirror, you can get as creative as you want in where an application can run.

So, from my perspective, I feel like the most exciting part of things is that we get to a point where we would build a mobile application on a mobile device, and we would actually be able to make that mobile app collaborate or work with some features running on different wearable materials like glasses or a watch or others.

It gets me excited because I feel like this is where we started in mobile. I mean, there was a time when the CPU available in mobile, the RUS, just produced so much limitations of what you can build on them. Today I feel like what we're seeing is probably a similar trend on these wearables, but with the advantage of being able to parallel that or connect that to your mobile device. It's really great. I mean, thinking of how far we can go with these wearables excite me and I myself am extremely interested in looking into some of these wearables and what we can do on them.

We at FIS Mobile are extremely innovative on what we can do to help our customers in delivering their data into all these different channels, and wearables are a large part of it, and it's going to be probably a part that we focus on going forward.

Josiah Renaudin: There's really a lot to look forward to in both, like you said, just mobile applications which can be on things beyond phones and phones in general. Everything is always expanding. It's always going into a new direction, so that will be really interesting to look at, both in 2015 and moving forward. Thank you very much for your time, Shadi. I really appreciate you coming on the phone and talking to me about all this. I'm looking forward to hearing more about creating winning mobile apps when you have your session in San Diego.

Shadi Saifan: The pleasure is mine. Thank you so much for your time.

Director of engineering at FIS Mobile, Shadi Saifan is leading solution strategy and solution engineering and QA for all FIS Mobile client initiatives. Shadi is a professional technology leader with fifteen years of experience in delivering distributed, mobile, and enterprise solutions—with a focus on architecture, design, and development. With extensive knowledge in mobile technologies and platforms, he has worked with a large number of clients, cross-functional teams, and a network of service providers to implement highly scalable distributed projects for the mobile channel. Shadi previously worked for Deloitte Consulting, IBM Global Services, and Hewlett-Packard in various design and technical roles.