Originally Posted by mendhak
I'll explain it with an example. Let's say you work for a company, CompanyA which assembles computers. While your company does the assembling and selling, it buys the parts from elsewhere. So, it decides to order the hamsters to power the computers from CompanyB. Now your company may have a parts-ordering system in which you enter the details you want. It will process all your information and produce an XML file which makes sense to you.
On the other hand, the hamster company has its own order receiving system. Its system does not understand your XML. Your XML is, to that company, a steaming pile of hamster doodoo. Somewhere along the way, your doodoo needs to be translated into XML understood by the hamster ordering system. Biztalk can allow you to define rules to translate the XML from one format to another.
If it were a one-to-one relationship between companies, it would've been fine. But your parts could come from anywhere, your company may have a business relationship with 200 companies. It's not feasible to write code that translates into all of these formats. Well, it'd be feasible, but why should the order department in your company wait for you to create the code for that while you are on your coffee break, right? Biztalk helps by allowing non-programmers to create the translations for each new company they interact with.
Further, Biztalk goes on to handle other things like message queuing (if the other company's web service is unavailable).
That's what Biztalk is.