The First Step in working with our ISV Partners
The introductory post hopefully gave you a better idea of our team charter of enabling our ISV partners and their products to achieve maximum scalability on our data platform. I wanted to share some more today about how we work with our ISVs. The process is very collaborative and I attempt to describe the initial step in this post (with more detail in later entries).
The first step is really to learn about our partners application and what are the requirements from the application from a technical and business level from the end customer viewpoint. The customer viewpoint is very important as it helps us understand the performance, availability and scalability aspects to meet the needs of a business. Most of our partners build apps that can be called ‘Tier 1’ – this means that the customer’s business will be impacted if there is down time or loss or performance degradation.
Next we try to understand the application and how it is put together from a technical perspective. There are several tools to help with this but at the end of the day it is working with our customers side by side in their facility or ours. The picture below is taken from a recent engagement where an ISV came to our labs in Redmond. Our lab is located in Building 20 on the corporate campus and provides an excellent environment for collaboration, whiteboarding and discussion.
We have a great facility that includes a dedicated ISV lab which has huge whiteboards and the furniture/layout facilitates collaboration as we work side by side. The picture below is taken from an architecture design session and we went into great detail to understand the ISV app architecture, the data access architecture, schema and other areas. Once we have a good understanding we can recommend some areas of improvements that will not require fundamental changes in application code but would provide a performance improvements. In the case above we saw several hundred recompiles in the application code (due to the way that SQL was generated without parameterization). This was changed to use a stored procedure and resulted in significant gains due to the recompiles going away. The ISV was happy and was able to provide this change via a patch to a customer that was about to go live with the application. The customer was happier as they were able to meet their user SLA and get unbeatable price/performance with the app running on ISQL Server on an industry standard servers(X64). In the next post I will describe in more detail some of our engagements and learnings
