I want to thank you, Ed, for giving me a clearer argument for building out a more robust and recyclable lab environment. Well articulated.
Ivan Lindenfeld From: [email protected] [mailto:[email protected]] On Behalf Of Nemec, Dale Sent: Wednesday, September 16, 2015 12:58 PM To: [email protected] Subject: [mssms] RE: WHAT??? Another Release?!? WHAT??? Ed's not having fun in Vegas? Thanks Ed for the insights! I guess the "old way" of providing a stable and reliable computing environment (i.e. network, machine, servers, etc.) are going to have to change along with the software dev and release cycles. And when IT doesn't "move" fast enough, the users are able to self-service via cloud services which brings up all sorts of IP and protection questions. Try to have some amount of fun, eh? Dale Nemec | Global Architecture & Technology Ops (ESS) | Tektronix From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ed Aldrich Sent: Wednesday, September 16, 2015 6:52 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] WHAT??? Another Release?!? Observations On the Concepts of Time and SW Development Since I'm not having fun in Las Vegas at IT/Dev (BTW! Did you hear about the killer Keynote Mike Schultz delivered??? Standing ovation at the beginning!!), I thought I'd take a moment to share something I've been wrestling with some time now. This probably should be a blog post, but here it is anyway. You may have noticed over the past 6-12 months or so that there are more and more releases of SCCM product updates coming out of Redmond. This causes a lot of consternation trying to keep up, while still doing the usual test/evaluate before going into production. I thought it a good idea to share some of the realities that the MVPs are learning through our interactions with the Product Group that helps explain this, and to set expectations for the future in the wider community. What used to work for SCCM (from 1.0 -> 5.0 of shipping every 4.5 years), doesn't work anymore. The Product Group used to have the luxury of coding something huge for 2 years, and then have a 2 year endgame with a couple of beta's to drive up quality prior to final release. We all know that they definitely know how to ship a high level of quality with SCCM, if they have a 4-5 year release cycle. As we are seeing now with the Win10 release, Microsoft as a company, and their technology, has evolved. Consequently the dev team(s) no longer have the luxury of a 4-5 year ship cycle. This is clear, and is not just something impacting the SCCM team. For example, SMS 5.0 (SCCM 2012) started design/architecture in 2006 (one year before 2007 shipped). The team felt strategically way back then that device management would be key in the near future. They invested heavily in device management for SCCM 2012. However by the time it shipped in 2012, the whole landscape had changed. They can no longer plan releases 4 years in advance. Out of necessity there is a requirement for more agile development, and moving faster. There is literally a new OS of one kind or another nearly every single month, whether it is Windows, Windows Phone, IOS, or some flavor of Android. There is no longer the luxury of having a 2 year endgames in SCCM to drive up quality. As a further illustration of what you have seen, and will be seeing: SCCM is scheduled to ship two major releases in 2015 (SP2/R2SP1 went out in May, and vNext is due in Q4). The team also shipped 4 previews releases in a 120 day period (Ignite preview in May, TP2 in July, TP3 in Aug and the latest 1509 Preview in Sept just going out). Consequently, the PG Team are evolving from the old way of doing things, to a new, more agile development process. Windows is doing the same thing. The engineering efforts have to build a pipeline that can move at the rhythm of the rest of the industry, and do so without risking the hundreds of millions of devices being managed by CfgMgr. Going forward, I suspect the plan will be to ship these tech previews even faster to help get more feedback from the community and catch bugs and issues faster. In the past, with the long release cycles and lengthy BETAs, those betas helped to catch real world issues, but that is a luxury not possible in today's rapid-release cycle. By releasing SCCM updates more often, it is clear that the team will need that same amount of community feedback. Thus, they are moving towards releasing these previews faster. Rather than having 4 betas over a 4 year ship cycle, they will now aim for 4 previews over approximately a 4-12 month SCCM schedule. The key here is to try and get the same level of feedback and iteration as was seen under the old, longer, model. Clearly all of this will have implications for the community as we will need to look at sorting out a more robust lab/testing model that lends itself well to a rapid rebuild/upgrade method to get these newer releases into a testing scenario efficiently. If I were you, I would be looking very hard at what I have, or should have, that will allow me the means to rapidly and repeatedly build up my test environment in order to keep pace with these frequent releases. There is a ton of modern tech evolving in this virtualization and cloud spaces. We all need to figure out the best way to adapt and evolve. Having this community as a means of sharing ideas, best practices, and how-to is going to be extremely important in the immediate future. Stay tuned! Ed Aldrich Mobile: (401) 924-2293 [email protected]<mailto:[email protected]> | www.1e.com<http://www.1e.com/> [Description: Description: cid:[email protected]] Ent Cli Mgmt (2003-2015) ________________________________ Legal Notice: This email is intended only for the person(s) to whom it is addressed. If you are not an intended recipient and have received this message in error, please notify the sender immediately by replying to this email or calling +44(0) 2083269015 (UK) or +1 866 592 4214 (USA). This email and any attachments may be privileged and/or confidential. The unauthorized use, disclosure, copying or printing of any information it contains is strictly prohibited. The opinions expressed in this email are those of the author and do not necessarily represent the views of 1E Ltd. Nothing in this email will operate to bind 1E to any order or other contract. ________________________________ NOTICE: The information contained in this message is proprietary and/or confidential and may be privileged. If you are not the intended recipient of this communication, you are hereby notified to: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately.
