3 ms·

I'm curious what you call it when you add an API to some business functions that run on a mainframe in order to make them available to other external software w

by h_r 11y ago

I'm curious what you call it when you add an API to some business functions that run on a mainframe in order to make them available to other external software written Java or .NET, for example. This kind of thing is done all the time in enterprise shops. Trying to frame it as a political power struggle between the negotiating parties frankly sounds pretty ridiculous. I have direct experience doing this sort of thing for years. It's really just a strategy for better leveraging your existing business assets. What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. If that context is missing (negotiating, somewhat hostile parties), then all you've done is say that you can't call it API. Hmmm ok then...

beagle3 11y ago
> What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. Suppose it turns out that your MF RPC (or however your API is implemented) works too slowly, and instead of passing whatever through TCP, you are going to generate a file accessible through the shared MF/non-MF file system with the relevant contents. If all it takes is calling up Frank in the MF programming department to do the MF side (or even better, doing it yourself) -- then, no, it's not an API any more than your private class names and functions are an API - the MF/non-MF dividing line (which will likely also separate operating systems, programming languages, etc) is of no consequence, because there's no negotiation around changing it. I have witnessed exactly such a power struggle last time I worked in an environment that had mainframes (some 25 years ago) - functionality that was available on the MF was needed on a unix workstation. The amount of dev work on the unix side to do a mainframe RPC or to do it from scratch was comparable. From most perspectives, the unix re-implementation was a pure win. It sounds like a clear-cut decision, but the MF people argued fiercely against it -- to the best of my understanding, because they were constantly losing turf and relevance. Would you not call this political?

by h_r 11y ago

beagle3 11y ago

> What is the value of saying, "That's no application programming interface, it's just an implementation detail." I think it just confuses the concept for possible surrounding context. Suppose it turns out that your MF RPC (or however your API is implemented) works too slowly, and instead of passing whatever through TCP, you are going to generate a file accessible through the shared MF/non-MF file system with the relevant contents. If all it takes is calling up Frank in the MF programming department to do the MF side (or even better, doing it yourself) -- then, no, it's not an API any more than your private class names and functions are an API - the MF/non-MF dividing line (which will likely also separate operating systems, programming languages, etc) is of no consequence, because there's no negotiation around changing it. I have witnessed exactly such a power struggle last time I worked in an environment that had mainframes (some 25 years ago) - functionality that was available on the MF was needed on a unix workstation. The amount of dev work on the unix side to do a mainframe RPC or to do it from scratch was comparable. From most perspectives, the unix re-implementation was a pure win. It sounds like a clear-cut decision, but the MF people argued fiercely against it -- to the best of my understanding, because they were constantly losing turf and relevance. Would you not call this political?