3 ms·

How so? The web is already standardized on REST as the 'universal' API. Publicly accessible microservices are becoming more and more common over time and some

How so? The web is already standardized on REST as the 'universal' API. Publicly accessible microservices are becoming more and more common over time and some of them are being used to create integrations. Have you heard of Zapier? https://zapier.com/how-it-works/ https://zapier.com/how-it-works/ Slack bots also interact with other services: https://slack.com/apps/category/At0EFT67V3-new-noteworthy https://slack.com/apps/category/At0EFT67V3-new-noteworthy There's also the Huggin project: https://github.com/cantino/huginn https://github.com/cantino/huginn

ebiester 11y ago
I am thinking more at the internal-software level. Consider an enterprise that has a simple case management app -- essentially, a help desk app for one portion of the business. There is another app within the system that was developed 5 years before to help choose when to start a case. It's maintained by a different team, so there's no natural coordination. If these were two Unix tools built like programmers would build, someone could connect the output of one, to a filter in the middle, to the input of the next. However, in the real organization, there is an individual who spends 20 hours a month to manually copy the information from app 1 to app 2 because the work to create a proper hypermedia interface. The combination of a corporate-aware Huginn (single sign on, etc) and a revolution in corporate apps that treated hypermedia as a first class citizen could make it happen. It's not happening now, however.
- EvanPlaice 11y ago
  The problem with 'enterprisey' corporate applications has more to do with the culture of the developers who build those applications. Instead of breaking applications apart into distinct services they devs of corporate apps prefer to use OOP to create complex inter-dependent monolithic architectures. APIs for such apps are usually exposed by using a library, so a lot of emphasis is placed on access privileges at the language level (ie private/internal/public) instead of at the interface level (ie pipes/REST). The problem isn't that the capability doesn't exist, it's that corporations are either unaware or unwilling to experiment with alternative approaches. For example, one employee could spend half their time collecting data in Excel files from multiple members of a team, organizing it in a presentation-ready format, and emailing it up the chain. Alternatively, the team members could each have a Google Spreadsheet where they input the data and a timed trigger fires off a bot that processes the data, saves it to a new file, and emails the link up the chain. Both accomplish the same result. The second is a lot less prone to error/bias, and is also a lot more cost effective. But, to get an organization to adopt the latter approach requires convincing the organization to give up Excel as their canonical tool for organizing data. I have fought that battle and it's a lost cause. Even when adequate proof of cost/time savings are presented in a business-friendly format, inertia trumps reason. A company could theoretically hire a developer to deploy a digital assistant to streamline/automate the mundane and repetitive business processes. Except, devs are expensive, in short supply, and it's a really hard sell business leaders on the idea of adopting processes/tools that they don't fully understand.

ebiester 11y ago

I am thinking more at the internal-software level. Consider an enterprise that has a simple case management app -- essentially, a help desk app for one portion of the business. There is another app within the system that was developed 5 years before to help choose when to start a case. It's maintained by a different team, so there's no natural coordination. If these were two Unix tools built like programmers would build, someone could connect the output of one, to a filter in the middle, to the input of the next. However, in the real organization, there is an individual who spends 20 hours a month to manually copy the information from app 1 to app 2 because the work to create a proper hypermedia interface. The combination of a corporate-aware Huginn (single sign on, etc) and a revolution in corporate apps that treated hypermedia as a first class citizen could make it happen. It's not happening now, however.

EvanPlaice 11y ago
The problem with 'enterprisey' corporate applications has more to do with the culture of the developers who build those applications. Instead of breaking applications apart into distinct services they devs of corporate apps prefer to use OOP to create complex inter-dependent monolithic architectures. APIs for such apps are usually exposed by using a library, so a lot of emphasis is placed on access privileges at the language level (ie private/internal/public) instead of at the interface level (ie pipes/REST). The problem isn't that the capability doesn't exist, it's that corporations are either unaware or unwilling to experiment with alternative approaches. For example, one employee could spend half their time collecting data in Excel files from multiple members of a team, organizing it in a presentation-ready format, and emailing it up the chain. Alternatively, the team members could each have a Google Spreadsheet where they input the data and a timed trigger fires off a bot that processes the data, saves it to a new file, and emails the link up the chain. Both accomplish the same result. The second is a lot less prone to error/bias, and is also a lot more cost effective. But, to get an organization to adopt the latter approach requires convincing the organization to give up Excel as their canonical tool for organizing data. I have fought that battle and it's a lost cause. Even when adequate proof of cost/time savings are presented in a business-friendly format, inertia trumps reason. A company could theoretically hire a developer to deploy a digital assistant to streamline/automate the mundane and repetitive business processes. Except, devs are expensive, in short supply, and it's a really hard sell business leaders on the idea of adopting processes/tools that they don't fully understand.