The Microsoft Application Architecture Guide, 2nd edition, is now available on Amazon and should be available on the shelf at your local bookstores soon.  The PDF was downloaded ~180,000 times.  This is the Microsoft platform playbook for application architecture.  You can think of it as a set of blueprints, and as your personal mentor for building common types of applications on the Microsoft platform:  mobile, RIA, services, and Web applications.

The backbone of the guide is an information model for the application architecture space.  It’s a durable and evolvable map to give you a firm foundation of principles, patterns, and practices that you can overlay the latest technologies.  It’s your “tome of know-how.”  While it’s not a step-by-step for building specific applications, it is a pragmatic guide for designing your architecture, with quality attributes, key software principles, common patterns, and architectural styles in mind.  It’s holistic and focused on the key engineering decisions where you face your highest risks and most important choices.

Key Features of the Book
The book has several compelling features for slicing and dicing the application architecture body of knowledge:    

• Canonical Frame.  This describes at a meta-level, the tiers and layers that an architect should consider. Each tier/layer will be described in terms of its focus, function, capabilities, common design patterns and technologies.
• Application Types.  These are canonical application archetypes to illustrate common application types: Mobile, Rich Client, RIA, Services, and Web applications.  Each archetype is described in terms of the target scenarios, technologies, patterns and infrastructure it contains. Each archetype is mapped to the canonical app frame. They are illustrative of common application types and not comprehensive or definitive.
• Quality attributes.  This is a set of qualities and capabilities that shape your application architecture: performance, security, scalability, manageability, deployment, communication, etc.
• Cross-cutting concerns.  This is a common set of categories for hot spots for key engineering decisions: Authentication, Authorization, Caching, Communication, Configuration Management, Exception Management, Logging and Instrumentation, State Management, and Validation.
• Step-by-Step Design Approach.
• Principles, patterns, and practices.   Using the application types, canonical frame, and cross-cutting concerns as backdrops, the guide provides an overlay of relevant principles, patterns, and practices.
• Technologies and capabilities.  The guide provides an overview and description of the Microsoft custom application development platform and the main technologies and capabilities within it.

Contents at a Glance
The full Microsoft Application Architecture Guide is available for free on MSDN in HTML.  This is the contents of the guide at a glance:

• Foreword by S. Somasegar
• Foreword by Scott Guthrie
• Preface by David Hill

Chapters

• Chapter 1: What is Software Architecture?
• Chapter 2: Key Principles of Software Architecture
• Chapter 3: Architectural Patterns and Styles
• Chapter 4: A Technique for Architecture and Design
• Chapter 5: Layered Application Guidelines
• Chapter 6: Presentation Layer Guidelines
• Chapter 7: Business Layer Guidelines
• Chapter 8: Data Layer Guidelines
• Chapter 9: Service Layer Guidelines
• Chapter 10: Component Guidelines
• Chapter 11: Designing Presentation Components
• Chapter 12: Designing Business Components
• Chapter 13: Designing Business Entities
• Chapter 14: Designing Workflow Components
• Chapter 15: Designing Data Components
• Chapter 16: Quality Attributes
• Chapter 17: Crosscutting Concerns
• Chapter 18: Communication and Messaging
• Chapter 19: Physical Tiers and Deployment
• Chapter 20: Choosing an Application Type
• Chapter 21: Designing Web Applications
• Chapter 22: Designing Rich Client Applications
• Chapter 23: Designing Rich Internet Applications
• Chapter 24: Designing Mobile Applications
• Chapter 25: Designing Service Applications
• Chapter 26: Designing Hosted and Cloud Services
• Chapter 27: Designing Office Business Applications
• Chapter 28: Designing SharePoint LOB Applications

Appendices

• Appendix A: The Microsoft Application Platform
• Appendix B: Presentation Technology Matrix
• Appendix C: Data Access Technology Matrix
• Appendix D: Integration Technology Matrix
• Appendix E: Workflow Technology Matrix
• Appendix F: patterns & practices Enterprise Library
• Appendix G: patterns & practices Pattern Catalog

The Team
Here is the team that brought you the guide:

• Core Dev Team: J.D. Meier, Alex Homer, David Hill, Jason Taylor, Prashant Bansode, Lonnie Wall, Rob Boucher Jr, Akshay Bogawat
• Test Team - Rohit Sharma, Praveen Rangarajan, Kashinath TR, Vijaya Jankiraman
• Edit Team - Dennis Rea
• External Contributors/Reviewers - Adwait Ullal; Andy Eunson; Brian Sletten; Christian Weyer; David Guimbellot; David Ing; David Weller; Derek Greer; Eduardo Jezierski; Evan Hoff; Gajapathi Kannan; Jeremy D. Miller; John Kordyback; Keith Pleas; Kent Corley; Mark Baker; Paul Ballard; Peter Oehlert; Norman Headlam; Ryan Plant; Sam Gentile; Sidney G Pinney; Ted Neward; Udi Dahan
• Microsoft Contributors / Reviewers - Ade Miller; Amit Chopra; Anna Liu; Anoop Gupta; Bob Brumfield; Brad Abrams; Brian Cawelti; Bhushan Nene; Burley Kawasaki; Carl Perry; Chris Keyser; Chris Tavares; Clint Edmonson; Dan Reagan; David Hill; Denny Dayton; Diego Dagum; Dmitri Martynov; Dmitri Ossipov; Don Smith; Dragos Manolescu; Elisa Flasko; Eric Fleck; Erwin van der Valk; Faisal Mohamood; Francis Cheung; Gary Lewis; Glenn Block; Gregory Leake; Ian Ellison-Taylor; Ilia Fortunov; J.R. Arredondo; John deVadoss; Joseph Hofstader; Koby Avital; Loke Uei Tan; Luke Nyswonger; Manish Prabhu; Meghan Perez; Mehran Nikoo; Michael Puleio; Mike Francis; Mike Walker; Mubarak Elamin; Nick Malik; Nobuyuki Akama; Ofer Ashkenazi; Pablo Castro; Pat Helland; Phil Haack; Rabi Satter; Reed Robison; Rob Tiffany; Ryno Rijnsburger; Scott Hanselman; Seema Ramchandani; Serena Yeoh; Simon Calvert; Srinath Vasireddy; Tom Hollander; Wojtek Kozaczynski

Application Architecture Knowledge Base
The guide was developed in conjunction with our Application Architecture Guide v2.0 Knowledge Base Project. The knowledge base project was used to inform and steer the guide during its development. The Application Architecture Knowledge Base includes a large amount of material that expands on specific topics in the main guide. It also includes draft material from the main guide that is targeted and packaged for more specific audiences, such as the Pocket Guide series.

• Overview Slides
• Train the Trainer (Video)
• Pocket Guides
• Videos
• Slides
• Figures (Visios)

Key Links at a Glance
Here are the key links at a glance:

• Microsoft Application Architecture Guide (MSDN)
• Microsoft Application Architecture Guide (Amazon)
• Application Architecture Knowledge Base

A final PDF is now available for our patterns & practices Application Architecture Guide, second edition.  This is our platform playbook for the Microsoft application platform.

Here are the relevant links:

• HTML version of Microsoft Application Architecture Guide, second edition.
• PDF version of the Microsoft Application Architecture Guide, second edition.
• Printed version of the Microsoft Application Architecture Guide, second edition.
• Knowledge Base for the Microsoft Application Architecture Guide, second edition.

Here are some of my related posts:

• Now Available: patterns & practices Application Architecture Book
• A Language for Architecture
• Ray Ozzie on the Microsoft Application Architecture Guide 2.0
• Grady Booch on the Microsoft Application Architecture Guide 2.0
• 100,000 downloads of Microsoft Application Architecture Guide 2.0

This post is a summary of my lessons learned from leading distributed teams.  I've managed distributed project teams since 2001, spanning the UK, Argentina, India, and other parts of the world.  While I preferred having everybody together on site around a whiteboard to simplify and improve communication,  flexibility with distributed teams gave me access to the right talent, wherever it may be.

Key Challenges
These are some of the most common challenges I faced:

• Trust
• Time zone differences
• Sharing state
• Changes in direction that have a ripple effect
• Communication overhead
• Keeping everybody on the same page
• Sharing knowledge across the team
• Partitioning work for enough autonomy but to keep checks and balances
• Lack of a whiteboard

Distance didn’t matter as much as differences in time zones.  If the time zone differences were too much, it meant  a lot more information, knowledge and state had to be packaged up and handed over.  However, when you leverage time zone differences, the experience can feel like you carry the baton forward, or, it’s like “The Elves and the Shoemaker,” where you make progress around the clock.

Success Patterns for Distributed Teams
The following success patterns helped improve distributed team effectiveness:

• Forming, storming, norming and performing.   The forming, storming, norming and performing lens helps remind everybody to expect that things smooth out over time.  It’s a simple maturity model for explaining how a team gels.
• Proxy / On Point.  One of the most helpful patterns for cross-site communication is to have somebody act as the proxy or person on point to funnel key communication.  This is especially important when their are major time zone differences.  The additional patterns, such as the show and tell, and the Monday iterations and daily stand-ups, keep this from being a single point of failure.  Instead, it’s a focal point with some accountability when key information needs to be shared across time zones.
• Rhythm of results.  Daily, Weekly, and Monthly Results.   While the team might ship every two weeks, thinking in terms of daily, weekly, and monthly results helps set the right mindset.  It creates a bias for action, and it helps get the kinks out of execution.
• Monday Vision, Daily Outcomes, and Friday Reflection.   This is a simple, high-level pattern to drive results each week.   The approach is to identify 3 key outcomes for the week, as well as 3 key outcomes each day, and to use Friday for learning and reflecting. 
• Stories.  By focusing on stories, it makes it easy for everybody on the team to think in terms of end-to-end stories over, features or discipline-focused activities.  It’s a great way to balance the customer, technical and business perspectives, as well as help the team converge around common goals.
• Monday Iteration plans.  Doing iteration plans on Mondays helps set the goals for the week, as well as include everybody’s input.  We keep these to 30 minutes or less.  The outcome is the prioritized set of stories for the week.
• Daily stand-ups.    Everybody calls in and we go around the team asking 3 questions: 1) what did you get done? 2) what are you getting done today? and 3) where do you need help?  We keep these to 10 minutes or less.  It sets the pace and prevents getting side-tracked.
• Invoke a teammate.  One goal up front is to make it easy for everybody on the team to reach whoever they need in an ad-hoc way.  Everybody identifies their preferred email, phone number, Skype account, and instant message information, as well as their main working hours.
• Show and Tell.  I use weekly show and tells as a forcing function.  It gives people on the team a chance to show off their work.  More importantly it’s a simple way to dog food results as well as use the team as a sounding board.  It’s one thing to build something, it’s another to show it to other people and get honest feedback.
• Wiki Knowledge Bases (KBs.)   Using Wikis helps simplify sharing information.  It keeps people from over-engineering and it’s easy to keep updated.
• Experience Step-Throughs.   These are simply short slide decks that mock up the experience.  Each deck walks through one story or scenario visually.  We test the experience with customers, and then we walk through as a team, from a technical perspective.  We do this for high-risk stories.   See Experience-Driven Development and Experience Step-Throughs.
• Distributed pairing.   I’ve found the fastest way to hand over information is to pair people up.  Pairing can also help people get unblocked or keep pace.  It’s not always obvious who pairs up well, so we test different combinations to find what works best for people.  Sometimes it helps to compliment skills.  For example, one person might be great technically, while another might be great with customer experience.
• Mentoring and buddies.   Helping new people on the team ramp up is a priority.  I’ve found the most effective way is to have people pair on things together.  For metaphors, we call it either “co-pilot” or a “student-driver” model.
• Email Triage.  As simple as it sounds, it’s been helpful to include “triage” in the title of some emails.  This tells the team that this email thread may be a drill-down or discussion on a topic.  It’s also a quick way for anybody on the team to ask for help, since they may not know who on the team has the answer.
• One mail.   This is a simple burn down list.  Whenever we’re pushing for a key milestone, it’s helpful to summarize the open work that everybody can see and comment on in a shared way.  To do so, we simply send out an email that lists the current open work to the team and everybody chimes in.  It helps everybody see a tangible finish line.
• Team project site.   It’s important that the team has one place to look for all the shared information.  The most important information here is the schedule, the deliverables, status, and any key information related to either the deliverables or the project.
• Lessons Learned.   I’m a fan of sharing lessons learned on the team.  To bootstrap these, we usually just start an email thread and dump our lessons learned.  We then port the lessons into the Wiki for easy reference.  We list the lessons as one-liners in the form of “do’s” and “don’ts".”  It’s a tickler list that provides a backdrop for richer conversations, dialogues, and discussions.
• Checklists.  Checklists for common tasks have been the best and simplest way to share information across the team.   They help reduce mistakes and carry lessons forward.
• Best Practices Repository.   We store our best practices for each project in a project-level repository.  At the end of the project, we port the best practices to a shared repository across projects.  This way each project is focused on “best practices,” and these are very specific and detailed.  The all up best practices are more generalized to be useful across projects, and as a starting point for new projects.
• Reduce friction in the process.   This is a shared goal on the team to get the kinks out of any sticking points in any of the processes.  We try to innovate in the process to save cost or time or improve effectiveness.  This helps us avoid death by a 1000 paper cuts.
• Video nuggets.   We’ve found that sharing short-videos can help share knowledge on the team very quickly.  These are throw-away videos, but they help capture a snapshot whenever somebody does research in a particular area.

No single pattern is a silver bullet.  Instead, it’s the composition of these patterns and practices that help improve distributed team communication and overall effectiveness.

Tools of the Trade
The following are some common tools of the trade:

• Email.  This is helpful for sharing technical details, state, and general asynchronous communication.
• Conference calls.  This is important for Monday iterations, daily stand-ups, Show and Tells, and any other team meetings.
• Microsoft Shared view.  This is helpful for distributed pairing as well as Show and Tells, so that everybody can see a shared desktop.
• Slides.  Slideware is a great way to share visuals and consolidate key information or to demo ideas and concepts.
• Mind Maps.   Mind maps are a great way to pair and map out what the team knows about a given topic.  We’ve also found them useful for creating Work Breakdown Structures, as a team.  This way everybody gets to see the big picture  as a simple map.
• Instant Messenger.  This is especially helpful for simply knowing when people on the team are around and for ad-hoc synch ups.
• Skype.   This has gradually replaced setting up conference calls.  In fact, we’ve started having better luck with Skype than conference calls in terms of clarity in some cases.
• Groove.  This has been our simplest way to share files instead of email.  There are some tricks to learn, but we’ve successfully shared projects of with thousands of files and hundreds of MBs.

What about you?  … What have been your best lessons learned when it comes to distributed teamwork?