|Microsoft's New World / Old World Development Schizophrenia - A Case in Point|
|Written by Darwin Sanoy|
|Saturday, October 10, 2015 9:06am|
For one of my clients I created a PowerShell automation framework that could work stand alone (great for testing) or under SCCM - with no coding changes to switch. I was excited to wire up it's error reporting system to SCCM custom status MIFs. Somehow in the age of the API the SCCM development team decided to drop this very helpful feature - but only from "Applications" because the are so much "better"...
SCCM is a complex system and like all systems it makes assumptions about what you need to do. All systems have to make fundamental assumptions like this. However, in the modern age of software - the way to give customers the ability to extend these systems is via APIs. So why eliminate these flexible options in an "upgrade"? The only answer I can think of is "old world" development methodologies. Microsoft development is currently in a schizophrenic. On one end of the spectrum you still have "Big, Blackbox Product Teams" that make assumptions like "we removed custom MIFs because in Application Objects we gave you the ability to handle multiple return codes in the UI". Great - so now rather than just bubble up my standard messages from an automation template, have to configure *each* SCCM Application for *each* error I would like to pass back and see in reports. Sure I could automate creating jobs or use a job definition file - but why not just leave the API available to me?
On the other side of the schizophrenia you have teams like those developming Azure and PowerShell - true agile development and a development idealogy that defaults to end-customer enabling APIs - so that the customers can teach the developers all the cool ways a flexible engine technology can be used.
Microsoft has left custom status MIFs working for SCCM "Package" objects (SCCM 2007 style packages) - but they continue to seed fear, uncertainty and doubt about the future of "Package" Objects. Yet package objects remain more flexible than Application objects in many, many ways. This also smacks of old world development - use your roadmap to shoehorn customers and their requirements into the product feature sets you want to support.
Microsoft, if you want to supercede a technological implementation around which customers have built out processes, practices and toolsets - please make sure it does all the former things. And if it the new functionality does not truly supercede in all ways - then don't threaten retirement of the more capable one. Let's face it, customers who implement something and get value from something as complex as SCCM are also likely to be developing their own processes, practices and toolsets around - having to change those is expensive and it unnecessarily inhibits adoption.
I hope that all the Microsoft development teams will transition to the customer empowering focus on how products are developed - including their roadmaps and respect for past customer investments. Thank you to the Microsoft teams that are doing this - it's a breath of fresh air!