Сложно рекапить последнее выступление Марка Ланкхорста (видео, слайды), потому что идейно мы с ним очень близки, а BizzDesign дает реально лучший инструментарий для применения практики архитектуры предприятия. Поэтому я помещу тезисы его выступления в контекст и разверну один аспект, который он только слегка засветил на вебинаре.
Это выступление было в стиле data fusion, объединение различных источников в связный рассказ.
Источники идей, которые засек я:
Chess And The Art Of Enterprise Architecture, Blame the Mathematicians! by Gerben Wierda
What color is your backlog by Philippe Kruchten
The architect elevator by Gregor Hohpe
Software Architecture Guide by Martin Fowler
Центральный слайд вебинара, пожалуй, этот:
Но интуиция этого слайда некорректна, т.к. дальше невысказанной главной мыслью повествования идет "пункт назначения меняется за время путешествия". То есть лесенка справа должна вести не в ту же точку, что и слева. В текущем виде это выглядит просто декомпозицией большой цели. NI, not interested. Должна быть некая окрестность пункта назначения, которая и символизирует Эджайл. Ключевой метафорой тут является шахматный ход, когда мы не знаем конечной цели проекта автоматизации, мы лишь можем улучшить ситуацию на доске здесь-и-сейчас. Серия таких улучшений эволюционно удерживает предприятие в окрестности выживания, а не ведет к светлой цели, установленной всеведущим начальством.
Вообще, для разбирательства с идеями BizzDesign о том, как устроено проектирование и перестройка предприятия, надо вначале разобраться с понятиями Эджайла, которое противостоит GTD, getting things done.
Getting things done на русском означает "добиваться желаемого положения дел". Когда начальство говорит эту фразу, само собой разумеется что:
Начальство знает, как должно быть
Исполнители знают, как прийти в нужную ситуацию
Исполнители готовы взяться за работу под те ресурсы и ограничения, которые выставляет начальство
Планы в таком случае играют роль жестких обязательств - все понимают под чем подписываются и как будут отвечать по обязательствам. И отношения сводятся к контролю исполнения этих обязательств.
Для того, чтобы такая модель работала, ситуация на протяжении всего проекта должна отвечать следующим условиям:
- Область рассмотрения, домен, предметная область должна быть зафиксирована и концептуализирована
- Команда разделяет онтологии и использует их для планирования и исполнения планов
- Отношения между понятиями онтологий представляют существующие причинно-следственные связи и на эти отношения можно полагаться в достаточной мере при планировании
- Практики как в части дисциплин так и в части технологий достаточно стабильны на всем протяжении проекта орг.изменения, а модель жизненного цикла, включая базисы требований, архитектуры и проектных планов, можно зафиксировать на старте проекта, уточнить и пересмотреть в контрольных точках
- Постоянное обучение и пополнение знаний отсутствует, знания фиксируются в конце проекта, см. ту же Олимпийские игры и рабочие практики Оргкомитета, там все есть
Добавляем в эту исходную ситуацию, когда стороны договариваются кто что кому почему и когда, неопределенность. Начальство (Заказчик) не знает, что хочет, по крайней мере вначале. Исполнители не очень хорошо понимают как они все это сделают и кто им в команду нужен. Технологии меняются. Плюс, проект исполняется не в чистом поле, и не с молодежью, которая готова освоить любую новую онтологию и радостно ее применять, а на работающем предприятии, с опытными работниками, которые забыли больше, чем молодежь когда-либо знала. Фактор brownfield, горы неотрефлексированных рабочих практик, отлаженной и работающей бизнес-машины, которая не может измениться быстро. Она может эволюционировать. Здесь неприемлем Скрам, который требует, чтобы перестроились все, вплоть до совета директоров, здесь не работает SAFe и Less, но, наверное, взлетает канбан метод эволюционной перестройки либо директивный водопад.
И тут я думаю, что канбанисты и архитекторы предприятия переизобретают велосипед, который придумали социологи, которые занимаются Science and technology studies и изучают социологию повседневности через практики. См. краткий обзор Виктора Вахштайна про онтологический поворот (видео).
Собственно, мое текущее направление исследований про boundary objects, трансдоменные объекты, которое я начал после прочтения Architectural Coordination of Enterprise Transformation ровно про то, как вытаскивать интуитивное понимание предметной области в более-менее формализованном виде, достаточном для дальнейшей координации в режиме SAFe/канбан.
Чисто практически это означает, например:
- итерации архитектуры с учетом в Jira. В каждой задаче можно создать ветку архитектуры проекта, в которую входит как системная архитектура, так и корпоративная архитектура. Именно возможность менять архитектуру через трекер и есть эти самые маленькие итерации, которые показывал на слайдах Марк;
- последовательности собраний. Ветки должны попадать в meeting sequence, как минимум арх.совет (пн.), change approval board (вт.), project status review (ср.), результат докладываться спонсору/директору проекта;
- жизненный цикл объектов и отношений. Если мы говорим про постоянное обучение, то как отражать в модели это постепенно возникающее понимание? Как отделить догадку от сформулированной и подтвержденной гипотезы, как указать на микротеорию? У объектов и отношений должны быть соответствующие атрибуты - "внесен со слов стейкхолдера", "проверен по литературе (сопоставлен с дисциплиной)", "операционализирован", "подтвержден(-а"", "опровергнут(-а)". У объектов и отношений должен быть владелец, автор, кто носит полные знания об этом куске модели реальности, у кого можно спросить, что же имеется в виду.
Выводы:
Корпоративная архитектура понемногу адаптируется к изменившейся реальности бизнеса, приближает свои методы к более работающим. Идет довольно широкая дискуссия по границам ее применимости и этот доклад обрисовывает текущее понимание сообщества о роли и месте практики архитектуры предприятия в процессе орг.развития.
Комментариев нет:
Отправить комментарий