As part of our “Challenges CMOs Face” series, we addressed 8 common challenges encountered by CMOs and marketing leaders, and included insight on how to overcome them. Our recommendation is to develop a long-term agile marketing roadmap to overcome common challenges. For our “Roadmapping – Next Steps” series, we have invited industry experts to provide their insights to help you take your marketing strategy to the next level. In this post, Mark Cowan at Put it Forward discusses the strategy and processes required for custom integrations.
Data integration is no longer about connecting one system or application to another. It’s about connecting people, systems and data to enable unrestricted collaboration and cohesive data stories. One story is your customer lifecycle. The right approach to data integration makes your customer lifecycle visible and actionable from the first contact through every touch point, so employees involved along the way have the information they need to do their jobs.
What is the right integration approach? We operate in a world of choices, and one in which we are trying to create platforms on which to operate our businesses. In a platform view, disjointed products need to work together. The integration method you choose determines how well the products connect and transfer data and the degree to which you can control your data and data quality, transparency, measurability, usability and security ― and ultimately your data stories.
Ideally, data integration is comparable to snapping together a toy’s colored plastic squares. The pieces all fit, and each piece connects with others to form one cohesive unit.
Integration Types: True Effects on the Business
Purchasing trends are shifting from IT to line of business (LOB) buyers who are trying to solve a problem quickly ― improving collaboration or generating revenue, for example. The enterprise data strategy and integration approach most likely aren’t decision factors, but they should be.
Integration approaches fall into two categories: code-based and configuration-based.
Code-based integration is point-to-point integration, like a string fixed between soup cans. Point-to-point integration allows simple data transfer in one direction with field-to-field mapping. Users can’t validate or correct data because they have no visibility into the data flow. Point-to-point integration, which is not recommended to connect more than three points, is supplied in these forms:
- Native integration ― branded or “skinned” by vendors that deliver it with their products. Leads to platform brittleness because swapping out anything is difficult.
- Vendor-embedded ― vendor-licensed third-party code embedded inside a product.
- Developer-supplied ― costly custom code that involves many enterprise resources and takes weeks or months to move through development, testing and quality assurance before it goes into production.
The outcome of code-based approaches? Multiple, parallel, opaque, inflexible integrations that hide and restrict data flow. While a vendor-supplied native integration is “free,” it doesn’t provide control. And costs can add up quickly when you consider code fixes, decisions based on bad data, and missed opportunities resulting from lack of analytics.
Third-Party Configuration-Based Integration
A third-party configuration-based integrator takes ownership of applications, code, and maintenance, relieving enterprises of the burden of deployment and management. Put It Forward’s data automation network integrates data services, development, and management tools, offering a “flip the switch” approach that allows business rules, properties, and schedules, all in one platform. Using preconfigured templates, users can connect applications in a few minutes, enabling bi-directional data transfer and even on-the-fly changes. All with no data throttling, memory allotments or scalability limits.
This approach easily solves LOB problems, and it shifts the conversation from technical integration to business integration. IT can manage at the platform level and better orchestrate where data is going or where it needs to go. Instead of writing code, developers can focus on strategic business issues.
Configuration-based integration puts enterprises on the path to:
- Platform independence
- Application independence
- Control of data stories
- Lower overall platform cost
Outcomes of configuration-based integration:
- Reduce lead qualification time by up to 175%
- Increase productivity by 10-20x
- Increase customer satisfaction by up to 6x
Integration Roadmaps: What to Watch For
The more information you can get about vendor intentions, the better, right? Yes, if it’s the right information, and it’s relevant to your situation. Unfortunately, vendor roadmaps may not be as useful as you think. Here’s why.
Roadmaps aren’t integrated among vendors or with enterprise data flow requirements. Nor do they address product-API integration, where data resides, or how to share data that needs to be associated with new product features. When vendors change direction or drop support for certain products, features or APIs, users are left to figure out workarounds or new solutions – sometimes with little notice and at considerable expense and disruption.
To learn more about the specific roadmaps to ask about, download our whitepaper, “The Truth with Native Integration”.
Vendors: What They Do and Why It Doesn’t Scale ― the Minimally Viable Product
Businesses are self-serving. Each one moves independent of other companies, focused on its strategy and technology and on how to sell its products and solutions. How an application works with other applications is generally of little concern. Technology vendors understand, however, that their products and solutions need to connect with others to some extent or they won’t be adopted. Even if the connection is minimally viable, they can demonstrate that their software plays nicely with others and isn’t an island of technology, even if it is platform-limiting.
The reality is that vendor-supplied native integration is a sales tool, often in the guise of an open API. Of course, open API really means “go build it.” Nonetheless, native integration eases the purchase process and locks an application into another application in the environment.
Integration Choices: Effects on Performance and Data Quality
A reflexive, just-in-time, adaptive business model requires two essential enablers. The first is performance, defined by real-time speed, completeness, accuracy, and timeliness. The second is information flowing at the same velocity.
The Solution: Third-Party Integration: Built-In Performance and Data Quality
At Put It Forward, we believe that an enterprise can operate best when information is put forward to the next person in line whose job is dependent on good data. A configuration approach includes a prebuilt foundation unto which business rules, APIs, analytics, and products can be layered.
The solution provides transparency, measurability, usability, accuracy, completeness, repairability and security. It checks data integrity; for example, two fields go through integration and need to equal three. Logs and time stamps record activities. Views are customizable for each user and for managers and administrators.
Consider the value to marketing, sales, service and other departments when users can access instantly the customer lifecycle and view the entire history of a contact. Put It Forward’s Foresight solution surfaces that data in the platform you are working in ― no longer do you need to search for it in another system. Check out Foresight in action in our demo video.
Put It Forward believes that people can do their best when the right information is put into their hands – to collaborate without compromise. We create the ability for people and organizations to simply get control of their data story and realize its full potential. Core to this vision is the Data Automation Network of Put It Forward, a configuration-driven approach to integrate, manage the platform, orchestrate, and see around corners.
About the Author: Mark Cowan is the Chief Data Officer at Put it Forward, the Data Automation Network. He has contributed to the definition of several global data standards, patents for data management, distributed system integration and financial systems. Mark is a recognized expert in system design, integration, and business enablement.