Tag: ERP

To gather insights on the current and future state of API management, we asked IT professionals from 18 companies to share their thoughts. We asked them, "What are some real-world problems APIs are solving?" Here's what they told us:

Applications

• Our main focus has been using APIs to integrate across applications and with business partners. Organizations are modernizing IT systems by replacing legacy systems with SaaS applications. These new applications need to integrate with other enterprise systems whether modern or legacy. For instance, we frequently work with customers who are modernizing their ERP system, and they need to integrate that new ERP with other systems.
  
  The legacy system was likely a tangle of file-based integrations. With the new ERP, a published API set is the integration point of choice for connecting to all of the other enterprise systems such as general ledger and warehouse management solutions. Additionally, these modernized ERP solutions are able to provide real-time access to enterprise information through their APIs.
  
  We also work with our customers to take advantage of publishing APIs to their partners that provide limited access to this information. For example, a partner wanting to check inventory or check the status of their order can use an API that provides a view into their data directly from the ERP. This can augment the traditional EDI process with API queries for certain transactions that benefit from real-time responses. 
• Put APIs on top of legacy systems built without APIs in mind. Write code and put API on top to make it easier for customers to interact with them like a CSV file. APIs automatically determine what the file has inside. 
• Six use cases: 1) Mobile, 2) IoT devices, 3) building out ecosystems – SaaS offering or partner, 4) content or transaction offering (media or ecommerce), 5) APIs as a business (tend to be smaller, the value of the company is monetized via the API), 6) internal agility (80% of API use is internal by large companies how to reuse code more effectively, this is the new SOA, using web APIs to improve internal reuse to achieve agility).

Industries

• One client building applications owning the development of the API is Hawaiian Airlines. They build APIs for complex legacy systems that are not API-friendly. Creating APIs required thinking about how to expose and secure the data in the most efficient way. Another good example is in the automotive industry in Europe and U.S. challenge is fragmentation of systems to maintain and new car owners have to go through those systems of onboard and connect cars that are more connected than ever. Register all seven new services at once. Create APIs for systems that did not expose APIs before and also contains PII. 
• Schiphol Airport started on one use case, improve passenger experience of going through the airport. Thought holistically to make the experience better. There is so much data that’s useful, it became an integration problem. Expanded boarding pass, tracking flights, arrival departure information, flier alerts, to achieve internal agility, they decided to make an API-focused effort to enable the integration of different applications. Opened internal APIs to build a partner ecosystem. Start with the mindset APIs will be open and control access rights.

Other

• As a company, we try to be cloud-neutral. On the backend, we can store content in different public object stores. Customers want to maintain their own keys. With key management services from large cloud providers, we can integrate with them as well and give customers a choice of what data they want where.
  • 1) Capital One, one of the world’s largest banking institutions, offers a variety of online financial services including API products. Third-party developers and partners can provide a first-class digital experience for their customers as well as create new revenue streams by using Capital One’s external APIs to open bank accounts, generate personalized credit card offers, and track customer rewards. NGINX technology has enabled Capital One to scale its applications to 12 billion operations per day with peaks of 2 million operations per second at latencies of just 10-30 milliseconds.
    
    2) Adobe, a large software company that develops multimedia and creativity software solutions, uses internal APIs as the primary means of data exchange and communication across various software applications used within the enterprise. Adobe uses NGINX as an API gateway for managing API traffic across all these internal systems.
    
    3) A large technology-focused market research company uses an internal API hub so that its analysts can easily use internal applications to compile, submit, and manage all content they produce. The company is transforming its internal application profile to be more services based and NGINX is providing the required resilience and performance given the mission-critical nature of the applications.
  • Northwoods need to integrate customer data sources. API-led development and API-led integration are about the more SaaS applications being launched still need to take their data and connect with them. Still an integration use case there, APIs aren’t standard, there’s a variety of ways to connect and integrate. Take advantage of Business Works to consume, connect to a data source and connect to a more common set of services to use with applications.
    
    More easily access information and reduce time to market by 25%. My favorite use case is Netflix. They need to connect with more than 500 client devices, iPhone, Android, X-Box, etc. They have well-normalized APIs that serves metadata from movies, handles search requests, image serving, actual streaming of the movies. But constrained devices over tight networks. They created a middleware backend for front end (BFF) to consume base APIs, contains the majority of the business logic the client needs to use and then opens interface to their own APIs that just serves that client.
    
    When a new client comes on, all they have to do is create a new BFF in the client code and they’re good to go. If the client for one device is no longer needed, they just kill that code off and it doesn’t break anything.
  • The fundamental problem APIs solves, is answering technical needs with the absolute best solution, in the smallest amount of time, for the smallest cost possible. We provide the best in class Search Experience in the form of APIs. In a matter of minutes — registration time included — customers can answer their Search Experience needs in the best possible way. Doing search right is actually a daunting task; yes, it is possible to spawn up a Solr instance, tune it to best fit a use case, install it on dedicated servers, deal with multi-cluster issues, monitor/operate them...
    
    But at what upfront cost? At what cost in the long run? How many experts will be required for this — how many site reliability engineers, natural language processing engineers? How much time will be necessary for even starting up? For what level of quality? Our customers can just discard these questions. That is what APIs solve in the real world; that is what we do for Search Experience.
  • Stoplight provides a suite of products to help organizations manage their API design workflows at scale. A critical part of this is building on top of the development workflows that already exist at most organizations. This means integrating with existing tools like GitHub. To do this, we integrate against the APIs that these tools expose.
    
    This allows us to do things like automatically pull information from GitHub into our product, and push information from our products into GitHub. The end result is a much better experience for our customers, and it's made possible because of the rich APIs that GitHub exposes.
  • Customers are powering use cases from orchestrating real-time integration between endpoints to composing entire business solutions using the Jitterbit Harmony API Integration platform.
    
    1) For example, Odyssey Logistics has orchestrated WIN Logistics — a no-cost, no-fee web-based transportation management solution, powered by Jitterbit to automate the on-boarding of new clients. So when a client registers with WIN, all of their customized configurations are migrated over automatically through an order send and receive API. This means that product lists, shipping origins/destinations, and equipment types are all brought into WIN in real-time.
    
    If a client makes a change in their ERP system, that change is automatically reflected in their WIN environment, in real-time. Additionally, Jitterbit’s API integrations streamline the broker-shipper relationship. So when brokers submit quotes, WIN automatically alerts those shippers without them having to constantly monitor their email. This allows brokers to quickly respond to requests and shippers to easily react to the quote of their choosing.
    
    2) Intellifo, a UK-based company that offers business management software to financial advisers and wealth managers, has connected to over 30 REST APIs of popular endpoints such as Salesforce, NetSuite, JIRA, Aha, Eventbrite, etc. via Jitterbit. One use case they have powered is the Salesforce-JIRA integration through RESTful APIs and webhooks that automatically raises defect tickets from Salesforce and updates bug tracking within JIRA.
    
    Keeping both systems up to date enables easy communication between Dev and Support and has enabled Intellifo to provide multi-channel support to their customer base. Intellifo has also designed a Production Incident slackbot powered by Jitterbit Harmony API Integration platform that consolidates information from systems such as JIRA, Confluence, Salesforce and NewVoiceMedia as it sends appropriate Slack notifications.
  • 1) Most of my customers are security first and foremost.
    2) Second is observability to know what’s going on. Now the state of the application is all spread around.
    3) People are paying for rate-limiting to prevent hacker from loading your app with requests.
    4) The canary deployment releasing update every day.
  • We built our Mass Customization Platform to allow all Cimpress businesses to leverage the best technologies developed in each.  For example, Vistaprint has spent over 20 years building market-leading technologies to solve all the problems involved in sending user uploads to printing presses (from obvious stuff like “is this image high enough resolution?” to more inside baseball like “will the ink in this image bleed together if printed on a particularly glossy surface?”).
    
    Over the past decade, we’ve turned this functionality into a fleet of microservices we call our Prepress APIs. No longer the sole possession of Vistaprint, they are now used millions of times a day across a dozen Cimpress businesses.
  • Most banks have figured that they have to have APIs. No one really challenges that, and they are in a state of either planning API programs, implementing them or even launching first API products. What we found our clients to struggle with — how do they monetize their API efforts? So FI.SPAN’s approach to that problem is — figure out your client’s use case first and then see what APIs would be needed to solve it.
    
    We spend a lot of time and research effort figuring that out. To give you an example — while some banks were trying out that new API thing via some harmless and non-critical “/GET ATM-locations” kind of APIs we were looking into their most profitable corporate customers’ need and found plenty of use cases which require fairly sophisticated APIs to support account payables as well as receivables, data reconciliation and numerous business automation scenarios. Almost every API we have today is powering some customer facing product.
  • For data access, we improve security and utility over traditional APIs by supporting newer protocols like GraphQL and SPARQL. Security is improved by embedded the data security rules with the data itself, so any data consumer or other apps don’t need to duplicate security rules and keep them maintained.
  • Our main customers are marketers and Marketing Technology companies, who used to build software solutions completely in-house. However, the main problem is that getting the data you’d need to build a marketable product would require awfully a lot of time and money.
    
    Marketing requires vast amounts of data in order to be effective, but the costs of collecting and analyzing all this data on own capacities are ridiculously high. And because obviously not every company is able to allocate the required amount of resources to get the software project off the ground, the technological threshold to entering the market was unreasonable.
    
    When the first APIs became available for the marketing community, it was a major game-changer. You can now build a simple keyword research tool in a matter of weeks.

Here's who shared their insights: