What’s New in 2012 R2: Beginning and Ending with Customer-specific Scenarios

Over the last three weeks, Microsoft has made an excitingseries of announcements about its next wave of products, including Windows Server 2012 R2, System Center 2012 R2, SQL Server 2014, Visual Studio 2013, Windows Intune and several new Windows Azure services. The preview bits are now available, and the customer feedback has been incredible!

The most common reaction I have heard from our customers and partners is that they cannot believe how much innovation has been packed into these releases – especially in such a short period of time. There is a truly amazing amount new value in these releases and, with this in mind, we want to help jump-start your understanding of the key scenarios that we are enabling.

As I’ve discussed this new wave of products with customers, partners, and press, I’ve heard the same question over and over: “How exactly did Microsoft build and deliver so much in such a short period of time?” My answer is that we have modified our own internal processes in a very specific way:We build for the cloud first.

A cloud-first design principle manifests itself in every aspect of development; it means that at every step we architect and design for the scale, security and simplicity of a high-scale cloud service. As a part of this cloud-first approach, we assembled a ‘Scenario Focus Team’ that identified the key user scenarios we needed to support – this meant that our engineers knew exactly what needed to be built at every stage of development, thus there was no time wasted debating what happened next. We knew our customers, we knew our scenarios, and that allowed all of the groups and stakeholders to work quickly and efficiently.

The cloud-first design approach also means that we build and deploy these products within our own cloud services first and then deliver them to our customers and partners. This enables us to first prove-out and battle-harden new capabilities at cloud scale, and then deliver them for enterprise use. The Windows Azure Pack is a great example of this: In Azure we built high-density web hosting where we could literally host 5,000 web servers on a single Windows Server instance. We exhaustively battle-hardened that feature, and now you can run it in your datacenters.

At Microsoft we operate more than 200 cloud services, many of which are servicing 100’s of millions of users every day. By architecting everything to deliver for that kind of scale, we are sure to meet the needs of enterprise anywhere and in any industry.

Our cloud-first approach was unique for another reason: It was the first time we had common/unified planning across Windows Client, Windows Server, System Center, Windows Azure, and Windows Intune. I know that may sound crazy, but it’s true – this is a first. We spent months planning and prioritizing the end-to-end scenarios together, with the goal of identifying and enabling all the dependencies and integration required for an effort this broad. Next we aligned on a common schedule with common engineering milestones.

The results have been fantastic. Last week, within 24 hours, we were able to release the previews bits of Windows Client 8.1, Windows Server 2012 R2, System Center 2012 R2, and SQL Server 2014.

By working together throughout the planning and build process, we established a common completion and Release to Manufacturing date, as well as a General Availability date. Because of these shared plans and development milestones, by the time we started the actual coding, the various teams were well aware of each dependency and the time to build the scenarios was much shorter.

The bottom-line impact of this Cloud-first approach is simple:  Better value, faster.

This wave of products shows that the changes we’ve made internally allow us to deliver more end-to-end scenarios out of the box, and those scenarios are all delivered at a higher quality.

This wave of products demonstrates that the changes we’ve made internally allow us to deliver more end-to-end scenarios out of the box, and each of those scenarios are all delivered at a higher quality.  This cloud-first approach also helps us deliver the Cloud OS vision that drives the STB business strategy.

The story behind the technologies that support the Cloud OS vision is an important part of how we enable customers to embrace cloud computing concepts.  Over the next eight weeks, we’ll examine in great detail the three core pillars (see the table below) that support and inspire these R2 products:  Empower People-centric IT, Transform the Datacenter, and Enable Modern Business Apps.  The program managers who defined these scenarios and worked within each pillar throughout the product development process, have authored in-depth overviews of these pillars and their specific scenarios, and we’ll release those on a weekly basis.

The story behind these pillars and these products is an important part of our vision for the future of corporate computing and the modern datacenter, and in the following post, David B. Cross, the Partner Director of Test and Operations for Windows Server, shares some of the insights the Windows Server & System Center team have applied during every stage of our planning, build, and deployment of this awesome new wave of products.  

* * *

Historically, Microsoft’s approach to building quality Software and Services was to first focus on quality assurance techniques that were targeted to ensure the component and feature functionality behaved according to design specifications. The limitation of this approach was that it ignores the fact that customers do not use the components and features of products in isolation – they use combinations of them to fulfill the needs of their business. Understanding this important fact made it critically important to validate all the functionality within the product, and then ensure it met customer expectations for interoperability.

As we move to the cloud with a faster and more agile cadence, and combine this move with a more complex set of components and requirements, this uncertainty and dependence on long-term beta testing is no longer realistic. With the Windows Server 2012 R2 and System Center 2012 R2 engineering cycle, we dynamically evolved our engineering planning, execution, and quality validation processes by engraining an end-to-end focus on customer scenarios into all phases of the development lifecycle. Specifically, starting with Windows Server 2012 (and expanding in the Windows Server 2012 R2 release), we used customer-specific end-to-end scenarios to plan, prioritize, design, implement and validate the solutions we bring to market.  This approach was analyzed and discussed in several sessions at TechEd 2013 a few weeks ago.

Our approach is to define scenarios from a customer point of view and develop a comprehensive understanding of both what they want to achieve and how they measure success. This scenario-centric approach to building the platform was the primary reason why our 2012 versions of Windows Server and System Center were so well received by our customers. This approach is now a critical part of how we build products and services going forward.

In the Windows Server and System Center division, we have applied this operational philosophy at every stage of development, and the result is a clearly defined value proposition for our customers and end users. The organizational principles we follow are simple:

• Customers can easily understand and have confidence in how various products and components work together end-to-end and no longer need to experiment in their private test labs to learn what might be possible.
• Customers learn from our internal experience and know the best practices, integration points for deployment, and the expected results (e.g. performance, scale, reliability, security, etc.) from the very start.
• Customers can easily validate the scenarios and quality metrics themselves to ensure the integration works in their environment and that these scenarios meet their needs end to end.

This engineering model goes well beyond processes and tools – it is a mindset that places an emphasis on becoming a customer advocate. Our engineers have shifted their attention from the perspective of “does this feature work?” to “will this scenario delight our customers?” Validation and quality are, therefore, not only measured from actual deployments and measurements of success criteria, but also from customer feedback and satisfaction metrics that are provided throughout the engineering cycle.

In all of our current operations we practice both interface validation as well as end-to-end integration testing to validate quality holistically. In addition to this, when moving applications, services and other functionality to the cloud, we must also test in-production or “live” under varying conditions and over time with real world customers. Also, in keeping with a long-standing Microsoft tradition, we still always start by eating our own dog food by deploying every new scenario internally to experience and validate the capabilities of our innovation first hand. We learn from our own internal Services operations and, based on our early deployments, we ensure that we are delivering powerful end-to-end scenarios that enable quick and reliable business solutions.

With this in mind, we are applying the following steps to drive this focus and process in our ongoing engineering cycles:

1. Plan based on customer needs. Our mission is to determine what actions our customers can take to achieve their desired result and understand which metrics are used by customers to measure success. Each of these elements are critical to the scenario-definition process. Once these scenarios are defined, we can then choose and prioritize what we will engineer and validate through the use of CTQ (critical to quality) measurements.
2. Design great products.  We invest in developing great designs for the priority scenarios by specifying requirements, prototyping implementations, and actively validating end user feasibility/usability. Adding more to a product is not the right decision if it will result in a scenario that is incomplete in the end.
3. Implement the software or service.  This is naturally performed by coding, testing, and tweaking incrementally as we measure progress against the scenario goals throughout the engineering cycle.
4. Review our scenarios frequently. We conduct assessments of the status of our scenario CTQs internally and with customers on a regular basis to ensure each scenario is refined based on feedback and deployments, and we are careful to never cut a dependent feature that will impact a scenario negatively. A scenario is only removed when we determine that it will be incomplete without the end-to-end integration of all dependent components. We believe that a few great scenarios are far better than a large number of partial ones.
5. Stabilize the software or service.  We must always ensure the scenarios survive the implementation phase intact, and that we meet our target CTQ goals in the process.  We also continually engage and monitor our target customers to ensure that they will achieve their goals with the end product when it is released.

* * *

We currently follow each of these steps for every new solution, and the current wave of products is an example of this philosophy at work. Our cloud-first focus has enabled common/unified planning which has in turn allowed our teams to collaborate to deliver integrated customer-focused scenarios.

Customer success is the inspiration for our customer-focused engineering, end-to-end product integration, and scenario validation. Windows Server 2012 R2, System Center 2012 R2, and the rest of this amazing wave of products, are a concrete example of our vision and promise for the Microsoft Cloud OS.

– Brad