«Эти архитекторы делают непонятно для кого», «Я тут в Miro накидал», «Нарисуй там что-нибудь архитектурное, а то мы уже код пишем» – знакомо?

Привет! Меня зовут Ущаповский Антон, я архитектор решений в МВС ИИ, последние несколько лет активно погружаюсь в различные аспекты разработки ПО и в ИТ-архитектуру, в частности. Как следствие, накопилось некоторое количество повторяющихся «болей», которые встречаю из раза в раз и наблюдаю их на регулярной основе практически на каждом ИТ-продукте.

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

За последние шесть лет испробовал множество аспектов работы с API-контрактами, не только с точки зрения проектирования, но и остальных этапов жизненного цикла этих артефактов.

Так-то API-контракт может быть не просто набором методов, которые «по-бырику» выставили, пока дальше код пишется, а что-то более зрелое и, соответственно, требующее более зрелого и продуманного подхода.

На что стоит обратить внимание при работе с API-контрактами внутри дружественной корпоративной среды множества разрабатываемых ИТ-систем?

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

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

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