Самое сложное в процессе подготовки постов "первого этапа" было не скатываться в язык тендерной заявки, но при этом соблюдать хоть какие-то каноны описания требований.
Встречайте! ЕДИНЫЙ АРХИТЕКТУРНЫЙ РЕПОЗИТОРИЙ и его концепция! если кто не понял, подсказываю: Вы в восхищении!
Любое ПО должно иметь назначение, и ЕАР призван стать своеобразным «полотном», связывающим воедино бизнес-процессы с реализующими их программными компонентами, их «историями» в самом широком понимании этого слова. ЕАР, если хотите - должен обеспечить единый источник правды для всех, кто её ищет. В рамках описанной IT-инфраструктуры, конечно.
Ниже будет шпаргалка на случай если ты, мой дорогой читатель, ещё пытаешься понять, какие проблемы решаются с помощью ЕАР
➡️Фрагментация данных.
Информация о БП, задачах, архитектурных решениях, интеграциях хранится в разрозненных источниках: таск-трекерах, wiki-системах, переписках, головах ключевых сотрудников. Как результат — при ротации команд, увольнении сотрудников значительная часть контекста сваливает вместе с его хранителями.
➡️Отсутствие прослеживаемости.
Ответы на вопросы
▪️Какие IT-системы отвечают за определённый процесс?
▪️Какие процессы затронет планируемое изменение?
▪️и обычное человеческое "Нахрена мы это сделали?"
приходят не то, что долго, а могут не прийти вообще.
➡️Разрыв между бизнесом и IT.
Бизнес-заказчики и команда разработки использую разные инструменты для описания и оценки и не имеют единого взгляда на IT-ландшафт целиком
Отсюда начинают произрастать проблемы, в том числе, скрытых зависимостей между бизнес-процессами и IT-системами, а вместо нормального impact-анализа имеем оценку в попугаях, полученную экспертным путём.
А всё почему? Да потому что
Бонусом к уже описанному и как следствие — всё увеличивающийся пиздец в виде
▪️нарастающего техдолга
▪️увеличения Time-to-Market новых фич
▪️рост стоимости поддержки и развития ПО
▪️системные ошибки при оценке изменений
Итак, фиксируем достижимую выгоду от нашего щеночка
➡️Стратегическую
▪️Снижение потери знаний при ротации команд, сокращение времени онбординга
▪️Повышение качества принимаемых решений
▪️Повышение прозрачности для бизнеса
➡️Операционную
▪️Повышение согласованности архитектурных решений
▪️Повышение уровня переиспользования архитектурных решений
▪️Упрощение доступа к историческим данным
➡️Техническую
▪️Непрерывное обогащение знаниями через интеграции с таск-трекерами
Утверждён график выхода ближайших серий
08.04. - ЕАР. Концепция. Часть II. Хоть какие-то требования
10.04 - ЕАР. Концепция. Часть III. Точки роста и риски.
#МедведьДелаетЕАР