1

I do system integration for critical and time sensitive systems. We have two standard ways we can build these system integrations. One is a simple (and cheap) email ingestion tool built into our platform and the other is a very customized (expensive) standalone HTTPS Restful API integration.

How do I nicely explain to a customer that if the message is really critical and time sensitive then email (SMTP) is NOT the way to do it.

Ben
  • 181
  • 2
    http://meta.programmers.stackexchange.com/questions/6629/how-do-i-explain-something-to-someone – kevin cline Sep 01 '16 at 17:48
  • 3
    Carefully explain the pros and cons from his perspective, and then let him make the decision. – Robert Harvey Sep 01 '16 at 17:51
  • 3
    Can they afford the expensive solution? or Can they afford NOT to build the expensive solution? – Tulains Córdova Sep 01 '16 at 17:54
  • 2
    Please don't take the fact that I bothered to answer this question as an endorsement of the way it was asked. I'm looking past the off topic "how to explain x to y" issue and pointing out that there is a design decision to make here. Framing your question this way won't get us to come down on your side. Learn your customers needs and tell us about them. Then you'll get better answers here. Feel free to use the "edit" link. – candied_orange Sep 01 '16 at 18:24
  • Looks like @TulainsCórdova is trying to help you with a another question: What is email ingestion and are there modern uses for that technology? – candied_orange Sep 01 '16 at 18:38
  • You tell the customer that he surely don't want to take the risk of getting such mails caught by his companies' spam filter (and he also does not want to take the risk of switching this spam filter off). – Doc Brown Sep 01 '16 at 21:26
  • If the message is really critical and time sensitive then relying on any internet based protocol is not the way to go. I'd better be careful with your explaining, you may trigger your client to figure this out and ask you some questions that would likely be most uncomfortable. – Martin Maat Sep 02 '16 at 06:44

3 Answers3

8

How do I nicely explain to a customer that if the message is really critical and time sensitive then email (SMTP) is NOT the way to do it.

By knowing why it's not.

Name one real need that the email solution can't solve.

I can guess at a few. HTTPS is fairly good at securely communicating and proving you're talking to who you think you're talking to. But are those real needs for your customer?

Customers are usually easy to convince that you know how to do what you want to do. I'm already convinced you know how to make a Restful API and I don't even know you.

What I don't know is that you really understand your customers needs. If you're trying to talk them out of using email there must be some reason they favor it. Maybe they've used it before. Maybe they understand it enough to trust it and somewhat maintain it. If you switch them to REST what are you taking away from them?

I've worked in systems that use email exactly the way your customer is describing. It feels like it's held together with bailing wire. But it can work.

Even manual email can be critical and time sensitive. People use it for that anyway. Sure your customer doesn't have other needs that an API works better for than an email parser? Maybe talk about those.

candied_orange
  • 108,538
3

I agree with everything CandiedOrange mentioned (including the how to explain x to y comment). It's all about the clients needs. I've built systems that rely on smtp email. It works fine and it suited the clients needs. And as far as I know it still runs, even now 7 years later.

However, there is one downside here, as I see it. And it's the response.

In a http request the response is given directly. Unless it's using fire and forget, but let's keep that aside for now as most restful services don't. The caller can immediately know if the receiver got the call. That is not really possible (as far as I know) with SMTP. This way you can handle errors in the communication faster with http(s).

So, in theory, the caller should be able to get a confirmation from the receiver faster (read: directly) if you're using http(s) than with SMTP. However, there's really no guarantee that a http request will be faster than smtp.

Another thing to consider is the dependency to the mailserver, eg. Exchange. What if it goes down or has to restart? If the two systems only depend on each other there's one less thing to worry about when applying updates and considering downtime.

Community
  • 1
smoksnes
  • 473
1

You don't!

You just make sure the client is aware of the distinctions:

Email is more inherently optimistic, and it's more inherently asynchronous. When the client sends a message, it assumes the recipient receives and processes it. Failures aren't necessarily reported. And those failures that are reported aren't always even reported back to the sender. And they sometimes can't be -- like if the sender uses a black-hole return-to address.

On the contrary, because HTTP is designed for document fetching, API's that run over HTTP can and generally do respond immediately with detailed success codes and messages directly to client. And while asynchronous message processing is still an option here, it's much more in-line with HTTP for clients to receive immediate success/fail operations if those are needed.

There may be other important things to point out. One of those might be, "I can develop REST API's faster, b/c it's what I normally do." And those points aren't invalid. But, they're not technical reasons. They're practical realities.

But, that's basically it. If you're competent enough to work it either way, you mostly just need to decide with the client whether the integration needs immediate failure processing, or whether the client-machine(s) can safely ignore errors.

svidgen
  • 14,669