Summary: Candid observations on the past and present of Microsoft patterns & practices

Introduction

Audience

Architects, development managers, and developers who are aware of guidance published by the patterns & practices team, and want to know more about patterns & practices guidance, the factors affecting what guidance the team produces, and the process by which the team produces guidance.

The audience also includes people at Microsoft who seek a common understanding of what the patterns & practices team is producing as it relates to being able to effectively communicate with customers throughout the PAG development process (and who, by the way, can't find our intranet Web site.)

Note:You can call me ... Microsoft originally formed the Prescriptive Architecture Group in late 2000. Many of consumers of the guidance produced by the group still refer to the group as PAG. Later, the group name was changed to Platform Architecture Guidance. Recently, the name of the group was changed to patterns & practices, to identify the group with what it produces.

Why Did We Write This?

Our intent is to give you a deeper understanding of our group's goals, approach, and deliverables. We believe this will help you to engage with us-participating and influencing the way we work and how we create value for you-as you build your solutions using the Microsoft platform.

Our hope is that you will consider this a story that starts (or enriches) a dialogue-a two-way exchange about how a group in Microsoft can help you succeed and the approaches it is taking to make that happen. You have a role in this dialog and we are eager to listen to your feedback and improve our offerings.

This document is not intended as an introduction to_ patterns & practices_ for those unfamiliar with the group. For this type of information, you should visit our main Web site at http://msdn.microsoft.com/practices .

Participating in the Dialogue

This is a set of candid observations-an insider's look at how we work and how we have evolved. This is a subjective point of view, and we realize customers, field people, partners, and even Microsoft product group members may want to tell their own stories and perspectives. Here's how you can participate in this conversation about p&p:

*Post a blog entry and add a link to it from here.
*Edit this page, or add your own wiki topic and link to it from here. If you choose to edit this page directly, please add questions, comments or your own observations. We respectfully request that you do not change the p&p stories. We will be monitoring your comments and updating this wiki periodically.

Content Overview

The topics associated with this wiki revolve around the following four areas.

*TheBirthAndPurposeOfPatternsAndPractices. Includes a brief overview of the factors leading to the launch of the group and the current vision.
*WhatPatternsAndPracticesCreates. Presents observations from a perspective external to p&p. Many customers have a black box view of p&p, and their perception is based solely on the things (assets) we have shipped. In this section we discuss what we have shipped (patterns, application blocks, engineering practices, and so on) and include background information on the forces that influenced our decisions. We also provide a frank discussion about our challenges with mapping different asset types to one another and providing a classification system that makes the most sense to our customers.
*HowPatternsAndPracticesWorks. Explains characteristics of our organization-culture, engineering process, approach, and relationship to other groups inside of Microsoft. This will help you understand the context in which we give guidance, how we work with the engineering groups that build the Microsoft products (product groups), and efforts we make to drive the learning about customer challenges and scenarios back into the product requirements for these groups.
*FuturePlansAndOpenIssues. Talks about directions and future opportunities. We're open about our plans for the next year, as well as our vision for the next three to five years. However, we do not attempt to paint the picture of everything that will come down the road. After all, the community will play a large part in determining what is to come.

Before You Start

We tried to take a candid approach throughout these documents. This means that along the way you will be exposed to facts and decisions that have not been popular, haven't been too wise in retrospect, or are honestly hard to explain without some interesting logic. We hope that by sharing this context, you can understand our values, goals, criteria, and the data that we've worked with. We hope you'll either give us direct feedback, or use our experience for your benefit.

These topics are not polished. But we felt it was important to put our strategy into your hands for early feedback (yet another attribute of the group's culture-seek feedback early, even if it means exposing incomplete solutions).

It is our belief that the dialog around p&p assets and questions like, "How can we help you succeed?" are key to creating an open learning system that benefits Microsoft (including patterns & practices) and customers more broadly.

Thanks for taking the time, and we hope you enjoy reading this and engaging with us as much as we enjoy creating things that help you.

Your Turn!

We hope that this has been entertaining to read and that it provided value in understanding what we’ve worked on and some trends. Why did we do this document? We expect feedback from you on it. We will update this as necessary, we’ll respond & link to your blogs (post your link below this), and we even would like you to insert your own excerpts into this document. By helping us understand your perspective of how & why you use p&p, and telling us how we can help you be more successful, you are influencing the purpose of our group directly.

Go ahead: click the Edit button for this page and add a link to your blog or your own story about p&p

Comments:

Patterns & Practices on GotDotNet: http://practices.gotdotnet.com/

For the last couple of weeks I have been projecting some of the 300 series webcasts with my dev team collegues during lunch. Their feedback is that they are useful and appreciated. Where there were opportunities for improvements would be with more tie-back to code during the webcasts, examples of how to work/code with the guidance in some context, some UML diagrams and a more produced style to the webcasts (ie the jokes keep falling pretty flat).
thanks for the comment I'll forward on --edjez