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.
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.
- Endangered Species: The Corporate Intranet
- Forget Intranets, Give Me an ESN
- Are These Vendors the Best at Social Media Monitoring?
- Beware Red Herrings: Intranet vs. ESN is a Sham
- Multitasking? You're Killing Yourself for Nothing
- Microsoft's New BI Tool Plays Nice, Even With 3rd Party Vendors
- Discussion Point: Why Would You Buy a Proprietary CMS?