Hi, I have set up a whole new blog for myself at
http://www.rickpelletier.com. . I will no longer be posting on this blog, nor reading comments posted here.
Thanks,
Rick
Rick explains how to add a new dynamic section to Community Server 2.0.
The standard BizTalk Server Developer Training course is Microsoft's 2157A (or 2157B). This is supposed to be a comprehensive course, but I feel that is has many shortcomings. Of course, its not that I blame them on the course's developers, I blame them on the very idea that a comprehensive course can be taught on BizTalk.
Am I just griping? No. I have decided that there are two major flaws with the approach to teaching that both the MS 2157 course and the associated courses from Developmentor, etc. My goal with this post is to inform people of what to truly expect from the 2157 and related courses. There are two main problems with 2157:
1) It focuses entirely on the Development and Administration tools individually, rather than on the concepts behind the tools. This means that even people who have completed this course are NOT capable of successfully dealing with the many (MANY) problems that they are certain to encounter. There is simply no way to teach people how to debug multiple types of code in a single week. XSLT, for example, is 100% different, mentally, to debug than C#.
2) They fail to include any training on the business practices necessary for successfully USING those tools. Students who pass the 2157 course are NOT prepared to interview people and to document requirements for a BizTalk Solution.
They can do an overview of how the architecture MIGHT work, but they have no real ability to dive down in a given component and tell you the best place to lookup the CustomerID from your database, given that the potential message size is small, but the customerID in inside a loop of the message (they won’t even think to ASK if the customerID field is inside a loop of the message…).
They can’t plan correct development time for a BizTalk Map, because they don’t understand that certain things are difficult to pull off with a map (such as nested looping, etc.). They can’t design proper test procedures for a BizTalk Solution, because they don’t truly understand it from start to finish.
I have no real answer to this – the obvious solution is that BizTalk Server cannot be taught in a 1 week class. Of course, companies would never want to train their developers on BizTalk Server if Microsoft told them that they would need 4 weeks to train, and even then they wouldn’t be ready to take the BizTalk MCP exam (which would require an additional 6 months of experience)
I guess I’m writing this just as a warning to everyone making a decision involving the 2157 course… Just keep your expectations low, and you won’t be disappointed.
Sometimes in my consultant travels I encounter development groups that are broken. Completely stalled, from the outside, it appears that the entire group is spinning their wheels -- constantly working, yet never producing anything. This is most often because the team does not have a strong management presence, in my opinion. The obvious answer is to install a strong management presence, but that plan can take months.
But what alternatives exist? I suggest that the debugging approach that we all use on our programs works just as well on Dev Teams. Start with defining the large problem, whether its "My program doesn't do anything" or "My Dev Team is 6 months late on all of their projects".
From there, the obvious next question to ask is "Why?"
You might think that the process HAS to be different working with people rather than with code, but I disagree. If you are debugging some code, and you keep following InnerException through InnerException, eventually you end up with a descriptive error that describes the ACTUAL problem. With people, the same methodology can produce the same results.
At one of my clients, I began working with their SharePoint developer to create a light project management SharePoint site. The site includes test tracking through the various stages, requiring a "sign off" from each stage's Subject Matter Expert. It also includes a development "Task" list for each project that the team is late on.
By dividing and conquering, I reduced the problem down to its smallest pieces -- we all knew that there were two guys who simply weren't working very hard, but the new system very clearly showed that the tests all piled up at Guy #2's stage, and stayed there for 3 days. Guy #1 was supposed to be Guy #2's manager, but he was clearly NOT doing any actual managing.
Using the SharePoint site, I managed to clearly define what the problem was: "Guy #2 is ducking his responsibilities, and Guy #1 is not performing his managerial duties and prioritizing Guy #2's time." The client eventually DID hire a new manager for the both of them, and the results I obtained by using SharePoint have been reported to her.
Using this methodology, you can debug your Dev Team to get it tuned to its highest possible productivity WITHOUT making costly and time consuming personnel changes or scrapping projects.