软件架构师应具备哪些有关 SharePoint 的知识？

Question

在我们公司，我们目前正在尝试定义我们的软件架构师必须了解的有关 SharePoint 的基本知识，以便他们构建和/或领导 SharePoint 实施项目。我们公司的许多架构师都有 .NET 开发人员背景，并且非常了解 .NET 开发以及各种框架组件和工具。但是，他们目前缺乏 SharePoint 知识。事实上，他们甚至不想知道细节。他们只想了解足够多的信息，以便做出正确的架构决策并应用经过验证的模式。如果需要更具体的知识，他们会询问 SharePoint 专家。

那么架构师需要具备哪些基本的 SharePoint 知识/技能？

Answer 1

列表、文档、工作流、权限等技能有点过于基础，是 SharePoint 开发人员的必备技能。

我认为场地（和场地结构）可能是属于建筑师的领域。

SharePoint 架构师可以在更多领域提供帮助：

• 容量规划 - 在场中运行多台服务器。可扩展性和其他神奇词汇。

• 了解使用 SharePoint 的功能和业务场景 - 这是很常见的。
  经理问：SharePoint 能为我做什么？ 开发者问：好吧，你想让它做什么。 然后经理问：嗯，我不知道它可以为我做什么，那我怎么知道我想要它做什么？

• 与 SharePoint 功能密切相关的是与每个组件相关的各种许可成本。

• 以及熟悉开发和定制成本。使用与 ASP.NET 相同的项目时间，然后将其乘以一个较大的系数，然后再添加一个额外的常数。

• 与可以做什么和成本多少密切相关的是投资回报率的所有重要问题。 祝您投资回报率最高！

• SharePoint 部署可能是一个大问题，而且很痛苦。

• SharePoint 从 v2 (MOSS 2003) 升级到 v3 (MOSS 2007)。我们应该会在 2010 年看到新版本的 SharePoint（？）。在下一版 Office 面世后不久。所以过去的升级经验可能会有用。

• 了解第 3 方 Web 部件。我相信 SharePoint 架构师应该能够为您提供他们从 CodePlex 尝试过的至少 5 个 Web 部件，并告诉您他们对它们的看法。这些都是免费的，您可以在闲暇时轻松获取和玩耍。

• 商业网络部件的一些知识。因为它们仍然比自己编写更便宜。

• 至少有 5 个他们虔诚地关注的 SharePoint 博客（了解社区）。如果没有自己的 SharePoint 博客（回馈社区）。

• 如果他们在 StackOverflow 上，他们必须尝试回答 SharePoint 问题（例如这个问题）。

• 参加本地 SharePoint 用户组。我认为社区很重要。尤其是您从直接与人交谈以及了解他们使用 SharePoint 安装所做的事情中学到的东西。你可能会让自己大吃一惊。

• SharePoint 集成经验 - 这有两种同样重要的风格 - 来自 SharePoint 访问现有系统（业务目录、Webpart 等），以及其他系统通过 Web 服务或 API 访问 SharePoint 内容。

• 此外，SharePoint 可与 Office、OCS、报告服务、性能点、项目服务器一起使用（或很好地使用）。

• SharePoint 托管安排 - Microsoft SharePoint 联机服务可能是开始使用 SharePoint 的一种流行且更便宜的选择。它可以在内部托管，也可以由第三方公司托管。了解选项总是有用的。

• 必须阅读过使用反射器的 SharePoint 代码（最好还有头发）。

我认为成为一名 SharePoint 架构师至少需要几年的时间（您的里程可能会有所不同）。您的 .NET 架构师需要想成为 SharePoint 架构师，否则我同意其他人的总结 - 找一个已经是 SharePoint 架构师的人。

Answer 2

架构师应该从功能和技术角度对我们的产品作品有很好的了解。

所以在我看来，建筑师应该：

• 从设计到推出，至少参与了 2 次 Sharepoint 部署。
• 了解我们可以使用 API 使用的主要 Sharepoint 组件。 即站点、列表、文档和工作流组件。

由于您的架构师都没有这方面的知识，我会将他们与现有 Sharepoint 项目中的 Sharepoint 专家配对，以便他们获得所需的知识。

Answer 3

理想情况下，SharePoint 架构师技能属于以下提到的类别

1. 基础设施级别/运营
   1. 容量规划
   2. 物理架构（农场设置、网络、操作系统、许可）
2. 应用程序级别（功能和非功能）\
   1. 需求和可行性分析（定制与 OOTB 开发/实施）
   2. 需求的技术功能映射
   3. 信息架构
   4. 逻辑架构
   5. 概念架构
   6. 详细设计
   7. 数据库设计（不是传统的数据库设计），这是关于网站集/Web 应用程序的内容数据库数量。
3. 部署
   1. 首次部署和增量部署的最佳方式

架构师将协同工作的其他一些活动是规划、估计、执行/实施、风险管理（评估、缓解）的项目经理。

除了与技术团队、测试人员、用户界面专业人员、供应商、客户（业务和 IT 团队）合作的日常任务。

如果有的话，与 Enterprise Architect 小组互动。

Answer 4

在我不那么谦虚的意见中，我认为整个“Sharepoint Architect”/“Expert”这件事玩得太过了。 Sharepoint 是一种集中组织数字资源的工具，用于集中协作或以集中方式协同工作。

Microsoft Sharepoint 是什么以及做什么的最佳解释 来自 WROX 书籍“Beginning Sharepoint 2010 - Building Business Solutions”

“因为计算机在任何业务中都扮演着不可或缺的角色，毫不奇怪，越来越多 在组织中创建、使用和共享的信息中有一部分是数字化的。越多 您开展的业务以及您的业务越成功，您获得的信息就越多 必须管理。通常，几乎每个流程和交易都有某种形式的文档 在您公司的日常运营中发挥作用。从提案到法律 文件，从销售收据到人力资源政策，所需的信息量 一家公司的运作是惊人的。

为了管理您的信息过载，SharePoint 提供了您可以用来建立业务的工具 应用程序来更好地存储、共享和管理数字信息。有了它，您可以创建列表， 为您的各个公司团队提供库和网站，以帮助您更多地运行业务流程 有效率的。通过将组织的重要业务数据定位在一个位置，它就变成了 让用户在需要时更容易和直观地找到正确的信息，而不是 搜索不同的位置，例如电子邮件、计算机硬盘驱动器或文件共享。

什么是 SHAREPOINT 2010？ SharePoint 2010 是一个可扩展且可扩展的基于 Web 的平台，由工具和技术组成 支持团队内部、整个企业和整个企业的信息协作和共享 在网上。总包是一个平台，您可以在该平台上构建业务应用程序来帮助您 更好地存储、共享和管理组织内的数字信息。因为你可以建造 无论有没有代码，该包都可以让普通业务用户创建、部署和管理 团队网站，而不依赖于熟练的资源，例如系统管理员或开发人员。 使用列表、库和 Web 部件，您可以将团队网站转变为专为提高组织的业务流程效率而构建的业务应用程序。”

为组织的 Sharepoint 部署创建架构并不是火箭科学。 1. 确定组织结构 2. 确定 Sharepoint 在集中组织数字资源方面可以做什么。 3. 制定 Sharepoint 建设计划。 4. 构建、测试、改进。 5. 维护它、测试它、改进它、添加它。那里！没那么难。

Answer 5

如果您不了解 Sharepoint 的来龙去脉（他们应该是构建它的专家），Sharepoint 可能是一个令人讨厌的野兽。他们至少应该知道列表、站点和权限是如何工作的。理想情况下，他们还应该知道所有 Web 部件如何在页面上组合在一起以及它们应该如何交互。真的，如果架构师不想了解 sharepoint，他们将创建一个 .net Web 应用程序并强制它在 sharepoint 上运行。它不会真正遵循共享点应用程序应该如何工作的范式。

我会查看一家名为 Mind Sharp 的公司，了解他们应该学习什么。

Answer 6

我的建议是，在 Sharepoint 世界中寻找一个不只是阅读 PowerPoint 的实干家，这只是基于其他人所说的话。

我们在 Sharepoint 场中抓取 500000 个项目时遇到了问题，每个人都提供了另​​一个故事如何获得更好的速度...通常人们在一个文件夹中引用不超过 2000 个项目，但这不会改变抓取速度....

所以一个好的架构是一个能够自己对他的设计进行概念验证的人，而不仅仅是参考一些模糊的故事.....

我见过许多没有现实生活经验的 Sharepoint Architects....