5.3 Особенности цифровых организаций и их стратегии

Переход организации в категорию цифровых сопровождается принятием многочисленных архитектурных решений, своего рода «перебалансировкой»: в организации становится «меньше людей и больше ИТ» в виде систем, сервисов, роботов, ИИ, данных, интеграций. Такие компании-феномены, как Amazon и Alibaba, уже практически целиком состоят из элементов ИТ-домена: сервисов, API, ИИ и т. д. Данные в таких компаниях не просто представляют статистику или связку в потоке операций процесса, а являют собой новое качество, образуя цифровые двойники реальности, на основе которых можно принимать полноценные решения разных уровней и управлять объектами реальности силами ИИ.

Особенность стратегии ЦТ заключается в том, что при ее разработке необходимо обеспечить учет и контроль всех элементов, находящихся в фокусе стратегии, во всех архитектурных слоях. Принципы, цели, задачи, драйверы, стейкхолдеры, ограничения, нормы, показатели должны быть объединены цифровой моделью, то есть иметь свои цифровые двойники, связи и оцифрованные трассы влияния (цепочки зависимых влияний) друг на друга и на все остальные элементы бизнеса (архитектуры бизнеса). Вот несколько примеров того, как формируются требования в цифровой стратегии с точки зрения архитектуры.

Изменения настолько высокой сложности и комплексности, как правило, не происходят как скачок от A к Б, а включают множество промежуточных состояний (или плато). Более того, в настоящее время в сообществе РЦТ преобладает мнение, что трансформация — это не разовое мероприятие, а непрерывное: она продолжается, пока организация не прекратит существование.

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

В рамках TOGAF предлагается циклический метод трансформации ADM. ADM подробно описывает пошаговую итеративную разработку архитектуры и по существу является методом трансформации предприятия. ADM подчеркивает повторяемость шагов, связь между фазами и центральной деятельностью, пронизывающей все фазы, — управлением требованиями. Эта деятельность работает с любыми видами требований, особенно с требованиями новых функциональных возможностей. Контекст (бизнес-среда, рынок, конкуренция) изменяется раньше, чем завершается очередной цикл колеса ADM; появляются новые технологические возможности, требования регулятора, бизнес-модели.

Совершенство организации не достигается раз и навсегда — она находится в колесе непрерывных трансформаций.

В девятой версии TOGAF процесс ADM состоит из восьми основных фаз и одной предварительной (см. рисунок 5.6). Деятельность во время предварительной фазы направлена на выявление бизнес-требований к целевой архитектуре предприятия («как должно быть») и включает основные принципы, адаптацию методики под особенности предприятия и выбор средств описания архитектуры. Результат фазы — требования, которые находятся в центре рисунка 5.6. Эти требования могут меняться по ходу очередного цикла трансформации: их добавляют, изымают, переформулируют в соответствии с изменениями контекста организации по ходу трансформации, по мере появления новых технологических трендов или изменения экономической ситуации на рынке.

Фаза A
Архитектурное видение — начальная фаза цикла разработки архитектуры. Здесь описываются рамки процесса разработки архитектуры, определяются заинтересованные лица, формируется видение того, какой должна быть архитектура, и утверждаются видение и план работ.

Фаза B
Архитектура бизнеса — разработка бизнес-архитектуры, основанная на согласованном на предыдущем шаге видении архитектуры. Описание существующей бизнес-архитектуры и формирование целевой.

Фаза C
Архитектура информационных систем — разработка архитектуры данных и архитектуры приложений. Описание существующих архитектур данных и приложений и формирование целевых.

Фаза D
Технологическая архитектура — описание существующей технологической архитектуры и формирование целевой.

Фаза E
Исследование вариантов реализации архитектурных решений, предложенных для построения целевой архитектуры организации. Это база для начального планирования реализации, выбор возможных решений из имеющихся альтернатив с учетом ограничений.

Фаза F
Планирование перехода к целевой архитектуре — формирование последовательности подробных переходных архитектур и разработка плана миграции.

Фаза G
Управление построением целевой архитектуры и ее контроль — формирование системы руководства преобразованием архитектуры предприятия (implementation governance), предполагающая создание «Совета по архитектуре» и стратегии соответствия архитектуре, которая, в свою очередь, определяет правила оценки проектов.

Фаза H
Управление изменениями — процедуры контроля целостности всех преобразований в организации и управления ими.

Каждая из восьми фаз разбивается на подфазы и содержит перечень входных и выходных документов, средства для оценки этих выходов, требования к персоналу, участвующему в моделировании и построении архитектуры.