Несколько замечаний о корпоративной архитектуре

По примеру старших товарищей я решил сделать в блоге обновляемое сообщение. Я периодически буду возвращаться к этой заметке, что-то добавлять, что-то вычеркивать, а еще что-то переписывать заново. Если изменения будут существенными, то я стану поднимать это сообщение вверх и повторно размещать ссылку на него в соц.сетях и не буду этого делать при незначительных изменениях. Тема, о которой пойдет речь, может быть озаглавлена «Роль ИТ-архитектора в организации», как это было сделано в одной из презентаций (см. https://www.slideshare.net/MxSmirnov/ss-31232067) или Когда, кому и зачем нужна Архитектура Предприятия, как в одноименном из сообщений этого блога.

В общем, моя цель собрать некоторые характерные особенности деятельности корпоративного архитектора, которым уделяется недостаточное внимание в разного рода методиках, подходах, статья и агитационных брошюрах о корпоративной архитектуре. Тем более, что я обещал это сделать в группе «Архитектура ИТ-решений» в Telegram https://t.me/itarchitect, когда мы обсуждали, делать ли следующий вебинар про микросервисы или об архитектуре предприятия.

Не знаю, когда удастся провести очередной вебинар, но некоторые свои соображения об обозначенной теме предлагаю для вашего обсуждения прямо сейчас. Итак,

Вводное замечание о моделировании. За десятилетия существования архитектуры информационных систем придумано много вариантов использования архитектурных картинок. Но наиболее убедительными, на мой взгляд, являются соображения, изложенные в разделе «Системное мышление» описания Large-Scale Scrum.Там даже раздел есть, озаглавленный: The First Law of Diagramming: Model to Have a Conversation. Мы рисуем свои картинки, чтоб их рассказывать. Диаграммы помогают нам более внятно изложить своё сообщение, а нашим слушателям не заблудиться в лабиринте обрушиваемых на их голову рассуждений, важных или не очень деталей, нюансов и смыслов.

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

Второй, не менее важный момент заключается в предмете обсуждения. Большинство нотаций моделирования значительно лучше описывают концепции, чем факты. Рассмотрим простой пример(см. рисунок ниже).

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

Конечно, порой бывает, что нам надо друг с другом обсудить ту или иную концепцию. Делается это обычно в непринужденной беседе за чашкой кофе. Но в современных организациях(к сожалению), управлению отводится намного большая роль нежели обучению. Нам чаще приходится рассказывать не о том, как что-то устроено, а предоставлять(руководителям) информацию о конкретных фактах (случившихся или не случившихся) и планах. Изложение концепции в такой среде будет скорее воспринято, как неуместное желание поучить начальника уму разуму. И даже при обсуждении технических аспектов управленцев больше волную вопросы кто виноват и что делать, а не понимание того, как это работает.

Таким образом, архитектору предприятия намного чаще надо излагать факты, визуализирую их в простой и наглядной форме. Для это задачи традиционно использовались совершенно другие методы: документы с большим количеством нумерованных списков, сносок и примечаний, многостраничные электронные таблицы, с перекрестными ссылками, а вовсе не архитектурные эскизы. Но кто из начальников любит читать документы или изучать таблицы? Даже численные данные они предпочитают потреблять в форме графиков. Запрос к архитектору предприятия часто формулируется схожим образом: дай мне картинку, из которой я сумею быстро увидеть ответ на вопрос, который я пока даже не сформулировал. С таким положением дел бесполезно бороться. И оно не должно вас расстраивать, огорчать или злить. Лучше принимать его как некую данность и заранее вооружится простым набором рекомендаций:

  1. Не приступайте к рисованию архитектурных картинок, не собрав архитектурное досье – набор из десятка коллекций, включающих от 5 до 20 объектов (связанных друг с другом некоторыми отношениями). Если в организации имеется архитектурный репозиторий, то это будет заметным подспорьем, если нет – сойдет и пара экселей.
  2. Используйте эти данные для рисования не одной, а целой серии картинок. Сбор информации дело не быстрое и непрерывное и если его проводить под каждую картинку снова и снова, то скорость их разработки будет невелика. Тем более, что часто мы не знаем кому и зачем нужна та или иная картинка и как она будет использоваться.
  3. Не стесняйтесь лишний раз спросить зачем нужна та или иная картинка и для чего вы потратите свое время на сбор материалов и рисование. (Сам постоянно испытываю неловкость задавая этот вопрос)
  4. Когда предмет дальнейшего обсуждения более-менее понятен, все равно сделайте несколько картинок (слайд-шоу), демонстрирующих развертывание событий. Разбрасывайте на своих слайдах ландшафтные карты подобно тому, как это делает гадалка с картами Торо: что было, что будет, чем дело закончится и т.п.
  5. Пишите на рисунке всё, что собираетесь сказать. Используйте для этого объекты диаграммы, сноски, комментарии. Ситуация может сложится так, что возможности прокомментировать диаграмму у вас просто не будет. Кто-то возьмет вашу картинку и отдаст её кому-то другому, а тот в свою очередь будет долго гадать, что хотел сказать автор. Напишите на каждой диаграмме своё имя и телефон, ссылку на страницу этой конкретной диаграммы в корпоративной wiki. Архитектура – это внутрикорпоративный сервис, такой же как заявки на ИТ-услуги или управление изменениями. К нему применимы все процессные подходы ITSM. Я даже позволю себе использовать неологизм архитектуризация (architecting), введенный в ГОСТ Р 57100. Звучит не очень, но из-за этого может быть лучше запомнится.

Резюмируя, архитектура предприятия в значительно большей степени оперирует не классами, а объектами(фактами). Архитектурные диаграммы – это не наборы знаний/данных, а образы вашего архитектурного репозитория, репрезентации, представления, заведомо неполные и, как правило, вырванные из контектса. Их разработка и сопровождение – это самостоятельный процесс. Измерять его надо не количеством изготовленных картинок, а числом обращений и связанными с этим метриками.

И еще одно замечание. Сформулировав тезис, что основная задача архитектурных диаграмм – поддерживать conversation, мы должны понимать не только плюсы, но и ограничения такого вида деятельности. Совместное обсуждение историй имеет свои проблемы, особенно когда обсуждение строится «с чистого листа». Так, например, мы часто обсуждаем не те аспекты информационных систем, которые следует обсудить, а те, которые хорошо знаем. Метод свободных ассоциаций (рисую о системе то, что вспомню), оставляет за бортом обсуждения бОльшую часть знаний и может сложиться так, что ответ на сегодняшний конкретный вопрос лежит именно в них. Другая проблема в том, что разговоры и картинки – это контент, а не цифра, что создает существенные сложности для их обработки компьютерами и программами. Знания быстро устаревают, забывая нас об этом предупредить посредством соответствующих нотификаций.

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

Несколько замечаний о корпоративной архитектуре: 3 комментария

  1. Очень верное наблюдение. Я бы сказал, что корпоративные пользователи имеют очень низкий уровень абстрактного мышления (их этому не учат, потому что оно “функциональным” людям не нужно).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *