6952
правки
Изменения
м
Начало - Начало — вполне традиционный телеком с экспансией по регионам и странам СНГ, с 1993 по 2000. Потом, до 2014 - 2014 — годы развития в своей отрасли, освоение 3G и 4G. А вот с 2015 пошел вывод цифровых услуг и выход в другие сегменты бизнеса, который успешно продолжается. * Медиа - Медиа — начинали как online-кинотеатр, которому нужен контент. Киона. А как таких стало много, стало понятно, что нужен свой контент. Они его снимают, при чем дешевле, чем у конкуретновконкурентов, за разумные деньги. Инвесторы не верили, съемки всеми воспнинимаются воспримаются как черная дыра. Досуг и эмоции - эмоции — важно для людей. И это уже не только online, мюзикл в МДМ "Ничего «Ничего не бойся, я с тобой" - тобой» — самый успешный в России.* Авто. Для начало - начало — подсоединить автомобиль к интернету. Следующий шаг - шаг — мультимедиа, киона, сим-карту надо использовать. А дальше - дальше — человек в авто 1.5 часа в день и можно взаимодействовать с клиентом. И тут работает синергия с основным бизнесом. Например, видеорегистратор - видеорегистратор — можно писать все, а вы платите, только если хотите скачать - скачать — fremium модель. Предоставить такое может только мобильный оператор. А люди скачивают не только проишествияпроисшествия, на дороге много любопытного происходит.* Финансы - Финансы — воронка, нужна всем, воронка становится гладкой, если предоставить клиенту финасовое финансовое плечо. И там много разных услуг, финтех - финтех — это антибанк, диверсификация.* Туризм - Туризм — потому что никто не знает лучше о потоках движения, чем мобильные операторы. И они - они — во всех регионах, могут обеспечивать поддержку. А дальше - дальше — ИТ-компетенции: билингбиллинг, поддержка они умеют лучше туроператоров. А если бесплатный роуминг - роуминг — вообще вау.* Реклама - Реклама — везде, где биг дата. Начали вкладываться раньше, и хотя вкладываются может недостаточно, но лучше конкурентов* Cloud - Cloud — у них ЦОД по всей стране, высокоскоростная связь, возможности по секьюрити. И они могут много возможностей чтобы стать игроком, пока не стали, туда идут.* Безопасность. Пошли позднее. К телеком-операторам доверие - потмоу доверие — потому что они много знают о человеке объективно, и оберегают это. Поэтому доверить безопасность в дом - дом — логично. А если роутер - роутер — то центр умного дома, при чем по сценариям без пугающих ремонтов, постепенно. Умный дом в мире где-то взлетает, по-разному, они верят, что через безопасность.* b2b были не очень сильны, так как в России телекомы были b2c. Но развитие в ИТ привело к тому, что появилось много разных услуг именно для бизнеса - бизнеса — и корпоратам, малым предприятиям. Видео, видеонаблюение, чат-боты и так далее.
Дальше - Дальше — заметки по ходу выступления.
Бактерии - Бактерии — у них нет выбора, функции запрограмированны ДНК. У людей выбор есть. Железо запрограммировано ДНК: рост, цвет волос, предрасположенность с диабету. А вот софт - софт — отличается. Можно что-то выучить: софт можно выбирать. Все выучить нельзя, поэтмоу поэтому точно надо выбирать. При этом мы все умрем, через 100 лет точно не будет. Так что надо выбирать.
Люди - Люди — самые совершенные приборы, мозг сложно устроен. И можно заимствовать. Мысль меняется динамически каждую секунду. 86 млрд нейронов - 86 млрд нейронов — а число связей непредставляемым не представляемым числом. Это - Это — мысли.
Инновации - Инновации — дети, которые совали гвозди в розетке. И это не все. Многие - Многие — как в системе.
BitCoin - BitCoin — один человек придумал и опубликовал - опубликовал — и крипта появилась.
Пример - Пример — из армии. Нет задачи делать точечные достижения, надо делать массовые операции, типа десанта в Нормандии. Когда кто-то начинает креативить - креативить — все ломается. Ключ успеха - успеха — логистика. Корпорация - Корпорация — также, все отлажено. Инновация - Инновация — это спецназ. Это отдельно и дорого.
Агентства - Агентства — аналитические проститутки 20 агентств. Тренды одинаковы, они всем продают и все корпорации идут куда скажешь.
Нет описания правки
В самом конце марта, 31.03 прошла первая ИТ-конференция МТС [https://truetechday.ru/ TrueTechDay]. Она проходила на нескольких площадках offline: Москва, Астана, Тбилиси и Дубай, по которым были распределены треки, и в online-формате. В Москве конференция была в концертном пространстве MTC Live, в котором шло четыре трека, а при желании - желании — можно было смотреть треки с других площадок в трансляции. По организации было немного ляпов, но не слишком значительных.
Зато пространство накладывало дополнительный отпечаток на атмосферу, эффект шоу. На первом - первом — вид сверху, от зала с докладами по архитектуре, на все пространство конференции, еще до начала выступления. Там внизу пространство для общения, оно на втором фото, а ряды для зрителей основного зала - зала — за стеной, на третьем фото - фото — вид снизу.
Спикеры могли еще посмотреть концертную площадку за кулисами - кулисами — спикерская была в гримерных для артистов. Этих фото у меня нет. Другие залы были достаточно компактными, отделены частично тканевыми занавесями, а не жесткими сценами, но в целом звук был устроен нормально, залы не мешали друг другу. Можно оценить по фото с моего выступления.
[[Файл:TrueTechDay-2023-mtsit0555.jpg|300px]]
По качеству контента конференция прошла на очень высоком уровне. И я очень желаю организаторам сохранить этот уровень в последующих конференциях, по опыту знаю, что это - это — не просто. Но надеюсь, что у них получится. Записи обещали опубликовать, а сама '''конференция была бесплатной'''. вообще есть смысл следить за бесплатными конференциями, которые проводят разные компании, потому что организаторы реально вкладываются в качество контента. Хотя понятно. что получается у всех по-разному, и это отчасти лотерея. Но '''у МТС получилось хорошо'''.
Я сам выступал с докладом по [[Модель Белбина для IT: сила и слабость разных команд (TrueTechDay-2023)|'''модель Белбина''']], на котором не буду останавливаться подробно. Скажу лишь, что это был гибрид между моими первыми докладами с рассказом про модель как таковую, например [[Роли в команде - модель Белбина (Максим Цепков на SPMconf-2012)|на SPMconf-2012]] и последними докладами, начиная с [[Модель Белбина для IT: сила и слабость разных команд (TeamLeadConf-2020)|TeamLeadConf]] ([https://habr.com/ru/company/oleg-bunin/blog/522586/ статья-расшифровка]), в которых я фокусировался на практических применениях для ИТ. Запись будет опубликована.
А дальше - дальше — заметки с других докладов. Я был на основном треке и треке архитектуры, параллельно шли треки BigData, AI и другие, смотрите программу. И, думаю, там тоже было интересно. Из всех докладов особо я хочу отметить '''пленарные выступления Вячеслава Николаева, Евгения Черешнева м Макса Завадского''' — в них реально был интересный контент, а также выступления '''Александра Бындю ''' про lowcode и '''Александра Белоклокова ''' про цифровой двойник X5. Но это - это — оценка из моих интересов и восприятия, у вас может быть другая.
= Президент МТС Вячеслав Николаев: МТС вчера и сегодня =
Название доклада дал я по содержанию, в программе это было обозначено просто как открытие конференции. Что интересно, Вячеслав в выступлении использовал концертное шоу-оборудование площадки, но достаточно уместно и не навязчиво. И доклад был содержаительнымсодержательным, а не рекламным, показывал логику развития. Если кратко, то суть - суть — в расширении через традиционные отраслевые границы, за счет чего эта экспансия дает эффект.
Disclaimer. Я не проверял ссылки и утверждения, это - конспект, при чем с голоса - возможны неточности.
Все это бизнесы не на продажу, а для включения в экосистему, которую они строят. Но при этом нет идеи. что все услуги должен оказывать сам МТС. Наоборот, они строят открытую экосистему, а не закрытую, как Андроид, а не Apple, зовут партнеров. Потому что уверены, что не получится сделать все самим.
Естественно, все эти изменения требовали соответствующего ИТ. МТС много лет живет на собственном билингебиллинге. В телекоме билинг - биллинг — много больше, чем в других областях, это не просто выставление счетов. В 12-13 году они поняли, что система надежная, но неповоротливая, и пришлось менять: неповоротливость мешала выводить новые продукты. Увеличили вдвое количество ИТшников, в 4-6 раз сократили сроки запуска продукта, в 10 раз повышение надежности, вдвое снижение затрат.
Была централизованная компания, Product говорили, что скучно и неповоротливо. Сейчас часть вынесено во внешние компании, многие контрольные органы превратились в сервисные. Этот процесс еще идет. Решили меняться и внешне - внешне — голосование за новый брендинг. Выставили Выставили ребрендинг на голосование - голосование — был большой отклик.
= Вице-президент по технологиям Павел Воронин: Что завтра? =
Это было очень короткое выступление. Основной тезис: будущее зависит от конкретных людей. Примеры из истории: открытие Америки Колумбом, Эдисон и Тесла - Тесла — электричество в каждый дом, Гейтс и Джобс - Джобс — эра персоналок и смартфонов. Нынешние тренды: Open AI и ChatGPT, квантовые технологии - технологии — за ними тоже конретные конкретные люди.
Разные визионеры говорят о разных сценариях. Будем ли мы жить в новом мире, где будем избавлены от монотонного ручного труда и жизнь будет длинной и счастливой, или в другом мире, где люди, вытесненые вытесненные с рынка труда опускаются в нищету, а экономика - экономика — в депрессию - депрессию — зависит от нас.
= Евгений Черешнев. Инновации невозможного =
Евгений Черешнев - Черешнев — исполнительный директор по стратегии и инновационному развитию МТС RED. Его выступление было посвящено инновациям - инновациям — как создавать то, о чем все мечтают, но мало у кого получается. И был еще подзаголовок - подзаголовок — как остаться человеком в эпоху ИИ. Это был замечательный фейерверк логически связанного ассоциативно-мемного мышления. Это кажется оксюмороном, где логика и где мемы, но у него реально получилось их объединить.
Основная мысль - мысль — дети любознательны, экспериментируют, суют пальцы в розетку, пускаются во всякие другие предприятия. Но родители и школа это исправляют. И от тех, с кем преуспели в исправлении, от инноваций ждать не приходится. К счастью, они справляются не со всеми, и компаниям стоит искать тех, кто сохранил любознательность и склонность к экспериментам, если они хотят инноваций. А родителям - родителям — поощрять эти качества, а не давить их, хотя с такими детьми и больше беспокойства.
И была прекрасная метафора: '''люди-кубики лежат одинаково, люди-шарики катятся в разные стороны.'''
В 90-х было две специальности - специальности — финансист или юрист. Он стал юристом, а техническое образованеи получал позднее.
История вселенной от большого взрыва - взрыва — это история усложнения структур. Начиная от синтеза элементов из водорода в звездах.
Мы давно не биологический вид жизни. С обезьяны, которая взяла палку-копалку: вау, можно не развиваться самой биологически, а использовать орудия. Дельфины миллионы лет выращивали сонар эволюцией. Люди - Люди — за 10 лет.
Мы как форма жизни номер 2 делаем все, чтобы сделать форму жизни номер 3: ИИ. Почему важно - важно — потому что вопрос, что останется после тебя. У машин нет этого, у них - них — бесконечное время. Если машину научили вести ИИ с учетом туманов шотландии Шотландии и кенгуру Австралии и так далее - далее — она умеет всегда. ИИ зовет, это эволюция. Останавливать бесполезно, надо возглавлять.
Но! Умнение ИИ будет отуплять население. Потому то результат-то дается готовый, без промежуточных этапов.
Более сложные штуки требуют меньшего времени. * В 2009 первые роботы, которые едва ходят. А в 2019 - 2019 — прыгают, уворачиваются.
* Лучшие практики из биологии. Рои дронов, которые формируют рекламу в Дубаях.
Нейронная сеть в мозгу гибкая, есть взять ребенка из 1000 лет назад - назад — он адаптируется к нашему миру, обучится. Проблема не с сетью, а с тем, что подать на вход. Ребенок - Ребенок — чистая болванка. Вопрос информации и гормонального подкрепления. Проблема не в нейронной сети, а в методике обучения. До 6 лет обучение с подкреплением - подкреплением — это нормально. При этом любопытство - любопытство — единственный стимул. Потом люди попадают в систему, и это исчезает. Делать иррациональные, спонтанные поступки - поступки — очень важно для инноваций. Друг. Они Они вместе совали гвозди в розетку, обесточили поселок, его потрясло и он решил стать физиком чтобы разобраться - разобраться — еще до школы.
А потом система выравниквает "каждый выравнивает «каждый становится кирпичем кирпичом в стене"стене». Всем дают одинаковые знания, при этом половину еще не учат - учат — и только этим отличаются.
Система образования выполняет госзаказ. Во всем мире. Подготовить стандартных. Не просто для простого управления - управления — а чтобы легко компоновались в группы. И это нормально работало. А теперь работать перестало. Китай, ШеньЖень - ШеньЖень — завод размером в город, полный автомат. Сейчас Китай может повторить любую инновацию за 48 часов. Они это делают, не скрывают.
В 20 веке создал продукт - продукт — можно жить 20-30 лет. А сейчас уникальная способность - непрервыно способность — непрерывно создавать продукты. Как Apple при Джобсе в лучшие годы, когда каждый год новое, и непонятное до анонса.
Братья Райт - Райт — стартаперы пытались делать самолет. Лэнли - Лэнли — делал тоже самое, только с доступом к бюджету и ВПК. У него не получилось. У братьев Райт - Райт — получилось.
Некролог компаний. АльтавистаAltavista, НетсекйпNetscape, Эксплорер, Нокиа, Кодак, Полароид, Скайп. Он консультировал Нокиа. Он был фанатом, лучшие телефоны. Он приходил, и говорил что телефоны - телефоны — круто, но Samsumg и Apple делают НЕ телефоны, будущее за этим. Они не слышали.
Люди Кубики - Кубики — лежат одинаково, шарики - шарики — катятся в разные стороны.
Идейные занимаются тем, что любят, а не тем что выгодно и это становится очень выгодно.
Что мешает инновациям: обычаи, стандарты (МСО), инструкции, решения сверху, привычка, закон (в частности тайны и охраны данных).
Очень глупо брать умных людей на работу и говорить им что делать. Надо их слушать.
= Марк Завадский. Технологии сильных эмоций - — что общего у китайских продавцов и русских смешариков =
Марк - — многогранен, он возглавлял 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 имеет низкий порог входа, и в целом популярен, по мере роста масштаба проекта появлются появляются проблемы. Это не значит, что применять не стоит, но проблемы полезно представлять еще на входе, оценить их проявление в вашем проекте и готовиться. По докладу у Александра вышла [https://habr.com/ru/articles/729188/ статья на хабре], которая сильно подробнее могих моих заметок.
Почему 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 и 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, память, переполненные диски и забитые логи.
Дальше был рассказ, как это у них устроено, как проходят эксперименты. У них были оценки эффекта от экспериментов. Например, эмуляция высокой нагрузки в обычный сезон позволила оценить запас и подготовитсья подготовиться к тому, чтобы выдержать нагрузки высокого сезона.
Эксперименты можно поставить сразу после развертывания, пока нагрузка низкая и выявить имеющиеся проблемы. А заодно - — увидеть как ведет себя мониторинг нового продукта под нагрузкой. И их надо регулярно повторять, так как любые обновления влияют на картину, а изменения происходят постоянно.{{wl-publish: 2023-05-04 13:25:17 +0300 | MaksTsepkov }}