Создание архитектуры ферм SharePoint — задача непростая, и решать ее лучше всего силами целой группы архитекторов. Организовав такую группу, вы резко повысите вероятность успешного завершения проекта. В этой статье я хочу поделиться своими соображениями о том, кого и почему следует включить в коллектив архитекторов, а также о том, каких принципов должна придерживаться такая команда. Но сначала мы выясним, какие роли могут выполнять архитекторы SharePoint.

Роли архитекторов SharePoint

Как правило, один человек не является специалистом по всем дисциплинам, необходимым для разработки проектов SharePoint, и архитекторы SharePoint обычно специализируются на одной или нескольких дисциплинах. Так, корпоративные архитекторы могут специализироваться на согласовании бизнес-целей с возможностями технологических средств и выполнять обязанности руководителей групп специалистов по SharePoint. Разработчики информационных систем, возможно, сосредоточатся на том, как распространить информационную архитектуру (скажем, метаданные, логическую модель) на SharePoint или расширить ее таким образом, чтобы они включала в себя и SharePoint. Технические специалисты по архитектуре могут специализироваться на развертывании SharePoint и связанных с этой платформой технологий.

Если вы являетесь архитектором, то вне зависимости от специализации на вас будут возложены задачи по получению требований и сбору вспомогательных материалов, которые обеспечат возможность разработки среды SharePoint. Не думайте, что вам удастся без труда получить всю необходимую информацию. Скорее всего, в целях документирования недоступных или неизвестных на данный момент сведений вам придется вступать во взаимодействие с участниками различных процессов.

Чтобы справиться с ролью архитектора, необходимо хорошо владеть навыками коммуникации, иметь опыт разрешения конфликтных ситуаций, а также уметь выполнять задачи с учетом расстановки сил в коллективе. Архитектору часто приходится вступать в дискуссии относительно работы, которую сотрудникам предстоит выполнить, и вести переговоры о том, как преодолеть обнаруженные расхождения во взглядах ко взаимному удовлетворению. Наконец, вы должны обладать навыками работы с соблюдением требований корпоративной культуры. Культура каждой организации имеет свои особенности, однако есть и общие принципы. К примеру, в компаниях, работающих в сфере технологий, к авторам не вполне проработанных решений обычно относятся довольно снисходительно, тогда как для финансовых организаций характерен более жесткий подход.

В дополнение к перечисленным базовым навыкам полезно иметь за плечами опыт в пяти областях: корпоративная архитектура, эксплуатация, информационная архитектура, SharePoint Server и SQL Server. Перед тем как перейти к ним, хочу отметить следующее: с практической точки зрения весьма сомнительно, что один человек может обладать опытом во всех пяти сферах. Более того, вполне возможно, что в некоторых организациях не окажется ни одного сотрудника, обладающего опытом работы в той или иной специализированной области. Поэтому ответственность за эти участки, или роли, обычно возлагается на нескольких человек, и некоторые из этих ролей порой приходится передавать работникам со стороны.

Корпоративная архитектура. Сотрудник, ответственный за эту сферу, должен оценивать бизнес-требования (такие, как управление службами, управление продуктами и финансовые требования) с точки зрения корпорации. Вполне возможно, что данную роль придется поручить стороннему специалисту, который будет работать во взаимодействии со штатным архитектором организации.

Эксплуатация. Работник, выполняющий эту роль, должен иметь четкое представление об эксплуатационных процессах организации, о процедурах, политиках, наборах инструментальных средств и об участии в работе представителей сторонних компаний (к примеру, выполняющих отданные «на сторону» функции).

Информационная архитектура. Тот, на кого возложили эту роль, должен разбираться как в терминологии, так и в данных, применяемых в коммерческой деятельности организации, и использовать эти знания в процессе формулирования требований к метаданным, определения типов контента, рабочих потоков и т.д. Эту роль часто отдают на аутсорсинг. Более подробные сведения о роли «информационная архитектура» можно найти на сайте Information Architecture Institute, в книге Луиса Розенфелда и Питера Морвилла Information Architecture for the World Wide Web (издательство O'Reilly Media, 2002 г.) или в книге The Elements of User Experience (Джесси Джеймс Гарретт, 2003 г.).

SharePoint Server. Сотрудник, выполняющий эту роль, должен иметь за плечами опыт развертывания и поддержки новейших версий SharePoint Server (например, SharePoint Server 2013) в течение ряда лет, а также опыт подготовки специалистов по обслуживанию данных систем. Отсутствие серьезного опыта работы с SharePoint Server нежелательно как для самого сотрудника, так и для организации в целом. Чтобы быть на уровне ожиданий пользователей (что может и чего не может делать продукт в серийном исполнении), чтобы уметь устанавливать и настраивать системы SharePoint Server, а также осуществлять административное управление ими (ведь у каждого изделия свои особенности), он должен освоить все тонкости работы с продуктом. Кроме того, выполняющий роль SharePoint Server сотрудник должен знать, как определять базовые показатели для нормального функционирования и планомерно наращивать пропускную способность с использованием заранее заданных критериев (то есть осуществлять мониторинг производительности и пропускной способности, результаты которого дают возможность определять, когда устанавливать дополнительные аппаратные средства и соответствующим образом конфигурировать ферму, чтобы оставаться в границах ожидаемого уровня обслуживания).

SQL Server. Работник, которому доверена эта роль, должен обладать опытом развертывания и поддержки новейших версий SQL Server (например, SQL Server 2012), а также опытом подготовки специалистов по их эксплуатации. Не имеющий достаточного опыта работы с SQL Server сотрудник подвергает риску как свою карьеру, так и перспективы всей организации, поскольку SQL Server по праву считается «сердцем» платформы SharePoint. В частности, структура SQL Server должна обеспечивать требуемую пропускную способность, выраженную в объеме дискового пространства и в числе дисковых операций ввода-вывода в секунду (IOPS), на протяжении всего жизненного цикла продукта. Эти требования должны быть четко сформулированы и переданы архитекторам хранилища SAN. Кроме того, должны быть организованы операционные процедуры, обеспечивающие мониторинг и профилактическое обслуживание.

Наконец, чтобы успешно спроектировать ферму SharePoint, необходимо проявить такие качества, как терпение, широта взглядов, понимание особенностей работы с политиками и готовность учиться. Я всегда советую коллегам постоянно быть готовыми к восприятию нового. Качества, развивать которые я призываю сотрудников, отличают человека, готового самостоятельно решать задачи, от работника, способного только выполнять команды.

Коллектив архитекторов SharePoint

Как показывает практика, почти за каждым человеком, добившимся успеха в жизни, стоит сплоченный коллектив, и в этом смысле архитектор, успешно спроектировавший среду SharePoint, не является исключением. В таблице приводится перечень членов команды архитекторов SharePoint, указываются роли, которые им полагается играть, и главные ожидаемые результаты их деятельности. Отметим, что в некоторых проектах могут быть представлены роли, не упомянутые в таблице.

 

Члены группы архитекторов SharePoint

Не в каждом проекте используются все роли, перечисленные в таблице. Так, ответ на вопрос о том, следует ли включать в штат представителя сторонней компании, зависит от того, отдаются ли какие-либо роли на сторону. Общее правило таково: чем большие участки передаются в чужие руки, тем важнее ввести в состав бригады представителя сторонней компании. Не имея такого сотрудника, вы рискуете столкнуться с «дорожными заторами» или непредвиденными проблемами на более поздних этапах реализации проекта.

Как правило, чем крупнее организация, тем больше должно быть число входящих в группу архитекторов; дело в том, что одноцелевые роли хорошо вписываются в масштабные структуры. Если вы собрали многочисленную команду, каждый ее член будет отдавать выполнению порученной ему роли весь свой опыт. С другой стороны, вам придется иметь дело с более широким кругом лиц, каждое из которых имеет собственный режим работы.

А вот в небольших организациях сотруднику обычно приходится принимать на себя несколько ролей. Но хотя это обстоятельство может упростить деятельность группы — вам придется принимать во внимание персональные особенности и графики работы меньшего числа сотрудников — за плечами у членов группы обычно не столь богатый опыт в областях, относящихся к выполнению некоторых ролей.

Важно отметить, что в коллективе архитекторов должны быть представлены все заинтересованные отделы.

Мысленно возвращаясь к тому времени, когда я делал первые шаги в ИТ-отрасли, я вспоминаю, что обычно начинал проект с сервера и двигался от него, как от центра. Эта стратегия эффективна в небольших организациях с системами минимальной сложности, но когда речь заходит о более крупных и более сложных организациях, такой подход почти наверняка приведет к неудаче. Мне доводилось терпеть поражения, и я извлек из них множество практических уроков. В ту пору мне казалось, что это негативные уроки, но теперь, оглядываясь назад, я убеждаюсь, что это весьма позитивный опыт, и я хочу поделиться им с вами.

Первый урок, о котором я хочу упомянуть, состоит в следующем. Вы совершите одну из самых серьезных ошибок в процессе развертывания компонентов SharePoint, если будете смотреть на эту работу как на технологическое решение и разворачивать систему, не учитывая пожеланий коммерческих подразделений.

Вот еще несколько усвоенных мною уроков, которые вам стоит иметь в виду при проектировании архитектуры SharePoint.

Изложите факты на бумаге. На встречах с заинтересованными сторонами и с членами группы вам придется документировать и распространять информацию. Подобным же образом, когда вы будете осуществлять процесс сбора и создания артефактов (о котором речь пойдет ниже), вам нужно будет фиксировать детали, чтобы обеспечить поддающуюся измерению возможность отслеживания.

Это важно, поскольку реализация проекта порой занимает много времени, и люди забывают, о чем было достигнуто соглашение, и кто в нем участвовал. Кроме того, вам следует использовать сайт SharePoint для размещения, распределения и отслеживания контента. Наконец, рекомендую создать план по взаимодействию, в котором будут содержаться сведения о том, какие коммуникации необходимы, с кем, как часто и в каком формате.

Обеспечьте поддающуюся измерению возможность отслеживания. «На выходе» любого совещания, любой презентации и операции по сбору данных должны фиксироваться некие артефакты. К ним могут относиться сделанные на совещании записи, касающиеся различных проблем, действий, которые необходимо совершить, решений, которые следует принять, назначения прав собственности, сроков проведения мероприятий, а также ожидаемых результатов. Кроме того, такими артефактами могут считаться направленные вам документы, подтверждения соглашений или требований.

Процедуры организации и отслеживания артефактов именуются обеспечением поддающейся измерению возможности отслеживания. Они помогают «привязывать» фактические требования к заинтересованным сторонам, напоминать партнерам о тех или иных фактах и организовывать эффективное взаимодействие. Рекомендации по установлению поддающейся измерению возможности отслеживания вы можете найти на сайте Project Management Institute (www.pmi.org/). Выполните поиск по фразе project management body of knowledge или просто по акрониму «PMBOK».

Используйте механизмы управления

Управление — это интересная, но сложная тема, поскольку она касается как людей, так и технологий. Как правило, наибольшую сложность представляют именно люди, ибо нам приходится иметь дело с разными психологическими типами. Возможно, вам доводилось работать с «держимордами», с «нытиками» или с другими персонажами, отравляющими жизнь членов коллектива.

Вот здесь-то и приходит на помощь исполнительный спонсор. Сотрудник, выдвигаемый на эту роль, имеет большой организаторский опыт и политический вес, достаточный для того, чтобы решать проблемы такого рода еще до того, как они пустят под откос весь проект. Итак, управление в первую очередь предполагает работу с людьми и только во вторую — с технологиями, потому что если вы не работаете с людьми (образно говоря, не смазываете колеса), с технологиями вы не управитесь наверняка.

Так в чем же состоит специфика управления? Вопросы создания, запуска и руководства программой управления SharePoint обсуждаются на общедоступном веб-семинаре Real-World SharePoint Governance (sharepointpromag.com/webinar/real-world-sharepoint-governance).

Наряду с этим вебинаром в Интернете существует множество других ресурсов, содержащих рекомендации по вопросам, связанным с управлением, но мне пока не удалось отыскать ресурс, где проблемы управления освещались бы, что называется, от начала до конца. Поэтому для того чтобы осмыслить ситуацию в целом, вам придется просмотреть ряд ресурсов, таких как:

  • статьи о планировании управления, перечисленные на веб-странице Governance planning in SharePoint 2013 (technet.microsoft.com/en-us/library/ff598584.aspx);
  • книгу How Top Performers Manage IT Decision Rights for Superior Results (авторы Питер Уайлл и Жанна В. Росс, издательство Harvard Business Review Press, 2004 г., hbr.org/product/it-governance-how-top-performers-manage-it-decision-rights-for-superior-results/an/1248KB-KND-ENG);
  • «Белые книги» и другие ресурсы на сайте AvePoint (www.avepoint.com/solutions/governance#resources).

Следите за политическими тенденциями внутри организации. Наряду с применением механизмов эффективного управления и привлечением возможностей исполнительного спонсора вы должны постоянно держать в поле зрения политический ландшафт своей организации. Не сформировались ли в ней автономные «вотчины», которые могут представлять угрозу для всего проекта?

Вообще говоря, чем крупнее масштаб организации и чем сильнее она распределена территориально, тем выше вероятность появления в ней политически обособленных «островков». Чтобы примирять противостоящие точки зрения и находить управу на тех, кто попросту не хочет сотрудничать, вам нужно взаимодействовать со спонсором и использовать методы эффективного управления. Необходимо понимать, какие битвы вы можете выиграть, а какие не стоит даже затевать.

Если вы хотите добиться успеха, формулируйте достижимые метрики. С помощью методов эффективного управления вы должны устанавливать достижимые метрики для своей архитектуры. Эти метрики могут принимать различные формы.

Финансовые. Пример финансовой метрики: стоимость планирования, проектирования и развертывания фермы SharePoint не должна превышать 4 млн долл., а ежегодные расходы на эксплуатацию — 2,5 млн долл.

Метрики, касающиеся бизнес-процессов. К ним относятся сокращение количества обращений за санкциями на использование форм и упрощение бизнес-отчетов.

Технические. Примеры технических метрик: загрузка страницы должна укладываться в норматив 10 секунд, запросы на поиск должны возвращать результаты в пределах первых 3 страниц, которые должны отображаться до истечения 10 секунд.

Операционные. Пример операционной метрики: при подготовке сайтов необходимо обеспечивать заданный уровень обслуживания.

Организационные. Пример организационной метрики: необходимо обеспечивать соответствие установленным законом требованиям, имеющим отношение к данной отрасли.

Заключайте соглашения об уровне обслуживания (service level agreement, SLA). Основным объектом SLA должны быть компоненты SharePoint в формате предлагаемой услуги, и эти соглашения должны основываться на метриках для достижения успеха. Ниже приводится ряд примеров метрик, ориентированных на службы.

Доступность. К метрикам доступности могут относиться целевые сроки восстановления (recovery time objectives, RTO), целевые точки восстановления (recovery point objectives, RPO), доступность службы, а также время, за которое можно восстановить ферму, сервер, коллекцию сайтов, сайт, список, библиотеку или объект (например, документ) в случае отказа службы.

Производительность. Метрики производительности могут включать в себя время загрузки страницы (например, страница загружается за 5 секунд), результаты поиска, а также время выгрузки документов в Интернет и загрузки на компьютер (например, документ объемом в 10 Мбайт загружается в течение 10 секунд).

Подготовка. К метрикам подготовки могут относиться промежутки времени, за которые подключаются дополнительные мощности (речь, к примеру, может идти о добавлении серверов, веб-приложений, коллекций сайтов или отдельных сайтов.

Во всех соглашениях об уровне обслуживания необходимо фиксировать сферу ответственности каждой из вступивших в соглашение сторон.

Выделите время на доказательство правильности концепции (proof of concept, POC) и на пилотное тестирование. Проследите за тем, чтобы эти операции были обязательно выполнены. Они полезны во многих отношениях: сигналы о возникающих проблемах будут поступать к вам раньше, пользователи смогут познакомиться с новой технологией, у сотрудников ИТ-подразделения появится возможность больше узнать о продуктах SharePoint, а руководители организаций получат практические примеры того, что может дать применение технологий SharePoint.

А теперь — о следующих шагах, которые группа архитекторов SharePoint должна выполнить, чтобы спроектировать успешную систему SharePoint.

  1. Определите риски и составьте план мероприятий на случай возникновения проблем.
  2. Создайте лабораторию.
  3. Собирайте данные.
  4. Документируйте требования и другую важную информацию.
  5. Обсуждайте, вдавайтесь в подробности и добивайтесь консенсуса.
  6. Определитесь, какую архитектуру вы будете применять: на базе одной фермы или с использованием нескольких ферм.
  7. Примите решение о том, следует ли виртуализировать SharePoint.
  8. Определитесь с тем, будете ли вы задействовать среду стороннего подрядчика.
  9. Докажите корректность избранной архитектурной модели.

Подробное описание перечисленных шагов предполагает использование большого объема материалов, поэтому я рассмотрю их в нескольких статьях.