Today is Partner day at MMS where we have special sessions focused to the special needs of ISV and IHVs.  I’ll be giving an 1.5 hour talk: System Center Foundation Technologies  in which I discuss the management technologies that ship in Windows that the System Center products build upon. 

Most, but not all, System Center products have been shipping for quite a long time so it presents a bit of challenge.  Whenever an new technology comes out, retrofitting an existing product to leverage it is a complex equation.  You might think that as soon as a new platform technology becomes available, products leap at the opportunity to convert to using it.   After all you get:

• Advanced features
• The team is dedicated to that technology so they bring expertise, passion, insight (scar tissue), etc to produce the best and most advanced features.
• Ability to get "free-features" as that technology advances
• These teams continue to innovate and push the envelope.  This is practical because they have a large # of customers which amortizes the investment. 
• Shifting your bugs and testing  burden to another team.
• One of my favorites.  Your ability to generate new features in your product is a function of how many calories you can apply to the problem.  If your dev staff is spending their calories on bug fixing, support costs and testing, it means fewer calories you can apply to new features.  Leveraging other people’s code is a way to export your expenses to another team.
• Reduction in training costs for your customer
• Reduced debugging costs for your field people
• Reduced documentation costs
• … many more benefits

Seems like a no-brainer right?  Hardly.  The team has to factor that against:

• Addressable market (do these technologies run on the [downlevel] platforms that I’m trying to sell to.)
  • I’ve been shocked by how few platform providers understand the concept and yet it is the #1 go/no go question.  If you offer me a STUNNING new technology with UNDENIABLE benefits and INCREDIBLE economies but you offer it on the TRS-80 that has 0% market share, then my friend, the conversation is over.  At the end of the day the folks that consume platforms are the folks that SELL STUFF to people.  If using your platform reduces the number of people that they can sell to (the addressable market) …. well do I even need to finish that statement?
  • This is why I am super hard core about shipping management technology downlevel. 
  • It turns out that management technology is hyper affected by the addressable market issue.  If you are building some user or server application, you just need to convince someone to buy it for some box.  In this scenario, you can make the case for upgrading the box to the latest greatest components because the advantage your application AND the new box/platform brings is SO compelling that it overcomes the inertia for leaving things alone.

    But you run management software on ALL YOUR MACHINES.  So imagine the conversation that starts out, "you’ll have to replace every machine in your enterprise but let me explain why that is actually a good idea".  This is why we are hyper affected, mgmt is a group activity not an individual activity.  If PowerShell only shipped in the latest/greatest OS, then as soon as the OS was the oldest OS in the enterprise, mgmt vendors would start leveraging it.  

    Yes there are hybrid models where under extraordinary circumstances, the vendor will "light up" when the platform is available.  Let me tell you that having been on the other side of this conversation and been responsible for some of these decisions when I worked in the CTO office at Tivoli – they are a pain in the butt.  You have a split code base, double the pain, half the pleasure.

• Conversion costs. 
  • A lot of people think that when 3 teams are developed the same thing, you can SAVE money by having them converge on a common implementation.  That is both absolutely correct and absolutely wrong.  It is correct that in the LONG RUN, you save money.  It is wrong in that you have to fund an additional (4th) team and THEN fund the conversion of the existing products!
  • This is one of the reasons we have PARTNER DAY.  It is cheap and easy to leverage a platform technology if you haven’t already developed your own solution.  That is why we tell partners both what we have and what we are developing so that they can make rational decisions about their own investments (e.g. focus somewhere else for a while or develop it in a way that can be swapped out to use our implementation when it is available).
• Lost opportunity costs.
  • At the end of the day, this is the #1 impediment for teams to embrace new platform technologies.  Take the conversion costs discussed above.  At the end of the day, you’ll do the math and look at the balance sheet and if 1) that is the only thing you looked at 2) you have a healthy business (e.g. you are not focused on surviving through the next 3 months) and 3) a moderately wise professional manager , you would conclude that right thing to do is to convert over ASAP. 
  • The real problem comes when they consider the resources required to do the work and WHAT OTHER FEATURES those resources could be developing!  In other words, what opportunities are lost by doing this work.  Most teams are wildly (overly?) optimistic about the impact their next set of features are going to have in the marketplace and therefore cutting any of them is very painful.

Then you have to consider the startups.  Startup efforts have no existing code and have a PASSION of leveraging other peoples code (thus incurring all the benefits of the first list) and catapulting themselves to new levels of competition by writing the code that they and only they could write.  Leveraging the platform technologies means that every turn of the crank puts them at greater and greater levels of functionality with little to no costs while they get to focus on truly competitive features.  In the meantime, their competition that didn’t pick up the new technology is spending the time and effort fixing bugs, duplicating features or falling behind.

Turn the crank once and there adopters have improved by a bunch and the non-adopters haven’t.  It is uncommon (but not unheard of) for one turn of the crank to produce a decisive advantage in the marketplace.  There are too many other factors in the equation.  But turn that crank a second and a third time and it can be devastating (literally!) [to the competition].

So you might look at all this and ask, "when should a team leverage a platform technology?"  That is the question every team must deal with and solve by themselves.  Using the platform and NOT using the platform are both bets.  You need to look at the details, the upsides/downsides and put your future on the line (pretty good theme given that MMS is being held in Vegas!).

In my talk today, I’ll be going through a couple examples of both.  I’ll discuss Exchange 2007 which retrofitted their existing architecture to take advantage of PowerShell and layer their entire Admin GUI over PowerShell.  I’ll also discussion SC Virtual Machine Manage (SCVMM) which is a V1 product and was able to leverage a number of the platform technologies our team produces (WMI, BITS, WS-MAN, PowerShell). 

If you think SCVMM V1 is awesome, you just wait until we turn the crank on our platform technologies!

Cheers.

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at:    http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at:  http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx