BizTalk Server 2006 comes with a number of adapters in the box, and a number of third parties provide adapters at extra cost for just about every system, new and old, regardless of platform.
The 2006 release includes extra adapters that were purchased by Microsoft from iWay, as these were the most commonly requested and used by BizTalk customers; this should mean that most systems you need to interface with have adapters in the box with BizTalk.
Adapters are really extensions of the BizTalk engine. Custom adapters can be written but need to be designed and developed with care since they are multithreaded server-side components. Microsoft intentionally designed a low-level programming API for adapters, allowing custom adapters to take advantage of the full set of functionality that out-of-the-box adapters enjoy. In short, custom adapters are treated as first-class citizens by the BizTalk engine.
This does, however, have implications. Custom adapter code needs to be written in a robust and resilient manner, which makes the task of developing custom adapters relatively significant. A poorly written adapter may starve BizTalk, introduce a performance bottleneck, or consume valuable (and not free) resources such as memory.
A common solution to interfacing with systems where an adapter isn't available or economically viable is to wrap (expose) the remote system via a Web service and call this via the SOAP adapter. This, of course, has a higher overhead than a native and ...