IT-Strategy321 — Введение

Архитектура следует за командами

Архитектура системы отражает коммуникационную структуру организации, которая её строит. Это не метафора — это наблюдение, подтверждённое десятилетиями практики (закон Конвея, 1967).

Практическое следствие: если команды фрагментированы — системы будут фрагментированы. Если команды изолированы — системы будут изолированы. Никакое архитектурное управление не преодолеет организационную структуру, которая лежит в основе.

Стратегия устойчивости — прежде всего решение в области организационного дизайна. Правильная структура команд — и архитектура следует. Инвестиции в архитектуру без внимания к структуре команд — потраченные впустую инвестиции.

95% операционных сбоев вызваны системой, а не отдельными людьми внутри неё (В. Э. Деминг — основоположник управления качеством). Когда терпит неудачу — корневая причина почти никогда не в человеке. Она в организационной структуре, которая сделала ошибку неизбежной.

«95% — это система. 5% — человек. Но увольняют всегда пять процентов.» — сказал ии-агент Довлатов

Оболочка: что это и зачем

Если архитектура следует за командами — что именно эти команды должны контролировать?

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

Ориентировочный предел — примерно 100 тысяч строк кода на модуль. Выше — начинает накапливаться непрозрачность, и кодовая база превращается в неуправляемое наследие, какой бы свежей ни была технология.

Этот слой развязывает внутреннюю деятельность от внешних и внутренних зависимостей. Когда поставщик меняет свой интерфейс или внутренняя система отказывает — воздействие локализуется на границе. Модули обмениваются данными без ожидания немедленного ответа: сбой одного не тянет за собой остальные. Рост — через размножение простых модулей, не через раздувание существующих.

Можно ли заменить любой внешний компонент без остановки бизнеса? А внутренний? Если ответ «нет» — оболочки нет.

«Ты думаешь, ты контролируешь систему? Если не можешь заменить любой компонент без остановки — система контролирует тебя.» — подумал ии-дух Сократа

Токсичный код — риск уровня правления

Оболочка работает, пока кодовая база сопровождаема. А что если нет?

Код, сгенерированный искусственным интеллектом — токсичная ипотека в мире программного обеспечения. Производится быстро, выглядит убедительно, взрывается системно.

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

Только команды, контролирующие полный цикл от разработки до эксплуатации, работающие с небольшой и полностью понятной кодовой базой, способны безопасно использовать ИИ. Это не вопрос политик — это структурное требование.

«Токсичные ипотеки тоже выглядели убедительно. Рейтинговые агентства подтвердили. Потом подтвердилось другое.» — сказал ии-агент Довлатов

Конкретные способности

Структурное требование звучит абстрактно. Вот конкретный список — без которых устойчивость остаётся декларацией:

Автономная работа без сети

Каждое бизнес-подразделение при поддержке своей команды способно продолжать ключевые процессы без сетевого доступа.

Наличные операции

Способность принимать и обрабатывать наличные платежи — постоянная операционная возможность.

Физическая устойчивость данных

Критические документы содержат двумерные штрихкоды со структурированными данными для автоматизированного повторного ввода при восстановлении систем.

Иерархия резервной связи

Внутренняя сеть, телефон, короткие сообщения, физический сбор в назначенных точках.

Отработка деградации

Тренировки отказа (уровень команды) и учения по деградации (уровень организации).

Протоколы для партнёров

Ключевые контрагенты имеют согласованные процедуры работы при сбоях.

Пять сценариев устойчивости из one-pager — отсутствие интернета, централизованного ИТ, платежей, потеря данных, кибератака — уже происходили. Вот шесть структурных требований, без которых большинство из них не пережить:

Чек-лист структурной устойчивости

1

Журналы, которые не может удалить или изменить ни один отдельный субъект, включая администраторов

2

Ключевые приложения, работающие без постоянного сетевого соединения

3

Каждый внешний интерфейс — зависимость и точка уязвимости. Сокращены до необходимого минимума

4

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

5

Команды, понимающие систему целиком — без зависимости от отдельных специалистов в изолированных группах

6

Собственная или открытая кодовая база — закрытый код, который организация не может проверить, это стратегическая зависимость

Сколько пунктов выполнено?

«Шесть пунктов, тебе проверить. Каждый непройденный — дверь, через которую войдёт хаос.» — подумал ии-дух Лао

Как это применяется

IT-Strategy321 не требует перестройки всей организации. Команда321 работает на операционном уровне. Иерархия выше может оставаться неизменной. Это не революция управления — это структурная коррекция на том уровне, где генерируется операционный риск.

Для организаций, работающих в нескольких юрисдикциях: распределение команд между независимыми организациями в разных странах — не только механизм организационной устойчивости, но и диверсификация суверенного и санкционного риска. Та же структура -321, применённая на уровне юрисдикций.

Первый шаг невелик: одна команда, одна зона ответственности, один внешний партнёр. Полгода. Расширяйте на основе фактов.

IT-Strategy321: Digital Last. Устойчивость — в первую очередь. С 1990 года.

Реализация: BizOpsDev / BizOpsVibe.

Что есть организация? — теоретический фундамент.