The fourth topic in our “Ten ways to tell if your enterprise software provider is open” series is vocabulary. Here, we’ll examine the words that are being used to determine the fundamental approach to a partner ecosystem. While subtle, the words used when describing one’s openness matter. Specifically, we’ll examine the difference between interface and integration.
What words would we use to discuss “openness?”
Merriam-Webster.com provides the following definitions:
Interface (n): the place at which independent and often unrelated systems meet and act on or communicate with each other.
Interface (v): to connect by means of an interface.
Integration (n): the act or process or an instance of integrating.
Integrate (v): to form, coordinate, or blend into a functioning or unified whole.
If we stop right here, and consider these definitions, which feels more appropriate to an ecosystem of solutions? Which embraces being open and connected? Which feels like the enterprise software provider is taking ownership of the connections between systems to enable the flow of data to better enable business processes?
Is “interface” or “integration” more open and connected?
If we are only talking about interfaces, we are really talking about a one-sided and minimalist approach to connectivity. Your iPhone used to have a headphone output and your car had an AUX jack. Neither the car nor the phone came equipped with a cable to connect the two. Could they claim they had an interface? Yes. Did they work hard to make that connection happen? No…and don’t get me started on their sound quality and volume controls.
If we are not talking about integration, then we are not really serious about being open and connected. Let’s look back to that iPhone example. Recently, new vehicles are being equipped with more robust entertainment systems that have Apple CarPlay built in. You can connect your phone with a USB cable that is usually included with your device, agree to permit access and your car and your phone are then integrated for maps, messages, calls and audio. Automotive manufacturers have included Apple CarPlay and Android Auto in their new offerings, recognizing that consumers will bring their phone of choice and that they must provide integration independent of device and operating system. They are also providing an integrated user experience that includes the smartphone features in the dash of the vehicle.
We don’t have to stop here, however. We can take integration to a next level, which is the “powered by” relationship.
“Powered by” means essential integration
Much like how Intel provides chips for computers, noted with the “Intel Inside” sticker, or the manufacturer of your automobile uses tires from a supplier dedicated to tire development, enterprise software providers can also choose to leverage partners as part of their own solution. This is done in place of attempting to build a new solution in order to catch up to prominent players in the market.
This practice is common with underlying application components like database and reporting technologies. While less common at the business process layer, it’s not unheard of. In fact, it serves as a glimpse into the future.
Enterprise software providers are constantly evaluating how to grow their offerings, but there are three commonly accepted ways to do so: build, buy or partner. In the powered-by relationship, we choose to partner, and we execute the partnership in a way that doesn’t inconvenience the client.
The integration that marries the solutions goes beyond simply moving data. We should find integrated menus and reports, as well as context-specific connections that allow for business process completion across applications with minimal disruption to the user.
Furthermore, the partner product is sold as if it were the product of the enterprise software provider. This streamlines client relationships, reduces paperwork and provides the same support and services infrastructure that is already familiar to the client. This, of course, also includes the support for the integration of data between the applications.
So how do we define “integration?”
With the continued emergence of identity management, single sign-on technologies and the ability for web pages to interact with business logic via scalable API layers, we will eventually see a fully federated user experience across multiple applications.
This endgame will likely usurp the simple integration of data across systems and instead provide an integration of the user experience, achieving true plug-and-play capability for enterprise software.
In this coming era of plug-and-play integration, users will be moving between applications without knowing they are doing so. Data and security integration/federation will be handled on the back end, while user experience teams will redesign the front end across applications, creating a new definition of what true integration can be. At MRI Software, we call this the Single ExperienceTM and we are already working toward this endgame. Who knows? Maybe Merriam-Webster will even redefine “integration” someday. Until then, we’ll take on that challenge ourselves.