我們有大約六個系統（它們都是內部系統），我們需要在它們之間發送數據。目前我們沒有一致的方式來做到這一點。我們使用SSIS，SQL Server鏈接服務器直接更新數據庫，ODBC連接直接更新數據庫，文本文件等。BizTalk是正確的解決方案嗎？
我們的目標是：
1）有連接的應用程序以一致的方式。
2）有一箇中心的方式來監視和記錄 應用程序之間的連接。
3）對於提供Web服務的應用程序，我們 想要開始使用它們，而不是直接與 數據庫連接。
無論我們使用什麼，都需要能夠連接到Web服務，數據庫，平面文件，並且還應該能夠通過tcp連接接受數據。
Biztalk是一個很好的解決方案，或者它是矯枉過正？
這真的取決於。對於你所描述的架構來說，這看起來很合適。但是，您需要驗證它是否可以與您嘗試集成的系統進行通信。例如;當這些系統使用Web服務，消息隊列或基於文件的通信時，這可能是一個很好的選擇。
當你開始使用biztalk時，你必須願意投資於硬件，軟件，最重要的是要學習使用它。 1）是的，如果你一定要封裝系統接口正確 2）是時，BizTalk支持這一與BAM 3）是的，這將匹配完美
從你」：關於您的積分
已經描述過（6個系統），現在肯定是研究更加正式的集成方法的好時機，因爲你毫無疑問地發現，在點對點/直接集成方法中會導致大量的排列/意大利麪每個新系統都被添加。
BizTalk同時支持hub and spoke, and bus type topologies（使用ESB工具包），其中任一項都會減少系統之間的互連數量。
要添加到oɔɯǝɹ：
一些注意事項：
。 BizTalk應該用於消息（例如電子文檔），但不適用於批量數據同步。對於真正的大數據傳輸/數據遷移/數據同步模式，SSIS是更好的選擇。
。正如David指出的那樣，BizTalk的學習曲線非常陡峭，而且該工具本身並不是免費的（需要SQL和BizTalk許可證，並且通常您還需要使用像SCOM這樣的監視工具）。爲了快速跟蹤這一點，您需要發送關於BizTalk培訓的開發，或者引入BizTalk顧問。
。微軟似乎將重點放在Azure Service Bus上，並且存在speculation，BizTalk將在未來的某個時間點合併到Azure服務總線中。如果你的企業戰略不完全是微軟，你可能還想考慮像NServiceBus和FUSE這樣的ESB產品。
您的問題是一個典型的企業問題。公司開始在數年內建立諸如人力資源，網絡，供應鏈，庫存，客戶管理等獨立應用程序，一旦它們達到某一點，這些應用程序就不能獨立生活，他們需要彼此交談，通常他們會啓動一些被黑客入侵的解決方案如數據庫級別的數據遷移。
但很快他們意識到問題沒有清晰的可見性，管理不善，沒有標準等，他們創造了一個真正的意大利細麪條。最大的威脅是應用程序將相互依賴，你失去了改變任何東西的敏捷性。對系統進行任何更改都需要大量測試和長時間的發佈週期。
這是BizTalk Server等中間件平臺爲您解決的一類問題。線程中的很多答覆都集中在BizTalk服務器的成本上（提到的一些成本是不正確的）。這不是一個便宜的產品，但是如果你將它在組織中扮演的角色看作是將所有應用程序連接在一起的中間中間件平臺，以及像許多第三方產品適配器那樣的非功能性好處如SAP，Oracle，FTP，FILE，Web服務等，輕鬆擴展您的平臺的能力，性能，長時間運行的工作流程，耐久性，長期運行工作流程的補償邏輯，節制您的環境等等，很快成本因素就會減少。
我的建議是看看BizTalk，如果你是新手，那麼請與當地的微軟辦公室聯繫。他們可以幫助或推薦一位可以來分析您的情況的參與者。
BizTalk將盡你所能輕鬆完成任何事情。主要擔心的是將成本與其他技術相比較。單獨授權可能會很昂貴（最便宜的是每臺服務器2.5k美元），然後您仍然需要開發解決方案，這涉及到BizTalk的大量特定技能。另外，您得到的監測（可能是我2010年改進 - 沒有廣泛使用）並不是完全開箱即用 - 它需要專業知識來配置和正確使用。最好的辦法是獲得免費的開發版本，並試試看它是如何適用的。 –