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.
3. Draft Your Cooperative App Use Model
An application doesn’t exist on it’s own. Create a model that depicts the vast ecosystem of integrations at your organization, organized by the categories identified in Step 1 and the prioritized end-points you gathered in Step 2. Keep in mind that integration is a means to an end, and collaboration is your goal. The ideal user experience is an application seamlessly interacting with data your customer has stored in other applications while never leaving your app. Focus on the benefits your applications users will receive by cooperating with other apps in the category you selected.
Here’s a use case to hit this topic home: As a marketer, I want to promote, launch and execute a webinar on a leading web conferencing application. To make my life easier, I aim to have my email lists stored in our CRM, registrants tracked in the web conferencing app and activity cards updated back in the CRM as they attend the webinar. Furthermore, I’d like to share the presentation via Box after the webinar using our messaging platform. Integrating these applications enables me, as a marketer, to effectively generate new leads and convert to qualified opportunities for sales.
4. Develop Integration Use Cases
Integration use models typically follow a consistent pattern, and you can use this pattern to guide the definition of the user stories required to develop cooperative use cases for your application. Note: “endpoint” is used to refer to the cloud application or service you’re connecting your application to. Discover your application’s integration pattern by evaluating these 10 dimensions of integration use cases:
1. Select – Where will my app present the user interface to select the endpoints the user will connect with your app?
2. Authenticate – How will I manage the authentication for each endpoint I’m connecting with my app? What type of authentication mechanism does the endpoint use (e.g., OAuth, SAML)? Where will I store and refresh the keys?
3. Objects – Which standard objects does my application need from each endpoint? What are the fields available for each data object?
4. Methods – Which methods do I want to support for each object? Determine which CRUD (Create, Retrieve, Update, Delete). How about Search capabilities?
5. Browse – How will users browse files and/or data from the endpoint?
6. Discover Custom Data – Do I need to discover custom data fields and custom data objects from the endpoints?
7. Map – How will I map standard and custom data objects and fields to my applications data model? WIll I give the user the ability to override my default settings for standard objects? How will I treat custom objects and data, and map that into my application’s data model?
8. Transform – Do I need to transform any of the data structures? Are formats for Date, Time and other values consistent?
9. Events & Synchronization – Are there events (e.g., changes to a data object) that my application needs to be alerted to?
10. Operations – Does my support and operations team need logging and usage data to support the integration? How will I handle alerts and notifications from the vendors regarding service outages, API changes, etc?
5. Build and Release an MVP (Minimum Viable Product)
Now that you’ve defined a broad set of integration use cases, it’s time to narrow the stories down into an iterative release plan so you can get your cooperative integration use model to market and gain feedback quickly. Some typical considerations for MVPs include:
a. Implement read-only use cases first. Delay the create, update, delete user stories until later releases. Get the data moving between the apps first and then provide a means to update it later.
b. Initially include only standard data objects and standard data fields from the endpoint.
c. Provide a standard mapping of standard data. Provide the ability for the user to change your default data mapping and transformations in future releases.
d. Delay implementing more complex event handling and data synchronization scenarios until later releases.
Your clients want to interact with the other apps and cloud services they’re using. Don’t inhibit them. Help them by making your app cooperative.
