Friday, July 23, 2010
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.
Tuesday, July 13, 2010
Hi, and welcome to my first blog post!
My name is Dave Sampson, and I'm a software IT consultant located in Adelaide, Australia. I've been in the IT industry over 10 years, working in government, and as part of both small and large IT shops. Technically, I've focused mainly on the Microsoft platform, but more recently have been expanding my horizons into the Oracle / Java world. My focus is primarily on application and connected systems development, which on the Microsoft platform means a whole lot of .NET, SQL Server, WCF, and BizTalk Server.
Anyway, this blog is intended to share my experiences through my consulting career. There'll be a whole lot of deep technical stuff that you may or may not find useful, but from the fact that I'm posting it, I've probably found it useful at some stage. Hopefully there'll also be just as much consulting and professional skills sharing, because I'm always keen to learn and share about new, better, or just different ways of doing things.
I'm going to try to commit to posting once a week about something. As I'm moving from an internal blog, some of my posts will likely be re-posts of old [censored internal] material that I still think is relevant. And moving forward, you'll hopefully hear all about the ups and downs of my consulting career and the technical and professional challenges I've faced.
So anyway, after putting it off for a few weeks now, here's my first post. Hopefully it won't be so long til the next one.
See you next time!