I have been invited to present on several topics at Microsoft TechEd 2009, May 11th-15th. The topics include:
I have had a number of inquiries regarding my mentorship opportunities lately, and thought I would share an overview of how this program works. Generally, it is related to the delivery of integration solutions, whether it be specific to BizTalk Server or not (SOA, .NET, Web Services, approaches to integration as a whole – these have all been needs that I have been able to work with individuals on in a mentorship role). The outline is as follows; feel free to contact me if you have any question about how this could specifically apply to your situation:
- Assess the need of the mentorship. What is it that you are working on? Development specific tasks? Long term infrastructure needs?
- Discuss the duration and level of support needed. Generally the duration is 3 to 6 months, on an as needed basis. I respond to email, phone calls, and other correspondence within the same day.
- Discuss the pricing options. Depending on the needs, and what level the mentorship is at, we can come to a mutually acceptable way in which to work together.
- Execute on the plan. Bringing specific needs and questions, we work together in a partnership role to ensure that what you are delivering, recommending, or documenting fits the needs, targets the audience, and is architected based on the proper application of technology.
It is often invaluable to have someone to work with on complex implementations and architectures. The mentorship program provides an extremely effective avenue to allowing this to happen.
There are a lot of parties in the technology world that use the terms “Consultant” and “Contractor” interchangeably. It is important to outline the differences between the two, and determine, when looking at bringing an individual or party into a project, that you understand who you are working with.
A [Technical] Contractor is someone who has a specific technical skillset, such as a background in an application, programming language, or platform, who can build out a solution based on requirements that have been specified. Of course, such persons (or groups of people) range from highly skilled to marginally incompetent. The one uniting factor is that they do not have the ability to step out of their area of expertise and offer a high level assessment as to what should be done in a given area, or even recommend that an entirely different technology from their skillset be used. For example, hiring someone with a deep understanding of SharePoint will lead to a SharePoint centric solution; hiring someone who loves Open Source solutions, will lead to an architecture based on Open Source concepts. A Contractor delivers what they know how to deliver, for a given price – they cannot, and will not, be able to give objective views as to what should be done; they can implement, but not architect.
A [Technical] Consultant is someone who often has a deep skillset in one or more technologies, and can implement and deliver solutions based on these technologies. However, these individuals (or parties) can actually stand back from the stated solution and make recommendations and provide insights into how these solutions should be implemented; whether they have anything to do with their specialized skill set or not. This ability to provide objective information about a solution, and work with their customers to come up with a solution that fits the need is where they can set themselves apart and bring a tremendous amount of value to the table.
There are many Contractors pawning themselves off as Consultants, to the detriment of their customers and clients. It is not the responsibility of the client to understand how to implement something, or what the best approach to a technical solution is; but it is their responsibility to find the appropriate resource for the job at hand, and to understand the difference in nature between a Contractor (skilled hired hand) and a Consultant (a partner to the business, and a skilled implementor).
I will be giving two sessions related to BizTalk 2006 R2 during the TechEd conferences in Orlando this summer. The descriptions are as follows:
1. Building EDI Solutions in BizTalk Server 2006 R2
With the release of BizTalk Server 2006 R2, true enterprise level EDI functionality has been introduced into the platform. Seasoned developers familiar with BizTalk implementations but inexperienced with the EDI components, and new developers looking at understanding how BizTalk can solve their EDI needs will both find value in looking in detail at the different aspects of BizTalk EDI development. This session will introduce working with EDI schemas and documents, configuring trading partners, mapping data, and delivering EDI documents (via the VAN or AS2). Witness a full end to end solution being developed, and walk away with a rich understanding of the skills required to successfully engage in this type of development.
2. EDI and BizTalk Server 2006 R2: Successful Trading Partner Management
The vast majority of B2B commerce is done using the EDI standard, and this continues to increase annually. Organizations are looking at ways to migrate their current solutions to more scalable, robust, and affordable enterprise platforms which will support this increasing workload. As the primary contender in this space, BizTalk Server 2006 R2 has extensive capabilities for supporting EDI, and it is essential to have the skills necessary to architect and develop BizTalk EDI solutions. This session will give an overview of the role that BizTalk parties play in EDI processing and will explore in detail, through walkthroughs and real world scenarios, the most effective means of configuring and managing trading partners. Key takeaways from this session will include best practices in implementing trading partners in BizTalk EDI solutions, understanding the difficulties associated with managing large numbers of trading partners, and considerations to take into account when scaling in order to support these larger implementations.
