[转] Leaving patterns & practices / iVAN

[J.D. Meier's Blog]“Life
is like skiing. Just like skiing, the goal is not to get to the bottom
of the hill. It’s to have a bunch of good runs before the sun sets.” – Seth Godin

It's been a good run. After more than 10 years in patterns & practices, I'm on to my next adventure here at Microsoft.

For this post, I wanted to take a stroll down memory lane. During my time at patterns & practices,
I learned more about project management, application architecture,
software development, processes, teamwork, leadership, product success,
and making impact than I think I could have ever hoped to learn anywhere
else. Perhaps the best part, is that I have 10+ years ofdeliberate practice in the art of “best practices” and I’ve had a chance to work with some of the most amazing people in the industry, lead SWAT teams around the world on fantastic voyages and epic adventures, and leave a legacy of several high-impact Microsoft Blue Books, all while mastering the art of prescriptive guidance.

There
are a few ways I can share my journey in patterns & practices. One
of my managers referred to me as “the abilities PM” because of my focus on quality attributes
(security, performance, scalability, etc.) and that’s a pretty good
place to start. My role as a PM (Program Manager) in patterns &
practices, can largely be defined in terms of my impact on these three
areas: security, performance, and application architecture. (Yes, there is more to the story, but those three areas, serve as a good enough lens for now.)

The Security Story
It all started when I joined patterns & practices (PAG or the Prescriptive Architecture Guidance team at the time.)

I moved from Microsoft Developer Support with the expectation that I would share and scale broadly with customers what I learned from living in across the hall from folks likeScott Guthrie, Brad Abrams,
and other .NET Framework leaders. Having performed more than 650
customer architecture and design reviews, I was in a unique position to
share all the principles, patterns, practices, and anti-patterns that I
had seen across a large number of customer projects, many of which were
on the leading and bleeding edge of this space.

But life has a way of throwing curve balls. Around this time, security was Jim Allchin’s
top priority, and he asked patterns & practices what we were going
to do about security. In turn, my manager asked me, what I was going to
do about security. Coming from a middleware background, security was
something I was usually trying to work around, especially when I had to
flow callers to the backend. My new challenge was to design security
architectures for our application platform on .NET. Boy, was I in for a
ride.

I knew security was the name of the game, but I had a lot to learn in terms of leading project teams around the world,
brokering in all the right parts of the company, our community, and the
industry. I also had a lot to learn in terms of how to create
prescriptive guidance. The purpose was not to just put out a book. The
purpose was to drive customer success on the platform. This included creating a durable, and evolvable security story
that our customers could build on, and that we could use to “train the
trainers.” This also meant creating a knowledge base that we could use
as an anchor fordriving product feedback and platform change.
This was all in addition to learning how to think about security from
an architecture and design standpoint, in a way that could help
customers build more secure applications.

And thus the first Microsoft Blue Book, Building Secure ASP.NET Applications, was born. It was our answer to IBM Redbooks.

While
I learned a lot from doing end-to-end security architectures and
putting our variety of products and technologies together, the real
learning came from driving Improving Web Application Security, or “Threats and Countermeasures”, as we affectionately called it. This journey was about learning how to bridge the gap between architecture and design, development, test, and operations. It was about learning how to think about security from
a threats, attacks, vulnerabilities, and countermeasures perspective.
It was about thinking about security in a more holistic way, and our
little mantra was “secure the network, host, and app.”

We had
the ultimate security dream team, on mission impossible, and we pulled
it off. Our core engineering team included Alex Mackman, Michael
Dunner, Srinath Vasireddy, Ray Escamilla and Anandha Murukan, and we had
an extended team of industry champs including Joel Scambray of the
Hacking Exposed series. (In fact, check out the extensive team list at
the bottom of our Threats and Countermeasures Landing Page.)

How do I know we pulled it off? We had outstanding results in our platform security competitive study,
and we were told that is was our prescriptive guidance that made the
difference in a very big way. In addition, our guide was downloaded
more than 800,000 times in the first six months, and it quickly
established the mental models and language for how our
growing customer base thought about security on the .NET platform. It
was a powerful thing when customers would say to us back in our
language, “We’re using the trusted subsystem model …” It was like
poetry in motion.

The big thing we learned from the journey was the power of having end-to-end application scenarios,
along with maps of threats and countermeasures, while baking security
into the life cycle, and using proven practices, like threat modeling,
to significantly change the game.

Here are some of the key security deliverables at a glance from the various security adventures over the years:

This
doesn’t include the product feedback work we did, or the work we did to
bake security into Visual Studio / MSF Agile, or the patents we filed,
which were the icing on the cake. As a sidenote, behind the scenes we
called our “threats and countermeasures” guide “WOMA.” It was short for
weapon-of-mass adoption, because our field was continuously telling us
stories of how they were winning accounts against the competition.

The Performance Story
Performance was right up my alley, but it was a significant shift from security.

Ironically,
I got a lot better at tackling security, by learning more about
performance. The big lesson I learned was that you have to bound or
constrain your efforts in some way. Just like performance can always be
improved, so can security, so it’s all about prioritizing, knowing
where to focus, and connecting back to the business objectives, aside
from the technical perspective, and user experience.

Our first epic adventure in the performance space was the guide, Improving .NET Application Performance and Scalability
(or, “Perf and Scale” as we affectionately called it.) It was where I
first got to work with folks like Rico Mariani, Jan Gray, and Gregor
Noriskin. It was mind blowing.

Working on performance and
scalability was probably the most technically challenging exercise I’ve
had at Microsoft. I remember spending countless days and nights walking
through CLR internals, figuring out how to optimize collections,
sorting through multi-threading patterns, and mastering how garbage
collection really worked. Strangely enough, the “ah-ha” that I
appreciated the most was figuring out that we could think of performance
in terms of response time, throughput, and resource utilization
(CPU, memory, network, and disk.) That little lens was the key to
figuring out how to do effective performance modeling and solving nasty
performance bottlenecks. It also helped us parse complicated
performance scenarios down into bite-sized chunks.

Here are some of the key performance deliverables at a glance from the various performance adventures over the years:

While performance took me to the depth of things, it was application architecture that took me to the breadth of things …

Application Architecture
Creating the Microsoft Application Architecture Guide was a chance to pull it all together.

It
was a chance to finally showcase how to put our platform technologies
together into common application archetypes. Rather than just a bunch
of technologies, we could talk about our application platform very specifically
in terms of application types: Web applications, RIA applications,
desktop applications, Web services, and mobile applications. We could
talk about scenarios and trade-offs. We could look at the shapes of applications in terms of architectural styles and patterns. We could look at cross-cutting concerns,
such as caching, communication, concurrency, configuration management,
data access, exception management, logging, state management,
validation, and workflow. We could also walk the various quality attributes, like performance, security, reliability, manageability, usability, etc.

As you can imagine, this meant putting together a comprehensive map of our Microsoft application platform. The surprise for me was that by putting together the map and looking broadly at the industry, it was easy to see the forest from the trees, as well as better understand and anticipate where the industry was going in terms of what was growing and what was dying. It was a great way to get ahead of the curve.
In fact, I’ve continued to map out our Microsoft application platform
each year, as a way to quickly see the forest from the trees and to
figure out where to spend my time.

During my adventures with
application architecture, I got to learn a lot and work with amazing
people. I also learned how to go across a lot of information faster
and easier, and bring teams of people along the journey. The secret was
to keep creating maps that helped everybody get on to the same page
fast. This was an invaluable approach as our team was hunting and
gathering all the pattern collections we could find. We basically built
a large catalog and constellation of application patterns in the form
of maps. While we didn’t include our maps in the guide, they helped our
team and extended team ramp up in various spaces very quickly, as well
as advance the practice of application architecture. Basically, we
could browse patterns of solutions at a glance.

If you read nothing else, check out A Technique for Architecture and Design.
Behind the scenes, we created this technique by synthesizing the
expertise of more than 30 top solution architects, that had years of
experience with structuring and designing end-to-end applications,
dealing with security, performance, and reliability issues, and dealing
with cross-cutting concerns. The idea was to put down on paper, a
proven practice for rapidly modeling applications on a whiteboard and
identify risks earlier vs. later.

What’s Next?
I’ll
have more to share as I go along. What you’ll most likely see is a
shift to more focus on strategy, execution, and business impact. I’ll
also share more information on the art and science of program management.
I’ve been mentoring a lot of people and I think the PM role at
Microsoft is a very special one. One of my mail goals is to broadly
share the lessons I’ve learned from driving projects and leading teams
and making impact as a PM on the patterns & practices team.

patterns & practices Guidance at a Glance
Meanwhile,
here is my catalog of patterns & practices guidance at a glance.
Note that a lot of the prescriptive guidance I’ve worked on is out of
date because of changes in technology. That said, you can still learn
many of the key principles, patterns, and practices that the guidance
is based on. In this respect, much of the guidance is “evergreen” in
that it’s timeless and durable.

Books

Developer Guidance Maps

Application Architecture

A Language for Software Architecture

Books / Guides

Application Architecture Guide

Methods

Agile Architecture Method

Guidelines

Architecture and Design Guidelines

Checklists

How Tos

Performance

Books / Guides

Methods

Guidelines

Checklists

Practices at a Glance

Performance Practices at a Glance

How Tos

Security

Guides

Methods

Threats and Countermeasures

Cheat Sheets

Guidelines

Checklists

Practices at a Glance

Questions and Answers

Explained

Application Scenarios

ASP.NET Security How Tos

WCF Security How Tos

Visual Studio Team System

Guides

Team Development with Visual Studio Team Foundation Server

Guidelines

Practices at a Glance

Questions and Answers

Source Control Practices at a Glance

How Tos

My Related Posts

作者：蒋金楠
微信公众账号：大内老A
微博：www.weibo.com/artech
如果你想及时得到个人撰写文章以及著作的消息推送，或者想看看个人推荐的技术资料，可以扫描左边二维码（或者长按识别二维码）关注个人公众号（原来公众帐号蒋金楠的自媒体将会停用）。
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。

原文链接

时间： 2024-11-03 17:38:52

[转] Leaving patterns & practices

[转] Leaving patterns & practices的相关文章

Microsoft模式和实践：模式篇（Microsoft Patterns & Practices：

New Release: patterns & practices App Arch Guide 2.0 Beta 1

Patterns & practices Application Architecture Guide 2.0 Released

Microsoft模式和实践：模式篇（Microsoft Patterns &amp; Practi

ASP.NET 2..0站点登录、导航与权限管理

实战 .Net 数据访问层 - 23

Phalanger-PHP的.NET编译器

ASP.NET MVC Controller激活系统详解：IoC的应用[上篇]

Unity(三)：快速入门