面对一个客户的具体需求，可以通过问如下问题来决定得到架构设计（尤其是可扩展性、可靠性方面）的基本数据。
- 访问用户有多少?
- 每一个访问用户的操作有哪些？这些操作大概需要花费多长时间完成？
- 这些访问用户一般工作时间段是哪些？
- 有没有上传文档的需求？文档的大小一般多大？
- 公司业务增长的速度多块？由此带来什么样的数据量变化？
等等。 还可以列很多这样的问题。一般来说，一个人在做架构设计的时候能够提出正确的问题比他能解决具体的问题还更重要，对这些问题的设计基本上可以反应出他在架构设计方面的经验有多丰富。如果抛开SharePoint，要设计一个大型网站，你同样需要问类似的问题，最终得到的Profile 越详细越好。
类似这种思想，在微软做产品或解决方案演示（Strategy Breifing）或者在做架构设计(Architecture Design Session)的时候，需要设计应用场景。用户导向和场景导向的思想不管是在研发还是在市场、销售都是思考问题的策略。把你事先设计好的场景串起来，就变成了一个完整的故事（Story）。客户喜欢听故事远胜于听一些产品的功能（Feature List）。
MOSS（Microsoft Office SharePoint Server）作为微软比较成熟的服务器端产品，在设计的时候就充分考虑到了客户的种种需要。比如
- 当数据量和访问量增长的时候，可以和MOM（现在是System Center系列的一部分）集成，以实现对于各种资源的监控和报警。
- 支持Clustering，对于大型的应用，常见的策略是前端（Front-End）使用NLB（Network Load Balancing）后端（Back-end）使用MSSC（Microsoft Cluster Service）是比较合适的。对于中型的应用，使用NLB就可以了。
- 数据库因为使用的是SQL Server，所以完成可以利用SQL Server的HA(High Availability)功能，实现SQL Server 的高可靠性，也有三种方式：Log Shipping, Clustering, Database Mirroring.
MOSS的这个产品的设计场景是什么呢？如果你有如下需求，那使用MOSS就对了。
- 文档管理，包括版本控制、集中化管理等
- 项目管理
- 企业内部资源搜索
- 团队合作Portal
- 简单的业务流程
- 在Web实现一些LOB前端操作
- 表单管理
- BI展现
可能还更多，因为是随意列出的，也许有些遗漏。但那又怎么样呢？说句心里话，一个产品如果功能太多，就很难做到每一个都很精致。至少在UI展现上，SharePoint给我的感觉就是这样。不过话又说回来，微软给自己服务器端产品的定位基本上都是平台的概念，这样才给合作伙伴留有余地去发挥。有听说过微软赚一美元，合作伙伴赚八美元这句话么？哈哈，至少在中国可未必是这样。
