Не совсем уверен, что это должно быть здесь или в Stackoverflow, но я смотрю на это не с точки зрения разработчиков, а с точки зрения администраторов.
Раньше у нас была довольно анемичная интрасеть - теперь с SharePoint 2013 она получит гораздо больше применения. Мы в основном откладывали инвестирование на последние полгода;)
Моя проблема в том, как организовать сайты так, чтобы они лучше всего работали с SharePoint в долгосрочной перспективе, с точки зрения администратора, в то время как, возможно, сайты добавляются или удаляются.
Раньше у нас было ОДНО семейство сайтов (Интранет) с подсайтами в нем (не в папке / sites) для всех основных частей небольшой компании (финансы, организация, ИТ-услуги и т. Д.). Я не уверен, что это «достаточно хорошая» гибкость для многолетней работы. Меня также немного беспокоит то, что все находится в одном семействе сайтов ...
Я просто настраиваю новую интрасеть (переместив старую в новое приложение, старое). Итак, мы приступаем к нескольким вопросам.
Я определенно хочу заняться поиском, так как мы планируем перемещать все больше и больше документов и т. Д. В sharepoint - мы маленькие (7 человек), но необходимо полное разделение отделов, например, разработчики не могут видеть наши финансовые отчеты . Нам также нужно - в 2-3 отделах - настроить интеграцию бизнес-аналитики, создать субпорталы для людей, чтобы люди могли видеть данные из баз данных (своего рода «получить обзор, как мы стоим»).
Немного потерял, как настроить это, чтобы настройка не вернулась, чтобы укусить меня через несколько месяцев.
Хорошо, я пока даю один ответ - посмотрим, найдет ли кто-нибудь что-нибудь получше.
Похоже, это все для Момента - хорошая вещь с подобными коллекциями сайтов заключается в том, что теоретически они могут перейти в разные базы данных контента, если они перерастут одну базу данных контента, которая у нас есть сейчас. Это актуально, поскольку в остальном это административный кошмар. Коллекции сайтов также имеют полностью автономную настройку безопасности и функций, что означает, что проекты по обновлению определенного сайта могут быть относительно изолированными. Опять же, это административное соображение, а не конкретный программист, но приятно знать, что я могу отдельно развивать финансы или другую область без слишком большого количества перекрестных ссылок. Всегда полезно думать об изолировании таких областей, чтобы проекты разработки не выходили за рамки возможностей.
TomTom,
Трудно кому-либо дать прямой ответ на ваш вопрос, поскольку вы спрашиваете об информационной архитектуре и топологии - все часто зависит от обстоятельств и требований бизнеса. В компании из семи человек непонятно, все ли это сотрудники или ваш ИТ-персонал? Вы используете SharePoint 2013 локально или размещаете? Сколько сайтов или семейств сайтов вы действительно видите добавлением и удалением в течение года? И, в таком случае, разделяете ли вы сайты или семейство сайтов, чтобы отделить доступ (например, финансы от HR и т. Д.)? Какую информацию вы разделяете - файлы? Я готов поспорить, что в компании из семи человек вы можете делать все, что вам нужно, в одном семействе сайтов и использовать пару библиотек документов для разделения доступа к информации. Сколько накладных расходов на навигацию и накладные расходы на сайт вам нужно?
Теперь, если я неправильно понял размер вашей компании и, допустим, вы поддерживаете компанию с парой тысяч сотрудников, я мог бы предложить вам эти предложения. 1. Подумайте о SharePoint в функциональных областях: интрасеть для потребления ресурсов (статический контент) и сотрудничество для работы над проектами и взаимодействия с другими. 2. Вы можете развернуть сайт публикации для целевого семейства сайтов в интрасети и воспользоваться его способностью создавать навигацию к другим ресурсам и сайтам. 3. Многие компании принимают участие в проектах с разными отделами. Вместо того, чтобы создавать HR-проект по пути / hr и ИТ-проект по пути / IT, что не так с общим путем, таким как / sites / project 1, sites / project2 и т. Д.? Таким образом, если ваша компания когда-либо реорганизуется, ваши проекты останутся всего лишь проектами, независимо от спонсирующего отдела. 4. Сайты против дополнительных сайтов. Как менеджер проекта, я всегда настаиваю на том, чтобы я запускал свой проект как семейство сайтов верхнего уровня. Я могу иметь полный доступ (и ответственность), и мне не нужно беспокоиться о том, что другие пользователи сайта проекта будут использовать мое ограниченное хранилище. Кроме того, я могу установить политики в отношении запросов доступа и хранения пользователей. Традиционно считалось, что подсайты снимают нагрузку на ИТ, вызванную запросами пользователей, но я никогда не видел и не слышал, чтобы это когда-либо было проблемой. Кроме того, преимущества, полученные в отношении квот, безопасности, сценариев резервного копирования и восстановления, благоприятствуют семействам сайтов, или, другими словами, семейству сайтов только с сайтом по умолчанию / внутренним сайтом.
Опять же, ваши вопросы носят общий характер, поэтому на них сложно дать идеальный ответ. Если вы новичок в SharePoint, вам могут помочь такие консультанты, как я, и онлайн-ресурсы.
Чак ЛаФорте
Forte Design