Я определяю границы сервисов по тому, кто меняет правило
Почему границы сервисов стоит определять по владельцу и жизни бизнес-правила: как избежать дробления ради схемы и сделать изменения в системе управляемыми.
Читать статью →IT-стратегия — Алексей Журинов — страница 2
Рубрики
Популярные метки
Я делаю журнал изменений частью архитектуры, когда система влияет на деньги и обязательства
Почему журнал изменений нужен архитектуре: какие факты сохранить о важном решении, как не превратить историю в контроль людей и быстрее вернуть систему в безопасное состояние.
Читать статью →Я сначала фиксирую правило, а потом выбираю технологию для архитектуры
Как принимать архитектурные решения от бизнес-правил: назначить владельца, определить границы данных, предусмотреть безопасное поведение при сбое и путь назад.
Читать статью →Я не добавляю сервис в архитектуру, пока не знаю, что будет без него
Как проверить новую сервисную зависимость в архитектуре: пройти маршрут пользователя, определить безопасное поведение при сбое и сохранить возможность выйти из решения.
Читать статью →Я начинаю замену финансовой системы с одного закрытого месяца, а не с презентации
Почему замену финансовой системы стоит начать с одного закрытого месяца: увидеть ручные обходы, путь важной цифры и требования к решению без презентационной пыли.
Читать статью →Я разделяю срочность и критичность до того, как обсуждать надёжность системы
Как отличить срочную проблему от критичного риска в IT-системе: оценить последствия, выбрать разумную защиту и назначить владельца решения до сбоя.
Читать статью →Я выбираю архитектурное решение по тому, как из него можно выйти
Как оценить архитектурное решение через обратимость: увидеть точку невозврата, защитить данные, ограничить первый шаг и сохранить возможность менять курс без пожара.
Читать статью →Я не сравниваю системы по таблице функций, пока не описан рабочий день после внедрения
Как выбрать новую бизнес-систему без ловушки таблицы функций: описать будущий рабочий день, убрать старый ручной обход и проверить решение на исключениях.
Читать статью →Я ищу не виноватого в сбое, а момент, когда система перестала быть видимой
Почему наблюдаемость IT-системы начинается с бизнес-маршрута: как видеть остановку процесса, назначить владельца сигнала и быстрее восстановить работу.
Читать статью →Я не прошу оценку разработки, пока не понимаю цену неверного решения
Почему оценка разработки начинается не с часов: как увидеть риск неверного решения, зафиксировать условия и разбить работу на проверяемые этапы.
Читать статью →