Over the last few years I've been engaged by a number of clients to work on projects involving Microsoft BizTalk Server. As I was embarking on this journey, one of my colleagues who had previously worked with BizTalk encouraged me with "You've done everything except BizTalk!"
What he said was true, I had done a lot of work with many of the technologies that support BizTalk such as XML, XPath, XML Schema, SQL Server, web services and WCF, and .NET. Having worked with these technologies did give me a very good grounding for getting started with BizTalk, and I was in most cases able to satisfy the requirements of each client in their use of BizTalk. It probably "helped" that the use of BizTalk is still somewhat in its infancy here, and hence clients' use (or expectations) for it is in many cases rather immature.
However, as I've come to appreciate the breadth of what BizTalk has to offer and the depth of knowledge required to fully leverage it, I've realised that working with BizTalk is not something that should be a part-time job.
Working with BizTalk is not something that you can pick up for 6 months, put down for another 6 months, and pick straight up again like other technologies I've worked with. Even though those other technologies (like .NET) actually change pace more rapidly than BizTalk does, I think it's more due to the underlying skillset and philosopy required to use BizTalk well. It's completely different to a typical "app dev" approach (which I've also had a good deal of experience with).
In the majority of app dev projects I've worked on, although the specifics of the functionality are different from client to client, there is usually a consistent set of patterns and architecture you can follow that you know will meet 90% of requirements.
BizTalk projects on the other hand are more usually EAI or SOA related: you're connecting a client's enterprise systems to their other enterprise systems or their partners' enterprise systems, or providing enterprise services that will be leveraged by other systems. The challenges are usually different on each engagement, and (at least I've found) require you to "think outside the box" more often than not. It's one of the things that most attracts me to working on projects involving BizTalk.
This is really where working with BizTalk shouldn't be part-time though: because in my opinion, the only way to learn what the product can do (out of the box and through extension where required) is to work with the product full-time. There is actually an excellent community and body of knowledge around using BizTalk (despite the expectation I was given when I first started working with it), but it really is a full-time job to keep up and stay across it all, and to get to play with interesting ideas and leverage them on clients' projects.
I know that to experienced BizTalk consultants I'm probably not saying anything new, this has just been my observation from my last few years. If you're serious about BizTalk, it's worth considering where it lies within your organisation's strategic direction and your own personal and professional development goals, whether your organisation is a consultancy or a direct consumer of BizTalk.
PS: And BizTalk administration is another job that shouldn't be part-time, but often is... But that's a story for another time.