2024-11-05: ArchDays - заглянуть в корпоративную архитектуру

Короткая ссылка: ArchDays-2024

Ссылки сюда (3) →

О других конференциях

Участвовал и выступал в конференции ArchDays-2024, которая собирает доклады о работе с архитектурой в крупных корпорациях, и соответствующую аудиторию. Темой этого года была архитектура предприятия, но доклады не ограничивались этой темой. Как и в прошлые годы организация была на уровне, помимо докладов шел активный нетворкинг, в который площадка — гостиница Украина — привносила свой колорит.

Доклады и обсуждения позволили мне сформулировать несколько интересных тезисов об архитектурной работе, и вынес их в начало отчета. Дальше — кратко о моем докладе и всех остальных, в том порядке, в котором я их слышал. По содержанию я хочу отметить доклад Максима Смирнова про architecture vision, Филиппа Дельгядо про конфигурации и Дениса Свеженина про визуализацию стратегии, но это — моя личная оценка. Еще отмечу, что на конференции было 4 параллельных трека, так что я заведомо слушал не все.

Об архитектурной работе

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

1. Архитектор должен быть деятелем и созидателем, а не трусом, который борется со страхами.
2. Capability map — методика, по которой ты собираешь гардероб не под ситуации своей жизни, а опираясь на журналы о светской жизни
3. Бизнес уверен, что ИТ — всемогуще, поэтому не зовет их обсуждать бизнес-инициативы: зачем, ведь они любую задачу выполнят.

1. Архитектора логично представлять созидателем и деятелем: он создает архитектуру, а затем — воплощает ее в материале. Но это — ответственная позиция, она требует принимать решения и отвечать за них. Она точно не подходит для консультантов, которые хотят получать деньги, но не нести ответственности. Думаю, стараниями консультантов позиция деятеля превратилась в позицию труса, который оценивает различные решения для предотвращения несчастий и минимизирует страхов, политкорректно называемых рисками.

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

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

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

2. Развивая эту тему — методика capability map, которая звучала не только в докладах, но и в обсуждениях в кулуарах. Здесь хорошая аналогия — создание своего гардероба. Многим известна ситуация, когда девушка говорит «у меня два шкафа одежды, а одеть на эту на эту встречу нечего!». У мужчин это тоже бывает, но в другой ситуации, когда друзья зовут на природу в не очень комфортную погоду. При этом «купить все» — невозможно, вещи. как правило покупаются по одной. И перед началом очередного сезона или при планировании отдыха возникает задача: выбрать чего не хватает, или что уже пора менять — и купить это. Желательно оптимизировать общую стоимость. По-моему, эта задача очень напоминает задачу развития ИТ-ландшафта, как ее описывает capability map.

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

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

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

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

Так реально когда-то было, сейчас — не так, ИТ часто ограничение бизнес. Но как признать конкретному CIO? Ему же скажут, что это он лично — ограничение, а не ИТ, что его заменят. Да и в целом идея выгодна для ИТ.

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

Ну а еще такой подход позволяет бизнесу не углубляться в ИТ. B наоборот, ИТ не слишком погружается в бизнес, также, кстати, как и в методике capability map.

Максим Цепков. Бизнес и софт как единая система: описываем архитектуру предприятия

Мой доклад Максим Цепков. Бизнес и софт как единая система: описываем архитектуру предприятия () был посвящен часто встречающемуся разрыву между ИТ и бизнесом и способам его преодоления. Разрыв имеет исторические причины: эту границу провели, когда в ИТ применяли методы организации, основанные на разделении труда. Эпоха RUP ушла в прошлое, а учебники — остались. Ну и концепция разделения труда сама по себе носит общий характер, она близка и бизнесу и ИТ. В докладе был системный взгляд на конструкцию сопряжения ИТ и бизнеса и обзор разных методик и способов преодоления разрыва, иллюстрированных конкретными примерами из моего опыта. Материала получилось многовато для одного доклада, так что для проработки надо взять презентацию и искать материалы. В чем-то замысел был именно такой: описаний конкретных методик — много, мне важно было показать big picture и выделить концептуальные моменты. Хотя я понимаю, что объем материала не позволил погрузиться темпе доклада. Мне приятно, что в отзывах опытные участники отметили, что даже для них в докладе были ценные мысли, а повторение — мать учения.

Максим Смирнов. Где проходит граница изменения

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

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

А самое интересное происходит раньше, когда идет обсуждение, что делаем, а что — нет. И зачем это делаем. На этом этапе не только отсутствует архитектор. Часто сам этот этап не определен, его результат не визуализирован, эти работы не видимы. И даже если архитектора позвали, эти работы скрыты, а у скрытых работ нет естественных хищников, которые ограничивают их рост. Поэтому значительная часть инициатив не превращается в изменения.

Впрочем, я полагаю, что представление о произвольности принятие решений бизнесом — проявление mindset рационального планирования деятельности, свойственного многим архитекторам. А бизнес часто живет не по плану устойчивого развития. он ставит эксперименты и проверяет гипотезы и это — совершенно другой mindset. Но часто в формулировке задачи акцент эксперимента уже отсутствует. В результате у тех. кто привык жить по плану ощущение, что задачи от бизнеса произвольны. Хотя, так тоже бывает, есть три варианта: делаем по плану, ставим эксперименты и делаем что-нибудь, и не надо путать второй и третий.

Описание процесса с самой начальной стадии были в работе Leffingwell 2011, там старт — от problem solution needs за которым следует evaluation, есть еще работы. Но их — мало. А ранее была ромашка TOGAF. И она — не про осуществление изменений, кроме последних стадий, она как раз про этапы принятия решений: выявление разрывов и постепенное проектирование.

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

Если проектов изменений много, то логично не рассматривать каждый из них изолированно. Надо взять все что делаем и будем делать, и нарисовать roadmap, желательно на одном листочке. И рассматривать все изменения не вдоль отдельных треков. а поперек, собрать вместе многослойку business — data — application — technology. И это можно будет оптимизировать.

Но это — работа архитектора уже после принятия решений, по совокупности проектов. Работа в целом описана. А вот до нее есть две фазы: preliminary — то самое скрытое обсуждение, и architecture vision, когда вчерне вырабатывается способ решения.

Шаблон Architecture vision.

1. Назначение документа. Максим полагает, что это — неважная формальность, а я не согласен. Именно назначение документа часто теряется, получается громадный документ, который растет и растет и не пригоден ни для одной цели.
2. Постановка задачи (описание проблемы) из двух частей.
   1. Стейкхолдеры, цели, проблемы, ограничения.
   2. business vision
3. Описание решения
4. Набор представлений value chain
5. …

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

Задача корпоративного архитектора — собрать в architecture vision из отдельных представлений стейкхолдеров целостное изменение. Требования стейкхолдеров часто противоречивы и архитектор каким-то образом это урегулирует. Организации обычно хотят трех вещей: понимать, что хочет клиент; быстро это реализовывать (TTM); тратить на это не очень много денег.

Architecture vision — про один трек изменений. Но дальше мы объединяем изменения в roadmap, и при этом отдельные треки расщепляются и объединяются. Зачем расцеплять большие изменения? Можно реализовывать части независимо и быстрее, движение шагами снижает риски, можно проводить изменения независимо и так далее.

Зачем объединять изменения и рассматривать их совместно? Можно получить дополнительную ценность. Нужно учитывать все изменения, которые совместно используют уникальный ресурс, например, рассылка клиентам должна быть ограничена по общему числу писем на клиента. Нужно обеспечить концептуальную целостность — противоречия есть не только в представлениях стейкхолдеров об одном треке, они есть между треками и их тоже надо как-то урегулировать. Есть оптимизация затрат. А еще важно снижение когнитивной нагрузки: вместо 100+ отдельных проектов мы получаем 1-2-3 крупных проекта, и это важно для объяснения всей организации.

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

Есть много вариантов описания фаз изменений, Максим привел лестницу Бена Ханта потребности:

1. безразличие — мы не знаем, что надо меняться
2. осведомленность — мы знаем о необходимости изменений, но не знаем как это сделать, ищем варианты
3. сравнение вариантов
4. выбор решения
5. инициация изменений

Границы изменений — важны. Они определяют ценность, сложность, риски. Корпоративная архитектура предлагает подход к этому. Но это — процесс, а не формула. Конкретное решение определяется ситуацией

Архитекторы не примут решения что делать. Они собирают решения в ADR. И дальше как-то делают сочетание и приоритеты. Я тут отмечу, что приоритеты часто и означают принятие фактического решения, через них происходит перехват управления. Я видел много ситуаций, когда какие-то проекты много лет стоят на 3-4 месте — и не двигаются, хотя бизнес все надеется, что ситуация изменится.

Денис Свеженин, ЛЕНТА. Стратегия автоматизации или автоматизация стратегии?

В докладе был рассказ про dashboard стратегического взгляда на бизнес-инициативы, который дополнен одной важной фичей: из него можно получить набор слайдов в удобном для руководства виде. Это важно, так как со стратегией работают именно через презентации.

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

Это было сделано год назад, к годовой проектной компании, информация для карточек была собрана вручную и дальше карточки компоновались на слайды. Опыт был признан удачным, в этом году руководство решило повторить форму, а ИТ решило, что не хочет две недели заниматься только сборкой презентаций. И поэтому решили автоматизировать. Исходные данные были — в бюджетной системе и в системе ведения проектных инициатив, их требовалось связать через набор справочников, вытащить и показать в нужном формате. И, главное, дать возможность экспортировать как набор слайдов, указав при этом нужные фильтры. Sharepoint + .Net + OpenXML + react. Сделали быстро, и теперь оно работает и как dashboard и как генератор презентаций целевых — для бюджета, акционеров и так далее.

Александр Войновский, Газпром нефть. Корпоративная архитектура. Buy or Build: способы оценки архитектуры

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

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

Проблема в том, что готовых систем — много. Есть отчеты Forrester и Gartner — там лидерский софт, его немного, но он дорог и далеко не всегда адекватен. А если мы идем дальше, то получаем каталоги и реестры, где тысячи и миллионы программ, и как из них найти подходящую — неясно. Для западного софта есть olive — инструмент автоматизированного выбора buy or build, вы поставили галочки на функционал — и вам выбирают лучшее решение. Но он не знает российского софта, и, в любом случае решение надо проверять.

Для отбора по функционалу есть техника capability map: ты выписываешь функциональные возможности. которые требуются, а потом — покрываешь их софтом в разных вариантах. Но дальше эти варианты надо сравнивать, выбирать лучший.

Полезно, если в компании есть инфраструктура для апробации, в которой можно развернуть кандидатное решение и посмотреть. Хотя увидеть можно не все. Если решение типовое — то там процедура понятна: ТЗ, тендер и оценка. Но вот как быть, если у нас есть альтернативы, включающие собственную разработку?

Вот здесь и начинается работа архитектора, который должен оценить и сравнить решения. И дальше был рассказ про методики SAAM, ATAM, Architecture evaluation framework в ISO 42030 2019, который «почти TOGAF», как сказал спикер. Я тут отмечу, что TOGAF появился на 20 лет раньше, в конце 1990-х, впрочем он развивается и могла подразумеваться последняя версия. Там качество расширено, рассматривается не только проектирование системы, но и взаимодействие с ней, например, удобство использования. которое. впрочем, практически невозможно оценить на этапе проектирования.

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

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

При этом методология такова, что она абстрагируется от реальных нужд бизнеса. Например, доступность. Конкретно бизнесу нужно, чтобы у него проводились критические операции: платежи шли, фуры на складе разгружались и загружались, магазины работали. Операционка всегда ограниченный набор сценариев. Разумные требования по конкретным сценариям заменяются требованиями на доступность 99 % в течении года, подобно тому, как реальные требования на разумное время отклика системы меняют на отклик системы в течении 2 секунд на 90 % запросов, которое не имеет бизнес-оснований. И это тоже сделано сознательно, потому что консультанты не хотят разбираться в подробностях конкретного бизнеса.

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

Впрочем, это — некоторое преувеличение, это не значит, что методики — бесполезны. Они указывают на риски, и полезно, если такой анализ проводится в ходе проектирования. Отмечу, что у нас в компании в свое время был опыт использования ATAM для оценки, Игорь Беспальчук рассказывал о нем в 2016 (презентация, видео). И действительно, анализ обнаружил полезные и интересные вещи. Но в целом метод в широкое использование не пошел, потому что главное — не предотвратить риски, а достичь цели, при этом оценка показала, что в целом качество является приемлемым, а выявленные проблемы — не принципиальными, при том. что конкретный проект был репрезентативным для компании.

Дальше Александр сказал, что такие компании, как ThoughtWorks используют сильно упрощенные методики. И у них, в в Газпром нефть тоже действуют проще. Какие аспекты они рассматривают?

• Информационные потоки. Сложность и окружение системы.
• Интеграция бизнес-систем — drill down
• Сетевое взаимодействие — еще один drill down.
• Технологическая архитектура: техстек, аппаратные платформы — они определяют доступность сервиса, сетевая инфраструктура
• Архитектура информационной безопасности, тут много атрибутов — перс.данные, коммерческая тайна и так далее. И инструменты.
• Требования к целевой технологической архитектуры: размещение, тип платформы, тип сервера и так далее.
• Требования к каналам связи — пропускная способность, загрузка, пользователи.
• Типы лицензирования.
• Импортозамещение
• Матрица рисков и сценарий снижения по каждому риску.

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

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

Филипп Дельгядо. Конфигурация и кастомизация в энтерпрайзе

Бизнес-конфигурация — это способ переложить часть разработки на пользователей для того, чтобы обеспечить быстрые изменения. Пример: выбор эквайринга, который осуществит конкретный платеж, для платежного шлюза. Там надо сравнивать условия комиссий, при чем они могут быть сложными, например, банки могут уменьшать комиссии при расчетах по своим картам, комиссия может зависеть от общего объема операций, влияет страна плательщика и тип карты и многое другое. А еще правила достаточно быстро меняются, иногда несколько раз в день.

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

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

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

Основной сценарий: изменили правила, например, по расчету комиссий или назначению скидок, на тестовом стенде, протестировали, что комиссия такая, как хотите, перенесли на продакшн — и оно заработало. Проблема в том, что протестировать могут только на ограниченном количестве простых случаев, а в сложных случаях может сработать неожиданно, например, взять большую комиссию или дать скидку 90 %, которую вовсе не ожидали те. кто настраивали правила. А в некоторых случаях — вообще сломать систему.

Как делать конфигурацию? Кажется, что для этих целей можно ипользовать конфигурационные файлы в git, используя какой-нибудь json, и обеспечивая пронос в рамках конвейера CI/CD. Проблема в том, что те, кто хотят настраивать бизнес-конфигурацию — не хотят работать в git. Им хочется на тестовом стенде поправить и нажать кнопочку. Бухгалтерия и операционный отдел точно не будут работать в git.

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

Отдельный вид конфигурации — локализация. Ее тоже сначала надо проверять на тесте, потом нести на прод. При этом программистам удобно словари для локализации вести распределенно, привязывая к фичам, а переводчикам удобно работать с одним большим файлом. И тут нужен pipeline, по которому собирается то. что требует перевода, передается переводчикам, а потом проносится на сервера. И обработка исключений: как система работает, когда конкретной локализации еще нет, а она уже нужна — тут могут бть правила выбора языков для замены.

Следующая вид конфигурации — правила валидации объектов. Они тоже сложны и меняются. Например, если пользователь из России — нужен паспорт. Но, возможно, не сразу, а для определенных действий. А для других действий нужен телефон. Кроме вадидации могут быть умолчания, например, страна — сразу Россия. И тут уже используется движок правил или декларативные описания: doors, json или xml, groovy или lua или kotlin.

А дальше возникают сценарии: создавать связанные объекты, например, открывать счет клиенту, или писать фрагменты бизнес-логики, например, маршрутизацию платежей, а не просто выбирать эквайера. И тут появляются навороченные правила, практически мини-программы. Но! Правила не безопасны и сложны, их надо отлаживать! Получается что сотрудник бухгалтерии — чуть-чуть программист — а это сложно. И это код: JavaScript, Lua, Groovy, Kotlin.

Kotlin хорош тем, что JVM компилируется, а это значит заданная в правилах бизнес-логика выполняется быстро и может использоваться массово. Но в коде можно ошибаться гораздо больше, чем в правилах: можно написать цикл, или включить функциональность, которые нарушит параллельность обработки. Поэтому сценарии желательно смотреть разработчикам.

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

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

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

Что нужно, чтобы реализовать конфигурации?

• Сервис конфигурации для распространения. Это кажется нарушением ограничений домена, но реально там доменной специфики меньше. Но внутри есть смысл делить по доменам.
• Нотификация. kafka, pooling, long-pooling. Сервис должен узнать об изменении
• Хранить. И редактировать в текстовых файликах. json,БД. Доступ из yaml
• Управлять версиями. Целиком, для доменов, применять, накатывать и так далее
• Отложенное применение — создают и тестируют заранее, а включают потом
• Загрузка из внешних источников, например, справочники из регуляторки.
• Редактор конфигурации — из метаданных и разметку.

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

• тип стенда
• фича-флаги
• большие справочники — БИНЫ ГАР/ФИАС/КЛАДР — логически это конфигурации, но их объем требует специальных действий при переносе.
• календари — рабочие дни, банковские дни
• курсы валют

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

Что помогает обеспечить устойчивость?

• Замкнутость. Ссылаешься на объекты конфигурации. Нельзя подставить номер клиента или вид договора.
• Техническая валидация YAML.
• Логическая валидация в контексте. Нельзя на уровне редактирования, надо прогонять тесты. Часто end2end
• Валидация всего продуктов, не только отдельных сервисов.
• Валидация по истории: меняем тарифы и прогоняем прошлые операции — что изменится, будет эффект или нет. Это — отдельный стенд.
• Пользователи стали разработчиками — нужен деплой вокруг них.
• Работа с ошибками. Когда сервер видит неверную конфигурацию — работает с предыдущей. Надо уметь отключать: вы испортили правила выбора эквайринга — включили использование первого, путь неэффективно, но платежи идут
• Всеобщий аудит и логирование.

Можно ли исправить сразу на проде? Нет, нельзя. Хотя иногда можно разрешить — пусть наступят на грабли.

Если конфигурации используются активно, у бизнеса возникает вопрос: а зачем теперь программисты? Это надо объяснять: развивать и обеспечивать надежность. Опыт показывает. что через некоторое время пользователи осваиваются с имеющимися конфигурациями и появляется поток запросов на доработки. Для тестирования конфигураций и настроек нужны тестовые стенды, приближенные к пользователю — чтобы он мог проверить свои правила на бизнес-кейсах. И ему надо не только поправить правила, но и добавить тестовые данные, и это надо не потерять.

По созданию конфигураций нет практик, часто делают на коленке, а потом живут. Поэтому лучше сразу понимать, что никуда не делать и проектировать.

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

В заключении я хочу сказать, что действительно, конфигурации в том или ином варианте встречаются очень часто. Мы их делали во многих системах, в некоторых объем конфигурирования был очень значительным и включал атрибутный состав и настройки интерфейсов, в других были калькуляторы со сложными правилами. А когда-то давно, в конце 90-х мы сделали АБС банка, где вся бизнес-логика описывалась за счет правил, и в задумке было, что настраивать это будут бизнес-технологи. Но, помимо устойчивости работы, проблемой является сложность настройки. В АБС передать настройку бизнес-технологам заказчика так и не получилось, они предпочитали ставить задачу нашим аналитикам, но те ее выполняли без разработчиков. Поэтому мы всегда следим при проектировании за сложностью настройки. Однако, тут тоже бывают промежуточные варианты: опытный пользователь настраивает систему отчетов, через механизм. который позволяет делать очень сложные запросы. а далее — делится ими с коллегами или подчиненными, обучая пользоваться готовым. То же самое возможно с шаблонами документов. И это тоже надо проектировать, оценивая уровень групп пользователей.

Евгения Умен из AB digital. Революционный refresh. Рефакторинг клиентского домена и долгий путь к балансу

AB Digital — технологический центр Ak Bars Банка. А в докладе был рассказ о том, как проектировали изменение архитектуры ИТ-ландшафта клиентского домена. Основная задача — Customer Data Platform. Для этого были зарубежные решения, которые ушли с российского рынка, и готового решения — нет. Но есть идея, что его можно собрать из нескольких, при том, что часть функционала может взять на себя MDM и CRM — границы между системами являются подвижными. При этом эти системы тоже подлежали замене. А требований к функционалу — нет, банк развивается, и в нем реализуется ряд бизнес-инициативы, которые эти требования формируют в некоторой перспективе, однако в моменте их никто не расскажет.

Путь, который они прошли, включал следующие этапы? которые описаны достаточно подробно: вход, выход, содержание этапа. И примеры. И если у вас — аналогичные задачи, то можно пойти этим путем.

1. Погружение. Вход — стратегия 4-6 лет, на выходе — получить карту l-1. Сложность в том, что стратегия меняется, а домены — разнородны. Примеры инициатив: привлечение лидов, геймификация, работа с согласиями клиентов, сегментация клиентов, rtm — предложения в реальном времени, работа с хабами лидов и купленными базами и так далее. При этом работа с согласиями, например, требуется во многих инициативах, есть много другого общего функционала.
2. Тепловая карта требуемого функционала, часть его уже поддержана в существующих системах, хотя этот функционал может и не использоваться. Были выделены сегменты, для которых поддержки нет.
3. Анализ референсов: на входе — тепловая карта, на выходе — подобранные классы решений. Тут сложность, что Customer Data Platform — новый класс решений, для него не было квадратуры Gartner, решения описаны плохо и зависят от масштаба. А для развитых классов, таких как CRM, есть разветвленная классификация блоков функционала — lead management, customer engagement, sales automation, и одни решения дают весь функционал, а другие — лишь частично.
4. Тепловая карта покрытия сейчас. Подобранные классы решений — сопоставляем с текущими решениями. Где есть провалы, где функционал находится «в другом месте».
5. Кровавый enterprise. Детальный разбор с системами, который выполняют «чужой функционал». Например, в CRM начали заводить нецелевые заявки, без документации, и неясно — что там есть. На мой взгляд, это обычная история: бизнес приспосабливает существующие системы для своих потребностей как может, он не ждет, пока ИТ принесет ему счастье, и делает он это поперек архитектуры. А для ИТ это риски при замене системы — выясняется, что новая, «правильная» система, на такой функционал не рассчитана.
6. Проработка вариантов целевой архитектуры. Вендора как навигация. Вендора хорошо рассказывают, но долго, 2-3 месяца. И дальше — частные архитектурные развилки. Хочется посмотреть референс, но это не всегда есть. CDP: есть две архитектуры, можно делать так или иначе, полностью ни одно не удовлетворяет. MDM — еще больше вариантов: разные виды потоков и потребление, нужен ли обратный поток — развилки.
7. Architecture vision. Собираем пазлы и развилки. И там еще выясняется объем кастомизации и ее стоимость. Каждый вариант прорабатывался до полноценного ландшафта. И референсы — где и как. Для одной из систем выбрали вариант из телекома, а не от федеральных банков, потому как он оказался сильно дешевле. Все варианты — микс коробочных решений. Собственная разработка — дорого и нет ресурсов.
8. Управление изменениями. Частные архитектурные развилки дают целевую архитектуру, ее презентуем бизнесу. Драфт целевых архитектур. Это долгий этап. Подумать, потом еще подумать. Я бы сказал. что это пока не управление изменениями, а их проектирование и презентация бизнесу.
9. Формирование transition-архитектур — проработка частных переходов. Там будет много вариантов и подробностей, будет идти.

Архитектурные зависимости проектов и блоки для проектов. И после этого можно считать, что discovery закончен, можно идти в delivery.

На мой взгляд, в целом — понятный процесс. Но я бы хотел обратить внимание на фазы работы с тепловыми картами покрытия, особенно на выделение функционала, который есть, но локализован в «неверной системе». Надо понимать, что нет никакого идеального разделения функционала между системами. А то, что появляется в отчетах Gartner и аналогичных — результат борьбы крупных вендоров за продвижение своих продуктов. Одни вендоры говорят о комплексном продукте, другие — берут себе узкую нишу, отчеты это как-то показывают, но при их составлении интересы вендоров тоже играют свою роль. Кстати, новые квадранты тоже появляются как результат работы вендоров над продвижением своих продуктов. И если мы некритично переносим это на наш ИТ-ландшафт, полагая правильны, то мы, фактически, начинаем для себя примерять одежку, сделанную по чужой мерке и для чужих целей. Так что тезис о том, что какой-то функционал у нас неправильно расположен, потому что в каких-то рыночных решениях он в другом месте, является ложным аргументом. Здесь правильно привлекать чисто архитектурные соображения, например, структуру интеграции при разных вариантах решений, или удобство работы пользователей — надо ли им использовать один продукт, или придется работать в нескольких.

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

Павел Кан, Ensi. Поиск рабочего компромисса между стройной теорией и заковыристой реальностью: архитектурные практики в гибридных командах с продуктовым подходом

Если кратко, то доклад о переходе от функциональных команд к кроссфункциональным продуктовым и организация архитектурной работы в этих условиях. Наиболее интересное — что архитектурная работа распределена по командам, нельзя делать единый архитектурный отдел. Потому что архитектура — не просто утверждение «правильно делать микросервисы». Это соглашения внутри команды, которыми все придерживаются. И если сделать отдельный отдел — соглашения не будут соблюдать. У них на старте был опыт концентрации архитектуры в отделе аналитики (там принимали финальные решения) — и они видят, что это был негативный опыт.

А теперь — подробнее. Ensi — платформа и сервисы для екома. Их партнеры — Ашан, с ними надо запустить новые процессы и сборки и доставки. В 2020 в Ашан вообще не было онлайн, сейчас 10 %. ИТ-ландшафт отстает от организационной структуры, бизнес меняется быстрее.

Были функциональные команды и 2-недельные спринты. А в 2024 привлекли ScrumTrek и перешли на продуктовые команды, в которых есть заказчики из Ашана, а но только ИТ. И отдельная команда разбирает бэклог технического долга. При этом кодовая база осталсь общей, в сервис Каталога может вносить изменение несколько команд — листинг, карточка команд, они могут конфликтовать или создавать регресс.

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

Кросскомандная структура — platform из техлидов, которая наблюдает за процессами. В обязанности — не только доработки и конфликты, но и обслуживание платформы. Платформа — единый процесс ci/cd, логирование и так далее.

Продуктовые команды тоже дифференцируются. Например, разделилась команда маркетинга и ecom. Маркетинг — большие задачи. А ecom улучшает CJM покупателя на сайте, и это можно делать мелкими задачами.

При любой трансформации возникают конфликт. Было отдельно команда подрядчика и бизнеса, их Объединили в одну команду. У людей сильно разный опыт, каждый начал тянуть в свою сторону. Надо управлять конфликтами, чтобы они давали пользу бизнесу. Повышение производительности — результат такого конструктивного спора.

Когда говорим про архитектуру, часто пренебрегаем политической составляющей. У бизнеса — примитивная дихотомия: за две недели и потом все переделать или делать долго дорого. Принимают первое. А дальше на долг смотрят негативно — тут мы срезали. А надо смотреть позитивно, в том числе закладывая туда реинжинириннг. Бизнесу позитив в долге — мы бежим быстрее, и понимаем связанные риски до того, как начинают стрелять. И сейчас собрали отдельную команду под долг. Договариваемся, и уже есть позитивные эффекты: производительность сайта — сразу дала конверсию.

[ Хронологический вид ]Комментарии

(нет элементов)

Войдите, чтобы комментировать.

— Максим Цепков • 00:30, 5 ноября 2024 • нет комментариев