You See, Mobile Enablement is Like Living In a Trailer Park...
"Mobile is not a device, it is a digital strategy and supporting enterprise architecture."
This has been a favorite statement of mine for a while now when discussing mobile initiatives. As mobile application consumers, generally what you see is the end user application only, and not the underlying components that enable the delivery of the functionality and data to your mobile device. Similar capabilities to desktop app or desktop web experience often seem to lead to the misconception that what you see is the same solution, simply ported to a mobile device, when the truth is that a successful mobile experience encompasses far more. Too often we see tough lessons learned as traditional desktop development teams without mobile development experience are tasked to 'make a mobile app and support omnichannel' and IT teams are told to support these requirements with no new investment in architecture to support mobile channels. Unfortunately, when digitizing services and creating mobile applications, consumers and external developers can be fickle and unforgiving communities. Frequent changes to APIs and services and poor customer experiences can turn a sweet concept into a bitter pill that be very difficult to recover from.
A little over a year ago, Axway, the company I work for at the time of this post, acquired a company called Appcelerator, whose focus was largely Mobile Application Development (MAD). Based on the integration since then, I think it is one of the most complimentary acquisitions they could have made. Axway already does a fair amount in the space of exposing data and services securely to the tactical edge, and their API creation and governance capabilities (API Management [APIM]) fall right in line with supporting those requirements as part of mobile initiatives. To someone who understands the challenges of exposing data and services to new consumption channels, it can be very simple to discuss why having a single platform for unified application development that includes MAD and APIM is a boon to an organization. Often however, project leaders can be thrust into a mobile initiative they are not prepared to support, due to the misconception that delivery mobile experiences is the same process as delivering desktop experiences. When this occurs, it is our goal to share knowledge, to educate and help drive a successful outcome.
The challenge with this is that with the ever changing world of technology and all the touch points in a mobile enablement strategy, it can be very difficult to dive right into a technical discussion without quickly overwhelming someone. There comes a time for 'drinking from the fire hose', but often the first step is to really help teams to understand the challenges they will face when embracing mobile strategies, and what they will need to plan on to overcome those challenges. Effectively, rather than treating mobile as a device, help team to develop an appropriate digital strategy and deploy an enterprise architecture that supports their end goal, to the end of delivering a successful and impactful customer experience. When it comes to taking these first steps, I personally am a huge fan of describing technology with metaphors to help people start to put the pieces together by illustrating the parallels between a technology and something someone already understands.
To that point... a mobile application is like a mobile home.
When I have shared this metaphor with colleagues, I have immediately been met from several with skepticism (you know who you are), but I think I have made believers out of them, so bear with me here. Let's start with the definition for a mobile home via good ol' Wikipedia:
Now first thing to note here is that we are not talking about an recreational vehicle (RV) that is meant to be parked in a driveway and taken out on vacations. We are talking about a structure that is built on a chassis, which enables transport, to supply housing potentially on a semi-permanent basis. Now the truth of the matter is, often when we think about mobile homes we think about homes plopped down in a community of similar structures, to stay until its dying day. The reality is however that the concept of a mobile home is a fully furnished structure, capable of delivering accommodation on demand that has the capability to be moved. Often one might see these used in this manner at construction sites to provides an office, restroom, kitchenette, etc. for architects and management. Alright, so if you have stuck with me thus far, lets assume you are willing to work with me and give the metaphor a chance, and not be 'that guy' who wants to argue about why my assumption of mobility of a mobile home is wrong before I even dive into the metaphor.
Let's say that you buy this fantastic mobile home with the idea that you want to travel the states in it, live in 5 different cities for a year each to ultimately decide where to settle down. What is it going to take to move it from point A to B?
Let's talk about moving your new mobile home to your plot at the first location, you know... moving it from on premise at the dealer site to a new platform. Unfortunately it is a bit of a legacy spot. While your connections for electricity and water became standardized after 2010, your first location hasn't been updated since 2005. How are you going to overcome this challenge? In order to supply the resources to make your home functional, you are going to need some converters to enable integration between your home's newer technology and the legacy connectors.
Now once you get there, can you simply drive down the street, back the thing up and drop it? How wide are the roads? Can they handle the wide load without first moving barriers such as cars parked on the street? How about the plot itself; has the neighbor been storing some stuff over the property line since it was unclaimed? Is the plan simply to show up and hope for the best, or are there perhaps some planning and logistics that need to occur first in order to ensure we can transport what we need to where we need it?
When mobile applications and services were first coming into being, the frequent transactions back and forth and the amount of data passed caused issues for mobile networks. They were not engineered to handle all this data flow, causing outages (I cannot find the term for the life of me, I want to say 'mobile storm' or 'cellular storm', but can't find a resource to back it up. Comment section... I would love you forever if you can help out there and overcome this gnawing question from my mind). As a result, while carriers did invest in the network, we also adapted the way we consumed resources on mobile devices. Adoption of lighter weight messaging with formats such as JSON, and stateless calls via RESTful APIs started to shift how services were consumed to adapt to these challenges. hen we talk about planning and logistics, maybe we are referring to changing how resources are consumed by orchestrating multiple API calls into a single request endpoint to limit the calls back and forth, planning for intermittent bandwidth issues. Changes to service consumption such as edge caching for more rapid responses and pagination to send only a subset of the total data in one go may also be parts of a successful mobile strategy.
How about security on your new mobile home? Say your previous house was in a high cost adult-only gated community, where you may be inclined to go as far as leaving your doors unlocked. When moving to a multitennant trailer park, do you feel the same way about leaving your doors unlocked, or might be you inclined to maybe add a deadbolt and a security camera to your new mobile home?
Have you ever had to type a STIG compliant password onto a cellphone screen? Caps, lower case, special characters, numbers... it can be quite taxing. Often with mobile applications we see new functionality adopted, such as OAuth, to provide a better user experience, or technology such as biometrics, enabled by fingerprint readers on mobile devices, utilized instead of passwords. Services that may have previously used HTTP Basic (user/pass) may be updated to support more secure authentication methods, stricter policies, or enhanced security with multifactor authentication. How does this change legacy services? Will they be changed to require biometrics, meaning every desktop now needs a fingerprint scanner? Does it make more sense to use an API Gateway/Management tool to put a mobile abstraction layer in place?
What about moving the mobile home? I drive an F150 that is great for groceries, hardware supplies, and supporting my wife's equine hobby. Say you have something similar. It's possible that this mobile home comes with a greater load that you have had to manage before. Do you have a powerful enough engine to move it? Should you trade in for an F350 given plans to move 5x or pay for a hauling service with a lower up front cost, but potentially ultimately a higher ultimate cost if used 5x, when you might not end up not moving as much as originally planned? If you choose to get the F350, are you allowed to haul a wide load, or do you need to get a CDL to move the home around?
This is another challenge with mobile applications. How do you gauge how much new traffic and revenue might come your way, and the associated loads? On one hand, you can purchase hardware, but this can often lead to overprovisioning. On the other hand does your organization have the knowledge to migrate and operate your current or new functionalities in the cloud? Your resulting API, service, or application may end up being the best solution on the market, leading to record breaking adoption. If you are not prepared for that much traffic and it overwhelms your infrastructure, then your ground breaking offering suddenly becomes unusable. Customers may stop using it and never return, and developers may not trust it enough to utilize the services within their own offerings.
I have some other pieces I though about throwing in (state based licensing and data residency, home owners association requirements and adoption of new tech to update your app [ask Axway about our Alexa skill demo!]), but I think for the purposes of this post the mighty mobile home has served its purpose. Just as the mobile home is a useless hunk of junk without the supporting capabilities to empower it to be mobile and livable, mobile is not a device, it is a digital strategy and supporting enterprise architecture. Building a mobile app is not enough, you have to be able to support everything that goes into enabling it to perform consistently and securely over remote networks.
This has been a favorite statement of mine for a while now when discussing mobile initiatives. As mobile application consumers, generally what you see is the end user application only, and not the underlying components that enable the delivery of the functionality and data to your mobile device. Similar capabilities to desktop app or desktop web experience often seem to lead to the misconception that what you see is the same solution, simply ported to a mobile device, when the truth is that a successful mobile experience encompasses far more. Too often we see tough lessons learned as traditional desktop development teams without mobile development experience are tasked to 'make a mobile app and support omnichannel' and IT teams are told to support these requirements with no new investment in architecture to support mobile channels. Unfortunately, when digitizing services and creating mobile applications, consumers and external developers can be fickle and unforgiving communities. Frequent changes to APIs and services and poor customer experiences can turn a sweet concept into a bitter pill that be very difficult to recover from.
A little over a year ago, Axway, the company I work for at the time of this post, acquired a company called Appcelerator, whose focus was largely Mobile Application Development (MAD). Based on the integration since then, I think it is one of the most complimentary acquisitions they could have made. Axway already does a fair amount in the space of exposing data and services securely to the tactical edge, and their API creation and governance capabilities (API Management [APIM]) fall right in line with supporting those requirements as part of mobile initiatives. To someone who understands the challenges of exposing data and services to new consumption channels, it can be very simple to discuss why having a single platform for unified application development that includes MAD and APIM is a boon to an organization. Often however, project leaders can be thrust into a mobile initiative they are not prepared to support, due to the misconception that delivery mobile experiences is the same process as delivering desktop experiences. When this occurs, it is our goal to share knowledge, to educate and help drive a successful outcome.
The challenge with this is that with the ever changing world of technology and all the touch points in a mobile enablement strategy, it can be very difficult to dive right into a technical discussion without quickly overwhelming someone. There comes a time for 'drinking from the fire hose', but often the first step is to really help teams to understand the challenges they will face when embracing mobile strategies, and what they will need to plan on to overcome those challenges. Effectively, rather than treating mobile as a device, help team to develop an appropriate digital strategy and deploy an enterprise architecture that supports their end goal, to the end of delivering a successful and impactful customer experience. When it comes to taking these first steps, I personally am a huge fan of describing technology with metaphors to help people start to put the pieces together by illustrating the parallels between a technology and something someone already understands.
To that point... a mobile application is like a mobile home.
When I have shared this metaphor with colleagues, I have immediately been met from several with skepticism (you know who you are), but I think I have made believers out of them, so bear with me here. Let's start with the definition for a mobile home via good ol' Wikipedia:
A mobile home (also trailer, trailer home, house trailer, static caravan, caravan) is a prefabricated structure, built in a factory on a permanently attached chassis before being transported to site (either by being towed or on a trailer). Used as permanent homes, for holiday or temporary accommodation, they are left often permanently or semi-permanently in one place, but can be moved, and may be required to move from time to time for legal reasons.
Now first thing to note here is that we are not talking about an recreational vehicle (RV) that is meant to be parked in a driveway and taken out on vacations. We are talking about a structure that is built on a chassis, which enables transport, to supply housing potentially on a semi-permanent basis. Now the truth of the matter is, often when we think about mobile homes we think about homes plopped down in a community of similar structures, to stay until its dying day. The reality is however that the concept of a mobile home is a fully furnished structure, capable of delivering accommodation on demand that has the capability to be moved. Often one might see these used in this manner at construction sites to provides an office, restroom, kitchenette, etc. for architects and management. Alright, so if you have stuck with me thus far, lets assume you are willing to work with me and give the metaphor a chance, and not be 'that guy' who wants to argue about why my assumption of mobility of a mobile home is wrong before I even dive into the metaphor.
Let's say that you buy this fantastic mobile home with the idea that you want to travel the states in it, live in 5 different cities for a year each to ultimately decide where to settle down. What is it going to take to move it from point A to B?
Let's talk about moving your new mobile home to your plot at the first location, you know... moving it from on premise at the dealer site to a new platform. Unfortunately it is a bit of a legacy spot. While your connections for electricity and water became standardized after 2010, your first location hasn't been updated since 2005. How are you going to overcome this challenge? In order to supply the resources to make your home functional, you are going to need some converters to enable integration between your home's newer technology and the legacy connectors.
Now once you get there, can you simply drive down the street, back the thing up and drop it? How wide are the roads? Can they handle the wide load without first moving barriers such as cars parked on the street? How about the plot itself; has the neighbor been storing some stuff over the property line since it was unclaimed? Is the plan simply to show up and hope for the best, or are there perhaps some planning and logistics that need to occur first in order to ensure we can transport what we need to where we need it?
When mobile applications and services were first coming into being, the frequent transactions back and forth and the amount of data passed caused issues for mobile networks. They were not engineered to handle all this data flow, causing outages (I cannot find the term for the life of me, I want to say 'mobile storm' or 'cellular storm', but can't find a resource to back it up. Comment section... I would love you forever if you can help out there and overcome this gnawing question from my mind). As a result, while carriers did invest in the network, we also adapted the way we consumed resources on mobile devices. Adoption of lighter weight messaging with formats such as JSON, and stateless calls via RESTful APIs started to shift how services were consumed to adapt to these challenges. hen we talk about planning and logistics, maybe we are referring to changing how resources are consumed by orchestrating multiple API calls into a single request endpoint to limit the calls back and forth, planning for intermittent bandwidth issues. Changes to service consumption such as edge caching for more rapid responses and pagination to send only a subset of the total data in one go may also be parts of a successful mobile strategy.
How about security on your new mobile home? Say your previous house was in a high cost adult-only gated community, where you may be inclined to go as far as leaving your doors unlocked. When moving to a multitennant trailer park, do you feel the same way about leaving your doors unlocked, or might be you inclined to maybe add a deadbolt and a security camera to your new mobile home?
Have you ever had to type a STIG compliant password onto a cellphone screen? Caps, lower case, special characters, numbers... it can be quite taxing. Often with mobile applications we see new functionality adopted, such as OAuth, to provide a better user experience, or technology such as biometrics, enabled by fingerprint readers on mobile devices, utilized instead of passwords. Services that may have previously used HTTP Basic (user/pass) may be updated to support more secure authentication methods, stricter policies, or enhanced security with multifactor authentication. How does this change legacy services? Will they be changed to require biometrics, meaning every desktop now needs a fingerprint scanner? Does it make more sense to use an API Gateway/Management tool to put a mobile abstraction layer in place?
What about moving the mobile home? I drive an F150 that is great for groceries, hardware supplies, and supporting my wife's equine hobby. Say you have something similar. It's possible that this mobile home comes with a greater load that you have had to manage before. Do you have a powerful enough engine to move it? Should you trade in for an F350 given plans to move 5x or pay for a hauling service with a lower up front cost, but potentially ultimately a higher ultimate cost if used 5x, when you might not end up not moving as much as originally planned? If you choose to get the F350, are you allowed to haul a wide load, or do you need to get a CDL to move the home around?
This is another challenge with mobile applications. How do you gauge how much new traffic and revenue might come your way, and the associated loads? On one hand, you can purchase hardware, but this can often lead to overprovisioning. On the other hand does your organization have the knowledge to migrate and operate your current or new functionalities in the cloud? Your resulting API, service, or application may end up being the best solution on the market, leading to record breaking adoption. If you are not prepared for that much traffic and it overwhelms your infrastructure, then your ground breaking offering suddenly becomes unusable. Customers may stop using it and never return, and developers may not trust it enough to utilize the services within their own offerings.
I have some other pieces I though about throwing in (state based licensing and data residency, home owners association requirements and adoption of new tech to update your app [ask Axway about our Alexa skill demo!]), but I think for the purposes of this post the mighty mobile home has served its purpose. Just as the mobile home is a useless hunk of junk without the supporting capabilities to empower it to be mobile and livable, mobile is not a device, it is a digital strategy and supporting enterprise architecture. Building a mobile app is not enough, you have to be able to support everything that goes into enabling it to perform consistently and securely over remote networks.
Comments
Post a Comment