С чего начинать проектирование интеграции? А как продолжить и ничего не забыть?
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.
Что самое сложное в интеграции?
Интеграция включает в себя все аспекты и нюансы работы системного аналитика. Чтобы спроектировать интеграционное решение приходится знать и понимать многие дисциплины системной инженерии, плюс хорошо разбираться в технологиях и добавлять, развивать абстрактное мышление, чтобы картину взаимодействия систем уложить у себя в голове. Другими словами - приходится действительно заниматься системным анализом))
Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)
Предлагаю в ближайшие недели обсудить часто возникающие проблемы в работе интеграционного аналитика.
Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)
Серия постов по интеграции будет полезна системным аналитикам с разным опытом работы, которые вдумчиво решают свои рабочие задачи и хотят повысить качество своей работы.
Мы получим с вами выжимку по теме интеграции, которая в том числе, поможет вам понять свои белые пятна и смело добавить новые пункты в план своего развития.
#интеграция #мойопыт #анонс #системныйаналитик #системныйанализ
А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇
Что нужно знать, чтобы написать ТЗ на интеграцию?
Где границы задачи?
Хочется взять новые проекты интеграции, но считаете что вы не готовы?)
Мой путь в айти начался, как раз с интеграции, в далёком 2006 году в телекоме, в команде шинной интеграции продукта IBM WebSphere. Интеграция, как красная линия, проходит через весь мой опыт. Практически ни один из проектов, в которых я участвовала, не проходил без интеграции.
Мне знакомы трудности и "подводные камни" на пути системного аналитика.
Что самое сложное в интеграции?
Интеграция включает в себя все аспекты и нюансы работы системного аналитика. Чтобы спроектировать интеграционное решение приходится знать и понимать многие дисциплины системной инженерии, плюс хорошо разбираться в технологиях и добавлять, развивать абстрактное мышление, чтобы картину взаимодействия систем уложить у себя в голове. Другими словами - приходится действительно заниматься системным анализом))
Что поможет?
- фундамент знаний различных дисциплин
- опыт, тут я как #капитаночевидность
- шаблон ТЗ (с любыми шаблонами работать проще)
- знание, применение инструментов проекторования, основа - это sequence диаграмма (Uml) и сценарная техника (Use Cases), но без диаграммы статусов State Machine (Uml) и диаграмм C4 (DFD+Component) тоже не обойтись
- знание технологий SOAP, REST API
- и такие замечательные слова как безопасность, логирование, мониторинг, квотирование, мастер-данные, гарантированная доставка тоже должны быть понятны, как и шина, и брокер)
Предлагаю в ближайшие недели обсудить часто возникающие проблемы в работе интеграционного аналитика.
Разберём:
1.Из каких шагов состоит проектирование интеграции
2.Что точно стоит изучить, чтобы стало понятнее и легче
3.Как можно классифицировать интеграцию
4.Часто возникающие подводные камни или #смертныегрехи системного аналитика
5.Кейсы из жизни, их у меня накопилось много)
Серия постов по интеграции будет полезна системным аналитикам с разным опытом работы, которые вдумчиво решают свои рабочие задачи и хотят повысить качество своей работы.
Мы получим с вами выжимку по теме интеграции, которая в том числе, поможет вам понять свои белые пятна и смело добавить новые пункты в план своего развития.
#интеграция #мойопыт #анонс #системныйаналитик #системныйанализ
А прямо сейчас задавайте свои вопросы, которые касаются интеграции 👇
Интеграция - это не только маппинг данных. 😎
Некоторые руководители считают, а что там сложного в интеграции, описали маппинг данных и всё! Вперёд!
Проблема интеграции состоит в том, что она затрагивает все аспекты области проектирования информационных систем. И к решению подобной задачи нужно подходить системно.
Да, можно и нужно разбираться в технологиях. Да, REST API, Кафка, микросервисная архитектура это текущий тренд отрасли и все бегут в эту сторону, услышав модные слова (и то уже сделаны выводы, что не так с микросервисами и не везде они нужны).
К задаче интеграции нужно подходить, как к "слоёному пирогу", и снимать слой за слоем уровней требований.
Отсюда и проблема, что аналитики чего-то не знают, где-то есть пробелы, не видят границы и задачу системно. Ходят с курса на курс, читают книги, смотрят вебинары, но это всё не даёт единую картину мира. Это всё прекрасно и нужно, но стоит собирать знания вместе, чтобы оно заработало.
Например, чтобы соединить две системы между собой, сначала нужно понять на бизнес уровне, что соединяется? Зачем? Какой бизнес-процесс в итоге мы выстраиваем. Да, если мы работаем со справочниками тут нет вопросов, тут действительно маппинг данных и регламенты обмена включаются, и вперёд!
Но если у нас сложная интеграция, то нужно понимать, как будет работать бизнес-уровень, какие объекты предметной области участвуют в процессах, как меняются их статусы при интеграции, как сценарии на пользовательском уровне переходят в функциональный, как наше решение вписывается в системный контекст ИТ-ландшафта компаний. И только пройдя несколько уровней абстракции, мы доходим до данных и технологий обмена этими данными. И тут как раз нам и нужны знания по REST API, SOAP,тут дальше можно назвать другие страшные слова.
Я конечно #капитаночевидность будучи системным аналитиком, подходи к задаче системно и будет тебе счастье) Делай нормально и будет нормально))
Но действительно это работает!
Завтра расскажу о системном подходе к интеграции☝️
А пока делитесь мыслями, какие у вас подходы при проектирование решений интеграции? Что вам помогает?)
#интеграция #системныйаналитик #системныйанализ #мойопыт #капитаночевидность #выводы #рассуждения
Некоторые руководители считают, а что там сложного в интеграции, описали маппинг данных и всё! Вперёд!
Проблема интеграции состоит в том, что она затрагивает все аспекты области проектирования информационных систем. И к решению подобной задачи нужно подходить системно.
Да, можно и нужно разбираться в технологиях. Да, REST API, Кафка, микросервисная архитектура это текущий тренд отрасли и все бегут в эту сторону, услышав модные слова (и то уже сделаны выводы, что не так с микросервисами и не везде они нужны).
К задаче интеграции нужно подходить, как к "слоёному пирогу", и снимать слой за слоем уровней требований.
Отсюда и проблема, что аналитики чего-то не знают, где-то есть пробелы, не видят границы и задачу системно. Ходят с курса на курс, читают книги, смотрят вебинары, но это всё не даёт единую картину мира. Это всё прекрасно и нужно, но стоит собирать знания вместе, чтобы оно заработало.
Например, чтобы соединить две системы между собой, сначала нужно понять на бизнес уровне, что соединяется? Зачем? Какой бизнес-процесс в итоге мы выстраиваем. Да, если мы работаем со справочниками тут нет вопросов, тут действительно маппинг данных и регламенты обмена включаются, и вперёд!
Но если у нас сложная интеграция, то нужно понимать, как будет работать бизнес-уровень, какие объекты предметной области участвуют в процессах, как меняются их статусы при интеграции, как сценарии на пользовательском уровне переходят в функциональный, как наше решение вписывается в системный контекст ИТ-ландшафта компаний. И только пройдя несколько уровней абстракции, мы доходим до данных и технологий обмена этими данными. И тут как раз нам и нужны знания по REST API, SOAP,
Я конечно #капитаночевидность будучи системным аналитиком, подходи к задаче системно и будет тебе счастье) Делай нормально и будет нормально))
Но действительно это работает!
Завтра расскажу о системном подходе к интеграции
А пока делитесь мыслями, какие у вас подходы при проектирование решений интеграции? Что вам помогает?)
#интеграция #системныйаналитик #системныйанализ #мойопыт #капитаночевидность #выводы #рассуждения
Please open Telegram to view this post
VIEW IN TELEGRAM
Готовых, чётких, пошаговых инструкций в проектирование интеграционных решений нет.
Все люди, а аналитики тоже люди)) любят готовые решения, как пошагово что-то делать и будет счастье. Что в вебинаре про погружение в предметку (смотрите), что на курсе интеграции я часто слышу разочарование, а какие должны быть шаги, дайте чёткую инструкцию?
Когда я говорю, что да, наш с вами курс или вебинар, выстроен так, что мы идём последовательно, но в ваших проектах не так. Нет инструкций для вашей ситуации, вы сами должны её придумать, сами пройти путь проектирования. Происходит разочарование. При этом иногда очень сложно объяснить, как я пришла к тому или иному решению, потому что путь не линейный.
Аналитик может цикл за циклом возвращаться к артефактам, и это нормально! Не ждите чистовой версии с первого раза! Ваш перфекционизм нужен только при ловле блох! Получил новую информацию понял, что нужно пойти и что-то изменить, вернулся и изменил. Изменения это нормально. Понял, что слишком большой кусок взял на переваривание, остановился, декомпозировал, разделил и пошёл властвовать с небольшим объёмом. А иногда другая крайность появляется, так много всего, за что хвататься, нужно всё!!! Ааааа!!! Начни с ключевых моментов, в интеграции это сценарии и sequence диаграмма, по этим сценариям. А дальше стройте вокруг них.
Горькая правда состоит в том, что подходы к своей работе, к проектированию вы формируете сами. Работа системного аналитика не так проста, как её продают. И самое ценное это наслоение знаний, на фундамент, и всё это работает в системе и в итоге вам выдает хороший результат.
Я как ментор, тренер создаю реальные условия на курсах, сессиях, от которых бывает участников бомбит "дайте адаптированный вариант!" Но на ваших проектах не будет такой адаптации и вам придётся справляться самим.
Мне же хочется заложить граф связанных инструментов, знаний, навыков, чтобы очертить поле битвы. И подсветить, то чего не хватает аналитику для его работы. Чтобы он в боевых условиях не растерялся и понял, ага, это вот там должно быть, помню, помню этот пазл. Отсюда кстати и уверенность приходит)
Да, я могу показать один из вариантов, а может даже ни один и подходов к решению задачи может быть много. И тут всё зависит от уровня прокачки аналитика. Потому что кому-то не нужны шаблоны, адаптированные задачи и "костыли", а кому-то пока нужно научиться ходить, то есть мыслить))) а потом уже и бегать на скорости!и тут Остапа понесло...
Поэтому я и топлю всегда за интерактивные занятия, за менторский подход в долгую, когда чувствуешь группу и сразу можешь менять направление информации или отходить в сторону, чтобы сразу закрыть пробелы по ходу курса. И понимаешь, что есть время и можно успеть разложить всё по плану, потому что этим временем я управляю сама))
#выводы #рассуждения #капитаночевидность #мойопыт #системныйанализ #системныйаналитик #интеграция
Завтра продолжим говорить про то, из чего состоит проектирование интеграционных решений🤓
Все люди, а аналитики тоже люди)) любят готовые решения, как пошагово что-то делать и будет счастье. Что в вебинаре про погружение в предметку (смотрите), что на курсе интеграции я часто слышу разочарование, а какие должны быть шаги, дайте чёткую инструкцию?
Когда я говорю, что да, наш с вами курс или вебинар, выстроен так, что мы идём последовательно, но в ваших проектах не так. Нет инструкций для вашей ситуации, вы сами должны её придумать, сами пройти путь проектирования. Происходит разочарование. При этом иногда очень сложно объяснить, как я пришла к тому или иному решению, потому что путь не линейный.
Аналитик может цикл за циклом возвращаться к артефактам, и это нормально! Не ждите чистовой версии с первого раза! Ваш перфекционизм нужен только при ловле блох! Получил новую информацию понял, что нужно пойти и что-то изменить, вернулся и изменил. Изменения это нормально. Понял, что слишком большой кусок взял на переваривание, остановился, декомпозировал, разделил и пошёл властвовать с небольшим объёмом. А иногда другая крайность появляется, так много всего, за что хвататься, нужно всё!!! Ааааа!!! Начни с ключевых моментов, в интеграции это сценарии и sequence диаграмма, по этим сценариям. А дальше стройте вокруг них.
Горькая правда состоит в том, что подходы к своей работе, к проектированию вы формируете сами. Работа системного аналитика не так проста, как её продают. И самое ценное это наслоение знаний, на фундамент, и всё это работает в системе и в итоге вам выдает хороший результат.
Я как ментор, тренер создаю реальные условия на курсах, сессиях, от которых бывает участников бомбит "дайте адаптированный вариант!" Но на ваших проектах не будет такой адаптации и вам придётся справляться самим.
Мне же хочется заложить граф связанных инструментов, знаний, навыков, чтобы очертить поле битвы. И подсветить, то чего не хватает аналитику для его работы. Чтобы он в боевых условиях не растерялся и понял, ага, это вот там должно быть, помню, помню этот пазл. Отсюда кстати и уверенность приходит)
Да, я могу показать один из вариантов, а может даже ни один и подходов к решению задачи может быть много. И тут всё зависит от уровня прокачки аналитика. Потому что кому-то не нужны шаблоны, адаптированные задачи и "костыли", а кому-то пока нужно научиться ходить, то есть мыслить))) а потом уже и бегать на скорости!
Поэтому я и топлю всегда за интерактивные занятия, за менторский подход в долгую, когда чувствуешь группу и сразу можешь менять направление информации или отходить в сторону, чтобы сразу закрыть пробелы по ходу курса. И понимаешь, что есть время и можно успеть разложить всё по плану, потому что этим временем я управляю сама))
#выводы #рассуждения #капитаночевидность #мойопыт #системныйанализ #системныйаналитик #интеграция
Завтра продолжим говорить про то, из чего состоит проектирование интеграционных решений
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Наталья Косинова. Как разобраться в предметной области: инструкция по применению
Любой специалист сталкивается с проблемой освоения новой для себя предметной областью. Нужно ли быть сильным экспертом в предметке, чтобы работать на новых п...
Как я проектирую интеграцию.
Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно (вспоминаем эффект Бандуры) .
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов (могу и сама на них проверить API, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).
Очень кратко описала процесс, специально опуская детали.
Когда ребята приходят к нам на интеграцию мы проходим по тем шагам, которые помогут действительно спроектировать решение и написать ТЗ. Каждый участник на курс приходит за своим, но то что отмечают многие, это то, что на финише остаётся в голове система, что повышает уверенность в работе, на собеседованиях. А это очень важный момент! Даже каверзные вопросы не ставят в тупик, появляется понимание куда рыть и в какой плоскости лежит решение.
И я действительно как карьерная фея🤩 , понимаю, что уже несколько выпускников наших потоков курса поменяли работу и выросли в грейдах.
Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний📈
Приходите к нам на интеграцию➡️ https://sup.expert/
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):
✅1.Первое с чего я начинаю, я собираю всю информацию. Всё подряд. Собираю спецификации, если есть бизнес требования, бизнес процессы, архитектуру, окружение и изучаю. Не каждому подойдёт такой первый пункт, потому что с большим объёмом информации без структуры сложно. И можно упасть на дно (вспоминаем эффект Бандуры) .
✅2.Дальше, я рисую диаграмму компонентов uml, фактически это третий уровень в C4. Мне важно понимать, кто какие интерфейсы предоставляет, а кто использует и какие технологии у нас есть, как мы передаём данные. Тоже до неё может быть ещё несколько других диаграмм и циклов изучения.
✅3.Изучаю API, если они есть, то замечательно. Я могу визуализировать API в виде диаграммы, я её называю "точки интеграции", пытаюсь понять сервисы API, кто за что отвечает.
✅4.Понимая процесс, сразу рисую sequence диаграмму. Не все могут сходу нарисовать sequence, это нормально. И можно брать дополнительные инструменты, которые шаг за шагом помогут сделать срез информации.
✅5.Описываю диаграмму статусов объектов, которые участвуют в информационном обмене. Опять же тут уже у голове должны быть процессы. И модель предметки.
✅6.Изучаю, как ошибки, описанные в API нужно обработать, как администрировать интеграцию.
✅7.Возвращаюсь к sequence и дорабатываю. На самом деле к sequence я могу возвращаться много раз)) это ключевой артефакт и в него я могу добавить моменты, связанные с работой с мастер-данными, с гарантированной доставкой, параметрами настройки интеграционного слоя. И конечно учитываю, как сценарий влияет на жизненный цикл объекта, какие статусы меняются и какие обновления, синхронизации данных необходимы.
✅8.Перехожу к маппингу данных. Чаще всего я описываю, как заполнять поля сервиса из API, который мы например вызываем, по каким правилам происходит преобразование данных, где берем значения из настроек. Добавляю обязательно примеры реальных данных.
✅9.Если требуется, отдельно описываю алгоритм работы интеграционного модуля (если у нас шинная интеграция, например), в виде обычной активити диаграммы.
✅10.Перехожу к НФТ. Сюда относится безопасность, производительность, масштабирование, администрирование. Если есть числовые данные, указываю, если нет пытаюсь посчитать и согласовать с разработкой.
✅11.Отдельно описываю логирование, мониторинг, квотирование. И могут быть различные специфичные требования от администратора, которому должна быть доступна возможность управлять всем этим богатством, и правильно реагировать на индиценты.
✅12.В дополнение всегда прикладываю спецификацию API, примеры реальных данных, явки и пароли тестовых стендов (могу и сама на них проверить API, иногда спека отличается от реальной жизни и тогда всё будет насмарку)).
Очень кратко описала процесс, специально опуская детали.
Когда ребята приходят к нам на интеграцию мы проходим по тем шагам, которые помогут действительно спроектировать решение и написать ТЗ. Каждый участник на курс приходит за своим, но то что отмечают многие, это то, что на финише остаётся в голове система, что повышает уверенность в работе, на собеседованиях. А это очень важный момент! Даже каверзные вопросы не ставят в тупик, появляется понимание куда рыть и в какой плоскости лежит решение.
И я действительно как карьерная фея
Многие смогли понять свои проблемы и написать план собственного развития и мощно обновили свои базы знаний
Приходите к нам на интеграцию
#системныйаналитик #интеграция #системныйанализ #мойопыт #выводы #анонс
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Наташа Косинова. Варю айти СУП
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
Ошибки проектирования сценариев взаимодействия систем при их интеграции.
Честно, сегодня хотела взять реальную sequence диаграмму с проекта или то, что рисуют ученики и разобрать ошибки. Но понимаю, что очень много на это нужно времени. Но идея мне нравится и вы мне в этом можете помочь и прислать свой вариант, и я его разберу))
А сегодня поговорю о частой ошибке, которую совершают аналитики - это нарезка или проектирование use cases. Тема use cases - сценарной техники сложна и проста одновременно.
Если смотреть канонично на сценарий/use case/прецендет, то что Коберн вкладывал в это понятие это то, как пользователь взаимодействует с системой и какие ожидает реакции системы на свои действия. Чтобы составить набор use cases на пользовательском уровне требований, нужно ответить на следующие вопросы:
✅1.Какие роли есть в системе
✅2.Как эти роли между собой связаны (может быть связь через наследование полномочий)
✅3.Что и какая роль ожидает от системы, то есть зачем я как диспетчер лезу в информационную систему, что я хочу от неё получить? Например, отчёт, его распечатать и отдать механику.
И уже на этом уровне возникает проблема, что не очень понятна бизнес цель и аналитик нарезает сценария применяя CRUD (Create, Read, Update, Delete). И у нас получается сценарии: создать отчет, прочитать отчет, редактировать отчет, удалить отчет. Это тоже хорошо, CRUD нам везде в помощь, но цель генерации отчёта для выпуска водителя на линию звучит совсем по-другому. Не правда ли? Я как диспетчер, хочу внести изменения в отчёт, чтобы зафиксировать сколько нужно бензина. Или отправить автомобиль в ремонт, на тех.обслуживание и т.д.
Почувствовали разницу?
А теперь следующая частая ошибка аналитика, он спускается на системный уровень проектирования интеграции, при этом оставаясь на пользовательском уровне абстракции. Но на системном уровне, бизнес цель пользователя превращается в системную цель.
Отвечаем на вопрос:
Что должна сделать система, чтобы помочь пользователю выполнить бизнес-цель?
И мало того, что выполнить, но и в связке с другой системой, в интеграции. И тогда у нас появляются use cases на системном уровне, вот которые мы уже превращаем в sequence диаграммы.
И для нашего диспетчера, чтобы отправить водителя в рейс система А, должна передать в систему В информацию о водителе и автомобиле и получить согласование от врача, механика. И use cases будет про передачу данных с целью обновления, и подтверждения этого обновления.
И вот мы в итоге получаем совсем другую нарезку сценариев для интеграции.
Действительно инструмент use cases прост, но сложен, когда нужно подключать абстрактное мышление и возвращать себя на уровень требований, на котором мы находимся во время проектирования.
И это всё #капитаннеочевидность и не сразу доходишь до понимая, как, где, зачем и почему нужно применять тот или иной инструмент проектирования. И как сеньорного аналитика отличает не только знания "портфеля инструментов", но и целесообразность их применения в том или ином случае.
#интеграция #системныйаналитик #системныйанализ #мойопыт #рассуждения #выводы
P. S. Моё предложение в силе разобрать вашу sequence диаграмму)
Честно, сегодня хотела взять реальную sequence диаграмму с проекта или то, что рисуют ученики и разобрать ошибки. Но понимаю, что очень много на это нужно времени. Но идея мне нравится и вы мне в этом можете помочь и прислать свой вариант, и я его разберу))
А сегодня поговорю о частой ошибке, которую совершают аналитики - это нарезка или проектирование use cases. Тема use cases - сценарной техники сложна и проста одновременно.
Если смотреть канонично на сценарий/use case/прецендет, то что Коберн вкладывал в это понятие это то, как пользователь взаимодействует с системой и какие ожидает реакции системы на свои действия. Чтобы составить набор use cases на пользовательском уровне требований, нужно ответить на следующие вопросы:
✅1.Какие роли есть в системе
✅2.Как эти роли между собой связаны (может быть связь через наследование полномочий)
✅3.Что и какая роль ожидает от системы, то есть зачем я как диспетчер лезу в информационную систему, что я хочу от неё получить? Например, отчёт, его распечатать и отдать механику.
И уже на этом уровне возникает проблема, что не очень понятна бизнес цель и аналитик нарезает сценария применяя CRUD (Create, Read, Update, Delete). И у нас получается сценарии: создать отчет, прочитать отчет, редактировать отчет, удалить отчет. Это тоже хорошо, CRUD нам везде в помощь, но цель генерации отчёта для выпуска водителя на линию звучит совсем по-другому. Не правда ли? Я как диспетчер, хочу внести изменения в отчёт, чтобы зафиксировать сколько нужно бензина. Или отправить автомобиль в ремонт, на тех.обслуживание и т.д.
Почувствовали разницу?
А теперь следующая частая ошибка аналитика, он спускается на системный уровень проектирования интеграции, при этом оставаясь на пользовательском уровне абстракции. Но на системном уровне, бизнес цель пользователя превращается в системную цель.
Отвечаем на вопрос:
Что должна сделать система, чтобы помочь пользователю выполнить бизнес-цель?
И мало того, что выполнить, но и в связке с другой системой, в интеграции. И тогда у нас появляются use cases на системном уровне, вот которые мы уже превращаем в sequence диаграммы.
И для нашего диспетчера, чтобы отправить водителя в рейс система А, должна передать в систему В информацию о водителе и автомобиле и получить согласование от врача, механика. И use cases будет про передачу данных с целью обновления, и подтверждения этого обновления.
И вот мы в итоге получаем совсем другую нарезку сценариев для интеграции.
Действительно инструмент use cases прост, но сложен, когда нужно подключать абстрактное мышление и возвращать себя на уровень требований, на котором мы находимся во время проектирования.
И это всё #капитаннеочевидность и не сразу доходишь до понимая, как, где, зачем и почему нужно применять тот или иной инструмент проектирования. И как сеньорного аналитика отличает не только знания "портфеля инструментов", но и целесообразность их применения в том или ином случае.
#интеграция #системныйаналитик #системныйанализ #мойопыт #рассуждения #выводы
P. S. Моё предложение в силе разобрать вашу sequence диаграмму)
История Искусств или ТРИЗ?)
Одно из моих хобби - это рисование. У меня в этом направление есть наставник, это Евгения (#нереклама, посмотреть работы). И вот мы на днях вместе ходили в Третьяковку.
Евгения архитектор, и мне нравится её системность и глубина знаний. Вот ты ходишь, смотришь картины. Ну да красиво, сейчас я уже могу оценить то, как детально проработано. Но почему картина шедевр, узнаешь только тогда, когда добавляешь знаний про историю её создания. И вот тут История Искусств для меня становится очень важным примером необходимости подобных знаний. Так и теория решения инженерных задач (ТРИЗ), показывает важные закономерности в создание инженерных изобретений.
И кстати, ТРИЗ помогает аналитику в проектирование интерфейсов.
Проектируя информационную систему, мы увидим результатв лучшем случае виде диаграммы. Но почему так? Часто остаётся открытым вопросом.
Я вижу, как аналитики бегут за знаниями технологий, языков программирования, не задавая вопрос, а что лежит в основе? В чем фундамент? Почему так?
Мы видим результат эволюции и развития инноваций, забывая про то, что опыт пройденного пути нам важен, чтобы решать свои задачи.
Поэтому, да, сложно, да больно, но чтобы спроектировать интеграцию нужно понимать, какой путь нужно пройти, откуда ноги растут тех или иных принятых решений, в чем фундамент? Каков путь? И пройти этот путь по разным уровням требований, начиная с бизнеса, заканчивая технологиями передачи данных можно вместе с нами на курсе интеграции, старт совсем скоро 16 ноября!
#системныйанализ #интеграция #анонс #курсинтеграции #системныйаналитик #курс
Одно из моих хобби - это рисование. У меня в этом направление есть наставник, это Евгения (#нереклама, посмотреть работы). И вот мы на днях вместе ходили в Третьяковку.
Евгения архитектор, и мне нравится её системность и глубина знаний. Вот ты ходишь, смотришь картины. Ну да красиво, сейчас я уже могу оценить то, как детально проработано. Но почему картина шедевр, узнаешь только тогда, когда добавляешь знаний про историю её создания. И вот тут История Искусств для меня становится очень важным примером необходимости подобных знаний. Так и теория решения инженерных задач (ТРИЗ), показывает важные закономерности в создание инженерных изобретений.
И кстати, ТРИЗ помогает аналитику в проектирование интерфейсов.
Проектируя информационную систему, мы увидим результат
Я вижу, как аналитики бегут за знаниями технологий, языков программирования, не задавая вопрос, а что лежит в основе? В чем фундамент? Почему так?
Мы видим результат эволюции и развития инноваций, забывая про то, что опыт пройденного пути нам важен, чтобы решать свои задачи.
Поэтому, да, сложно, да больно, но чтобы спроектировать интеграцию нужно понимать, какой путь нужно пройти, откуда ноги растут тех или иных принятых решений, в чем фундамент? Каков путь? И пройти этот путь по разным уровням требований, начиная с бизнеса, заканчивая технологиями передачи данных можно вместе с нами на курсе интеграции, старт совсем скоро 16 ноября!
#системныйанализ #интеграция #анонс #курсинтеграции #системныйаналитик #курс
Через 2 недели стартует, последний в этом году, поток интеграции.
Вас ждёт аналитический марафон в 2 месяца! ✅
-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
Блок 2 - use cases, онтологическая модель предметной области, state machine
Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
Блок 4 - словарь данных, маппинг данных, администрирование, activity
Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
Блок 5 - введение в OSI модель сети, REST API, json
Блок 6 - SOAP, xml
Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
Блок 8 - Паттерны интеграции, шина, брокер
-------------------------------
Кому подойдёт курс?
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно пройти курс, понять, что входит в интеграцию, увидеть путь рассуждений, которые приводят к результату. Вы приобретёте навыки и уверенность, что позволит брать в работу новые задачи.
Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков, посмотрите со стороны на свою работу, артефакты анализа. Будете понимать на что обращать внимание в качестве наставника.
Формат курса - онлайн занятия, приближенные к классической схеме обучения,
✅в четверг лекция (утром по Москве с 9 до 11),
✅во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).
Наш формат похож на формат групповых менторских сессий, где ведущие общаются с группой и сразу, по ходу, могут обсуждать возникающие вопросы. Мы подстраиваемся под уровень знаний участников и стараемся давать новый блок информации так, чтобы он ложился на текущий фундамент. Мы не являемся огромной школой или площадкой, что позволяет нам создавать уютное, открытое общение и делиться опытом между собой.
Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!
Мы предлагаем разные тарифы обучения:
Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.
Если вы хотите разрабатывать учебный проект и выполнять домашние задания по проектированию, для вас подходит тариф "плюс практика", с разбором домашних заданий.
Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!
Имея чёткое расписание, просто приходя на занятия, вы точно сможете почерпнуть для себя полезные знания.
Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, с точки зрения разработчика и архитектора раскрывает тему технологий, архитектуры решений и интеграции с помощью брокеров сообщений. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
Чтобы записаться на курс оставьте свою заявку на нашем сайте➡️ https://sup.expert/
Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу🔽
До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт
Вас ждёт аналитический марафон в 2 месяца! ✅
-------------------------------
Курс интеграции состоит из 8 блоков и разделён на два этапа:
Первый 🎯 - это проектирование интеграционного решения от концепции до уровня данных (блоки с 1 по 4).
Блок 1 - отвечаем на вопрос, что такое интеграция, строим С4
Блок 2 - use cases, онтологическая модель предметной области, state machine
Блок 3 - sequence, мастер данные, гарантированная доставка, обработка ошибок, валидация данных
Блок 4 - словарь данных, маппинг данных, администрирование, activity
Второй 🎯 - разбор технологий передачи данных, паттернов интеграции, шина и брокеры (блоки с 5 по 8).
Блок 5 - введение в OSI модель сети, REST API, json
Блок 6 - SOAP, xml
Блок 7 - graphQL, gRPC, логирование, мониторинг, квотирование, безопасность
Блок 8 - Паттерны интеграции, шина, брокер
-------------------------------
Кому подойдёт курс?
Если вы начинающий аналитик с опытом от 1 до 3 лет, вам точно будет полезно пройти курс, понять, что входит в интеграцию, увидеть путь рассуждений, которые приводят к результату. Вы приобретёте навыки и уверенность, что позволит брать в работу новые задачи.
Если вы аналитик с опытом от 3 до 5 лет, курс поможет систематизировать знания понять свои пробелы, увидеть эволюцию проектирования, что в конечном итоге позволит вам выйти на новый уровень, составить план развития, а может и сменить работу (такие прецеденты у нас уже есть))).
Если вы ведущий аналитик или тим лид анализа, вы сможете понять, каким путем стоит идти вместе с командой, чтобы повысить качество результата работы аналитиков, посмотрите со стороны на свою работу, артефакты анализа. Будете понимать на что обращать внимание в качестве наставника.
Формат курса - онлайн занятия, приближенные к классической схеме обучения,
✅в четверг лекция (утром по Москве с 9 до 11),
✅во вторник семинар - разбор домашних заданий (утром по Москве с 9 до 11).
Наш формат похож на формат групповых менторских сессий, где ведущие общаются с группой и сразу, по ходу, могут обсуждать возникающие вопросы. Мы подстраиваемся под уровень знаний участников и стараемся давать новый блок информации так, чтобы он ложился на текущий фундамент. Мы не являемся огромной школой или площадкой, что позволяет нам создавать уютное, открытое общение и делиться опытом между собой.
Сколько сможете унести знаний зависит только от вас))
Многие ребята пересматривают записи занятий и узнают снова и снова что-то новое.
➡️ Презентации
➡️ Материал
➡️ Видео записи занятий остаются у вас навсегда!
Мы предлагаем разные тарифы обучения:
Можно прийти на тариф "только послушать", участвовать в онлайн формате в обсуждениях, интерактивных практиках.
Если вы хотите разрабатывать учебный проект и выполнять домашние задания по проектированию, для вас подходит тариф "плюс практика", с разбором домашних заданий.
Мы специально проводим занятия в утреннее время в будние, чтобы вы со свежей головой смогли разобраться в сложной системной информации. Учиться и работать одновременно это действительно сложно, поэтому мы стараемся создать условия, чтобы вы успешно прошли весь аналитический марафон вместе с нами)) Каждый новый поток для нас, как новый вызов!
Имея чёткое расписание, просто приходя на занятия, вы точно сможете почерпнуть для себя полезные знания.
Ведущие:
Основные лекции по проектированию провожу я, Косинова Наталья, мой опыт интеграции более 15 лет, восновном шинная интеграция проектов Билайн, Тинькофф, А3, МТС, Госсектор, Утконос и другие.
Мне помогает
Андрей Корниенко, с точки зрения разработчика и архитектора раскрывает тему технологий, архитектуры решений и интеграции с помощью брокеров сообщений. Именно взгляда разработчика часто не хватает аналитику, когда речь идёт о реализации решения.
Чтобы записаться на курс оставьте свою заявку на нашем сайте
Если у вас остались вопросы, пишите в комментариях, я обязательно отвечу
До встречи на занятиях!
#анонс #курсинтеграции #интеграция #системныйаналитик #системныйанализ #мойопыт
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Администрирование интеграции
Не совсем #капитаночевидность что интеграцией нужно управлять и после выкатки на продуктив, она становится узким горлышком.
Часто и разработка, и аналитик забывают о том, что нужна возможность изменения настроек. И тогда разработчик становится частью своего продукта. Но и аналитик тоже может стать "частью команды, частью корабля". У нас был такой случай, мы узнали, что интеграция работает только в купе с аналитиком, тогда, когда он ушёл в отпуск и всё упало.
Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.
Тех поддержка в таких случаях разводит руками. Потому что им не сделали инструменты управления. Не сделали, вот мы и не можем передать целые куски в поддержку.
Что делать?
✅ Рассматривать тех поддержку, администраторов системы, как полноценных заказчиков. Им поддерживать решение и они должны получать конкретные инструкции. И в интересах команды, всё сделать так, чтобы к ним не бегали по каждому чиху.
✅ Аналитик может просчитать на несколько шагов вперёд, как будет развиваться бизнес. И именно эти точки развития заложить в реализацию.
Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
➡️ - тайм зона, бизнес любит расширять свои границы на разные регионы, даже если не сразу говорит, но захватить мир все хотят,
➡️ - включение, отключение целых блоков бизнес-процессов, есть такие моменты, что вот мы сомневаемся, сегодня надо, а завтра нет, лучше добавить и сделать возможность отключения по настройкам,
➡️ - разные форматы данных, например, что-то нужно настроить по умолчанию, или правила валидации, регулярные выражения, шаблоны вывода и т.п.
➡️ - настройки связанные с обработкой ошибок, нужно ли включать повторные вызовы, если была ошибка, сколько раз, за какой период,
➡️ - уровни логирования данных (может быть встроенная функциональность разных платформ, а может быть своя логика),
➡️ - квотирование, есть платные сервисы и каждый их вызов это деньги, а если вы ещё делаете механизм повторных отправок, можно попасть на бабло, так что лучше сразу задуматься как этим управлять и, например, переключать функционал с платного на бесплатный, некоторые государственные сервисы не очень любят, когда их бомбят запросами и тоже могут ввести квоту на количество обращений в день.
Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.
⚡️ Ну во-первых, можно делать значения по умолчанию, и не трогать ружье, которое висит на стене, но раз в год выстрелит.
⚡️ А во вторых, можно сделать нормальные человекочитаемые названия, и внятное описание и согласовать с администраторами и тех поддержкой, и дать инструкцию, продумать использование этих самых настроек.
Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.
В интеграции много подобных не очевидных нюансов, если хочется глубже в них разбираться приходи на наш курс интеграции, совсем скоро старт потока (16 ноября), и что-то мне подсказывает, что с нового года будет повышение цены.
Запрыгнуть в нашу уютную группу можно оставив заявку на сайте➡️ https://sup.expert/
#интеграция #администрирование #настройки #выводы
Не совсем #капитаночевидность что интеграцией нужно управлять и после выкатки на продуктив, она становится узким горлышком.
Часто и разработка, и аналитик забывают о том, что нужна возможность изменения настроек. И тогда разработчик становится частью своего продукта. Но и аналитик тоже может стать "частью команды, частью корабля". У нас был такой случай, мы узнали, что интеграция работает только в купе с аналитиком, тогда, когда он ушёл в отпуск и всё упало.
Так что принцип "сделать так, чтобы ко мне мало прибегали с вопросами" очень мотивирует.
Тех поддержка в таких случаях разводит руками. Потому что им не сделали инструменты управления. Не сделали, вот мы и не можем передать целые куски в поддержку.
Что делать?
✅ Рассматривать тех поддержку, администраторов системы, как полноценных заказчиков. Им поддерживать решение и они должны получать конкретные инструкции. И в интересах команды, всё сделать так, чтобы к ним не бегали по каждому чиху.
✅ Аналитик может просчитать на несколько шагов вперёд, как будет развиваться бизнес. И именно эти точки развития заложить в реализацию.
Какие могут быть параметры настроек?
Например, типичные и часто встречающиеся:
Как-то мне аналитик, сказал, вот ты топишь за настройки, а у нас их было так много, что мы запутались.
Конечно, я могла что-то забыть, и полно все детали в пост не впихнуть, но с думаю мой посыл понятен.
В интеграции много подобных не очевидных нюансов, если хочется глубже в них разбираться приходи на наш курс интеграции, совсем скоро старт потока (16 ноября), и что-то мне подсказывает, что с нового года будет повышение цены.
Запрыгнуть в нашу уютную группу можно оставив заявку на сайте
#интеграция #администрирование #настройки #выводы
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
Квотирование в интеграции, что это такое и зачем нужно?
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Реальные результаты наших участников курса интеграции.
В большинстве своём на курс приходят ребята, кто был у меня на менторстве, оно и понятно, но и не только! У каждого свои цели. И вот немного классифицирую, по грейдам, кто что уносит и использует на практике:
1.Начну с джунов или тех кто хочет стать системным аналитиком. Очень сложно бывает показать, что именно нужно специалисту для прокачки. Курс интеграции, как курс молодого бойца показывает систему знаний, инструментов, подходов и практик. Что хорошо, мы полностью проходим по пирамиде артефактов и доходим до уровня технологий, данных. Я не хочу давать обещания, которые считаю нереальными. Но то, что джун поймёт, куда ему дальше и что такое системный анализ это точно.
2.По результатам курса можно написать свой собственный план развития, и взять за основу те ссылки, те внешние источники, книги которые мы рекомендуем, и на которые опираемся.
3.Миддл аналитики обретают уверенность! Это очень важно. Они могут чего-то не знать, но понимать объем, границы задачи и чувствовать себя увереннее. Понимают, куда смотреть, что делать.
4.Как так уже давно получилось, что я стала для многих "карьерной феей"))) Ребята после работы со мной идут дальше, есть даже те кто вырос в айти директора, кто-то в архитектора, тим лида. И вот по результатам наших даже двух потоков курса, много кто сменил работу! Пошёл выше по грейдам, прибавил в деньгах. Как говорит Андрей Корниенко, у аналитиков открылись глаза и поняли, что именно они должны делать, отсюда уверенность, энергия перемен и попытка дальше себя развивать, для этого меняют среду. Мы ничего специально не делаем, так получается))) А то компании, чего неладное подумают))
5.Многие отмечали такой факт, что стали увереннее на собеседованиях и смогли ответить на каверзные вопросы. Или честно сказать, что они и в каком объёме могут сделать.
Так что не хочу обещать вам успешный успех, скажу лишь только одно - вы сможете унести столько сколько можете на текущий момент. Есть у нас такие прецеденты, когда участник курса пересмотрел его заново в записи, и вынес новое, чего за первый заход в упор не понимал. Это было любопытно и радостно))
Видео запись и материалы остаются навсегда, как и возможность общения со мной и моим компаньоном. Андрей Корниенко помогает мне на курсе в части технологий, взглядом разработчика и архитектора, что очень важно в работе аналитика.
Приглашаю вас присоединиться к группе, старт уже завтра! В новый год вы вступите с новыми знаниями))
#системныйанализ #курс #курсинтеграции #анонс #результатыучастников #интеграция
Остались вопросы, пишите мне‼️
В большинстве своём на курс приходят ребята, кто был у меня на менторстве, оно и понятно, но и не только! У каждого свои цели. И вот немного классифицирую, по грейдам, кто что уносит и использует на практике:
1.Начну с джунов или тех кто хочет стать системным аналитиком. Очень сложно бывает показать, что именно нужно специалисту для прокачки. Курс интеграции, как курс молодого бойца показывает систему знаний, инструментов, подходов и практик. Что хорошо, мы полностью проходим по пирамиде артефактов и доходим до уровня технологий, данных. Я не хочу давать обещания, которые считаю нереальными. Но то, что джун поймёт, куда ему дальше и что такое системный анализ это точно.
2.По результатам курса можно написать свой собственный план развития, и взять за основу те ссылки, те внешние источники, книги которые мы рекомендуем, и на которые опираемся.
3.Миддл аналитики обретают уверенность! Это очень важно. Они могут чего-то не знать, но понимать объем, границы задачи и чувствовать себя увереннее. Понимают, куда смотреть, что делать.
4.Как так уже давно получилось, что я стала для многих "карьерной феей"))) Ребята после работы со мной идут дальше, есть даже те кто вырос в айти директора, кто-то в архитектора, тим лида. И вот по результатам наших даже двух потоков курса, много кто сменил работу! Пошёл выше по грейдам, прибавил в деньгах. Как говорит Андрей Корниенко, у аналитиков открылись глаза и поняли, что именно они должны делать, отсюда уверенность, энергия перемен и попытка дальше себя развивать, для этого меняют среду. Мы ничего специально не делаем, так получается))) А то компании, чего неладное подумают))
5.Многие отмечали такой факт, что стали увереннее на собеседованиях и смогли ответить на каверзные вопросы. Или честно сказать, что они и в каком объёме могут сделать.
Так что не хочу обещать вам успешный успех, скажу лишь только одно - вы сможете унести столько сколько можете на текущий момент. Есть у нас такие прецеденты, когда участник курса пересмотрел его заново в записи, и вынес новое, чего за первый заход в упор не понимал. Это было любопытно и радостно))
Видео запись и материалы остаются навсегда, как и возможность общения со мной и моим компаньоном. Андрей Корниенко помогает мне на курсе в части технологий, взглядом разработчика и архитектора, что очень важно в работе аналитика.
Приглашаю вас присоединиться к группе, старт уже завтра! В новый год вы вступите с новыми знаниями))
#системныйанализ #курс #курсинтеграции #анонс #результатыучастников #интеграция
Остались вопросы, пишите мне
Please open Telegram to view this post
VIEW IN TELEGRAM
Концептуальное проектирование
Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.
Первая это Концептуальное проектирование(сюда же DFD отнесу), а второе - это блок-схемы, с помощью которых можно и алгоритм описать и процесс, и сделать это хорошо!
Сегодня решила написать про Концептуальное проектирование.
Что может быть проще - в центр поместить систему, которую мы проектируем, вокруг участников информационного обмена, и стрелками показать направление потоков данных, кто, кому, что передаёт.
Но, в чем трудность?
✅1.Заставить себя мыслить в структуре и разложить по схеме - участники, данные уже не те просто. Скучно, дайте нам сразу строить космический корабль. Чтобы выделить набор данных нужно хорошо понимать, а что мы собственно делаем и промоделировать процессы.
✅2.Если возьмём DFD - да, есть разные нотации, но суть одна и та же, к наших участникам, и данным, добавляется хранение данных. Откуда и куда уходят данные и где остаются.
DFD, концептуальное проектирование заставляет нас думать структурой. И отбрасывать то, что круче, интереснее, можно помоделировать)))
По сути мы наш концепт раскладываем по следующим пунктам:
1.Источник данных
2.Потребитель данных
3.Обработка, работа, логические функции над данными
4.Потоки данных
5.Хранилища данных
И нам неважно, как будет реализована наша концепция, на начальном этапе. Какие технологии передачи данных будут выбраны. Требования ещё не собрали и до структуры хранилищ не добрались, как и до самого кода.
К DFD мы можем подходить, как в слоёному пирогу, как и с ER диаграммами, по этапам:
1.Описать концепцию - участники и потоки данных
2.Добавить логику обработки - получим логический уровень
3.Добавить хранение данных - физический уровень
Но если вы сделаете хотя бы концепцию решения уже станет лучше))) и будут видны участники, системный контекст, границы решения.
Мне нравится статья по этой теме в школе системного анализа и проектирования.
Рекомендую к применению на проектах)
#интеграция #концепция #dfd #системныйаналитик #системныйанализ #системныйконтекст
Есть две вещи, которые простые, очевидные #капитаночевидность поэтому их мало кто делает.
Первая это Концептуальное проектирование
Сегодня решила написать про Концептуальное проектирование.
Что может быть проще - в центр поместить систему, которую мы проектируем, вокруг участников информационного обмена, и стрелками показать направление потоков данных, кто, кому, что передаёт.
Но, в чем трудность?
✅1.Заставить себя мыслить в структуре и разложить по схеме - участники, данные уже не те просто. Скучно, дайте нам сразу строить космический корабль. Чтобы выделить набор данных нужно хорошо понимать, а что мы собственно делаем и промоделировать процессы.
✅2.Если возьмём DFD - да, есть разные нотации, но суть одна и та же, к наших участникам, и данным, добавляется хранение данных. Откуда и куда уходят данные и где остаются.
DFD, концептуальное проектирование заставляет нас думать структурой. И отбрасывать то, что круче, интереснее, можно помоделировать)))
По сути мы наш концепт раскладываем по следующим пунктам:
1.Источник данных
2.Потребитель данных
3.Обработка, работа, логические функции над данными
4.Потоки данных
5.Хранилища данных
И нам неважно, как будет реализована наша концепция, на начальном этапе. Какие технологии передачи данных будут выбраны. Требования ещё не собрали и до структуры хранилищ не добрались, как и до самого кода.
К DFD мы можем подходить, как в слоёному пирогу, как и с ER диаграммами, по этапам:
1.Описать концепцию - участники и потоки данных
2.Добавить логику обработки - получим логический уровень
3.Добавить хранение данных - физический уровень
Но если вы сделаете хотя бы концепцию решения уже станет лучше))) и будут видны участники, системный контекст, границы решения.
Мне нравится статья по этой теме в школе системного анализа и проектирования.
Рекомендую к применению на проектах)
#интеграция #концепция #dfd #системныйаналитик #системныйанализ #системныйконтекст
Записала разбор sequence диаграммы.
Примем тот факт, что автор, никогда не делала раньше sequence диаграмм.
Будет полезно для начинающих и не только. Вдруг ещё что-то заметите, что бы можно было улучшить?)
#sequence #uml #системныйанализ #системныйаналитик #интеграция #разбор
https://youtu.be/JiJDt-jWFtY
Примем тот факт, что автор, никогда не делала раньше sequence диаграмм.
Будет полезно для начинающих и не только. Вдруг ещё что-то заметите, что бы можно было улучшить?)
#sequence #uml #системныйанализ #системныйаналитик #интеграция #разбор
https://youtu.be/JiJDt-jWFtY
YouTube
Разбор диаграммы последовательностей (sequence, UML) с проекта
Разбираю ошибки примера диаграммы последовательности (sequence, UML). Диаграмму предоставила подписчица.
Хотите больше узнать про системный анализ и работу аналитиков в айти? Подписывайтесь на мой телеграм канал - https://t.me/start_in_IT
Хотите, чтобы…
Хотите больше узнать про системный анализ и работу аналитиков в айти? Подписывайтесь на мой телеграм канал - https://t.me/start_in_IT
Хотите, чтобы…
Сначала вы работаете на интеграцию, потом интеграция работает на вас.
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
♟ Поискать инсайты и новую информацию, чего возможно я, как тренер, ментор, упускаю в системном подходе к проектированию интеграции. И довыявить точки расширения roadmap.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Забавно, то, что моя карьера системного аналитика в 2006 году началась с интеграции, и кто бы мог подумать, что я буду учить проектированию интеграций) И интеграции никуда не исчезает за эти годы!
Уже много мной накоплено опыта, и кажется, что про интеграцию сказано всё!
Но так ли оно?
----------------
Поэтому на ближайшие две недели, в рамках своего блога, я объявляю себе челлендж по мини-интеграции, чтобы:
♟Получить чёткий roadmap, как действовать, когда прилетела задача на интеграцию и нужно сесть и написать ТЗ.
----------------
Не знаю, к чему меня приведёт этот челлендж, но мне интересно, снова систематизировать подходы к проектированию.
Некоторые наши ученики-аналитики говорят, что мы с Андреем Корниенко учим не просто интеграции, а системному анализу через интеграцию.
И нам хочется создать новый продукт, который был бы доступен всем и имел сжатый формат, который бы отвечал аналитику на комплекс его основных вопросов.
----------------
У каждого аналитика могут быть свои цели, например (как их вижу я):
Junior - хочет получить волшебную таблетку, чтобы дали готовые шаблоны, чек-листы, roadmap, чтобы увереннее действовать и решать поставленные задачи.
Middle - хочет расширить свои знания, навыки и опыт, чтобы брать в работу сложные задачи, с запутанной логикой.
Senior - хочет систематизировать свои знания и понять, что не видно, о чем забыл и на что стоит обратить внимание, чтобы повысить свою компетенцию.
Team Lead - хочет грамотно делегировать задачи их декомпозировать, отдавать команде и получать сисиемный хороший результат.
----------------
Вы можете мне дописать свои цели ниже в комментариях, которые вы ждёте от интеграции, и в какую область мне ещё посмотреть.
Ух, ну что ж! Погнали! 🚀
#интеграция #челлендж #проектирование #боли #миниинтеграция
Please open Telegram to view this post
VIEW IN TELEGRAM
Моё лицо выглядит примерно вот так, когда мне говорят - нам нужно ТЗ на интеграцию!
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Блин это долго, тяжело, и хочется закричать - не хочу!! Не надо!
А всё потому что на старте, у нас высокая неопределённость. А аналитик думает категорией - "завтра в бой, так, мне нужно sequence, rest api, безопасность, нфт... Блин ещё swagger руками потрогать... А вдруг я что-то забуду?" 🤯
А ещё лучше, когда что-то прилетает, из серии - "я это не знаю"!
И вот я уже вижу, как потихоньку, легко, но верно, я начинаю падать в грязь лицом...
А ещё сверху приправим соусом "ты же специалист, тебе виднее, мы знаем, что ты можешь... ждём ТЗ..."
Вот в такой ситуации, я могу говорить, ребята, возьмите С4, или Uml и ещё 100500 разных подходов. Но лучше выдохнуть, сделать шаг назад, и начать с любой схемы! Нет вы не ослышались, любая диаграмма, картинка, визуализация подойдёт. Упрощайте!
Не нужно мучить себя нотациями, правилами, инструментами, вам нужно понять, а что собственно происходит?
Нарисуйте всё что знаете по задаче, даже если это будут 2 квадратика и стрелочка между ними со словом интеграция.
На днях на менторской сессии, я открыла диаграмму с одного своего проекта, и поняла, что это смесь DFD, Component и даже Deployment diagram. А цель моя была понять объем задачи, получилось? Да! Все красные стрелочки - это объем.
Я часто рассказываю, что когда мне присылают описание API, я просто схематично рисую диаграмму и называю "точки интеграции", визуализирую вызовы, их набор, направление, логику, последовательность.
А самое сокровенное, что я хочу сказать, прикиньте эту диаграмму можно никому не показывать)))
Так что, получая новую задачу по интеграции:
✅Не требуйте от себя быстрого крутого, финального результата
✅Рисуйте визуализацию задачи
✅Начинайте с концептуального или бизнес-уровня
✅Если вы перечислите, хотя бы участников и красными стрелочками покажите, то что нужно разработать, это уже круто!
✅Просто начните, вы уже можете объяснить себе, о чем идёт речь?)
#капитаночевидность
#интеграция #челлендж #мойопыт
Как оценить задачу?
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Можно смотреть на формулы, уходить в глубину и сложность задачи. Но когда это всё недоступно, или нет опыта, а ответ нужен здесь и сейчас. Просто делаю задачу-шаблон, считаю время и получается некий эталон, на который можно уже накинуть погрешность в несколько дней и дать оценку.
Когда-то так и произошло.
Типичный бизнес любит находу принять решение и щёлкнуть пальцами. Хочу!! Вчера!!
И вот прибегает ко мне чайка менеджер и говорит - срочно нужна интеграция с регионом! Задача первого, высшего, максимального приоритета! Ааааа! Сколько, сколько, сколько? Тебе нужно времени?
Когда меня спрашивают сколько нужно на разработку большой системы с нуля, я всегда говорю полгода. Руководство конечно возмущается, много! Скашивает до 3 месяцев, а в результате полгода...
Но тут была другая история.
Сразу скажу про исходные данные:
✅ Я хорошо знала бизнес.
✅ Я глубоко понимала как работает сфера.
✅ У меня уже был опыт подобных интеграций.
Я сказала месяц.
Отдать должное менеджеру, он сказал времени нет, ТЗ нужно срочно. И что можно сделать для ускорения? Ай зараза....
Я перечислила:
👉получить актуальное описание,
👉тестовый стенд,
👉тестовые данные,
👉контактное лицо, кто ответит на все мои вопросы,
👉понять кто принимает решение на доработку с их стороны, чтобы не тормозили.
И мы решили, что поедем в командировку к нашему партнёру. Нам нужно реализовать использование SOAP API у себя, и понять, все ли данные нужные нам есть, а что должен разработать компаньон.
И вот мы сели в поезд. В гостинице я распечатала описание, вечерком выделила фломастером, всё что мне было непонятно, написала список вопросов. И даже какие-то первые черновые варианты интеграции прикинула.
На следующий день у нас произошла встреча с командой партнёра, я смогла оперативно задать все вопросы, соединить наших разработчиков и разработчиков партнёра. Айти директор компании партнёра посмотрел на нас, обсудили договор, пришли к согласию. Переговоры сначала шли тяжело, но потом пошли в сторону поиска точек соприкосновения. И в итоге мы чётко зафиксировали, что делаем мы, что они и что нам нужно. Я написала отчёт о встрече! Не принебрегайте им!
Все довольны, мы устали часов 6 переговоров... Временами жёстких...
И вот мы уже вечером сидим в поезде обратно в Москву, и молчим...
По приезду, я запираюсь в комнате, ни с кем не общаюсь и с утра до вечера пишу ТЗ.
Забег с командировкой и написанием низкогоуровневого ТЗ с объёмом на 5-6 интеграционных сценариев у меня занял 4 дня.
4 дня это эталон надрывной работы над задачей.
Больше мне не хотелось такого надрыва, да и не всегда партнёр действительно может оперативно принять решения.
После этой истории, на вопрос, сколько тебе нужно времени на ТЗ по интеграции я всегда говорила - месяц!)))
#челлендж #интеграция #оценкаинтеграции #мойопыт
Сценарии в интеграции
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
Таааак сейчас будет сложно, а что вы думали?) Работать аналитиком и не ныть? Как бы не так, этот путь для смелых и ироничных)
Когда мы говорим про проектирование интеграции, то хочется сразу начать смотреть вглубь и побежать изучать код, уровень данных, технологий и конечно думать про то, как спроектировать API.
Но пока рано пить шампанское, давайте разберёмся с тем, а зачем нам это всё?
Ключевой артефакт интеграции это use case, представленный в виде sequence диаграммы (сценариев может быть несколько), где наглядно видно, кто кому какие данные передал и в какой момент.
Так вот, когда мы говорим про сценарий, тут ломается многое. Потому что кажется, что это очень простой инструмент. Сценарий у фильма есть, или мини ролика в ютюге. А тут то, как два пальца... И будет сделано.
Но! Мы говорим про системный уровень, когда спускаемся на уровень данных, ошибок, вызовов и технологий. Мы описываем фактически реализацию, и делать сразу такой огромный шаг - это фактически сразу увеличивать сложность задачи, падать в неизвестность и соответственно понижать качество требований.
Поэтому стоит поднять уровень требований выше (см. Пирамида артефактов).
И лучше на уровень пользовательских требований.
Вы меня спросите, какой нафиг пользователь в интеграции? Во-первых, мы смотрим на классификацию от Вигерса, как на некий канон. Но никто нам не запрещает ввести свой уровень абстракции работы с требованиям, чтобы снижать неопределённость.
Это может быть организационный уровень, когда мы прописываем, какая система в сторону какой передала данные, почему и в каком объёме. Выстраиваем процесс.
Use cases - канонично, это уровень пользовательских требований, где мы описываем, как пользователь использует систему, чтобы достигнуть своей бизнес - цели.
То есть, я как пользователь хочу сделать заказ с доставкой на дом. Заказ нужно собрать на складе (система склада) и отдать в службу доставки (сервис доставки). У меня происходит декомпозирование цели и зная, как работает IT-ландшант, аналитик поймёт, где будут стыки взаимодействия систем. Как склад передаёт информацию о заказе в сервис доставке.
И поднимаясь на уровень пользовательских требований мы можем спроектировать сценарии, которые будут понятны нашему бизнес-заказчику. Были такие сказочные времена, когда BRD (Business Requirement Documen) ко мне приходил от бизнес-аналитика и я уже могла, изучив материал, спускаться на уровень взаимодействия систем. И действительно заниматься системным анализом.
Зачем вообщем-то я обо всём этом пишу?
✅Первое - как я сказала выше, вы вырываете сразу себе яму, зачем себя зарывать сразу на старте?
✅Второе - без определённого опыта, на системном уровне сложно оставаться. Получается адовый гибрид - местами понятно, и детально, местами нет, и разработчику нужно додуматься? А бизнес часть поймёт, часть не поймёт. Ни нашим, ни вашим.
✅Третье - чисто эмоционально, будет сложно. Это равносильно тому, что вы хотите сшить костюм, но нет мерок, нет эскиза, но вы уже пошли покупать пуговицы и нитки. Конечно, мы русские люди, любим героизм на пустом месте, создав сначала себе проблемы.
Итого: когда к вам прилетает задача на интеграцию, не бегите сразу читать API, спросите:
👉Зачем и кому нужна эта интеграция?
👉В каких бизнес-процессах она участвует?
👉Кто из пользователей в этих процессах участвует, какие стоят цели со стороны бизнеса?
И опишите сценарий по шаблону Коберну - базовый сценарий, расширения, оставаясь на уровне пользователя, где пользователь источник требований.
#интеграция #челлендж #сценарийинтеграции #мойопыт
Ух. Старалась объяснить на пальцах)
Насколько понятна идея?)
ООП - объектно-ориентированный подход к программированию.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Я часто говорю о том, что ООП аналитику нужно знать, ибо именно при таком подходе в разработке, часто и нужен аналитик. Чтобы спроектировать решение.
Возвращаясь к теме интеграции, скажу, что ООП ключевая вещь.
✅Аналитику нужно понимать, какая предметная область лежит в основе решения.
✅Какие объекты предметной области участвуют в процессах (в интеграционных сценариях).
✅И как собственно интеграция влияет на жизненный путь объекта. Как из одного статуса объект переходит в другой, и что при этом происходит.
Например, у нас есть с вами предметная область - ритейл. То есть создаётся корзина, в соответствии с ней заказ, заказ оплачивается, и после оплаты происходит его сборка на складе и отгрузка в доставку.
Рассказывая, что происходит и над какими объектами, мы с вами можем выделить как раз ключевые бизнес объекты, и их статусы.
И как часто бывает, если потянуть за веревочку, мы целый клубок всего находим, где нам нужно понимание ООП:
♟1.Объекты предметной области и связи между ними
♟2.Структура объектов, иерархия данных
♟3.Жизненный цикл ключевых объектов предметной области
♟4.Операции над объектами (основа для API).
И в итоге мы с вами получаем целый пласт информации, которая нам необходима, чтобы в конечном приближение указать детали - доступные операции над структурой объектов, выполняя которые, объекты меняют статусы в соответствии со своим жизненным циклом.
И мы с вами по статусу объекта сможем понять, на каком этапе обработки он находится. Например, заказ собран уже на складе и готов к отгрузке на доставку.
Очень часто, аналитики в задачах интеграции принебрегают анализом таких артефактов, как онтологическая модель предметной области (можно также брать ER - диаграмму или диаграмму классов), диаграмма статусов (state machine) + правила перехода из статуса статус.
Не стоит забывать, что ООП - это один из способов упрощения работы с данными. Когда сложные структуры мы укладываем в объекты, и определяем связи между объектами, и описываем операции над ними, исходя из процессов, в которых участвуют объекты.
По сути ООП - это способ представления нашего реального мира в виртуальном, мы делаем проекцию, таким способом автоматизирую сложные операции реальных процессов.
#челлендж #интеграция #ооп
Так что не стоит забывать про платформу знаний, которая вам необходима, чтобы написать идеальное ТЗ на интеграцию - это ООП.
Паттерны интеграций (технологии передачи данных)
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Я всё о высоких материях, но к сожалению без них никак. Собираем предыдущие два поста вместе и получаем следующего слона, на котором стоит интеграция. Технологии!
Не сложно увидеть, что технологии я поставила последними. Так и есть, не стоит бежать сразу на уровень данных и способы их передачи. Сначала мы определяем кто, какие бизнес-объекты в каких сценариях участвуют, а дальше спускаемся на уровень технологий и отвечаем на вопрос - как будет происходить передача данных.
И говоря про Паттерны интеграции на уровне данных выделяют 4 паттерна:
✅Обмен файлами
✅Общая база данных
✅Удалённый вызов процедур (считайте прямой вызов API, SOAP, REST)
✅Обмен с помощью очередей сообщений (абстракция в виде очередей, сюда относим шину (ESB), брокер сообщений).
Паттерны обмен файлами и общая база данных, часто относят к антипаттернам, много минусов в их применение. Зато очень понятные Паттерны, правда "Общая база данных" требует хороших компетенций в проектирование структур данных, самых схем баз данных и выборки данных.
Все Паттерны интеграции по типу передачи данных очень логичны, выстроены последовательно, я бы сказала эволюционно. И можно увидеть, то как шина, в конечном итоге, вбирает в себя все предыдущие Паттерны и способы передачи данных, включая брокер.
На текущий момент самые популярные Паттерны это шина и брокер.
Шина фактически является швейцарским ножиком, который на все случаи жизни позволяет развивать айти ландшафт компании.
Столь популярный брокер, может встречаться как отдельное решение (например, мы выстраивали систему очередей для системы отправки SMS сообщений), но чаще всего брокер встречаем в микросервисной архитектуре.
Про технологии и Паттерны интеграции всегда есть что сказать, тем более, мир не стоит на месте и постоянно появляется, что-то новое. Но как мы видим, фундамент айти не меняется, так что OSI модель построения сетей поможет разобраться в технологиях передачи данных.
Смотрите на решения глубже, опускаясь на фундамент и понимая, что лежит в основе, проще принимать решения и изучать новое и быть в струе развития технологий.
#челлендж #интеграция #паттерныинтеграции #технологии
Обожаю работать с аналитиками))
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой🔝 правил, которые помогают мне определить идеального клиента-аналитика:
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.Мест для выпендивания можно найти дофига других)))
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.Сделай с нуля из меня тим лида, чтобы я зарабатывал полляма и ничего не делал, это не ко мне))
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста😎
#интеграция #челлендж #топ #клиенты
Мало того, что аналитик это специалист, который постоянно ищет противоречия, выстраивает логику, делает выводы, но ещё и обладает профессиональным чутьем, где собака зарыта.
От аналитиков всегда прилетают глубокие вопросы. И это действительно здорово!) Потому что не всё видно с первого раза. Плюс я сама расту за счёт такой обратной связи, и мотивация есть двигаться дальше.
-----------------------
За годы работы в качестве тренера, ментора, преподавателя, у меня сложился свой
⏺ Я не люблю слово преподаватель, потому что оно сразу показывает некую позицию, я вам сейчас преподам. Я люблю работать с аналитиками с позицией "на равных", взрослый - взрослый. Менторская позиция. Мы одинаковые, я просто расскажу своё мнение и способ, как я вижу можно решить твой запрос. Но за тобой всегда своё собственное мнение, что и как делать. Прислушиваться или нет. Именно взрослый человек принимает свои решения и управляет своей жизнью.
⏺ Также я стараюсь выстраивать общение с позиции "со мной всё в порядке", "с тобой всё в порядке". Если человек пришёл учиться или получить от меня комментарии, то это уже стрессовая позиция, не вижу смысла её усугублять и пытаться потешить своё эго.
⏺ Также не работаю по принципу no pain, no gain. Так много этого надрыва вокруг, критики и давления, что не вижу в таком подходе ничего хорошего, особенно когда говорим про игру вдолгую.
⏺ Конечно круто, когда человек приходит с чётким запросом, знает чего хочет и понимает адекватность своего запроса.
⏺ Умеет и готов работать, плюс создаёт для себя условия успеха, в виде регулярности, дисциплины. Причём дисциплина тут это не хлыст сверху, а неотъемлемая часть жизни. Потому что рутина даёт результат. Но и совсем уж расслабиться и ничего не делать это не про аналитиков))) Ребята аналитики выстраивают себе систему и именно эта система, регулярность, целенаправленность и даёт результат. Я некоторые ещё те ломовые лошади!)
⏺ Конечно приятно работать с людьми с опытом, в том числе и жизненным. Потому что я скорее работаю, как ускоритель той базы которая уже есть. Создавать базу с нуля сложно, и пока я за такое не берусь.
⏺ Взаимодействие строиться на доверие. Ибо нет смысла идти к специалисту, который тебе не нравится, ментально в том числе. Искать когда будет провал или какой либо подвох.
⏺ Границы ответственности. Мне не интересно делать за кого-то его работу, мне интересно видеть прогресс. Переложить с больной головы на здоровую прекрасно, но вам то, что с этого?
-----------------------
Есть такое понятие сложный клиент, вот я бы скорее сказала, что клиент есть клиент, и он может быть не ваш, либо вы не можете найти подход и общий язык. Да, есть и такие, кто будет хлопать дверью, кричать. Это нормально, все мы разные и хотим разного)))
Комфортное открытое пространство общения, где можно задавать вопросы и обсуждать все свои проблемы, вот к чему я всегда стремлюсь. Конечно у меня нет нимба над головой и я тоже могу и уставать, и какой-то бред ляпнуть, но возвращаемся к пункту, взрослый - взрослый. Взрослый принимает свои ошибки и их исправляет.
Вот именно за таким общением я вас и приглашаю в нашу 🔥 мощную команду февральского потока интеграции. Уже много интересных ребят с разных компаний придёт))
Будет мощно, жарко и всем придётся поработать! Но есть ради чего стараться!
А мы с Андреем постараемся сработать ускорителями вашего профессионального роста
#интеграция #челлендж #топ #клиенты
Please open Telegram to view this post
VIEW IN TELEGRAM
Как выбрать решение по интеграции?
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территориюподвинься щенок, не задавай мне такие вопросы
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,подозрительно на которые нет ответов. Как-то на проекте я спросила, почему купили шину IBM, а не ORACLE? Мне сказали, тсссс! Молчи! Нашему инвестору IBM красивую презентацию показали и ужин устроили и ещё то, чего мы не знаем. И не говорим вслух...
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
Частый и любимый вопрос от аналитика.
И он понятен! Архитекторы, разработчики закатывают глаза вверх и отвечают, что-то типа дружок не заходи на мою территорию
И когда ты раз получил негатив, два получил негатив, уже в следующий раз не будешь спрашивать, но и чувствовать себя на обочине жизни не хочется. Все там в замесе участвуют, я на всё это хозяйство ТЗ пиши, и не должен понимать, а почему выбрали то или иное решение?
Попробуем разобраться вместе.
Какие могут быть варианты:
✅1.По-другому нельзя, у нас нет выбора - у нас интеграция с сервисом на который мы не можем повлиять, сказали SOAP, значит SOAP, и нет тут долгих размышлений и логики принятия решения.
✅2.Среда нас ограничивает - мы такие умные и красивые пришли со своим REST API, микросервисами, а наш партнёр нам говорит - Дорогой ты мой человек! Мы когда в пятницу уходим на выходные, всё отрубаем и сервер тоже. И вообще у нас Марья Ивановна будет работать с вашими данными на винде. Дайте человеку файл на почту, чтобы смогла его открыть, прочитать и ничего не потерялось.
✅3.Политическое решение. Не нужно вам знать почему так! Слишком много задаёшь вопросов, товарищ,
✅4.Нет ресурсов - банально, может быть там, что нет разработчиков, кто бы модно, молодёжно смог сделать. Поэтому берут проверенный, рабочий вариант.
✅5.И может быть вариант - да бог его знает, все так делают и ваще Вася наш гений, вот он так и решил, играет в технологии, главное. Всё работает, все довольны!
✅6. А может быть вариант - не знаю, исторически сложилось, или никто не думал, поэтому не задавай вопросы!
Ну и главный фактор - решение принимает человек и он исходит (в лучшем случае) из того, какие у него вводные данные:
📍сроки,
📍требования,
📍безопасность,
📍скорость передачи,
📍объем передачи данных,
📍надёжность,
📍масштабируемость,
📍среда (ограничения среды),
📍ресурсы,
📍поддержка,
📍бюджет,
📍уже что-то пообещали начальству...
И не стоит подходит к вопросу, а как должно быть?
С такой позиции, что мы сейчас делаем раз и навсегда. И интеграция у нас будет вылита в бронзе.
Как-то на одном проекте, у нас интеграция за год поменялась несколько раз:
✅В начале, надо было быстро, сделать point-to-point напрямую, шаблонно, так как уже было api
✅Потом переделали и завернули на шину, сделали центр обмена xml-сообщениями
✅Потом поняли, что нужен брокер, поставили и завернули на очередь.
И при таком раскладе решение везде работало, и прошло эволюцию вместе с айти ландшафтом компании.
Поэтому, мы стараемся разбирать позицию аналитика в связке - требование, ограничение, и влияние на решение. Но аналитик не принимает окончательные решения по разработке, аналитик помогает команде погрузиться в плоскость проблем, требований, ограничений, рисков, как раз задавая неудобные вопросы, которые направляют нашу команду в нужном русле.
👉Именно такой путь мы и будем с вами проходить на курсе интеграции.
👉Будем делиться кейсами из жизни, опытом, знаниями и проходить цепочку проектирования решения от концепции до уровня технологий и паттернов интеграции.
-----------------------
Залетайте к нам в февральский поток! 🚀
#интеграция #челлендж #выборрешения
sup.expert
Курс по интеграции