Feature
To achieve competitive advantage, large organizations today are developing mobile applications that meet three key objectives: 1) enable new mobile business processes for employees, 2) meet the growing mobile demands of customers, and 3) unlock new revenue potential within their business and with partners.
To accomplish this, organizations often need to integrate mobile apps with enterprise systems and data — collectively referred to as the backend.
Organizations that do not integrate mobile apps securely and effectively with their existing backend infrastructure will face competitors whose employees are more productive, whose customers are more satisfied and whose ecosystem fuels new business opportunities.
DIY vs. BaaS
Historically, many IT departments have gone the do it yourself route to mobilize business processes, often by using homegrown solutions and at other times by cobbling together various third party tools. But just as the cloud has disrupted virtually every other business function, cloud-based mobile middleware solutions, otherwise known as cloud-based Backend as a Service (BaaS), are now emerging as viable alternatives to DIY.
The motivation of these BaaS adopters is easy to understand. Why spend time developing and maintaining something that isn’t your core competency when you can outsource that component to a proven, more cost effective vendor?
Tackling enterprise mobile integration challenges with BaaS instead of homegrown solutions achieves benefits in speed, cost, quality and reliability. Perhaps more importantly, BaaS enables a “UX first” development approach that leads to consumer grade enterprise app experiences. This leads to higher user satisfaction and, ultimately, improved margins.
To prove my point, let’s compare five stages of the app development process:
Selecting Target Mobile Platforms
DIY: In the era of bring your own device (BYOD) for the enterprise, successful apps live across multiple client endpoints – iOS, Android, Web, etc. With the DIY approach, developers are limited in the number of mobile platforms they can support, in part because they have to devote resources to building a different back end connection to each platform. And there are a lot of platforms. This typically means that the interface between each data source and each mobile client must be custom tailored, which also means there is a potentially astronomical number of unique source to mobile connections that must be developed and maintained over time.
BaaS: By serving as an any to any universal connector, a BaaS can provide a single interface to any mobile platform. It essentially “commoditizes the pipe,” meaning that there is no additional connection “toll” to pay to plug a given back end data source into another mobile platform, or to plug a given mobile platform into another back end data source.
Analyze Backend System Interfaces
DIY: How does the backend present its data to the outside world? What type of inputs will the client app give the back end and what type of outputs will the client expect back? What type of API exists on the back end? What’s the connection protocol? How will the app handle poor network connections and offline behavior? How will the back end handle errors? What response codes will be returned? These are some of the questions the DIY developer needs to ask and answer before moving forward.
BaaS: A BaaS implementation provides out of the box solutions to these challenges so that developers can focus on the front end.
Select Middleware Technology that Works with Backend Interfaces
DIY: Developers need middleware technology that generates compatible APIs for the client, such as Apache Axis2 or WSClient++. Developers must be familiar with the appropriate tools and make an evaluation as to which tool is best suited for their specific situation.
Learning Opportunities
Webinar
Apr
30
Supercharge Contact Center Efficiency with Generative AI
Learn practical strategies to reduce post-call documentation time by over 8 minutes.
Register
Conference
May
1
Qualtrics X4 Salt Lake City 2024
Register
Webinar
May
2
Unleash AI for Crisis Management: Transform Threats into Triumphs
Learn how Sprinklr Insights provides real-time insights on current events, trends, and brand crises to empower your team.
Register
Webinar
May
9
Driving Customer-Centricity in the Financial Services Industry
Discover how financial organizations are leveraging generative AI technologies.
Register
Conference
May
9
An Irish Roundtable in the Valley: The Economic Impact of AI on the World of Work Stanford 2024
Exploring the Impact of AI On the World of Work with Irish diaspora leaders and tech business champions from the North of Ireland
Register
Conference
May
13
Gartner Marketing Symposium/Xpo Conference London 2024
Register
BaaS: Not needed. Out of the box, BaaS generates a REST interface that maps to the API, which the organization then tailors based on data field mappings, and so on.
Generate the Backend Interface
DIY: Once the middleware technology is selected, other implementation choices also need to be made -- and both the front end and back end developers need to agree on these choices. This agreement is necessary if the front end developer will build an interface to the back end that the back end developer is expecting.
What makes this agreement so challenging is that there are so many areas on which the two must agree in order for the interface to work -- and in a DIY scenario, front and back end developers may need to negotiate every single item. Areas of potential disagreement run the gamut from high level architectural decisions (like how to implement client side caching, if at all) to more granular decisions, such as whether the data passed from back end to front end will come over the link in an array .
Once an interface strategy has been decided, there is an array of implementation details on which the front end and back end must agree, including how to move data between the two, caching, offline operation, and features such as social log ins and security.
BaaS: BaaS takes this back and forth between development teams off the table. Consequently, there is less rework and therefore much less time spent on conference calls and email, so resources are used more efficiently.
A BaaS can make coming to agreement simpler in two key ways. First, it can greatly reduce the number of variables over which the front end and back end teams need to negotiate and, second, it can make it easier for them to negotiate over those remaining variables. The number of variables is reduced to the extent that the BaaS provides off the shelf connections to enterprise data that the development team would otherwise need to create on its own. And BaaS decouples the front and back end development processes, so that developers can focus on building great front end experiences while IT integrates the necessary back end systems. Once both processes are complete, connecting the two is just a matter of flipping a switch.
Handling Security
DIY: There is a lot to do here in the DIY approach. Much of it has to do with how the code on both the back end and front end will manage OAuth tokens and provide support for user authentication flow. OAuth is one of the newest measures for integrating security for the enterprise, and is currently one of the measures being most rapidly adopted for authenticating users of a web service.
Part of OAuth’s appeal is that it passes encrypted tokens between clients and servers rather than usernames and passwords, and that the tokens are provided by a trusted third party service. It is that third party that receives, authenticates and stores usernames and passwords -- not the organization’s own server. The benefit is there is much less exposure to man in the middle attacks by which credentials are intercepted and decrypted.
BaaS: With BaaS, you can leverage the BaaS provider’s OAuth security in conjunction with enterprise authentication including LDAP, Active Directory and SSO via connectors. The combination delivers secure, enterprise grade, identity management. OAuth support generally involves installing a BaaS solution library and the OAuth service provider’s authentication library (enterprise or other 3rd party identity management), which work together to create an identity.
Installing the BaaS library means the mobile app already has the functionality to encrypt user credentials, pass them to the OAuth authentication service as the service prescribes, and handle the three way interchange between client, server and the OAuth service provider.
Adding It Up
As you can see, the built in functionality of BaaS means there is less risk of front end versus back end incompatibilities; hence, less time spent by development teams going back and forth looking to prevent or troubleshoot issues. It also means that developers avoid handling complex middleware, getting up to speed on the latest OAuth security protocols, engineering advanced caching policies across potentially dozens of different devices, and much more.
Instead they can focus on what truly makes a difference to their organizations -- the front end functionality and experience the mobile app delivers to users. A better, more differentiating experience delivered at far less cost and on a much shorter timeline -- now that’s how you make a successful enterprise mobile.
