As you’ll see when you read this book, there is a fine line between best practices and design decisions. Best practices tend to be built on the proper use of the technology, taking into account what the technology does, what it does not do, and what it was intended to do. Design decisions tend to account for how that technology can fit into the current culture and how it will map to meeting the business and technology requirements. At some point, design concepts and best practices are intermingled. At other times, best practices are presented with a notation that other design choices might be possible and might be the best choice given a different scenario. Consider this e-mail we recently received from an administrator:

Sure, we’ve recently got the Extranet Collaboration Toolkit for SharePoint, but my takeaway is that it’s based on a virtually useless premise: that everything we’d like to access via SharePoint is in a perimeter network. It addresses some self-service functionality far more than my security concerns. My security concerns:

Thanks for any thoughts!

Now, regardless of what you think might be the answer to our friend’s design question, what we want you to focus on is how different the answers or choices would be if the system administrators were willing to manage extranet accounts or if the SharePoint Server 2007 farm was placed in the perimeter network. We think that it would be a best practice for the system administrators to manage the external accounts. But in this case, asserting that position as a design choice for his scenario would likely lead to the design being rejected. Take the same scenario; change a couple of details, and suddenly what is a best practice in one scenario is a non-factor or perhaps a poor design choice in another. So often, the art of the design is found in applying the combination of the requirements and the culture of the organization to the features of SharePoint Server 2007.

It is impossible for us to discuss every possible scenario that might exist in the market today. You’ll likely need to adapt our thinking to your scenario in order to arrive at a good design for your environment. This book will provide a starting point for discussions about SharePoint Server 2007 deployments world-wide. But the results of your discussions may be shaped by responses that disagree with our recommended best practices as much as those that do align with our recommendations. As long as your design and deployment is improved, either through agreement or disagreement with the ideas we offer in this book, we will consider our efforts as having borne fruit.

It would be good to let you know that our ideas have been vetted with several different groups within Microsoft, including some who support this product directly with Microsoft customers, the internal group that is responsible for implementing and managing SharePoint within Microsoft, and team members whose full-time responsibility is developing and communicating best practices for SharePoint Server 2007. This is not to say that every word is somehow endorsed by the product team, but we have incorporated the input of different groups who work with this product all day, everyday. Their input has both improved this book and sharpened our thinking on the product. Any mistakes in the book, of course, belong to us.