Интеграция - это не только маппинг данных. 😎

Некоторые руководители считают, а что там сложного в интеграции, описали маппинг данных и всё! Вперёд!

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

Да, можно и нужно разбираться в технологиях. Да, REST API, Кафка, микросервисная архитектура это текущий тренд отрасли и все бегут в эту сторону, услышав модные слова (и то уже сделаны выводы, что не так с микросервисами и не везде они нужны).
К задаче интеграции нужно подходить, как к "слоёному пирогу", и снимать слой за слоем уровней требований.
Отсюда и проблема, что аналитики чего-то не знают, где-то есть пробелы, не видят границы и задачу системно. Ходят с курса на курс, читают книги, смотрят вебинары, но это всё не даёт единую картину мира. Это всё прекрасно и нужно, но стоит собирать знания вместе, чтобы оно заработало.

Например, чтобы соединить две системы между собой, сначала нужно понять на бизнес уровне, что соединяется? Зачем? Какой бизнес-процесс в итоге мы выстраиваем. Да, если мы работаем со справочниками тут нет вопросов, тут действительно маппинг данных и регламенты обмена включаются, и вперёд!
Но если у нас сложная интеграция, то нужно понимать, как будет работать бизнес-уровень, какие объекты предметной области участвуют в процессах, как меняются их статусы при интеграции, как сценарии на пользовательском уровне переходят в функциональный, как наше решение вписывается в системный контекст ИТ-ландшафта компаний. И только пройдя несколько уровней абстракции, мы доходим до данных и технологий обмена этими данными. И тут как раз нам и нужны знания по REST API, SOAP, тут дальше можно назвать другие страшные слова.

Я конечно #капитаночевидность будучи системным аналитиком, подходи к задаче системно и будет тебе счастье) Делай нормально и будет нормально))
Но действительно это работает!

Завтра расскажу о системном подходе к интеграции ☝️

А пока делитесь мыслями, какие у вас подходы при проектирование решений интеграции? Что вам помогает?)

#интеграция #системныйаналитик #системныйанализ #мойопыт #капитаночевидность #выводы #рассуждения

Готовых, чётких, пошаговых инструкций в проектирование интеграционных решений нет.

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

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

Аналитик может цикл за циклом возвращаться к артефактам, и это нормально! Не ждите чистовой версии с первого раза! Ваш перфекционизм нужен только при ловле блох! Получил новую информацию понял, что нужно пойти и что-то изменить, вернулся и изменил. Изменения это нормально. Понял, что слишком большой кусок взял на переваривание, остановился, декомпозировал, разделил и пошёл властвовать с небольшим объёмом. А иногда другая крайность появляется, так много всего, за что хвататься, нужно всё!!! Ааааа!!! Начни с ключевых моментов, в интеграции это сценарии и sequence диаграмма, по этим сценариям. А дальше стройте вокруг них.

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

Я как ментор, тренер создаю реальные условия на курсах, сессиях, от которых бывает участников бомбит "дайте адаптированный вариант!" Но на ваших проектах не будет такой адаптации и вам придётся справляться самим.
Мне же хочется заложить граф связанных инструментов, знаний, навыков, чтобы очертить поле битвы. И подсветить, то чего не хватает аналитику для его работы. Чтобы он в боевых условиях не растерялся и понял, ага, это вот там должно быть, помню, помню этот пазл. Отсюда кстати и уверенность приходит)

Да, я могу показать один из вариантов, а может даже ни один и подходов к решению задачи может быть много. И тут всё зависит от уровня прокачки аналитика. Потому что кому-то не нужны шаблоны, адаптированные задачи и "костыли", а кому-то пока нужно научиться ходить, то есть мыслить))) а потом уже и бегать на скорости! и тут Остапа понесло...

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

#выводы #рассуждения #капитаночевидность #мойопыт #системныйанализ #системныйаналитик #интеграция

Завтра продолжим говорить про то, из чего состоит проектирование интеграционных решений 🤓

Администрирование интеграции

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

Часто и разработка, и аналитик забывают о том, что нужна возможность изменения настроек. И тогда разработчик становится частью своего продукта. Но и аналитик тоже может стать "частью команды, частью корабля". У нас был такой случай, мы узнали, что интеграция работает только в купе с аналитиком, тогда, когда он ушёл в отпуск и всё упало.

Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.

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

Что делать?
✅ Рассматривать тех поддержку, администраторов системы, как полноценных заказчиков. Им поддерживать решение и они должны получать конкретные инструкции. И в интересах команды, всё сделать так, чтобы к ним не бегали по каждому чиху.

✅ Аналитик может просчитать на несколько шагов вперёд, как будет развиваться бизнес. И именно эти точки развития заложить в реализацию.

Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
➡️- тайм зона, бизнес любит расширять свои границы на разные регионы, даже если не сразу говорит, но захватить мир все хотят,

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

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

➡️- настройки связанные с обработкой ошибок, нужно ли включать повторные вызовы, если была ошибка, сколько раз, за какой период,

➡️- уровни логирования данных (может быть встроенная функциональность разных платформ, а может быть своя логика),

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


Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.

⚡️Ну во-первых, можно делать значения по умолчанию, и не трогать ружье, которое висит на стене, но раз в год выстрелит.

⚡️А во вторых, можно сделать нормальные человекочитаемые названия, и внятное описание и согласовать с администраторами и тех поддержкой, и дать инструкцию, продумать использование этих самых настроек.

Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.

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

Запрыгнуть в нашу уютную группу можно оставив заявку на сайте ➡️https://sup.expert/

#интеграция #администрирование #настройки #выводы

Кому нужны эти НФТ? Бред какой-то, это уже немодно.


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

Есть ещё такой момент, что требования это вроде как вотчина аналитика. Но аналитик структурирует, перерабатывает информацию, проектируют решение на языке требований. И вот тебе тут НФТ, писать о железе? О масштабирование, архитектуре? Это что реально моё? И странно и сложно. И тут аналитик становится техническим писателем, опроси всех, собери информацию, зафиксируй. Но эта часть непонятная, а я вроде как за неё должен отвечать, но не знаю! Конечно не хочется браться за эфемерную штуку.

Что делать? 🤓

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

✅Второе, за что реально может отвечать аналитик и что увидеть?
Тут также как в икеа, со стороны пользователя мы можем описать сценарий использования, где наши волшебные требования себя будут проявлять. И указать условия выполнения, ограничения, понятность шагов. Что например, по регламенту 30 минут на согласование документа, проверяем на группе испытуемых, засекаем время, смотрим результат. Что без инструкций новый пользователь сможет освоить функционал за 5 или 10 минут.

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

✅Четвёртое, что я всегда говорю аналитикам, что аналитик это звено, которое задаёт неудобные вопросы и этими неудобными вопросами погружает команду в плоскость принятия решения. Соответственно в части НФТ, даже если непонятно, что там с железом, можно задать вопросы, взять стандарты, ISO, ГОСТ, и опираться на них в части количественных показателей.

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

✅Шестое, законы, правила регулятора. Это разряд #капитаночевидность но все про него забывают. Какие отчёты требует регулятор, что будет вносить в законы в ближайшее время, как среда влияет на наше решение, какой язык, локализация и т. п. Например, развивая платёжную систему в России мы сталкивались не только с законом хранения обезличенных персональных данных, стандартом проведения платежа, но и законами на уровне субъекта нашей необъятной родины. Потому что губернатор на уровне своей губернии мог ввести какой-то свой закон по расчёту и оплаты жкх и взятия комиссии за проведение платежа.
А система честный знак, вводит этапами продажу товаров через них, и мы тоже должны учитывать подобные вещи в своих планах разработки.

А ещё есть очень жёсткий момент, что НФТ стоит брать из реальных показателей. Не описывать сферического коня в вакууме, а приземлить на то, что есть и доступно нам уже сейчас. Нет смысла фиксировать показатели, если мы не знаем, достигнем их или нет, есть такие технологии или нет?

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

Основы работы с требованиями, в том числе и НФТ будем разбирать уже в эти выходные на онлайн игре "Китайская ручка", приходите!)

Регистрация по ссылке ➡️ https://sup.expert/pen