Hello! My name is Pratul Dublish and I am a Program Manager in the Dynamic Systems Foundation team at Microsoft. My team is responsible for building the infrastructure and tools for Service Modeling Language (SML). The recent public announcement about SML has generated a lot of interest and questions, and I am starting this blog to provide my personal perspective on SML, the events that led to the formation of the SML working group, and answer your questions. In future blogs, I will attempt to explain how to use SML for building models and also reply to questions and comments posted by you.
I joined the Dynamic Systems Foundation team in February 04, after working as a Program Manager in Windows Media DRM (remember the “very popular” Secure Audio Path feature in Windows XP ;-) ) and MapPoint teams. I was attracted to this team by its compelling vision to drastically simplify and reduce the costs for IT services management through the power of model-based management. The team was working on a technology called System Definition Model (SDM) that had been created in Microsoft Research. Most of you must’ve have heard about SDM – Microsoft has talked about SDM at various conferences for the last two years and it has shipped in Visual Studio 2005.
When I joined the team, the development of SDM v1 (code name Collider) was well under way for Visual Studio 2005 and the team was started work on SDM v2. The primary scenario for SDM v1 was to enable design-time validation of distributed deployments in Visual Studio’s design surface, and SDM v2 was being designed to support model-based deployment and configuration of IT services and systems. Our focus was on building a runtime that exposed a C#-programmer friendly API. We designed a rich, but proprietary, meta-model for SDM v2. This did not worry us since we believed that SDM v2 will be confined to Microsoft’s products. We built a proof of concept prototype that demonstrated the power of model-based deployment by using a model of SharePoint for deployment and configuration. We were able to convince two products to use SDM v2 (it helped that one product was owned by our team J) and started work on building features to support the scenarios for these two products.
We were cruising along when we decided to conduct an SDM v2 design preview in November 05. This design preview changed everything. What happened? Well, our customers and partners talked, and we listened and took action. The overwhelming feedback from customers and partners was that they loved the concept of SDM and the power of model-based management, but they disliked its proprietary schema and Windows-centric nature. They asked that SDM schema be aligned with existing XML standards, and that Microsoft should consider standardizing SDM. This triggered off a chain of events that culminated in the SML announcement.
We went back and digested the feedback, and decided to define a new version of SDM – SDM v3 (you may find it funny since we had not shipped SDM v2, but SDM v2 was still being used within Microsoft, so we incremented the version number). We decided to base the meta-model of SDM v3 on existing XML standards: XML Schema 1.0, Schematron, and XPath 1.0. This decision was based on the feedback from partners and the ubiquitous support for XML technology in platforms, products, and tools from different vendors.
The transition from SDM v2 to v3 was not easy. My team had invested considerable effort in designing the SDM v2 schema and building an SDM v2 runtime with a rich programming model, ability to discover SDM instances by inspecting real-world IT services, and the ability to synchronize changes to SDM instances to the corresponding real-world services. In addition to designing a new meta-model, we had to build a new runtime that exposed an XML-friendly API. But once the decision was made to move to SDM v3, we built the SDM v3 runtime in record time (Did I mention that my team has really awesome developers?)
In parallel, Microsoft had initiated discussions with other industry leaders about forming a working group to standardize SDM v3. Once this group was formed, Microsoft submitted the SDM v3 meta-model specification as an initial input to the working group. The SML specification is the result of this initial input and the contributions made by other members of the SML working group.
What do we expect to achieve by standardizing SML? The primary reason for this effort is promote interoperability between different management systems, enable easier management of heterogeneous systems, and allow customers to build models that can be used across management systems from different vendors – thereby ensuring that the customer investment in models that capture their best practices is preserved and these models are portable across different systems. If you’re starting to think “Wait a minute, a standard modeling language is not sufficient to enable this?”, then you are right. SML alone is not sufficient to get us to this manageability Shangri La. Common models and common management protocols are also required. The good news is that we are thinking about common models, so stay tuned for further updates.