Интеграционные проекты что это
Интеграционные проекты: практические кейсы на основе собственного опыта
Интеграционные проекты: практические кейсы на основе собственного опыта
Интеграционные проекты: практические кейсы на основе собственного опыта
Любой интеграционный проект включает в себя несколько этапов, я не буду останавливаться на этапах, не смежных технической области или напрямую не относящихся к информационной безопасности, и выделю четыре (см. рис. 1).
Остановимся на каждом этапе подробнее. В данной статье мы рассмотрим все этапы интеграции на примере создания системы мониторинга событий информационной безопасности (СМСИБ).
СМСИБ применяется для:
Проведение обследования
В большинстве случаев на данном этапе проводится изучение текущей инфраструктуры. Итоговым документом должен быть отчет о предпроектном обследовании, который содержит:
СМСИБ применяется для:
Этот этап чаще всего проводится заказчиками в рамках системной интеграции единого проекта, но также может проводиться отдельно как научно-исследовательская работа (НИР).
Если предпроектное обследование проводится в рамках НИР, то, помимо аудита текущей инфраструктуры, анализируются имеющиеся на российском рынке продукты СМСИБ, выбирается программный продукт и составляется технико-экономическое обоснование. В таком случае документ “Отчет о предпроектном обследовании” дополнительно включает в себя:
Подготовка технической/проектной и эксплуатационной документации
Это является важным этапом, т.к. определяет технические решения, проект внедрения СМСИБ, порядок подготовки к вводу СМСИБ в действие, порядок взаимодействия подразделений и многое другое.
Важно, чтобы техническая и эксплуатационная документация была подготовлена в соответствии с требованиями:
Более подробно о составе документов и их содержании говорить не буду.
Внедрение
Самый важный этап. В нем, как правило, задействованы не только специалисты, обеспечивающие ИБ, но и представители блока ИТ. В нашем случае мы еще привлекали разработчиков программного обеспечения, интеграция которого была запланирована с СМСИБ.
Этап внедрения включает в себя следующие мероприятия:
Как менеджер проектов, который занимается организацией взаимодействия интеграторов, вендоров и представителей ИТ-блока, согласованием документации и принятием решений по определению архитектуры СМСИБ, я бы определила, что самыми сложными работами являются подключение источников событий и настройка правил корреляции. Именно от их правильного выполнения зависит корректная работа СМСИБ, и на них я остановлюсь поподробней.
Для себя мы решили подключить источники событий, представленные в табл. 1.
Так же, как и источники событий, каждая организация выбирает для себя, какие события либо их совокупность будут являться инцидентами ИБ (от этого и будет зависеть настройка правил корреляции).
В табл. 2 приведен перечень инцидентов ИБ, для выявления которых в СМСИБ настраиваются правила анализа (корреляции) собираемых событий безопасности.
Проблемные моменты
Хотелось бы отметить проблемные моменты, с которыми столкнулись при выполнении работ по подключению источников событий и настройке правил корреляции.
Техническая поддержка
Здесь все просто. Поддерживать систему в работоспособном состоянии непременно необходимо, так как не каждая организация может позволить себе иметь в штате квалифицированного специалиста, обычно заключают договор на оказание технической поддержки первой и второй линии. Данные о правилах оказания технической поддержки прописываются в SLA.
Все эти этапы могут выполнить как разные интеграторы, так и один интегратор (системная интеграция).
При проведении интеграционного проекта я очень рекомендую проводить системную интеграцию (рис. 2), так как такой вид проектной деятельности в будущем поможет избежать ряда проблем, связанных с донастройкой и эксплуатацией систем ИБ.
Преимуществами системной интеграции являются:
Подводя итог, хотелось бы сказать, что внедрять новые системы совсем даже не страшно, а увлекательно, интересно.
Управление интеграцией проекта
Интегрировать – это объединять в одно целое какие-либо элементы или процессы. Интеграция (лат. integratio — восстановление, восполнение, от integer — целый). Управлять интеграцией в проектном менеджменте означает выполнять действия и процессы, направленные на объединение и координацию процессов и действий, необходимых для достижения целей проекта и удовлетворения ожиданий его заинтересованных сторон. Области знаний в управлении проектами зависят друг от друга, процессы управления проектами пересекаются между собой, проектная деятельность может быть связана с результатами текущей деятельности организации и, наоборот, поэтому важно управлять данными взаимозависимостями с целью принятия своевременных решений относительно конфликтов ресурсов, конфликтов целей и влиянием на проект различных заинтересованных сторон. Кроме того, управление интеграцией включает в себя действия, необходимые для интеграции различных документов проектной деятельности. Процессы управления интеграцией проекта. К процессам управления интеграцией проекта относят следующие процессы:
Инструменты и методы
УПРАВЛЕНИЕ ИНТЕГРАЦИЕЙ ПРОЕКТА
Разработка Устава проекта
Описание работ по проекту :Бизнес-потребность; Описание содержания продукта; Стратегический план; Экономическое обоснование; Контракт; Факторы среды предприятия; Активы процессов организации
Разработка плана управления проектом
Устав проекта; Выходы процессов планирования
Факторы среды предприятия; Активы процессов организации
План управления проектом
Руководство и управление исполнением проекта
План управления проектом; Одобренные запросы на изменение; Факторы среды предприятия; Активы процессов организации
Информационная система управления проектами
Результаты: Информация о выполненных работах; Запросы на изменение; Обновления плана управления проектом
Обновления документов проекта
Мониторинг и управление работами проекта
План управления проектом; Отчеты об исполнении
Факторы среды предприятия; Активы процессов организации
Запросы на изменение
Обновления плана управления проектом
Обновления документов проекта
Осуществление общего управления изменениями
План управления проектом; Информация о выполненных работах; Запросы на изменения; Факторы среды предприятия; Активы процессов организации
Собрания по управлению изменениями
Обновления статусов запросов на изменение
Обновления плана управления проектом
Обновления документов проекта
Завершение проекта или фазы
План управления проектом; Принятые результаты; Активы процессов организации
Передача конечного продукта, услуги или результата
Система управления проектами: интеграционный подход
От менеджеров проектов зависит многое, но, безусловно, не все. Для успешной и эффективной работы менеджера и всей команды проекта должны быть созданы определенные условия.
Управление проектами – искусство, наука, ремесло
Деятельность многих компаний в самых разных областях реализуется в форме проектов. В то же время известно, что даже в не слишком сложных проектах возникают проблемы, которые проявляются в недовольстве заказчика и собственного руководства, срыве сроков, превышении смет, конфликтах внутри команды проекта и др. Профилактика и преодоление этих проблем являются важнейшими составляющими деятельности управленческого персонала проекта и должны поддерживаться соответствующими стандартами, методологией и инструментальными средствами.
Таким образом, как и любой другой вид профессиональной деятельности, деятельность по управлению проектами порождает развитие самостоятельного рынка продуктов и услуг. Опишем примеры некоторых таких услуг и продуктов (см. рис. 1).
Рис. 1. Услуги и продукты на рынке управления проектами
Управлять проектами должны профессионалы, но количество настоящих профессионалов в этой области в России относительно невелико и, очевидно, отстает даже от осознанного спроса. Искусством управления проектами обладают конкретные личности, в которых соединены определенные человеческие качества, опыт и знания. Далеко не каждая компания, реализующая проекты, связанные с ее бизнес-деятельностью, имеет (или даже может себе позволить иметь) в своем штате подобных специалистов. Такая услуга, как предоставление персонала управления проектами (менеджеров проектов), достаточно широко распространена в мире. Не является она чем-то экзотическим и в России.
К важнейшим элементам, влияющим на развитие и формирование данного сегмента рынка, относятся обучающие курсы и сертификационные программы. Очевидно, при прочих равных условиях предпочтение будет отдано сертифицированным специалистам и консалтинговым компаниям, располагающим этими специалистами.
К настоящему времени накоплен значительный опыт по различным методам управления проектами в таких областях, как определение целей, сетевое планирование и управление, планирование и контроль затрат, управление рисками и т. д. Продукты и услуги в научно-методическом секторе рынка предлагаются в разнообразных формах – от учебной литературы до специализированных программных средств, от отдельных образовательных программ до сертификации по национальной и международным программам.
От менеджеров проектов зависит многое, но, безусловно, не все. Для успешной и эффективной работы менеджера и всей команды проекта должны быть созданы определенные условия, позволяющие в полной мере реализовать их возможности. Требуется, чтобы существующие обычно по отдельности методические, инструментальные и некоторые иные средства, необходимые для успешного управления проектом, были объединены в одну систему, в рамках которой задачи менеджера и команды проекта решались бы с наибольшей эффективностью. Другими словами, требуется создание и обеспечение эксплуатации интегрированной системы управления проектами – СУП. Это особенно важно при выполнении больших проектов или на предприятиях, постоянно занимающихся проектной деятельностью.
Интегрированная система управления проектами предприятия
Постановка задачи создания интегрированной СУП требует первоочередного внимания к тому набору функций, которые будет обеспечивать такая СУП. Сразу стоит обратить внимание на то, что во многие СУП должны входить функции, которые часто упускают из виду или считают полностью принадлежащими другим системам предприятия.
Часто под СУП понимают пакеты прикладных программ, автоматизирующие функции календарно-ресурсного планирования. Такой взгляд представляется весьма упрощенным, поскольку эти функции далеко не исчерпывают всего многообразия задач управления проектами. По этой причине даже в качестве отдельных инструментальных средств управления проектами часто требуется привлечение программных пакетов смежных областей, таких как управление документами, управление персоналом и т. д.
Говоря об интегрированной системе управления проектами предприятия, мы имеем в виду не только совместное использование инструментальных средств, но и особые формы и технологии управления, позволяющие вписать проектную деятельность в общий контекст деятельности компании.
В каждой компании существуют определенные, иногда значительные, особенности управления проектами. Эти различия в рамках СУП отражаются на уровне формирования конкретных управленческих процедур, маршрутов документов, используемых инструментов и т. д. Сходные принципы построения, концепция интегрированной СУП могут быть сведены к ряду основных вариантов решений, которые составляют основу общей для самых разных предприятий методики проектирования СУП конкретного предприятия.
В этой статье мы основываемся на методике проектирования интегрированной СУП, разработанной автором статьи и его коллегами. В данной методике создание СУП рассматривается как хорошо формализуемый процесс, результатом которого являются решения в нескольких областях:
Таким образом, интегрированная система управления проектами (СУП) рассматривается как организационная и программно-техническая среда, предоставляющая менеджеру инструменты выработки и реализации сбалансированных управленческих решений, охватывающих разные уровни и стадии управления проектом на всех фазах его жизненного цикла, позволяющие обеспечить эффективность управления и координацию выполнения работ по проекту.
Архитектура СУП
Организационная составляющая
Прежде всего необходимо сказать, что СУП не замыкается в рамках только информационных технологий. Более того, опираясь на собственный опыт, мы можем утверждать, что чаще всего первоначальная осознанная потребность в поддержке управления проектами лежит как раз не в области информационных технологий.
Характерным примером в этом смысле являются работы по созданию (внедрению) интегрированных информационных систем для федеральных министерств и крупных компаний.
Создание данных систем неизбежно нарушает сложившийся баланс интересов различных функциональных подразделений. Попытка изменения этого баланса в ту или иную сторону в приказном порядке, как правило, к успеху не приводит, поскольку незаинтересованные стороны имеют достаточно возможностей для сколь угодно долгого затягивания процесса.
В силу этого функция руководства созданием (внедрением) информационной системы не может быть делегирована какому-либо одному подразделению. В принятии решений должны равноправно участвовать все затрагиваемые стороны, а применяемые организационные формы должны обеспечивать сторонам это участие на всех этапах работ и на всех уровнях принятия решений (см. также статью С. В. Питеркина в этом же номере журнала. – Прим. ред.).
Наиболее адекватной формой организации таких работ можно считать применение методов проектного управления. А основным (иногда – единственным) элементом СУП, востребованным в таких проектах, является организационное обеспечение управления проектом.
В общем виде организационная составляющая СУП представляет собой совокупность документов, описывающих органы управления проектами, регламенты взаимодействия участников проекта, процедуры выполнения основных этапов, инструкции управленческого персонала, шаблоны управленческих документов и т. д. Отметим также, что организационные решения могут поддерживаться на уровне информационных технологий (например, средствами технологии workflow).
ИТ-составляющая
Разумеется, реализация крупных проектов невозможна без применения в СУП соответствующих информационных технологий. Базовыми элементами в них выступают пакеты прикладных программ. Наиболее широко представлены пакеты календарно-ресурсного планирования (Microsoft Project, Primavera Project Planner; Open Plan Professional, Spider Project и др.). Однако сам по себе такой пакет позволяет лишь автоматизировать ту или иную функцию управления в проекте (менеджер, администратор, эксперт по рискам и т. д.).
Информационные же технологии, применяемые в СУП, должны поддерживать не только определенные функции управления, но и сквозные процессы управления проектами. А такой подход требует погружения и процессов управления, и поддерживающих их информационных технологий в контекст общих для предприятия так называемых “корпоративных” решений и отношений.
Управление проектами и общие корпоративные решения
Для того чтобы понять роль и место управления проектами в системе отношений внутри предприятия, рассмотрим в качестве примера идеальный процесс формирования команды проекта в компании, организационная структура которой построена по матричному типу.
Напомним, что матричная организационная структура предполагает существование в компании функциональных подразделений (ресурсных по отношению к комплексному проекту, для выполнения которого требуется объединение возможностей разных функций/подразделений), которые предоставляют персонал, необходимый для реализации проектов. Интересы проекта в рассматриваемом процессе представляет менеджер проекта, интересы ресурсного подразделения – его руководитель. Интересы компании в целом представляет спонсор проекта, являющийся, как правило, и топ-менеджером компании. (В данной статье в примере “Процесс формирования команды проекта” используется упрощенный вариант взаимоотношений и действий управленческого персонала компании. – Прим. автора.).
Пример: “Процесс формирования команды проекта”
Этап 1. Менеджер проекта формирует календарный план работ, определяя роли и квалификацию участников проекта, а также их занятость в нем. Эта информация фиксируется в системе календарно-ресурсного планирования. Затем эти сведения передаются в систему управления персоналом предприятия, которая предоставляет менеджеру проекта информацию о доступных ресурсах, удовлетворяющих требованиям проекта.
Этап 2. Менеджер проекта готовит заявку на необходимый ему персонал, которая согласуется руководителями соответствующих ресурсных подразделений. При возникновении конфликта ресурсов проблемы выносятся на уровень спонсора проекта. Возникающая переписка регистрируется на формальном уровне в системе управления документооборотом предприятия. Продвижение документов обеспечивается системой управления бизнес-процессами предприятия (workflow).
Этап 3. После того как ресурсы выделены, руководители ресурсных подразделений вносят соответствующие изменения в статусы выделенных в проект сотрудников, а менеджер проекта формирует задания исполнителям и фиксирует их в системе календарно-ресурсного планирования.
Этот пример показывает, что в контур управления проектом вовлекаются, кроме системы календарно-ресурсного планирования (которая традиционно рассматривается как основа автоматизации управления проектами), еще и целый ряд других информационных систем, эксплуатирующихся на предприятии.
К упомянутым в примере системам можно добавить и другие стандартные пакеты и системы, которые могли бы использоваться при решении тех или иных задач управления проектом – от статистических пакетов до систем финансового планирования и ERP-систем.
Говоря об интеграционном подходе к управлению проектами, мы имеем в виду рассмотрение этой деятельности в более широком контексте – деятельности компании в целом. Это означает, что решение задач в отдельных областях управления проектами должно базироваться на более общих, “корпоративных” решениях.
Когда мы говорим об интегрированной СУП, мы стоим на позиции менеджера проекта, который рассматривает все информационное и инструментальное поле компании с точки зрения проекта. На самом деле правильнее говорить об интегрированной информационной системе предприятия и о СУП как ее составной части. С учетом этого, например, с точки зрения руководства компании, СУП является одним из источников информации, используемой для анализа и принятия решений.
В организационной области интеграционный подход выражается в необходимости формирования управленческих структур, лежащих над штатным расписанием (руководящий комитет, группа управления, рабочая группа), и организационно-распорядительных документов, описывающих сквозные процессы, затрагивающие не только персонал проекта, но и постоянные структурные подразделения предприятия (ресурсные подразделения, финансовую службу, службу логистики, службу безопасности и т. д.).
В ИТ-области интеграционный подход выражается в необходимости создания контура взаимосвязанных продуктов, в котором СУП связывается с другими системами предприятия информационными и пользовательскими интерфейсами (пример такого контура приведен на рис. 2.). А это, в свою очередь, приводит к необходимости установления интерфейсов между базовыми пакетами прикладных программ, использованных для создания связываемых элементов интегрированной системы предприятия.
Рис. 2. Единый контур программных продуктов предприятия
В обеих областях решения чаще всего не являются универсальными и разрабатываются под требования конкретных заказчиков.
Частные продукты в составе СУП
Итак, мы определили СУП как интеграционную технологию. Определение “комплексный” лучше всего характеризует СУП как продукт.
Собственно работы по созданию СУП носят в основном консалтинговый и интеграционный характер.
Однако практика показывает, что, как правило, при создании СУП возникает необходимость в предоставлении заказчику целого комплекса продуктов, включая:
Как самостоятельные (имеющие самостоятельную ценность для будущего владельца) продукты можно рассматривать и целый ряд локальных результатов, достигаемых в процессе создания и внедрения СУП. В данной статье ограничимся упоминанием только двух таких продуктов.
1. Концепция автоматизированной системы управления проектом, в рамках которой определяются:
2. Организационное обеспечение системы управления проектом, включающее описание регламентов взаимодействия участников проекта, процедур управления различными этапами проекта, детальных инструкций по исполнению процедур и шаблонов управленческих документов, а также положений о временных органах проектного управления и соответствующих должностных инструкций.
Схема работ по созданию СУП содержит этапы, традиционные для разработки информационных систем, – обследование, разработку концепции, выбор программных продуктов, работы по интеграции, обучение персонала. Специфика этих работ проявляется главным образом в объекте обследования, используемых моделях и смещении внимания в сторону организационного обеспечения. Работы всех этапов создания СУП могут быть в значительной степени формализованы вплоть до использования стандартизованных бланков анкет, методик формирования моделей и шаблонов документов (это, в частности, является задачей и наполнением упомянутой выше методики проектирования СУП).
Более детальное рассмотрение вопросов, обозначенных в этом разделе, а также вопросов организации эффективного использования и воспроизводства СУП автор считает целесообразным произвести в отдельных статьях.
Автор: Григорий Ципес,
ведущий системный аналитик компании IBS
Источник: Опубликовано в журнале “Директор ИС”, – 12, 2000 год
Интеграции бояться — в аналитики не идти
Совсем недавно рассказывала об этом на AnalystDays’13. Интерес аудитории к моему докладу сподвиг обобщить мои мысли в виде статьи.
Мои советы базируются на собственном опыте и прочитанной литературе. Если ваше мнение отличается или вы знаете новые тренды по теме интеграции, делитесь ими в комментариях. Там же можно задать вопросы.
Что такое интеграционное взаимодействие?
Даже если вы, будучи аналитиком, еще никогда не сталкивались с интеграцией, думаю в скором времени вы с ней познакомитесь. Это одна из самых актуальных задач в нашей сфере, особенно при проектировании IT экосистем.
Под интеграцией мы понимаем единый процесс, который объединяет технологии и системы в последовательную цепочку и в результате преобразует форматы данных между системами.
Почему это сложно?
Попытку склеить в единый процесс то, что нарабатывалось годами, усложняет ряд факторов:
Проектирование каждой новой задачи с точки зрения аналитики не похож на предыдущий. Всегда возникают нюансы. Есть технологические паттерны проектирования, которые приходят на помощь архитекторам и разработчикам, но с точки зрения аналитика таких шаблонов нет.
Иногда старые системы дают вполне хорошие показатели по надежности, но не упрощают интеграцию с точки зрения аналитика.
Данные бывают хаотичными и не всегда есть возможность их формализовать и структурировать. Форматы данных разные, а порой и несовместимые.
Требования могут меняться прямо в процессе работы, особенно если надо интегрироваться с государственными системами (выходят поправки в действующее законодательство, меняются бизнес-процессы), не говоря уже о дизайне и пользовательском интерфейсе, который постоянно необходимо дорабатывать.
Если понимать интеграцию как передачу данных, возникает вопрос безопасности, особенно когда затронуты персональная, финансовая или иная информация, требующая повышенной защиты.
Все это усложняет и без того непростую задачу. В каждом интеграционном кейсе будут свои подводные камни.
Как не наступить на грабли?
Готового шаблона быть не может. От задачи к задаче процесс изменяется. Но можно дать общие рекомендации. Для этого пройдемся по основным этапам разработки интеграционного взаимодействия.
Разработка технического задания
Независимо от того, в каком виде вы получаете задачу на интеграцию, вам в любом случае придется проектировать документацию, будь то ТЗ, ЧТЗ или постановка. В каждой компании название разное, суть одна – необходимо максимально точно описать то, что от вас хотят.
Однажды на проекте в сфере здравоохранения я столкнулась с такой ситуацией.
Кейс 1. А отменить?
Одной из первых моих интеграционных задач был обмен такими сущностями, как направление на оказание медицинской помощи. Мы интегрировались через шину данных, обмениваясь данными по SOAP протоколу. Наша система была источником данных, а получателем была медицинская ИС, разработанная внешним вендором. У нас на руках был согласованный государственным заказчиком пакет документов – ТЗ, ПМИ (программа и методика испытаний). И уже на приемке под конец бизнес-тестирования, когда заветные акты о выполненных работах были близки к подписанию, вдруг возникает вопрос заказчика: ”А давайте попробуем отменить направление?”.
И тут все, мягко говоря, позеленели. Казалось бы, такой необходимый процесс – отмена направления. Но в ТЗ было сказано «Обмен направлениями» без детализации. И об отмене напрочь забыли. Естественно, приемка закончилась не так, как ожидалось.
На что обратить внимание
Чтобы не столкнуться с подобными ситуациями, уже на этапе написания ТЗ необходимо учесть следующие моменты:
Цель. Вы должны четко понимать, в чем основная цель интеграции – какую задачу предстоит решить в конечном итоге. В приведенном кейсе мы неправильно поняли основную цель. Обмен предусмотрели только в одну сторону.
Описание бизнес-процесса. Необходимо максимально детально расписать все возможные сценарии интеграционного бизнес-процесса. На мой взгляд, лучше потратить на это больше времени и избежать любых разночтений в требованиях, чем краснеть на приемке за свое упущение.
Данные, которыми необходимо обмениваться. При проектировании ТЗ нужно четко понимать, что вы передаете, что принимаете, что из этого будет обязательным по спецификации и в каком формате данные будут переданы. Если пропустить обязательный тег или послать пустое значение вместо ожидаемого непустого, успешного взаимодействия реализовать не получится. Придется тратить ресурсы на доработку.
Проектная документация внешней системы. При проектировании взаимодействия необходимо досконально изучить документацию интегрируемой системы. Иногда уже на сдаче проекта выясняется, что неучтенная фраза в документации означает целый бизнес-процесс, который в итоге окажется нереализованным. Понимание внешней системы упростит задачу.
Проектирование взаимодействия
В качестве следующей иллюстрации к моему рассказу вспоминается еще один пример.
Кейс 2. Когда архитектора нет
На одном из моих прошлых проектов переходили от монолита к микросервисам. Задача была непростая, а архитектора у нас не было. Его функции закрывали product owner, тимлид команды и я, как аналитик.
Трудность была в том, что основной бизнес-функционал системы затрагивал сразу несколько подсистем. Чтобы распилить все на микросервисы, сделав каждый из них автономным, нужно было реструктурировать бизнес-функционал, доработать систему хранения данных.
Данные лежали в реляционной БД. Мы начали с доработки схемы хранения. Далее продумывали, как сервисы будут взаимодействовать. На тот момент мы выбрали распределенные очереди сообщений, но не буду вдаваться в технические подробности.
При отсутствии архитектора решить задачу помогли наши обсуждения каждого вопроса, особенно на этапе проектирования и выбора паттернов. Таким образом мы сложили наши знания и опыт, что помогло выбрать правильные подходы.
Проект был условно поделен на 3 этапа по полгода каждый. Сначала внедрили реструктурированную БД, далее частично взаимодействие между сервисами. В конце полностью перенесли основной бизнес-функционал на микросервисную архитектуру. Таким образом проект успешно был реализован, а сам переход от монолита к микросервису занял примерно 1,5 года.
Вначале было трудно. Мы чувствовали себя слепыми котятами, так как не было стопроцентной уверенности, что идем верным путем. Но методом проб и ошибок приходили к логически верному решению. Кроме того, в то время работа была офлайн, часто обращались за советом к соседним командам, много коммуницировали, обсуждали любые появившиеся вопросы.
Надо понимать, что роль системного аналитика в проектировании интеграции весьма важна. Она заключается в детальном описании выбранного паттерна проектирования. Здесь важно учесть формат данных и соблюсти полное его соответствие у системы-источника и системы-получателя данных. Кроме того, необходимо учитывать обязательность передаваемой информации, структуру данных и многое другое.
Обязательные навыки системного аналитика, которые помогут решать задачи интеграции
Необходимость изучить архитектуру проекта тянет за собой много требований. Системный аналитик, на мой взгляд, должен:
понимать, что такое API;
понимать, что такое интеграционная шина данных, как она работает и как она может облегчить задачу интеграции;
понимать, как из одной системы в другую дойдет сообщение, и что при этом произойдет, а значит требуется знать, как работают очереди сообщений (сейчас это один из наиболее популярных способов взаимодействия систем);
понимать, как происходит работа с данными. Тут и реляционные, и нереляционные базы данных.
Да, системному аналитику не обязательно уметь проектировать все это, но необходимо следить за технологиями, понимать, зачем и в каких ситуациях они применяются.
Разработка
И вот у вас на руках готовое ТЗ, выбран паттерн, пришло время реализации.
Разработка интеграции, как и решение любых других задач, требует от команды полного понимания поставленной цели.
Тут напрашивается еще один пример…
Кейс 3. Трудности перевода
Мне дали задачу на разработку отчета, который должен был строится по данным из внешней системы. Там нужно было предусмотреть функционал редактирования данных для определенных ролей. Оговорюсь, что права доступа в системе регламентировались техподдержкой и оформлялись в виде матрицы доступа.
Я приступила к описанию требований и разработке постановки. На мой взгляд все было описано достаточно подробно, с указанием данных, которыми надо заполнять отчет (откуда что получать), в том числе, с указанием ролей, которые могут их редактировать. Однако современные реалии и дистанционный формат работы наложили свои отпечатки. Из-за недостаточной коммуникации с разработчиком, задачу он понял не так. В итоге он захардкодил роли, которые могут редактировать отчет, словно забыв о существовании нашей ролевой модели в системе.
Вот такие бывают трудности перевода.
Роль аналитика на этапе разработки
Задача системного аналитика на этапе разработки – консультирование команды. Как бы обширно и максимально подробно не была расписана постановка, у разработчика обязательно возникнут вопросы. Не прекращается общение и с бизнес-заказчиком. Изменчивый характер требований никто, увы, не отменял.
Тестирование
После разработки пришла пора тестировать. А тестировать интеграцию не менее трудно, чем ее проектировать и разрабатывать. Хочу вспомнить пример на эту тему.
Кейс 4. А ты подготовил тесты?
На банковском проекте необходимо было подготовить интеграционное взаимодействие нашей системы с внешней и по полученным данным сформировать печатную форму, отправив ее по электронной почте. Я подготовила все постановки, согласно требованиям, однако не позаботилась о сценариях тестирования, сочтя задачу довольно простой.
Разработка заняла несколько дней, однако тестирование затянулось почти на месяц! Все потому, что мы заранее не согласовали сценарии тестирования, а заказчик решил проверить функционал на принципиально разных контрагентах. Не буду вдаваться в банковские подробности, скажу только, что от типа контрагента (физическое или юридическое лицо, резидент или не резидент РФ) немного меняется функционал. Отсутствие заранее согласованных тестов, увы, стоило нам сдвинутых сроков, и слегка потрепанных нервов.
Системный аналитик должен хорошо разбираться в проектируемой системе и ее функционале. Поскольку он ориентируется в требованиях заказчика, я все чаще вижу, что аналитиков подключают к этапу проектирования тестовых сценариев.
На что обратить внимание
Приведенный выше пример показывает, что уже на стадии проектирования технического задания будет весьма полезно задуматься и о программе, и о методике испытаний (или проще говоря о сценариях тестирования). В каждой отдельной компании такой документ может называться по-разному.
Трудности с подготовкой тестовых сценариев и тест кейсов обусловлены тем, что работу внешней системы вы явно никак не контролируете. Поэтому при подготовке сценариев вам необходимо предварительно обсудить, как будет проходить тестирование. Например, эмуляция ответов внешней системы, если технически это возможно, или налаживание коммуникации с командой разработки внешней системы.
Заранее подготовленный документ сценариев тестирования – это отличное подспорье, которое может упростить сдачу проекта. Действуйте строго в рамках согласованных сценариев тестирования и ТЗ.
Может показаться, что все мои задачи интеграции в итоге закончились сорванными сроками и полным фиаско. Конечно, это не так. В статье мне хотелось подсветить именно провальные моменты и проиллюстрировать их примерами, чтобы читатель наглядно понимал, на что обратить внимание при работе с интеграцией.
Если же говорить об успешных кейсах, то тут мне есть чем гордится. Я работала над проектированием интеграционной шины данных для региональных проектов здравоохранения, чтобы обеспечивать работу Единой Государственной Системы в сфере здравоохранения (ЕГИСЗ).
Далее уже на проекте банка неоднократно работала над задачами интеграции банковской системы с внешними по получению разного рода атрибутов контрагентов, формированию банковской отчетности, агрегации данных и их дальнейшей передачи во внешнюю систему и т.п.
Вместо заключения еще раз отмечу, что роль системного аналитика в проектировании интеграционного взаимодействия крайне важна. Но для решения этой задачи трудно или даже практически невозможно написать готовый алгоритм. Поэтому в своей статье я постаралась выделить и проиллюстрировать примерами основные важные моменты, на которые нужно обращать внимание, чтобы не попасть впросак.