2023-05-04: TrueTechDay - живая конференция и хороший контент

Короткая ссылка: TrueTechDay-2023

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

пост на FB

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

В самом конце марта, 31.03 прошла первая ИТ-конференция МТС TrueTechDay. Она проходила на нескольких площадках offline: Москва, Астана, Тбилиси и Дубай, по которым были распределены треки, и в online-формате. В Москве конференция была в концертном пространстве MTC Live, в котором шло четыре трека, а при желании — можно было смотреть треки с других площадок в трансляции. По организации было немного ляпов, но не слишком значительных.

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

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

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

Я сам выступал с докладом по модель Белбина, на котором не буду останавливаться подробно. Скажу лишь, что это был гибрид между моими первыми докладами с рассказом про модель как таковую, например на SPMconf-2012 и последними докладами, начиная с TeamLeadConf (статья-расшифровка), в которых я фокусировался на практических применениях для ИТ. Запись будет опубликована.

А дальше — заметки с других докладов. Я был на основном треке и треке архитектуры, параллельно шли треки BigData, AI и другие, смотрите программу. И, думаю, там тоже было интересно. Из всех докладов особо я хочу отметить пленарные выступления Вячеслава Николаева, Евгения Черешнева м Макса Завадского — в них реально был интересный контент, а также выступления Александра Бындю про lowcode и Александра Белоклокова про цифровой двойник X5. Но это — оценка из моих интересов и восприятия, у вас может быть другая.

Президент МТС Вячеслав Николаев: МТС вчера и сегодня

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

Disclaimer. Я не проверял ссылки и утверждения, это - конспект, при чем с голоса - возможны неточности. 

Начало — вполне традиционный телеком с экспансией по регионам и странам СНГ, с 1993 по 2000. Потом, до 2014 — годы развития в своей отрасли, освоение 3G и 4G. А вот с 2015 пошел вывод цифровых услуг и выход в другие сегменты бизнеса, который успешно продолжается.

• Медиа — начинали как online-кинотеатр, которому нужен контент. Киона. А как таких стало много, стало понятно, что нужен свой контент. Они его снимают, при чем дешевле, чем у конкурентов, за разумные деньги. Инвесторы не верили, съемки всеми воспримаются как черная дыра. Досуг и эмоции — важно для людей. И это уже не только online, мюзикл в МДМ «Ничего не бойся, я с тобой» — самый успешный в России.
• Авто. Для начало — подсоединить автомобиль к интернету. Следующий шаг — мультимедиа, киона, сим-карту надо использовать. А дальше — человек в авто 1.5 часа в день и можно взаимодействовать с клиентом. И тут работает синергия с основным бизнесом. Например, видеорегистратор — можно писать все, а вы платите, только если хотите скачать — fremium модель. Предоставить такое может только мобильный оператор. А люди скачивают не только происшествия, на дороге много любопытного происходит.
• Финансы — воронка, нужна всем, воронка становится гладкой, если предоставить клиенту финансовое плечо. И там много разных услуг, финтех — это антибанк, диверсификация.
• Туризм — потому что никто не знает лучше о потоках движения, чем мобильные операторы. И они — во всех регионах, могут обеспечивать поддержку. А дальше — ИТ-компетенции: биллинг, поддержка они умеют лучше туроператоров. А если бесплатный роуминг — вообще вау.
• Реклама — везде, где биг дата. Начали вкладываться раньше, и хотя вкладываются может недостаточно, но лучше конкурентов
• Cloud — у них ЦОД по всей стране, высокоскоростная связь, возможности по секьюрити. И они могут много возможностей чтобы стать игроком, пока не стали, туда идут.
• Безопасность. Пошли позднее. К телеком-операторам доверие — потому что они много знают о человеке объективно, и оберегают это. Поэтому доверить безопасность в дом — логично. А если роутер — то центр умного дома, при чем по сценариям без пугающих ремонтов, постепенно. Умный дом в мире где-то взлетает, по-разному, они верят, что через безопасность.
• b2b были не очень сильны, так как в России телекомы были b2c. Но развитие в ИТ привело к тому, что появилось много разных услуг именно для бизнеса — и корпоратам, малым предприятиям. Видео, видеонаблюение, чат-боты и так далее.

Все это бизнесы не на продажу, а для включения в экосистему, которую они строят. Но при этом нет идеи. что все услуги должен оказывать сам МТС. Наоборот, они строят открытую экосистему, а не закрытую, как Андроид, а не Apple, зовут партнеров. Потому что уверены, что не получится сделать все самим.

Естественно, все эти изменения требовали соответствующего ИТ. МТС много лет живет на собственном биллинге. В телекоме биллинг — много больше, чем в других областях, это не просто выставление счетов. В 12-13 году они поняли, что система надежная, но неповоротливая, и пришлось менять: неповоротливость мешала выводить новые продукты. Увеличили вдвое количество ИТшников, в 4-6 раз сократили сроки запуска продукта, в 10 раз повышение надежности, вдвое снижение затрат.

Была централизованная компания, Product говорили, что скучно и неповоротливо. Сейчас часть вынесено во внешние компании, многие контрольные органы превратились в сервисные. Этот процесс еще идет. Решили меняться и внешне — голосование за новый брендинг. Выставили ребрендинг на голосование — был большой отклик.

Вице-президент по технологиям Павел Воронин: Что завтра?

Это было очень короткое выступление. Основной тезис: будущее зависит от конкретных людей. Примеры из истории: открытие Америки Колумбом, Эдисон и Тесла — электричество в каждый дом, Гейтс и Джобс — эра персоналок и смартфонов. Нынешние тренды: Open AI и ChatGPT, квантовые технологии — за ними тоже конкретные люди.

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

Евгений Черешнев. Инновации невозможного

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

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

И была прекрасная метафора: люди-кубики лежат одинаково, люди-шарики катятся в разные стороны.

Дальше — заметки по ходу выступления.

В 90-х было две специальности — финансист или юрист. Он стал юристом, а техническое образованеи получал позднее.

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

Бактерии — у них нет выбора, функции запрограмированны ДНК. У людей выбор есть. Железо запрограммировано ДНК: рост, цвет волос, предрасположенность с диабету. А вот софт — отличается. Можно что-то выучить: софт можно выбирать. Все выучить нельзя, поэтому точно надо выбирать. При этом мы все умрем, через 100 лет точно не будет. Так что надо выбирать.

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

Мы как форма жизни номер 2 делаем все, чтобы сделать форму жизни номер 3: ИИ. Почему важно — потому что вопрос, что останется после тебя. У машин нет этого, у них — бесконечное время. Если машину научили вести ИИ с учетом туманов Шотландии и кенгуру Австралии и так далее — она умеет всегда. ИИ зовет, это эволюция. Останавливать бесполезно, надо возглавлять.

Но! Умнение ИИ будет отуплять население. Потому то результат-то дается готовый, без промежуточных этапов.

Более сложные штуки требуют меньшего времени.

• В 2009 первые роботы, которые едва ходят. А в 2019 — прыгают, уворачиваются.
• Лучшие практики из биологии. Рои дронов, которые формируют рекламу в Дубаях.

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

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

А потом система выравнивает «каждый становится кирпичом в стене». Всем дают одинаковые знания, при этом половину еще не учат — и только этим отличаются.

Система образования выполняет госзаказ. Во всем мире. Подготовить стандартных. Не просто для простого управления — а чтобы легко компоновались в группы. И это нормально работало. А теперь работать перестало. Китай, ШеньЖень — завод размером в город, полный автомат. Сейчас Китай может повторить любую инновацию за 48 часов. Они это делают, не скрывают.

В 20 веке создал продукт — можно жить 20-30 лет. А сейчас уникальная способность — непрерывно создавать продукты. Как Apple при Джобсе в лучшие годы, когда каждый год новое, и непонятное до анонса.

Инновации — дети, которые совали гвозди в розетке. И это не все. Многие — как в системе.

BitCoin — один человек придумал и опубликовал — и крипта появилась.

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

Братья Райт — стартаперы пытались делать самолет. Лэнли — делал тоже самое, только с доступом к бюджету и ВПК. У него не получилось. У братьев Райт — получилось.

Некролог компаний. Altavista, Netscape, Эксплорер, Нокиа, Кодак, Полароид, Скайп. Он консультировал Нокиа. Он был фанатом, лучшие телефоны. Он приходил, и говорил что телефоны — круто, но Samsumg и Apple делают НЕ телефоны, будущее за этим. Они не слышали.

Агентства — аналитические проститутки 20 агентств. Тренды одинаковы, они всем продают и все корпорации идут куда скажешь.

Люди Кубики — лежат одинаково, шарики — катятся в разные стороны.

Идейные занимаются тем, что любят, а не тем что выгодно и это становится очень выгодно.

Что мешает инновациям: обычаи, стандарты (МСО), инструкции, решения сверху, привычка, закон (в частности тайны и охраны данных).

Очень глупо брать умных людей на работу и говорить им что делать. Надо их слушать.

Марк Завадский. Технологии сильных эмоций — что общего у китайских продавцов и русских смешариков

Марк — многогранен, он возглавлял Alibaba Russia при выходе на российский рынок, работал в Сбербанке тогда, когда он стал Сбером, потом пошел в компанию, которая делает Смешарики и Фиксиков.

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

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

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

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

Он спрашивал сына: кем ты хочешь стать, доктором или кем-то еще. Ответ: «Нет, хочу стать никем, как ты». И это очень интересный ответ — никем.

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

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

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

Инструменты. Из Сунь Цзы.

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

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

Ценности-качества: Ум, Устойчивость, Оптимизм (светиться), Рефлексия

В поддержке. Жалуешься, что товар на сайте выглядит лучше, чем когда пришел? Взгляни в зеркало и на свои фото! Ни у кого не было такой интенсивной и дешевой коммуникации с клиентом.

Много бизнес-моделей. Эмоциональная связь с клиентами и пользователями.

Мульты. Лицензирование персонажей, выстраивание связи. Там тоже много технологий. Сезон делают 2-3 года.

Эмоции помогают правильно отстроить бизнес. Данные бесполезны сами по себе — как нефть. Нужны заводы и устройства-потребители. Потребность в информации, общении и потреблении.

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

Все становится контентом. Контентом моет стать любой продукт. Как пример — ролик передачи полномочий от Джека Ма Дэниэлю Чжану — 50к сотрудников. Концерт, бизнес-юниты. И они тоже пели, шоу передачи.

Александр Алехин, руководитель центра корпоративной архитектуры МТС. Эволюция архитектуры — composable ecosystem

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

Интервью CTO, Ozon Антона Степаненко: Корпоративный лайфхак. Как организовать работу архитектурных комитетов

Озон — фича-тимы, в идеале команда сама делает любую фичу. Это ведет к размытию компетенций. Они учредили центры компетенций. Например, комитет по Go. Там представители Go из разных мест и задача — собрать использование технологии. И дальше из председателей всех центров собрали архитектурный комитет.

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

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

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

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

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

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

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

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

Бизнес-логика часто не ложится в паттерны проектирования. Что делать? Ответ: бизнес — он прав, он понимает потребности. Но сложнее. Если бизнес говорит: дайте ручку, чтобы красные платья были выше — то показываешь, что бизнес замается крутить ручки. Сложный процесс, А/Б тесты и так далее, показываешь. То есть корректировать желания — интересно.

Из ответов. Пока АК стопит новые технологии, к которым эксплуатация не готова. Они в этом проблемы не видят. В теории убедить АК можно, но пока никому не удавалось.

Алексей Стрекаловский. Архитектура edge сервиса на примере CDN

Технический доклад про организацию сервиса CDN с анализом вариантов и их проблем. Тут я подробно воспроизводить не буду. Они выбрали Angie — fork от Nginx потому что там хорошая открытая команда в России. А я узнал, что оказывается, IP-адрес вовсе не обязан был уникальным, есть технология AnyCast, когда идет просто отправка на ближайший узел с требуемым IP. И при разрешении в DNS есть вариант GeoDNS, когда для одного имени идет выбор ip с учетом геолокации. Ну а CDN — следующий уровень, когда есть маршрутизация с учетом загрузки серверов, ресайзинг, терминация сессий, шифрование и кэширование. И МТС готовится предоставить его прямо на вышках как продукт — это важно для использования с большим трафиком, таких как VR.

Екатерина Лысенко. Одна задача — разный путь: влияние бизнес-контекста на архитектуру

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

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

Кейс-1. Логистика. Компания «Легко везу» — минимум цен за 1 кг мелкие грузы, между городами-миллионниками, бизнес развивается. Есть сеть складов, постоянная команда, база клиентов, юриков больше чем физиков. И внезапно владельцы решают «пора бы выходить на новый рынок», осваивая соседние ниши. Бизнес готов к общению, готов принести идеи и дорабатывать.

• Идея-1. Специализированный сайт-агрегатор — агрегировать другие габаритные грузы, море-авиа-транспорт. Клиент приходит, бронирует слот, доставляет получает доставку. И для такого сайта нужна архитектура специализированной доски объявлений — в объявлении надо понимать маршруты, расписания, ограничения на грузы, чтобы покупатель мог найти нужное предложение, а компания могла это выставить. Заготовка — есть в собственных предложениях, но они покрывают только часть рынка. Объявления надо удобно выставить на витрину для потребителей, и предоставить удобное открытое API для тех, кто оказывает услуги, чтобы они выставляли предложения и подтверждали бронирование. И это — существенное развитие, которое надо сделать с учетом существующего.
• Развитие идеи. Неизбежно появится вопрос гарантий выполнения заказа подрядчиком, а для подрядчика — гарантий оплаты от заказчика, от платформы этого в некотором виде ожидают. И это — во взаимоотношениях между юридическими лицами, что предполагает проработку соответствующей юридической схемы, возможно — создание специальных кошельков покупателей с резервированием на них средств в оплату заказов, выпуск фискальных документов и так далее. Или можно решить, что это — принципиально за рамками бизнеса, что они просто сводят продавцов и покупателей.
• Идея-2. Платформа, где не только логисты, но и смежные услуги, для начала — те, где логистики много. Например, переезд под ключ, или покупка пиломатериалов или удобрений с доставкой или другого аналогичного товара, где логистика доставки может быть существенной. И тут тоже возникают вопросы представления этого для потребителя — объявления будут гораздо более разнородными, чем чистая логистика. Надо сегментировать аудиторию, вести ее по своим траекториям. Пиломатериалы и доставка пиломатериалов — разные товары. А строители коттеджей и владельцы дач — группы с разными потребностями, хотя обоим нужны пиломатериалы, а дачникам — еще и удобрения. И тоже API для взаимодействия с поставщиками. И вопросы гарантии сделки, которая становится сложнее.

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

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

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

Артем Елизаров. Управление проектами и изменениями. Как быть понятнее для бизнеса

Артем Елизаров — руководитель департамента по продукту и технологиям собственных продаж Ozon. Он делился опытом организации разработки. Разработка делится по продуктам, над каждым из которых работают несколько команд. И есть бизнес-заказчики, которым для развития продуктов требуются доработки в одном или нескольких продуктах. Доработки оцениваются в человеко-днях, которые переводятся в маечную классификацию. Малые доработки (XS до 10 дней) ИТ приоритизирует самостоятельно. А остальное согласование планов происходит на Техкомах, которые организованы по продуктам. При этом у каждой команды еть емкость спринта, оцененная в задачах разного размера в маечной классификации. Опыт говорит, что должна быть смесь задач разного размера, при этом количество задач в спринте — небольшое, для фокусировки.

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

Очень важно не просто сделать разработку, а проверить достижение ожидаемого эффекта. Всегда. Завершение проекта — отдельный тикет в jira. Готовятся к этому на старте: договариваются, что и где будут мерить, меряют текущие метрики. Это помогает посмотреть, что-то поправить или констатировать провал.

Большие кросс-доменные проекты. Есть кросс-доменный координатор в ИТ, обычно в домене, где максимум изменений, и один ответственный от бизнеса. Таких больших проектов немного, 1-2.

Выводы

• Создавайте инструменты, объединяющие людей
• Просите заказчика объяснить, зачем нужно что-то делать.

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

Александр Бындю. Применение low-code платформ в энтерпрайзе

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

Почему lowcode популярен?

• Визуальная разработка. Накидываем квадратики и соединяем стрелочками.
• Бизнес хочет потмоу что процесс нарисован и он всегда актуален, работа идет именно так.
• Можно играть в inner-source — отделы закидывают друг другу
• Быстрое прототипирование

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

Вашу систему будут менять постоянно. Потому что бизнес идет вперед. Мы хотим безопасно и дешево вносить изменения. А это значит, что не ломаем предыдущее и рефакторим дублирование. Lowcode это плохо умеет.

Технические проблемы инфраструктуры.

• Система контроля версий. Ревью изменений — их хотелось бы видеть. А в визуальном языке — сложно. В лучшем случае можно работать с Yaml или xml, а это — тяжело. Платформу не умеют работать с версиями и тем более сравнивать. И проблему надо как-то решать на коленке, иначе спагетти-код и другие известные последствия.
• Трассировка, CI/CD — в каждой lowcode своя, и со стандартными не сопрягаются, это — боль получается, особенно если надо сопрягать разные решения при интеграции.
• Выделения дублирования для рефакторинга — стандартных средств при визуальном проектировании нет. Кусок реального процесса в коде на комунде: листаем и листаем. В результате рефакторинг — на коленке.
• Lowcode позволяет писать внутри блоков. Искать проблемы в этом случае — ад. Ищем способ писать весь код снаружи.
• Информационная безопасность и SLA. Рисуем квадратики со стрелочками — кто-то начал пересылать данные, а они — паспортные, а они легли в трассировку, а трассировка куда-то легла — и у вас проблемы. О безопасности должна заботиться платформа. Но она обычно не умеет.

Организационные проблемы.

• Отсутствует общий визуальный язык. Каждая придумала свой. Каждый раз — переобучать пользователей. BPMN — классно, так как она общая.
• Обучение пользователей стоит денег и времени. Знающих — мало или нет.
• У citizen integrator — разработчика на lowcode есть основная работа. Если кто-то в бизнесе накидал квадратики для себя, для соседа — то кто это будет поддерживать?
• Shadow IT — пользователи накидывают квадратики, никто не смотрит, оно попадает в прод. За этим надо следить архитектурным комитетом
• Если решите отказаться от платформы — все надо переписывать с нуля.

Как можно действовать?

• Сделать свою lowcoe платформу. Монолит — микросервисный монолит — нормальные микросервисы — свой оркестратор — это и есть lowcode. Оркестратор, где event bus и квадратики соединяют, создают новый продукт из имеющихся. Тут все ваше, можете завернуть и даже продать. Минус — дорого, чтобы создать платформу для непрограммистов нужны очень хорошие программисты на бесконечный срок.
• Гибридное решение. Есть bpmn-движок, например, comunda, и есть зона обычного кода. В движке делают мало. Плюс — аналитики и продукты видят схему, в основной код в зоне рефакторинга.
• Back for Front: фронты из кубиков дергают API
• Быстрый MVP — накидали, взлетел — перепишите.

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

Александр Белоклоков, директор по архитектуре X5. Цифровой двойник

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

Для того, чтобы создать такое описание они разработали собственный продукт. Они смотрели инструменты, В частности, DocHub (статья, git) и Orbus. Но нужного функционала не хватало, освоение сложно, стоят «как чугунный мост». Поэтому — собственная разработка, сделали и наполнили примерно за полтора года, успешно используют. Получился продукт, который не специфичен для X5 и для retail. На нашем рынке не видел аналогов, поэтому готовы предоставлять другим. Пока не как коробку, а как пилоты. Два идут, желающие приглашаются.

Первоначальная постановка включала 3D:

• Describe — описание того, что есть.
• Design изменений, эксперимент
• Discover — посмотреть, что спроектировали и о чем договорились.

Целевая аудитория — не только архитекторы. Это governance, информационная безопасность, топы, СТО — всем им нужна актуальная картинка из реальных данных.

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

Поэтому архитекторы работают в продукте и есть жесткое требование, что любые коллегиальные органы требуют схем в продукте. Первая версия стартовала в мае 2021.

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

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

Пример — HR функция. Цепочка values — value chain — capability — процессы — приложения — до железа.

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

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

Можно ли перенести на производство, например, завод автоматизировать? Тут они не знают. На заводах — MES, разнообразие оборудования и входных данных.

Козлов Максим. Готовимся к турбулентности в современных архитектурных решениях. «А что если … ?»

Козлов Максим — руководитель направления в центре компетенций Архитектура МТС. Чтобы обеспечить надежность, безопасность, консистентность — строят архитектуру. Но инциденты все равно случаются и важно обеспечить живучесть, liveness: чтобы система все равно продолжала работать, даже при возникновении проблем, на которые вы не тестировали.

Как это сделать, отвечает chaos engineering. Задача — обеспечить при инцидентах сохранение выполнения нефункциональных требований там, где для бизнеса они являются функциональными и жизненно важными. Атаки — разные, у них пять видов: сетевые с потерей пакетов и dns, оказывается, до 15 % на кластере бывает запросто; падение и перезагрузка хостов, падение и прерывание приложений; атаки на регионы; исчерпание ресурсов — cpu, память, переполненные диски и забитые логи.

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

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

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

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

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

— Максим Цепков • 13:25, 4 мая 2023 • нет комментариев