Question

尽管我的商业经验大多数都跟开发定制的软件系统有关，也还是见过不少SharePoint1和其他产品/平台实现，软件架构的基本原理已被遗忘或忽视。这里总结了为什么软件架构对SharePoint项目很重要。

1微软开发的企业信息管理方案。——译者注

很多SharePoint实现都不只是SharePoint

我见过的很多SharePoint解决方案都不仅仅是最终用户可以创建列表、分享文档和协作的SharePoint产品的简单实现。与大多数软件系统一样，它们是新旧技术的混合体，是复杂的集成，常常通过Web服务和其他集成技术进入企业的其他部分。无论是运行在SharePoint内部还是外部，定制的.NET代码往往也是整体解决方案的一部分。如果你不考虑“大局”、了解环境及其约束，你最终构建的东西有可能是错的或者不管用。

非功能性需求仍然适用于SharePoint解决方案

即使你没有为你的SharePoint解决方案写任何定制代码，也不意味着你能忽略非功能需求。性能、可伸缩性、安全性、可用性、灾难恢复、审计、监测等都是潜在适用的。我见过SharePoint项目团队忽视对关键非功能性需求的考虑，甚至是面向互联网的公开网站。结果不出所料，一个响应时间糟糕或安全缺陷严重（如跨站点脚本）的解决方案。这样的问题在项目生命周期的后期才被发现。

SharePoint项目很复杂，也需要技术领导力

和其他编程语言一样，SharePoint是一个复杂的平台，解决一个问题通常有很多不同的方式。为了得到保持方法的一致性，避免混乱，SharePoint项目很强的技术领导力。无论你是实现一个平台还是从无到有编写软件系统，软件架构角色都适用。如果你见过这样的SharePoint项目，一个看起来很混乱的团队最终交付质量糟糕的解决方案，你就会明白为什么有技术领导力很重要。

SharePoint解决方案仍然需要编写文档

有了这样的复杂度，我还惊讶地不断看到没有任何文档的SharePoint解决方案。我不是在说多达200页的文件，但至少应该有一些轻量级的文档，给出解决方案的概览。用一些图表来展示SharePoint解决方案如何在高层次工作，也很有用。我的C4方法也很适合SharePoint，一些轻量级的文档可以成为未来的支持、维护和改进工作的一个很好的出发点，特别是如果项目团队有变化，或者如果项目在外包协议下交付。

强大的领导力和纪律不只是针对软件开发项目

如果要交付软件解决方案，那就需要确保至少有一个人担任技术领导角色，否则你就错了。另一方面，所有这些都适用于其他平台的产品，比如SAP和微软Dynamics CRM，特别是如果你“只是增加一个面向互联网的ASP.NET网站，来通过互联网暴露一些数据”。

我曾向SharePoint团队提起这一点，有的回答：“但是SharePoint不是软件开发。”无论是不是软件开发，成功的SharePoint项目需要很强的技术领导力和纪律。SharePoint项目也需要软件架构。