The demand for open and connected technologies is on the rise, and smart CIOs and CTOs know that interoperability and integration are key to creating agility and preparing their business for the future. This open approach is already a reality for enterprise software, as evidenced by the recent Salesforce.com acquisition of Mulesoft, a leading integration platform.
It shouldn’t come as a surprise that some technology vendors are making bold claims about their ability to meet market demands for openness. But how can you tell if a provider truly embraces it?
In his blog, “Ten ways to tell if your enterprise software provider is truly open,” Brian Zrimsek presents a list of qualities to help you separate those who talk the talk from those who actually walk the walk. The next step in determining openness is to investigate whether the provider’s technology proves – or disproves – their commitment and willingness to be truly open.
Here are ten qualities of providers that have embraced open technologies.
1. They embrace modern integration. In the 1980s through the early 2000s, fax machines were the dominant method of quick data transfers between individuals and companies. While most businesses progressed out of the dark ages, some companies today still send reports between systems manually via email attachments, or worse, through the mail.
The current industry standard is an application programming interface, better known as API. API infrastructures allow for a smooth transmission of data between systems in real time.
2. They still support file-based options. While your software may be ready to handle the demands of being open and connected, it’s possible some of your other vendors may not be up to the task. Look to understand if your software can handle another organization, such as a bank, picking up files from your system for their own consumption. This can include file types such as excel and CSV. This is especially important in a SaaS-based environment where you may not have direct control of firewall settings.
3. Security isn’t an afterthought. With an API, you will allow another software provider the ability to access and manipulate information on your system. You need to make sure the system is secured in such a way that only approved users have access. Consider checking into the security rights of the vendor exactly as you would any employee accessing your system, both from an authentication and authorization perspective.
4. Tokens for access. Since most of these calls are going to be made from one system to the next, it’s important to understand things such as man in the middle attacks and what they mean for data manipulation. Making sure the vendor of choice allows tokens or credentials of some sort is key to data integrity as it passes from system to system.
5. Flexibility in API decisions. While companies may check off support for API’s, and check off having all the methods that exist, do they allow you to customize those calls, or better yet, create your own? You may have custom business processes including tables and fields that you would like a vendor to have access to. If you’re limited by the system-created API, you’ll have a product that can communicate, but not very effectively. This can make your integration potentially useless and force you to result back to a legacy integration or none at all.
6. Their APIs are directional. You’ll want to make sure the vendor’s APIs allow you to both GET and POST. This will allow data to be created in a POST method and data to be read in a GET method. You’ll want to verify that not only can they do that with other vendors, but that other vendors can do that to their system as well. Closing the loop on the transition is key to an automated process between two systems.
7. REST is something they practice. I know what you’re thinking, we all need rest in real life and the same thing applies with being connected in software. REST APIs are commonly used today, but many legacy providers are still using SOAP APIs – a less performant and restrictive API methodology – as their go-to solution. REST API technology supports many data formats, is scalable, and is more performant than legacy APIs.
8. Basic HTTP methods are accounted for. Verifying that the vendor’s API mechanism can do these basic methods will make sure your software will meet the needs of being connected. Methods such as GET, the return of data; POST, the sending of data; PUT, sending of data but only once to avoid duplicate entries, and DELETE, the removal of data. Bonus points if the company can provide other HTTP methods including HEAD, PATCH and OPTIONS.
9. Error code logging exists. While we would like to expect our software to work flawlessly all the time, there are instances where errors occur. Make sure to account for how you can troubleshoot in the event of an issue or failure. Status codes such as 404 and 503 are very helpful when trying to diagnose the connection between two systems. This information should be easily accessible for both systems when an interaction fails to execute successfully.
10. They are scalable. Everything listed above is a great thing to have, but it doesn’t mean anything if it’s not usable. Estimate how many transactions, or API events, you will have going across the two systems and make sure the framework is able to handle that payload. If the vendor is a SaaS provider with one server for 10,000 users where all users are submitting 10 API requests a second you may run into some performance problems, making the experience less desirable over time. This scenario is extreme, but it does exist in the market. Look for a vendor who is scalable and allows those API calls to be asynchronous as opposed to synchronous.
11. They can adopt a common look and feel. Yes, this blog goes to 11. This is an emerging concept that is about more than just data transfer. Vendors who are able to come together in a unified sense where a user feels like they are in the same system visually while the data is transferring via APIs on the backend is the next generation of open and connected. Get an added layer of integration if both vendors give access to the same SSO provider, eliminating the need for multiple usernames and passwords across systems. You’ll know that you’re getting the tightest integration possible with this product because both vendors have invested the time and effort to make sure it operates as seamlessly as possible from both sides of the fence.
In the era of integration, users will be moving between applications without even realizing it. This is the Single ExperienceTM we strive to create at MRI Software. If you’re not sure whether your provider is walking the walk when it comes to being open and connected, give us a call. We’ll be glad to talk – and walk – with you.