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