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

Совсем недавно рассказывала об этом на AnalystDays’13. Интерес аудитории к моему докладу сподвиг обобщить мои мысли в виде статьи.

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

Что такое интеграционное взаимодействие? 

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

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

Почему это сложно? 

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

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

• Иногда старые системы дают вполне хорошие показатели по надежности, но не упрощают интеграцию с точки зрения аналитика.

• Данные бывают хаотичными и не всегда есть возможность их формализовать и структурировать. Форматы данных разные, а порой и несовместимые.

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

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

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

Как не наступить на грабли?

Готового шаблона быть не может. От задачи к задаче процесс изменяется. Но можно дать общие рекомендации. Для этого пройдемся по основным этапам разработки интеграционного взаимодействия.

Разработка технического задания

Независимо от того, в каком виде вы получаете задачу на интеграцию, вам в любом случае придется проектировать документацию, будь то ТЗ, ЧТЗ или постановка. В каждой компании название разное, суть одна – необходимо максимально точно описать то, что от вас хотят. 

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

Однажды на проекте в сфере здравоохранения я столкнулась с такой ситуацией...

Кейс 1. А отменить?

Одной из первых моих интеграционных задач был обмен такими сущностями, как направление на оказание медицинской помощи. Мы интегрировались через шину данных, обмениваясь данными по SOAP протоколу. Наша система была источником данных, а получателем была медицинская ИС, разработанная внешним вендором. У нас на руках был согласованный государственным заказчиком пакет документов – ТЗ, ПМИ (программа и методика испытаний). И уже на приемке под конец бизнес-тестирования, когда заветные акты о выполненных работах были близки к подписанию, вдруг возникает вопрос заказчика: ”А давайте попробуем отменить направление?”.

И тут все, мягко говоря, позеленели. Казалось бы, такой необходимый процесс – отмена направления. Но в ТЗ было сказано «Обмен направлениями» без детализации. И об отмене напрочь забыли. Естественно, приемка закончилась не так, как ожидалось.

В целом моделирование данных и проверка функционала по добавлению/чтению/изменению/удалению (или CRUD) - отличный способ избежать подобных ситуаций!

На что обратить внимание

Чтобы не столкнуться с подобными ситуациями, уже на этапе написания ТЗ необходимо учесть следующие моменты:

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

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

• Способ интеграционного взаимодействия. Способов немало, они все широко известны и описаны в профессиональной литературе и интернете. Здесь я не буду их перечислять. Скажу только, что от выбранного способа напрямую зависит тот перечень обязательной информации, без которой поставленную задачу не решить. От себя порекомендую хорошую книжку - Шаблоны интеграции корпоративных приложений Грегора Хопа и Бобби Вулфа. Из нее можно узнать, какие есть паттерны. Книжка ориентирована на архитекторов, но будет полезна не только им и разработке, но и аналитикам.

• Данные, которыми необходимо обмениваться. При проектировании ТЗ нужно четко понимать, что вы передаете, что принимаете, что из этого будет обязательным по спецификации и в каком формате данные будут переданы. Если пропустить обязательный тег или послать пустое значение вместо ожидаемого непустого, успешного взаимодействия реализовать не получится. Придется тратить ресурсы на доработку.

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

Кстати, на этом этапе также рекомендую подумать о плане тестирования - тест-кейсах. Это поможет при приемке.

Проектирование взаимодействия

В качестве следующей иллюстрации к моему рассказу вспоминается еще один пример.

Кейс 2. Когда архитектора нет

На одном из моих прошлых проектов переходили от монолита к микросервисам. Задача была непростая, а архитектора у нас не было. Его функции закрывали product owner, тимлид команды и я, как аналитик.

Трудность была в том, что основной бизнес-функционал системы затрагивал сразу несколько подсистем. Чтобы распилить все на микросервисы, сделав каждый из них автономным, нужно было реструктурировать бизнес-функционал, доработать систему хранения данных. 

Данные лежали в реляционной БД. Мы начали с доработки схемы хранения. Далее продумывали, как сервисы будут взаимодействовать. На тот момент мы выбрали распределенные очереди сообщений, но не буду вдаваться в технические подробности.

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

Проект был условно поделен на 3 этапа по полгода каждый. Сначала внедрили реструктурированную БД, далее частично взаимодействие между сервисами. В конце полностью перенесли основной бизнес-функционал на микросервисную архитектуру. Таким образом проект успешно был реализован, а сам переход от монолита к микросервису занял примерно 1,5 года. 

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

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

Обязательные навыки системного аналитика, которые помогут решать задачи интеграции

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

• понимать, что такое API;

• уметь работать с сервисами - понимать, что куда передать, чтобы решить задачу интеграции,

• понимать, что такое интеграционная шина данных, как она работает и как она может облегчить задачу интеграции;

• понимать, как из одной системы в другую дойдет сообщение, и что при этом произойдет, а значит требуется знать, как работают очереди сообщений (сейчас это один из наиболее популярных способов взаимодействия систем);

• понимать, как происходит работа с данными. Тут и реляционные, и нереляционные базы данных.

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

Разработка

И вот у вас на руках готовое ТЗ, выбран паттерн, пришло время реализации.

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

Тут напрашивается еще один пример… 

Кейс 3. Трудности перевода

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

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

Вот такие бывают трудности перевода.

Роль аналитика на этапе разработки

Задача системного аналитика на этапе разработки – консультирование команды. Как бы обширно и максимально подробно не была расписана постановка, у разработчика обязательно возникнут вопросы. Не прекращается общение и с бизнес-заказчиком. Изменчивый характер требований никто, увы, не отменял.

В текущих условиях, когда все чаще IT живет в удаленном формате, созвоны и чаты в различных мессенджерах - обязательная часть работы аналитика. На практике для меня вопросы разработчиков и регулярное общение с ними приоритетно. Уделить им внимание на этом этапе важнее, чем потом разгребать последствия недопонимания постановки.

Тестирование

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

Кейс 4. А ты подготовил тесты?

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

Разработка заняла несколько дней, однако тестирование затянулось почти на месяц! Все потому, что мы заранее не согласовали сценарии тестирования, а заказчик решил проверить функционал на принципиально разных контрагентах. Не буду вдаваться в банковские подробности, скажу только, что от типа контрагента (физическое или юридическое лицо, резидент или не резидент РФ) немного меняется функционал. Отсутствие заранее согласованных тестов, увы, стоило нам сдвинутых сроков, и слегка потрепанных нервов.

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

На что обратить внимание

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

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

Заранее подготовленный документ сценариев тестирования – это отличное подспорье, которое может упростить сдачу проекта. Действуйте строго в рамках согласованных сценариев тестирования и ТЗ.

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

Если же говорить об успешных кейсах, то тут мне есть чем гордится. Я работала над проектированием интеграционной шины данных для региональных проектов здравоохранения, чтобы обеспечивать работу Единой Государственной Системы в сфере здравоохранения (ЕГИСЗ).

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

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

Автор статьи: Лейла Кадырова, Максилект.

P.S. Мы публикуем наши статьи на нескольких площадках Рунета. Подписывайтесь на наши страницы в VK, FB, Instagram или Telegram-канал, чтобы узнавать обо всех наших публикациях и других новостях компании Maxilect.