Изменения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблон Architecture vision. # Назначение документа. Максим полагает, что это - это — неважная формальность, а я не согласен. Именно назначение документа часто теряется, получается громадный документ, который растет и растет и не пригоден ни для одной цели.# Постановка задачи (описание проблемы) из двух частей. ## Стейкхолдеры, цели, проблемы, ограничения.

# Набор представлений value chain # ...…

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

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

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

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

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

Есть много вариантов описания фаз изменений, Максим привел лестницу Бена Ханта потребности: # безразличие - безразличие — мы не знаем, что надо меняться # осведомленность - осведомленность — мы знаем о необходимости изменений, но не знаем как это сделать, ищем варианты # сравнение вариантов # выбор решения

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

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

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

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

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

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

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

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

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

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

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

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

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

Впрочем, это - это — некоторое преувеличение, это не значит, что методики - методики — бесполезны. Они указывают на риски, и полезно, если такой анализ проводится в ходе проектирования. Отмечу, что у нас в компании в свое время был опыт использования ATAM для оценки, Игорь Беспальчук рассказывал о нем в 2016 ([https://speakerdeck.com/custis/opyt-primienieniia-mietoda-atam-dlia-otsienki-arkhitiektury презентация], [https://vimeo.com/190918892 видео]). И действительно, анализ обнаружил полезные и интересные вещи. Но в целом метод в широкое использование не пошел, потому что главное - главное — не предотвратить риски, а достичь цели, при этом оценка показала, что в целом качество является приемлемым, а выявленные проблемы - проблемы — не принципиальными, при том. что конкретный проект был репрезентативным для компании.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* Отложенное применение - применение — создают и тестируют заранее, а включают потом

* Редактор конфигурации - конфигурации — из метаданных и разметку.

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

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

Что помогает обеспечить устойчивость? * Замкнутость. Ссылаешься на объекты конфигурации. Нельзя подставить номер клиента или вид договора. * Техническая валидация YAML.

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

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

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

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

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

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

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

# Формирование transition-архитектур - архитектур — проработка частных переходов. Там будет много вариантов и подробностей, будет идти.

И после этого можно считать, что discovery закончен, можно идти в delivery.

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

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

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

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

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

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

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

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

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

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