На недавнем вебинаре: ИТ-архитектура и управление изменениями. Обновление процесса CHG мы рассматривали процесс изнутри. Надеюсь, что это было полезным и содержательным. Однако взгляд с такой точки зрения сопровождается одним допущением – запросы на изменения поступают к нам из внешней среды случайным образом и в случайные моменты времени. Безусловно, это не так и в реальной жизни мы знаем о количестве и содержании будущих запросов на изменения немного больше, чем ничего. Особенно если наши бизнес-заказчики ведут плановое хозяйство, собирают свои пожелания на следующий год как-то устанавливают их приоритеты, классифицируют изменения, отделяют главное от самого главного, важное от срочного, появление новых продуктов от улучшения существующих.
Бизнес-заказчики это действительно делают и сейчас во многих организациях начинается очередной тур увлекательной корпоративной игры, называемой бюджетное планирование на следующий год. В рамках этого действа они безусловно заглянут и во ИТ с традиционным вопросом: Когда это можно запустить и сколько оно будет стоить? Обращаю ваше внимание, что ответ на этот вопрос зависит от выбора варианта реализации, а значит непосредственно относится к зоне ответственности корпоративного архитектора. Более того, решающим фактором при ответе на вопрос когда является наличие собственных ресурсов ИТ организации на доработку существующих систем и интеграцию. Вы можете рассматривать команды разработки своих приложений как потоки, через которые проходят изменения и доступность того или иного ресурса это, прежде всего, вопрос наличия во входной очереди других, более приоритетных проектов и задач. Обычно, в организации есть несколько основных систем с большой очередь таких запросов(систем, попавших в рамках очередной архитектурного проекта в категорию целевых). Но разработчикам других приложений не надо отчаиваться. Опытные заказчики отлично знают, что верный способ сделать проект, это реализация его в нецелевых системах. Поэтому рано или поздно они обязательно придут и к разработчикам нецелевых систем. Правда без бюджета и в тот момент, когда до запуска проекта осталось совсем мало времени.
Я не стану сейчас подробно рассказывать, как в короткие сроки раскидать проекты по системам, пойти, как принято говорить, на сложное решение о временных отступлениях от целевой архитектуры и ограничивать влияние изменений на корпоративный ИТ-ландшафт. В июле-августе обновились соответствующие разделы методологии Scaled Agile Framework, обязательно посмотрите Portfolio Kanban и связанные статьи. Подробнее мы все это обсудим на семинарах и мастер-классах. Хочу обратить ваше внимание на другой момент. Когда мы обсуждаем CI/CD, DevOps, микросервисы, то стремимся сделать для заказчика одну простую вещь: распараллелить процесс разработки этих самых ключевых систем, реализовать возможность одновременной доработки решения силами нескольких команд в интересах разных проектов. Это не самая простая задача и пока мы не научимся её решать не стоит говорить об evolutionary architecture, microservices и тем более некоторых платформах(самое любимое слово ИТ руководителя). Лучше на этапе глобального планирования перетасовать проекты и приложения