Have you ever found yourself sitting at a park, walking through the mall, waiting onboard a plane to takeoff, with a couple annoying three-year-olds nearby that simply won’t cooperate? It seems they have this natural instinct to do all the wrong things. Scream and shout. Whine and cry. Disobey commands. And we’re left wishing they just knew how to “play nice.”
“Playing nice” with each other is something application users wish for as well. They want the cloud applications they use to just work together, nicely. They want their applications to share customer data, employee data and contact data with each other without having to call their IT departments . In today’s world, it’s often nasty business to share data across applications in the cloud, mapping fields and having technologies help each other versus hinder. As application developers it becomes our responsibility to take this burden away from our customers, to deliver them apps that instantly cooperate with their other applications.
Enter the Next Generation of Application Integration: Building Cooperative Apps.
Cooperative Apps can instantly share data with other applications in the cloud, without placing an integration burden on the business or user who purchased the app. They work seamlessly with the other apps fitting within their solution space. Cooperative Apps “play nice” with other applications. They share data and seamlessly communicate with other applications just the way you want them to. Cooperative Apps reduce the need for Integration Platform-as-a-Service (iPaaS) offerings originally developed prior to the cloud era of API-based services and applications.
Back in the day (circa early 2000s) the first generation integration services, such as Enterprise Service Buses (ESBs), placed the “Integration Burden” squarely on the shoulders of an IT organization. Applications had not traditionally cooperated well with each other, requiring IT to implement very costly and expensive integration products. The ESB industry served a need when on-premise application dinosaurs ruled the software world, yet they will face the same fate as the on-prem applications they were originally developed to serve. They’ll be valuable in only the most complex use cases where on-premise and custom applications are prevalent.
The next generation of integration service enables application developers to build and deliver apps that instantly cooperate with each other. A “cooperative app” works seamlessly with data that is mastered in other systems. For example, a common use case is connecting customer data from a CRM to lead data in a Marketing Automation system, with files and documents in Box, Dropbox or any of the leading cloud storage services. Apps that “play nice” with other apps will move from preferred to required, as IT organizations and increasingly Line-of-Business Decision Makers will only select apps that fit with the other applications they’re using. The “Integration Burden” will strongly shift from the enterprise to the app developer and going forward, apps that don’t easily cooperate with other apps won’t survive.
Apps can “cooperate” and “play nicely.” While I can’t offer the same sort of manual for life with a three-year-old, I can recommend you take these 5 Steps in Building Cooperative Apps.
5 Steps in Building Cooperatives Apps
1. Start With Categories, Not Individual Endpoints
Your clients will always want options. Options are the delighters when it comes to building an optimal user experience. Knowing your app exists within a vast ecosystem of cloud services and applications your clients are already using, there’s vast opportunity to delight.
To start, identify the categories your application needs to collaborate with documents, CRM, Finance or Applicant Tracking Systems. Do this instead of focusing on individual endpoints. When you think in terms of a category, you consider use cases that broaden the options for your clients beyond designing to an individual endpoint. For example, you will have clients who have Marketing Automation services (the category) from HubSpot, Marketo, Eloqua, Salesforce and more (the endpoints,) so design your integration by considering the data objects and methods common to the category, not just one service. A category approach will have your app cooperating more quickly with a wider range of services, thereby expanding your market share.
2. Collect Data to Prioritize Endpoints Within Each Category
Next, start by supporting the services that will give you the broadest market reach. At a leading job board in company based in the UK, their users’ data were primarily distributed among Google Drive, Dropbox and Microsoft OneDrive for cloud document storage. By collecting this data from the sales and business development team and organizing it into a single cloud document category, the priority individual endpoints became prevalent.