Back in 2004 we looked into MS offerings in the EDI space and figured out that nothing (including BizTalk) was addressing our reliability requirements, so we started our proprietary software development and never looked back.
Out of curiosity I looked into this article and OMG, a simple case of reliable FTP download (not sure it does SFTP or uploads) is not even a part of a framework? How on Earth in the real world are you going to deal with situations when the file has not fully arrived into the source folder yet or they put it there twice by mistake simply because you already picked it up before they saw it? How are you uploading the files to (S)FTP? Does that have a chance to break your client’s EDI because they fell into the same trap?
For our software to run you can use Pentium 3 and no SQL server is required! It has agents and APIs that can be deployed to the client because some clients may be just desktop applications with no EDI capabilities. The other way for this sort of clients is sending attachments to by email.
I understand that MS needs to sell a product that is extremely configurable, but reading this article it seems like even a simple ETL is quite a lot of work and workflows. The advantage of our proprietary software is that if something has to be a part of the framework, we put it there, so over the years we ended up with an extremely robust framework. That is also a reason why we have not productised it. Instead we provide a VAN. The rationale for our clients is that they need no hardware, employees with associated costs (including compliance costs), and time to the market are days, not months!
Have a read at http://allelectronicmessages.com/B2B_Messages.aspx?r=s07