Хочешь насмешить бога расскажи ему о своих планах.
🤫
#анонс #курсинтеграции #конференции
Попробую)))
✅ 7 сентября
стартует 3 поток курса "Проектирование интеграции информационных систем", подробное описание вот тут sup.expert
Присоединяйтесь, группу мы начали уже формировать!
✅ 30 сентября я должна выступить на конференции в Ижевске, вот описание https://uic.dev/ с темой "Погружение в предметную область"
✅ Очень надеюсь, что в начале октября мы с Евгением Галактионовым ещё и вебинар запустим по бизнес-моделям и разберём, как верхушку пирамиды артефактов в части бизнес-анализа можно представить.
✅ Плюс ещё хочется прямые эфиры проводить на канале, если у кого есть идеи пишите в комментариях, а может кто-то хочет стать гостем))) Пока я по своим знакомым ищу интересных людей и их истории в айти.
Пока всё, и этого мне вполне хватает)))
✅ Плюс менторство, никто не отменял и за одну неделю ко мне пришли уже человека 4, чему я рада, ибо маховик размышлений не работает без вашего топлива🤌
🤫
#анонс #курсинтеграции #конференции
Попробую)))
✅ 7 сентября
стартует 3 поток курса "Проектирование интеграции информационных систем", подробное описание вот тут sup.expert
Присоединяйтесь, группу мы начали уже формировать!
✅ 30 сентября я должна выступить на конференции в Ижевске, вот описание https://uic.dev/ с темой "Погружение в предметную область"
✅ Очень надеюсь, что в начале октября мы с Евгением Галактионовым ещё и вебинар запустим по бизнес-моделям и разберём, как верхушку пирамиды артефактов в части бизнес-анализа можно представить.
✅ Плюс ещё хочется прямые эфиры проводить на канале, если у кого есть идеи пишите в комментариях, а может кто-то хочет стать гостем))) Пока я по своим знакомым ищу интересных людей и их истории в айти.
Пока всё, и этого мне вполне хватает)))
✅ Плюс менторство, никто не отменял и за одну неделю ко мне пришли уже человека 4, чему я рада, ибо маховик размышлений не работает без вашего топлива
Please open Telegram to view this post
VIEW IN TELEGRAM
uic.dev
UIC DEV Izhevsk 2024
Хочу рассказать, с разрешения Ивана Соколова, немного о нём и сделать репост ниже его поста 👇 о том, как он готовился к собеседованиям, развивал себя, как специалиста и осваивал для себя новое пространство, под названием системный анализ в айти 🔥
От себя скажу, что Иван имеет хорошую базу инженера и много лет работал на предприятие в космической отрасли. И эта база и личные качества помогли сделать большой шаг вперёд, получить опыт, знания, и как следствие, новый оффер на работу системным аналитиком.
Что помогло Ивану в прохождение несколько этапов собеседований читайте в его заметке ниже)))
👇
#курсинтеграции #собеседования #историиизжизни #реальныйкейс
От себя скажу, что Иван имеет хорошую базу инженера и много лет работал на предприятие в космической отрасли. И эта база и личные качества помогли сделать большой шаг вперёд, получить опыт, знания, и как следствие, новый оффер на работу системным аналитиком.
Что помогло Ивану в прохождение несколько этапов собеседований читайте в его заметке ниже)))
👇
#курсинтеграции #собеседования #историиизжизни #реальныйкейс
Чем сложна интеграция?
#интеграция #курсинтеграции #рассуждения #мойопыт #системныйаналитик #проектирование
Начну с того, что я люблю задачи по интеграции. Так сложились звезды, что свою карьеру я начала в команде шинной интеграции аж в 2006 году и интеграция, как "красная линия" идёт через весь мой опыт. Сейчас айти ландшафты стали сложнее, "развесистее", запутаннее и имеют часто "зоопарк" технологий и систем. И это нормально!
Конечно интеграция - это та самая задача, которая будет всегда актуальна. Интеграция систем конечно упрощается и по шаблонам больше похожа на конструктор, или обыденное действие "вставить вилку в розетку". Но имея всё вышеперечисленное в айти ландшафте, чтобы соединить/перестроить инфообмен систем нужно действительно заняться системным анализом.
И тогда команда проектирования сталкивается со следующими сложностями:
✅1.Первый пункт сложности - это разложить процесс на разные уровни абстракции. С точки зрения бизнеса, часто нет проблем в понимание. Мы соединяем бизнес процессы или соединяем обмен информацией на уровне справочников. Пользовательский уровень часто отсутствует, потому что пользователь далеко, либо наш пользователь это администратор системы. Вместо пользователя появляется уровень организационный, выстраивания информационного обмена между участниками.
✅2.Самое сложное это системный уровень, и чтобы спуститься на этот уровень нужны знания по технологиям передачи данных, устройство сетей, работа с API, понимание протоколов и их нюансов проектирования.
✅3.Как-то один руководитель мне сказал, а что сложного в интеграции? Передали данные, написали их маппинг делов то. Вот тут и кроется засада в виде выстраивания среды вокруг этой передачи данных. Тут появляется логирование, квотирование, мониторинг и те самые НФТ, которые описывают требования к безопасности, отказоустойчивости, масштабированию, доступности. Управления интеграцией! Администрирование! И в интеграции подобные вещи явно видны и критичны.
✅4.Ещё момент, про который почему-то многие аналитики забывают - это работа с ошибками/исключениями и выявление альтернатив с описанием их обработки. Конечно, есть моменты, которые вроде как очевидны разработчикам, но есть альтернативы неочевидные и решение по их обработке и реакции на события должны принимать бизнес-заказчики.
✅5.А теперь "тяжёлая артиллерия", это знание и понимание ООП. Да, да, да системному аналитику в интеграции нужны знания программирования. В основе большинства процессов лежат объекты и действия над ними, в интеграции нужно ещё и нырнуть на уровень проектирования процессов обработки объектов, так, чтобы не нарушить их жизненный цикл, а скорее выстроить в разрезе интеграционного взаимодействия. А в шинной интеграции у нас ещё и БД были, и вот тут тоже включаются компетенции связанные с проектированием реляционных баз данных.
И вот, что мы получаем в итоге? Что интеграция это частный случай проектирования информационных систем. И как бы не хотелось подобную задачу облегчить, и сделать понятной и шаблонной, всё равно мы сталкиваемся с тем, что компетенции аналитика в системном анализе, знаний технологий, основ проектирования информационных систем ООП, БД просто необходимо для адекватного решения задачи. Абы как "по быстрому", можно))) Но это вариант решения, за который сразу придёт немедленная расплата при выкатке на продуктив.
Размышляя на тему интеграции, я снова прихожу к выводу, что
Старт курса мы сдвинули на 21 сентября, и если интеграция для вас открытый, сложный вопрос, то наш курс для вас)
Регистрация по ссылке https://sup.expert/
#интеграция #курсинтеграции #рассуждения #мойопыт #системныйаналитик #проектирование
Начну с того, что я люблю задачи по интеграции. Так сложились звезды, что свою карьеру я начала в команде шинной интеграции аж в 2006 году и интеграция, как "красная линия" идёт через весь мой опыт. Сейчас айти ландшафты стали сложнее, "развесистее", запутаннее и имеют часто "зоопарк" технологий и систем. И это нормально!
Конечно интеграция - это та самая задача, которая будет всегда актуальна. Интеграция систем конечно упрощается и по шаблонам больше похожа на конструктор, или обыденное действие "вставить вилку в розетку". Но имея всё вышеперечисленное в айти ландшафте, чтобы соединить/перестроить инфообмен систем нужно действительно заняться системным анализом.
И тогда команда проектирования сталкивается со следующими сложностями:
✅1.Первый пункт сложности - это разложить процесс на разные уровни абстракции. С точки зрения бизнеса, часто нет проблем в понимание. Мы соединяем бизнес процессы или соединяем обмен информацией на уровне справочников. Пользовательский уровень часто отсутствует, потому что пользователь далеко, либо наш пользователь это администратор системы. Вместо пользователя появляется уровень организационный, выстраивания информационного обмена между участниками.
✅2.Самое сложное это системный уровень, и чтобы спуститься на этот уровень нужны знания по технологиям передачи данных, устройство сетей, работа с API, понимание протоколов и их нюансов проектирования.
✅3.Как-то один руководитель мне сказал, а что сложного в интеграции? Передали данные, написали их маппинг делов то. Вот тут и кроется засада в виде выстраивания среды вокруг этой передачи данных. Тут появляется логирование, квотирование, мониторинг и те самые НФТ, которые описывают требования к безопасности, отказоустойчивости, масштабированию, доступности. Управления интеграцией! Администрирование! И в интеграции подобные вещи явно видны и критичны.
✅4.Ещё момент, про который почему-то многие аналитики забывают - это работа с ошибками/исключениями и выявление альтернатив с описанием их обработки. Конечно, есть моменты, которые вроде как очевидны разработчикам, но есть альтернативы неочевидные и решение по их обработке и реакции на события должны принимать бизнес-заказчики.
✅5.А теперь "тяжёлая артиллерия", это знание и понимание ООП. Да, да, да системному аналитику в интеграции нужны знания программирования. В основе большинства процессов лежат объекты и действия над ними, в интеграции нужно ещё и нырнуть на уровень проектирования процессов обработки объектов, так, чтобы не нарушить их жизненный цикл, а скорее выстроить в разрезе интеграционного взаимодействия. А в шинной интеграции у нас ещё и БД были, и вот тут тоже включаются компетенции связанные с проектированием реляционных баз данных.
И вот, что мы получаем в итоге? Что интеграция это частный случай проектирования информационных систем. И как бы не хотелось подобную задачу облегчить, и сделать понятной и шаблонной, всё равно мы сталкиваемся с тем, что компетенции аналитика в системном анализе, знаний технологий, основ проектирования информационных систем ООП, БД просто необходимо для адекватного решения задачи. Абы как "по быстрому", можно))) Но это вариант решения, за который сразу придёт немедленная расплата при выкатке на продуктив.
Размышляя на тему интеграции, я снова прихожу к выводу, что
курс проектирования интеграции, который мы развиваем с Андреем Корниенко это ещё
и курс молодого бойца по проектированию информационных систем. Пока мы не хотим менять формат, наш курс больше похож на менторство, где в онлайн формате с участниками мы проходим основные шаги реализации проекта и разбираем трудности, которые чаще всего появляются. Старт курса мы сдвинули на 21 сентября, и если интеграция для вас открытый, сложный вопрос, то наш курс для вас)
Регистрация по ссылке https://sup.expert/
sup.expert
Курс по интеграции
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))
Его и предоставляю вашему вниманию.
💥
--------------------------
1. Определить системы, участвующие в обмене
2. Описать потоки данных
3. Понять наличие гарантированной доставки данных
4. Описать регламент взаимодействия систем:
• передаваемые данные
• частота передачи
• расписание
• система-инициатор обмена
5. Описать формат передачи данных:
• Названия атрибутов
• Тип, длина
• Обязательность
• Кодировка
6. Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7. Понять в какой системе хранятся мастер-данные по объектам.
8. Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9. Зафиксировать протоколы обмена данными.
10. Понять ограничения платформы/канала интеграции.
11. Нефункциональные требования:
• Выявить требования к скорости обработки и передачи данных.
• Понять необходимость шифрования данных.
• Оценить объем передаваемых данных.
• Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12. Описать интеграционный сценарий взаимодействия.
13. Понять способ взаимодействия – синхронное/асинхронное.
14. Описать механизм обработки ошибок.
15. Выявить требования к настройкам и администрированию.
--------------------------
Каждый из пунктов мы подробно разбираем на курсе "Проектирование интеграции информационных систем", который я смело уже могу назвать менторским подходом вцелом к проектированию информационных систем с нуля, начиная с концепции, переходя с одного уровня абстракции на другой, добираясь до самого низкоуровневого описания.
✔️ Я и мой компаньон Андрей Корниенко, ведём курс в формате лекций, домашних заданий, обсуждений и менторства, чтобы показать, как именно аналитику нужно думать, чтобы спроектировать интеграцию.
✔️ У нас нет сумасшедших потоков, наше преимущество это работа в долгую, наш курс это аналитический марафон в 2 месяца. Мы специально даём время на освоение материала и его осознание.
✔️ Мы не фабрика, не огромная площадка, нам самим прежде всего интересно передать свои знания и опыт, так чтобы это было системно и структурно. Это даёт нам проявлять гибкость и нестандартно зачитывать материал.
📌 Подробнее о курсе можно прочитать тут https://sup.expert/
старт потока совсем скоро, уже в этот четверг 21 сентября!)
Ждём тех кто ещё размышляет, у вас есть возможность запрыгнуть в уходящий поезд!📣
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских аналитиков, был написан коллективный чек-лист "Интеграции". Попытка как раз хоть как-то себе облегчить жизнь)))
Его и предоставляю вашему вниманию.
--------------------------
1. Определить системы, участвующие в обмене
2. Описать потоки данных
3. Понять наличие гарантированной доставки данных
4. Описать регламент взаимодействия систем:
• передаваемые данные
• частота передачи
• расписание
• система-инициатор обмена
5. Описать формат передачи данных:
• Названия атрибутов
• Тип, длина
• Обязательность
• Кодировка
6. Зафиксировать маппинг данных из формата системы-источника в формат системы-приёмника.
7. Понять в какой системе хранятся мастер-данные по объектам.
8. Выявить необходимость преобразования/проверки на актуальность/обогащения данных.
9. Зафиксировать протоколы обмена данными.
10. Понять ограничения платформы/канала интеграции.
11. Нефункциональные требования:
• Выявить требования к скорости обработки и передачи данных.
• Понять необходимость шифрования данных.
• Оценить объем передаваемых данных.
• Понять наличие ограничений на уровне регулятора (152 ФЗ, PCI DSS).
12. Описать интеграционный сценарий взаимодействия.
13. Понять способ взаимодействия – синхронное/асинхронное.
14. Описать механизм обработки ошибок.
15. Выявить требования к настройкам и администрированию.
--------------------------
Каждый из пунктов мы подробно разбираем на курсе "Проектирование интеграции информационных систем", который я смело уже могу назвать менторским подходом вцелом к проектированию информационных систем с нуля, начиная с концепции, переходя с одного уровня абстракции на другой, добираясь до самого низкоуровневого описания.
старт потока совсем скоро, уже в этот четверг 21 сентября!)
Ждём тех кто ещё размышляет, у вас есть возможность запрыгнуть в уходящий поезд!
Please open Telegram to view this post
VIEW IN TELEGRAM
sup.expert
Курс по интеграции
В потоке курса Интеграции у нас завязался с участниками интересный разговор. Вообще оч люблю аналитиков, они хоть и выносят мозг, но часто так глубоко смотрят в суть и задают неудобные вопросы.
Одна из моих любимых фраз это как раз про навык аналитика "задавать неудобные вопросы". Да, это может бесить, но это непосредственная работа аналитика уменьшать неопределенность, задавая вопросы и собирая нужную информацию.
#интеграция #курсинтеграции #курс #выводы #инсайты #грехианалитика #мысливслух #моемнение
Так вот, Андрей Корниенко, мы с ним вместе ведем курс, сказал, про "смертные грехи аналитика". Предлагаю один из них разобрать.
Звучит он как - "положиться на других", "довериться партнерам по интеграции". Честно для меня подобное мышление было откровением, что вообще возникает у команды или аналитика мысль, что вот там уже кто-то всё сделал, и теперь мы просто берем готовое и завязываемся на их решение.
Вот мы интегрируемся с большим и страшным, например Газпромом, и там не дураки же работают, возьмем по объектам их идентификаторы и просто сохраним у себя. Да, мы точно сохраним у себя их информацию, но логику и целостность данных будем выстраивать сами у себя.
✅1. Во первых, не забываем принципы СОА архитектуры, что все сервисы независимы друг от друга, и смотрят друг на друга как на черный ящик.
✅2. Нам нужна гибкость решения, масштабирования. Сегодня наш партнер по интеграции Газпром, а завтра нет. На практике у меня за год сторонний сервис сменился 3 раза! Нам нужна независимая логика работы нашей внутренней кухни, без завязок на внешнее.
✅3. Очень важная вещь, о которой многие не думают. Это юридическая составляющая работы с данными. К сожалению, многие аналитики и вцелом айтишники не очень сильны в юридических нюансах (я сама такая же), но не стоит забывать, что работая с данными мы можем быть ограничены законами, регламентами. И если какая-то произойдет жопа, придут разбираться на низкий уровень решения. И тут очень глупо говорить о том, что нууууу мы же завязали решение на нашего соседа по парте. А сосед скажет, у меня то всё хорошо, а это уже ваша зона ответственности.
Итого: решение интеграции - это всегда узкое горлышко, и делать его еще сложнее, завязываясь на сторонний сервис точно не нужно. Я искренне удивлена, что у аналитиков, архитекторов и разработчиков подобные мысли возникают.
Чтобы глубже разбираться в нюансах проектирования информационных систем и в частности интеграции приглашаю вас на мой курс "Проектирование интеграций ИТ Систем", набор на новый поток уже начался, старт занятий 16 ноября 2023 года, завершим на новогодних праздниках)))
Регистрация и описание курса по ссылке➡️ - Sup.expert
Одна из моих любимых фраз это как раз про навык аналитика "задавать неудобные вопросы". Да, это может бесить, но это непосредственная работа аналитика уменьшать неопределенность, задавая вопросы и собирая нужную информацию.
#интеграция #курсинтеграции #курс #выводы #инсайты #грехианалитика #мысливслух #моемнение
Так вот, Андрей Корниенко, мы с ним вместе ведем курс, сказал, про "смертные грехи аналитика". Предлагаю один из них разобрать.
Звучит он как - "положиться на других", "довериться партнерам по интеграции". Честно для меня подобное мышление было откровением, что вообще возникает у команды или аналитика мысль, что вот там уже кто-то всё сделал, и теперь мы просто берем готовое и завязываемся на их решение.
Вот мы интегрируемся с большим и страшным, например Газпромом, и там не дураки же работают, возьмем по объектам их идентификаторы и просто сохраним у себя. Да, мы точно сохраним у себя их информацию, но логику и целостность данных будем выстраивать сами у себя.
✅1. Во первых, не забываем принципы СОА архитектуры, что все сервисы независимы друг от друга, и смотрят друг на друга как на черный ящик.
✅2. Нам нужна гибкость решения, масштабирования. Сегодня наш партнер по интеграции Газпром, а завтра нет. На практике у меня за год сторонний сервис сменился 3 раза! Нам нужна независимая логика работы нашей внутренней кухни, без завязок на внешнее.
✅3. Очень важная вещь, о которой многие не думают. Это юридическая составляющая работы с данными. К сожалению, многие аналитики и вцелом айтишники не очень сильны в юридических нюансах (я сама такая же), но не стоит забывать, что работая с данными мы можем быть ограничены законами, регламентами. И если какая-то произойдет жопа, придут разбираться на низкий уровень решения. И тут очень глупо говорить о том, что нууууу мы же завязали решение на нашего соседа по парте. А сосед скажет, у меня то всё хорошо, а это уже ваша зона ответственности.
Итого: решение интеграции - это всегда узкое горлышко, и делать его еще сложнее, завязываясь на сторонний сервис точно не нужно. Я искренне удивлена, что у аналитиков, архитекторов и разработчиков подобные мысли возникают.
Чтобы глубже разбираться в нюансах проектирования информационных систем и в частности интеграции приглашаю вас на мой курс "Проектирование интеграций ИТ Систем", набор на новый поток уже начался, старт занятий 16 ноября 2023 года, завершим на новогодних праздниках)))
Регистрация и описание курса по ссылке
Please open Telegram to view this post
VIEW IN TELEGRAM
Как я проектирую интеграцию.
Расскажу именно свой процесс, да он может быть не последовательный, но я опишу его по шагам (+ см. чек-лист):
✅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
Наташа Косинова. Варю айти СУП
Чек-лист интеграции.
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
#интеграция #чеклист #курсинтеграции #проектирование #системныйаналитик #анонс
Аналитики страсть как любят готовые решения и шаблоны. Но жизнь намного сложнее и часто нет серебряной пули.
Много лет назад на одном из митапов московских…
История Искусств или ТРИЗ?)
Одно из моих хобби - это рисование. У меня в этом направление есть наставник, это Евгения (#нереклама, посмотреть работы). И вот мы на днях вместе ходили в Третьяковку.
Евгения архитектор, и мне нравится её системность и глубина знаний. Вот ты ходишь, смотришь картины. Ну да красиво, сейчас я уже могу оценить то, как детально проработано. Но почему картина шедевр, узнаешь только тогда, когда добавляешь знаний про историю её создания. И вот тут История Искусств для меня становится очень важным примером необходимости подобных знаний. Так и теория решения инженерных задач (ТРИЗ), показывает важные закономерности в создание инженерных изобретений.
И кстати, ТРИЗ помогает аналитику в проектирование интерфейсов.
Проектируя информационную систему, мы увидим результатв лучшем случае виде диаграммы. Но почему так? Часто остаётся открытым вопросом.
Я вижу, как аналитики бегут за знаниями технологий, языков программирования, не задавая вопрос, а что лежит в основе? В чем фундамент? Почему так?
Мы видим результат эволюции и развития инноваций, забывая про то, что опыт пройденного пути нам важен, чтобы решать свои задачи.
Поэтому, да, сложно, да больно, но чтобы спроектировать интеграцию нужно понимать, какой путь нужно пройти, откуда ноги растут тех или иных принятых решений, в чем фундамент? Каков путь? И пройти этот путь по разным уровням требований, начиная с бизнеса, заканчивая технологиями передачи данных можно вместе с нами на курсе интеграции, старт совсем скоро 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
Курс по интеграции
Квотирование в интеграции, что это такое и зачем нужно?
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Такой странный зверь - Квотирование. В интеграции, он как ружье, висящее на стене, может внезапно выстрелить.
Что такое Квотирование?
Из названия мы видим, что речь идёт про квоту. То есть одна система диктует правила о том, как к ней обращаться. Например, что больше 100 запросов в день от конкретного источника не принимаем. В начале 2000-х квота встречалась часто. Иногда о ней говорили и писали в спецификации и вводили для того, чтобы управлять нагрузкой. Чтобы банально повторными вызовами не завалили сервер.
Вроде бы сейчас 2023 год, какая квота? Но, она есть и есть иногда неявно.
✅Например, есть платные сервисы, и каждый запрос это деньги. Оно может быть очевидно #капитаночевидность , а может и нет. И когда разработчик спокойно отлаживает с тестировщиком сервис, может за день месячный бюджет оплаты израсходовать. Жизнь нас ничему не учит, и команды наступают на такие грабли часто. Таких историй слышала много и мы тоже так делали)))
Потом просто все разводят руками, а менеджер плачет и рвёт на себе волосы, потому что платить на счетам нужно.
✅А может быть государственный сервис, который на уровне бизнеса может ввести квоту. Например, запрос раз в 30 минут, ибо они обрабатываются вручную и это регламент. А может и количество за день, чтобы регулировать процесс или доход компании. Ситуации могут быть разные.
Что с этим делать?
Аналитику - задавать неудобные вопросы, просчитывать появление подобных случаев. И фиксировать в виде требований на интеграцию под названием "настройка Квотирования". Это может быть частота вызова, их количество за определённый период и шаг отправки. Например, раз в 30 минут, не более 100 в сутки по времени сервера (часто московское время, но может быть и другое, и таймзона тоже как ружье на стене, сегодня никому не нужен Владивосток, а завтра бизнес решит завоевать мир и выстрелит ситуация изменения таймзоны).
Интеграция - это соединение систем в единое информационное пространство, которым нужно управлять.
Так что Квотирование редкий зверь, но если вы его встречаете не пугайтесь, фиксируйте ситуацию, которая кажется на первый взгляд безумной, но в реальности реализуется.
#интеграция #квотирование #мойопыт #системныйанализ #курс #курсинтеграции
А какие вы встречали кейсы Квотирования в своей практике?
Делитесь в комментариях ниже 👇
Как выбрать паттерн интеграции?
Это любимый вопрос аналитика. И его можно понять, ибо ставя задачу на разработку и не понимая, как принимаются решения, сложно контролировать и принимать результат работы. Чувство не самое приятное, ты в команде, но почему так сделали непонятно.
➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷♀ Действительно, часто нет логического чёткого объяснения почему так.Потому что наш директор поехал на презентацию, там выпил водки и купил лицензию по шине, а теперь нам с ней работать. Занавес.
➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.
➡️ Дальше, самый сок, когда ты думаешь, ну вот сейчас будет шина, а вот тут брокер. Но приходит партнёр и говорит - у нас нет разработчиков, и вообще мы, уходя на выходные, выключаем сервер. У нас был такой кейс. И тут кроме интеграции через электронную почту, у нас не было больше никаких других вариантов. Даже с файлами они не хотели работать.
➡️ И если включать здравый смысл и логику, то нужно исходить из бизнес требований, нефункциональных требований, объёма передачи данных, масштабирования, развития компании, ИТ-ландшафта, ограничений бюджета,и конечно сотрудников.
Какие есть Паттерны?
По способу передачи данных:
Обмен данных с помощью
✅ файлов
✅ общей базы данных - это антипаттерны интеграции, от них лучше уходить.
Те кто хоть раз подобные паттерны пытался поддерживать в продуктиве могут рассказать множество замечательных историй, про седые волосы и бессонные ночи.
И остаётся чаще всего применяемые паттерны -
✅ удалённый вызов процедур
✅ обмен сообщениями (шина, брокер).
Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.
Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).
Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.
Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.
Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.
В реальности в ИТ-ландшафте компаний можно встретить гибрид из всех паттернов интеграции по способу передачи данных.
И каждый из них имеет свои плюсы и минусы, применимость в конкретных случаях, среде.
И кажется, что в айти всё логично, и есть обоснование всему, что происходит. Но нет. Часто скрытых смыслов и большого пути принятия решений попросту нет.
Подробнее про проектирование интеграционных решений вы можете узнать на нашем курсе, старт потока уже в этот четверг 16 ноября.
Почитать про курс можно вот тут➡️ sup.expert
#курсинтеграции #курс #системныйанализ #паттерныинтеграции
⚡️ Остались вопросы или вы хотите записаться, пишите напрямую мне))
Это любимый вопрос аналитика. И его можно понять, ибо ставя задачу на разработку и не понимая, как принимаются решения, сложно контролировать и принимать результат работы. Чувство не самое приятное, ты в команде, но почему так сделали непонятно.
➡️ Один из ответов, к сожалению, звучит так - потому что так сложилось. 🤷♀ Действительно, часто нет логического чёткого объяснения почему так.
➡️ Следующий ответ звучит, как - а мы только так можем, и никак по-другому. Действительно, команда просто по-другому не умеет, и делает так, как привычно. Нет компетенций, опыта, бюджета на новое, на обучение. Всё что угодно. Оно работает? Работает. Тогда не ломай, не трогай.
➡️ Дальше, самый сок, когда ты думаешь, ну вот сейчас будет шина, а вот тут брокер. Но приходит партнёр и говорит - у нас нет разработчиков, и вообще мы, уходя на выходные, выключаем сервер. У нас был такой кейс. И тут кроме интеграции через электронную почту, у нас не было больше никаких других вариантов. Даже с файлами они не хотели работать.
➡️ И если включать здравый смысл и логику, то нужно исходить из бизнес требований, нефункциональных требований, объёма передачи данных, масштабирования, развития компании, ИТ-ландшафта, ограничений бюджета,и конечно сотрудников.
Какие есть Паттерны?
По способу передачи данных:
Обмен данных с помощью
✅ файлов
✅ общей базы данных - это антипаттерны интеграции, от них лучше уходить.
Те кто хоть раз подобные паттерны пытался поддерживать в продуктиве могут рассказать множество замечательных историй, про седые волосы и бессонные ночи.
И остаётся чаще всего применяемые паттерны -
✅ удалённый вызов процедур
✅ обмен сообщениями (шина, брокер).
Удалённый вызов процедур - по сути онлайн обмен между двух систем, которые соединены напрямую, через API.
Брокер - это работа с абстракцией в виде очереди, которая может быть реализована по-разному (например, на основе протокола AMQP).
Шина - это швейцарский ножик, который вбирает в себя все Паттерны и нюансы управления интеграционным слоем.
Шина с централизованным обменом данных является одним из паттернов SOA архитектуры.
Брокер может быть с очередями частью шины или способом передачи сообщений в микросервисной архитектуре.
В реальности в ИТ-ландшафте компаний можно встретить гибрид из всех паттернов интеграции по способу передачи данных.
И каждый из них имеет свои плюсы и минусы, применимость в конкретных случаях, среде.
И кажется, что в айти всё логично, и есть обоснование всему, что происходит. Но нет. Часто скрытых смыслов и большого пути принятия решений попросту нет.
Подробнее про проектирование интеграционных решений вы можете узнать на нашем курсе, старт потока уже в этот четверг 16 ноября.
Почитать про курс можно вот тут
#курсинтеграции #курс #системныйанализ #паттерныинтеграции
Please open Telegram to view this post
VIEW IN TELEGRAM