Книжный куб

AI Trends for 2025 (Рубрика #AI) Недавно глянул это семиминутное видео от Martin Keen, IBM Fellow, который за много лет в IBM проявил себя как изобретатель (больше 400 патентов), технический руководитель, исследователь в AI, а также создатель контента на канале IBM Technology. В этом коротком видео он рассказывает о своем видении трендов в AI на 2025 год. Ксатати, в прошлом году он тоже делал такое видео на 2024 год, поэтому можно пойти и сравнить насколько его прогнозы попали в точку. Но давайте вернемся к прогнозам на этот год. 1) Agentic AI - это важный тренд на создание многошаговых планов и их исполнения с использованием доступных инструментов. Правда, пока современные модели испытывают трудности с логическим мышлением и выполнением сложных планов 2) Inference time compute - модели уже используют больше времени во врем inference, улучшая логический вывод. Это позволяет настраивать и улучшать систему без необходимости обучать/тюнить базовую модель. 3) Very large models - в этом году мы предположительно пробьем 1 трлн параметров в foundational models 4) Very small models - будут активно развиваться модели меньшего размера, которые могут работать на ноутбуках и телефонах. 5) More advanced use cases - ИИ улучшит качество обслуживания клиентов, IT operations и автоматизацию. 6) Near infinite memory - Современные модели ИИ имеют контекстные окна в миллионы токенов. Дальше будет больше и, например, условные чат-боты смогут сохранять и использовать всю доступную информацию по пользователю. 7) Human in the loop augmentation - Чат-боты могут превосходить врачей в диагностике, но в паре с экспертами они могут быть эффективнее. Для этого нужны более совершенные системы для интеграции ИИ в рабочие процессы. Мы, например, активно интегрируем свой Nestor во все процессы вокруг SDLC (software development lifecycle) для повышения продуктивности инженеров #AI #ML #Trends #Software #Engineering

Data завтрак в Т-Банке в начале января 2025 года (Рубрика #Data) Наконец-то я смог посмотреть доклады с data-завтрака, что был почти месяц назад. На нем выступл Дима Аношин, автор канала "Инжиниринг данных" (@rockyourdata), а также Валера Поляков, наш директор по данным. Я немного поучаствовал в организации мероприятия, но посетить не смог из-за того, что летел домой из Шри-Ланки. А темы были интересные: - Дима рассказывал о том, как выглядят data проекты в западных компаниях и на каких технологиях они строятся, благо у Димы есть опыт работы в Amazon, Microsoft и целом ряде компаний поменьше - Валера рассказывал про эволюцию подходов Т-Банка к работе с данными с начала времен и до текущего момента. Ну давайте я кратенько расскажу про каждый из докладов 1) Современные облачные решения для аналитики и их значимость для бизнеса от Димы Аношина - Начал Дима с рассказа о значении аналитики для увеличения прибыли и снижения затрат. - Дальше он рассказал о концептуальных аналитических решениях, которые базово состоят из источников, систем хранения и обработки данных. - Дима поделился 11 реальными проектами, в которых он участвовал за последние десять лет. По этим проектам было наглядно видны тренды - переход от on-prem в cloud, переход от all-in-one в separate storage и compute, восход облачных аналитических решений snowflake и databricks, оформление роли data engineer как людей, что делают инфру под dataops 2) История платформы данных в Т: от SAS до PaaS от Валеры Полякова История развития инфраструктуры данных с 2007 года. - Эпоха SAS (2007 - 2011): Работа с проприетарными инструментами SAS до перехода на Greenplum. - Эпоха Greenplum (2012 - 2016): Переход на MPP базы данных, выбор Greenplum, масштабирование инфраструктуры. Тут еще был поворот не туда с SAP BO в 2014 году:) - Эпоха роста сложности (2017 - 2021): Здесь компания активно росла и предел масштабирования для одного кластера Greenplum был достигнут. Дальше рост через был внедрение мультикластерности и собственных решений для репликации данных. Это привело к стремительному росту нагрузки и сложностей с управлением данными. - Эпоха изменений (2022 - 2026): Эпоха изменений, что принесла современные подходы -- Демократизация инженеринга данных и платформизация. -- Переход к облачной нативности платформы данных с использованием мультитенантной архитектуры. -- Внедрение концепции "данные как продукт" с акцентом на метрики качества. - Изменения несут за собой новые вызовы, с которыми мы работаем прямо сейчас -- Вопросы стандартизации данных между доменами. -- Важность централизованных практик для методологии работы с данными. -- Баланс между тактическими задачами и стратегическим развитием. В общем и целом, data-завтрак по моему мнению получился отличным, доклады плотными - надеюсь, что это превратится в традицию и мои коллеги из платформы данных еще не раз будут радовать нас интересными и полезными мероприятиями. P.S. В конце прошлого года я рассказывал доклад про эволюцию архитектуры в Т, который очень похож по структуре и логике повествования на Валерин доклад. В итоге, я ловил моментами дежавю, когда слушал этот доклад про эволюцию платформы данных:) #Engineering #Data #Architecture #Storytelling

The Rise of Vertical AI in Accounting (Рубрика AI) Прочитал на выходных интересную статью про AI в бухгалтерском учете из рассылки a16z Fintech от фонда AnderssenHorowitz. Вообще, Andreessen Horowitz (чаще известный как a16z) - это ведущая венчурная компания из Кремниевой долины, основанная в 2009 году Марком Андриссеном и Беном Хоровицем. С объемом капитала в $45 миллиардов (по состоянию на начало 2025 года), фирма инвестирует на разных этапах и в различных отраслях, включая технологии, ИИ, здравоохранение, криптовалюты и финтех, делая ставку на смелых предпринимателей и прорывные инновации. Известная своей активной поддержкой портфельных компаний, a16z инвестировала в такие трансформационные проекты, как Airbnb, Lyft и Slack, а также стала пионером в таких новых секторах, как Web3 и искусственный интеллект. Кстати, у ребят есть интересная подборка больших идей на 2025 год, которую интересно почитать для расширения сознания. Если же возвращаться к самой статье, то она посвящена растущей роли вертикального AI в бухгалтерском учете, особенно в решении задач, связанных с услугами клиентского консалтинга (Client Advisory Services, CAS). Суть вертикальности в том, что бухгалтерский учет отличается по областям (авторы приводят в пример строительство и медицину), а это приводит к тому, что универсальный подход (горизонтальный) может проигрывать вертикальному, когда есть фокус на конкретный домен. Вообще, на западе услуги клиентского консалтинга (CAS) являются драйвером роста для компаний благодаря следующим стратегическим преимуществам: - CAS формируют устойчивые отношения с клиентами, открывая возможности для перекрестных продаж. - Доходы CAS растут на 30% ежегодно по сравнению с 9% в среднем по отрасли. - CAS обеспечивает предсказуемый и менее сезонный поток доходов по сравнению с традиционными налоговыми и аудиторскими услугами. Но масштабирование CAS требует значительных трудозатрат на повторяющиеся задачи, такие как закрытие месяца, сверка транзакций и управление расходами. Эти задачи часто выполняются вручную младшими бухгалтерами или офшорными сотрудниками, но сейчас у многих есть желание автоматизировать это при помощи AI - ИИ может значительно сократить время на выполнение рутинных задач с часов до минут за счет автоматизации сбора данных, их обработки и сверки. - Однако для этого требуются высокоточные модели ИИ, способные работать с разнообразными источниками данных и учитывать особенности рабочих процессов в различных отраслях. Дальше авторы сравнивают вертикальный и горизонтальный подход, одновременно нативно встраивая рекламу Adaptive, компанию из их портфеля, что вертикально AI-фицирует бухгалтерию для строительных фирм. Забавно, что в компаниях с собственными ресурсами для внедрения AI получается комбинация в виде вертикальной проработки конкретных доменов, а также создание AI-платформы для подготовки и сервинга ассистентов. Примерно так существует вселенная ассистентов в Т-Банке. #AI #ML #Software #VC

[3/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering) Продолжая рассказ про эту крутую книгу, поднятый в постах 1 и 2, здесь я расскажу про третью часть книги под названием "Процессы". III. Processes (Процессы) 8. Style guides and rules (руководства по стилю и правила) Здесь авторы объясняют необходимость стандартизированных стилей кодирования и правил. Консистентность во всех кодовых базах снижает трение (friction), облегчает поддержку и позволяет автоматизированным инструментам помогать обеспечивать соблюдение этих стандартов. Забавно, что в части языках эти правила зафиксированы на уровне языка, например, в Go 9. Code review (обзор кода) Здесь авторы излагают подход Google к code review как ключевому процессу для поддержания качества. Они описывают лучшие практики, преимущества (такие как обмен знаниями и раннее обнаружение ошибок) и то, как систематические обзоры поддерживают масштабируемую разработку. 10. Documentation (документация) Эта глава сосредоточена на создании ясной, поддерживаемой и доступной документации. Авторы подчеркивают, как правильная документация помогает обеспечить долгосрочную жизнеспособность кода и облегчает процесс онбординга и сотрудничества. 11. Testing overview (обзор тестирования) Авторы представляют общую философию тестирования в Google. Эта глава объясняет, как тесты являются важными для обнаружения проблем на ранней стадии, обеспечения надежности кода и возможности быстрых циклов разработки. 12. Unit testing (юнит-тестирование) Авторы рассказывают про детали тестирования отдельных компонентов. Они подчеркивают важность хорошо написанных, быстрых юнит-тестов для проверки того, что небольшие части кода работают правильно. Забавно, что в некоторых компаниях инженеры не видят смысла в юнит тестах, так как они находят не все ошибки. Но unit tests - это не просто про поиск багов, это про написание кода, который является тестируемым. И уже эта цель приводит нас к хорошей декомпозиции кода на части, а также использованию композиционных подходов, которые позволяют заменить реализацию большинства компонентов во время тестирования. 13. Test doubles (тестовые дубликаты) В этой главе обсуждаются стратегии применения дублей, таких как моки, стабы и фейки, которые используются для имитации частей системы в изоляции. Это гарантирует, что юнит-тесты остаются локальными и могут запускаться без зависимости от внешних компонентов. 14. Larger testing (более крупное тестирование) В этой главе авторы выходят за пределы юнит тестов и рассказывают про интеграционные, системные и end2end тесты. Они объясняют, как эти более широкие тесты проверяют, что несколько компонентов работают правильно вместе. 15. Deprecation (устаревание) Авторы предлагают рекомендации по выводу из эксплуатации старого или устаревшего кода. Они подчеркивают управление жизненным циклом функций и кодовых путей для поддержания стабильности, позволяя при этом эволюционировать и совершенствоваться. Окончание будет в последнем посте из этой серии. #Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

Research on Enterprise Business Architecture Design Method Based on Domain-Driven Design (Рубрика #Architecture) Я продолжаю читать и делиться рассказами о whitepapers на тему архитектуры и сегодня речь про статью от ученых Huiwen Deng и Yan Zhao из China Aerospace Academy of Systems Science and Engineering, что в Пекине. В этой статье ребята решили объединить подходы из enterprise architecture с практиками DDD (Domain Driven Design) в попытке сблизить корпоративную архитектуру с IT архитектурой, чтобы это ни означало. Ну и все конечно во благо цифровой трансформации:) Для определения бизнес архитектуры авторы вспоминают определение OMG (Object Management Group) из TOGAF (The Open Group Architecture Framework)

The formal blueprint outlining the enterprise’s governance structure, business capabilities, value streams; it clearly defines the enterprise’s governance structure along with its business capabilities, processes, and data

Дальше авторы говорят, что именно она является основой цифровой трансформации и связывает стратегию корпорации с процессами и IT-системами. По факту, она служит неким "каркасом" для построения цифровых предприятий. Дальше авторы рассказывают базу про DDD, а точнее, что - DDD помогает моделировать сложные бизнес-процессы через глубокое понимание домена. - Для этого используются стратегические подходы: subdomains, bounded contexts По мнению авторов DDD дополняет традиционные методы бизнес-архитектуры более детализированным подходом к сложным процессам. Авторы предлагают использовать метамодель, объединяющую стратегии, домены, данные и IT-сервисы. Авторы упоминают 7 моделей в своем подходе: strategy model, organization model, process model, domain model, capability model, data model, IT service model. Первые три модели из этого списка авторы пробегают галопом по Европам, а вот последние четыре разбирают подробнее 1) Domain model: модель состоит из стратегии домена, где определяются сабдомены, доменные объекты и доменные события. Про это подробнее рекомендую почитать книгу Влада Хононова "Learning DDD", про которую я уже рассказывал. 2) Capability model: здесь авторы говорят про базовые возможности и точки расширения, дизайн capability components, а также про solution design. Условно, надо определиться с базовыми компонентами и способами их расширения, а дальше из этих базовых компонентов собирать те решения, которые требуются бизнесу 3) Data model: здесь авторы говорят про модель данных и делают отсылки к классическим подходам ETL/ELT и DWH с data lake. Интересно, что авторы похоже не слышали пока про федерализацию данных и data mesh. 4) IT service model: здесь авторы говорят про state, structure и port. Условно у нас есть изменяемое состояние, сервисы и их взаимосвязи, а также входные и выходные точки. Основной подхода авторов должны являться доменные объекты, что связывают бизнес и IT. Для определения логических границ IT-систем авторы предлагают использовать DDD и определять bounded context, используя single responsibility principle. А с точки зрения бизнес архитектуры выделение общих возможностей помогает бороться с дублями и избыточностью систем. В общем и целом, мне этот whitepaper дался не легко - я легко читал части про DDD, а вот части про enterprise architecture рассыпались на части - у меня было ощущение, что все слова по отдельности я понимаю, но вот смысла в них общего не слишком много, примерно как в старом видео про "Фирму, которая занимается ничем". Возможно, это просто мое предвзятое отношение к бюрократическим и бумажным процессам, что любят ребята из The Open Group, что и придумали TOGAF, который как мне кажется не подходит технологическим компаниям:) #Architecture #Software #DDD #SystemDesign #Whitepaper #Engineering

Comic Agile - Aligning Teams (Рубрика #Humor) Как-то из выступления Manuel Pais, автора Team Topologies, я узнал про этот ресурс. Мануэль показывал в своей презентации комикс про Team Topologies, а я вечером наткнулся на другой прикольный комикс про aligning teams, который тоже смешной и одновременно грустный. #Management #Leadership #Software

[2/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering) Продолжая рассказ про эту крутую книгу, я хотел бы рассказать чуть подробнее о содержании книги, что состоит из 5 частей и 25 глав I. Thesis (тезис) 1. What is software engineering? (Что такое инженерия программного обеспечения?) В этой главе авторы рассказывают основную идею о том, что разработка софта не является одноразовой работой, а приводит к созданию развивающегося продукта. А это значит, что мы не пишем код аля write-once как раньше писали в Perl или сейчас генерирует условный LLM, а мы проектируем софт с учетом изменений, поддержки и долгосрочной жизнеспособности, а не быстрых ad-hoc задач. Хотя если вы пишите одноразовой скрипт, то логично использовать GPT:) II. Culture (культура) 2. How to work well on teams (как хорошо работать в командах) Эта глава фокусируется на навыках сотрудничества, коммуникации и практиках, которые позволяют разнообразным командам эффективно работать вместе, закладывая основу для крупномасштабных проектов. По-факту, только маленькие проект можно сделать в одиночку, а если планируешь что-то большее, то придется объединяться, а значит разработка софта - это командный вид спорта. И для достижения успеха в нем надо прокачивать soft skills:) 3. Knowledge sharing (обмен знаниями) Эта глава подчеркивает важность документирования полученного опыта и insights. Здесь рассказывается про методы и процессы для обеспечения передачи ценных знаний. Забавно, что многие не любят сами писать документацию, но жалуются на ее отсутствие или неактуальность. Я как любитель письменного жанра рекомендую таким людям начать с себя и задать тренд по написанию документов, фиксирующих важные моменты, например, RFC/ADR, агенда встреч, PR/FAQ из подхода "Working backwards" от Amazon (подробнее в моем обзоре этой книги) 4. Engineering for Equity (инженерия для равенства) Изучает, как справедливые процессы, равный доступ к инструментам и сбалансированное распределение рабочей нагрузки помогают поддерживать продуктивную и инклюзивную инженерную среду. Честно говоря, эта глава выбивается из общего списка, так как по всей видимости написана поборниками повестки и инклюзивности. 5. How to lead a team (как руководить командой) Эта глава предоставляет практические рекомендации по руководству командой, подчеркивая четкую коммуникацию, согласование целей и построение доверия для того, чтобы команды могли работать наилучшим образом. 6. Leading at scale (руководство в масштабе) Здесь обсуждаются проблемы, специфичные для управления очень большими командами. Авторы описывают масштабируемые практики управления и структуры, которые помогают поддерживать последовательную производительность и культуру по мере роста команд. 7. Measuring engineering productivity (Измерение производительности инженерии) Эта глава посвящена неформальным и формальным метрикам для оценки эффективности инженерии. Авторы объясняют, как сбалансировать скорость с качеством, подчеркивая, что производительность заключается не только в результатах, но и в деятельности. Эта тема была мне настолько интересна, что я эту главу я давно уже разобрал в деталях в отдельном посте. #Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

"Дети Солнца" в театре-сцене "Мельников" (Рубрика #Culture) На прошлой неделе я был на предпоказе этого спектакля в постаноке молодого режиссера Лизы Дороничевой на сцене Театра — Сцены "Мельников". Спектакль основан на пьессе Максима Горького, который написал ее 120 лет назад сразу после событий Кровавого воскресенья. Я не большой знаток театра, но могу сказать, что постановка мне понравилась, особенно первый акт, в котором мы знакомимся с бытом ученого Павла Протасова, представителя интеллегенции, который полностью погружен в свои исследования и обращает мало внимания на происходяшее вокруг. Мы видим идеализм и стремление к прогрессу Павла, но это имеет мало общего с реальной жизнью и проблемами окружающих, которых в пьессе достаточно много: безответная любовь, семейные конфликты и социальные противоречия, а также эпидемия холеры. Герои пьессы сталкиваются с одиночеством и невозможностью найти общий язык как между собой, так и с абстрактным народом. Второй акт разворачивает основные идеи пьесы, поэтому получается тяжелым и мы видим - Разрыв между интеллигенцией и народом: мы видим пропасть между образованной элитой, мечтающей о светлом будущем, и простыми людьми, живущими в бедности и невежестве. - Идеализм и реальность: герои стремятся к высоким идеалом, но оторванность от реальной жизни приводит к трагедии - Социальное неравенство: мы видим разрыв между Павлом и его слугами, что усугубляет непонимание и приводит к социальным противоречиям - Любовь и одиночество: Личные отношения героев отражают их внутренние конфликты и неспособность к взаимопониманию. - Критика утопических идей: в конце пьессы мы видим как утопические идеалы разваливаются от контакта с реальным миром Интересно, что название "Дети солнца" символизирует стремление героев к знаниям и прогрессу, но также указывает на их оторванность от реальности. Солнце становится метафорой иллюзорного света, который ослепляет героев, мешая им видеть окружающий мир. В самой постановке этот солнечный свет играет ключевую роль - он светит в красивое окно, иногда обжигающе ярко, иногда сквозь дождь, а в начале второго акта его просто нет с нами, что показывает, что настали тяжелые дни. Отдельно отмечу, что постановка выполнена так, что мы оказываемся, фактически, вне времени и если не знать историю написания пьесы, то ни за что не поверишь, что ей 120 лет:) P.S. Кстати, художественным руководителем Театра на Бронной и Театра — Сцена «Мельников» является Константин Богомолов, который осенью прошлого года рассказывал о проектах нового сезона и где было упоминание о "Детях Солнца". #Theater #Culture #SelfDevelopment

Обложки для книг "Software Engineering at Google" и "Делай как в Google. Разработка программного обеспечения"

[1/4] Software Engineering at Google (Делай как в Google. Разработка программного обеспечения) (Рубрика #Engineering) Я читаю и перечитываю эту крутую книгу уже примерно пару лет, как раз с того момента, как она мне доехала с Amazon в 2022 году. Я никогда не читал ее в русском переводе от издательства "Питер", но перевод "Делай как в Google" по меньшей мере озадачивает меня, хотя я привык уже к играм разума российских издателей. Правда, я не читал перевод не из-за его качества, а потому что у меня была книга в оригинальном издании. Если говорить про саму книгу, то она была написана Титусом Уинтерсом, Томом Маншреком и Хайрумом Райтом, а также большим количеством других уважаемых людей из Google. Каждая глава в этой книге написана отдельным коллективом авторов, причем часто изначально в виде whitepaper для конференций разработке софта. Я отметил две особенности, что помешали лично мне проглотить ее быстро - Стиль изложения и динамика меняется от главы к главе - я не могу читать больше одной главы за один раз - Главы написаны академическим языком, а значит достаточно формальным и сложным Кстати: если вы хотите узнать про часть процессов разработки, связанных с continuous delivery, но изложенные простым языком, то рекомендую книгу "Grokking Continuous Delivery", которая тоже родилась в Google, но написана одним человеком и похожа по стилю на комикс. Кстати, я уже рассказывал про книгу "Grokking CD" раньше Если же возвращаться к изначальной книге, то основная цель авторов книги - поделиться своим опытом и уроками, что инженеры Google получили из управления огромной кодовой базой и сложнейшей инфраструктурой. Ребятам было важно не просто нашмалять код по быстрому, но спроектировать его так, чтобы системы можно было поддерживать и развивать с течением времени. Вообще, ключевые идеи такие - Programming over time (программирование с учетом эволюции): в книге подчеркивается, что хорошая программная инженерия — это не просто одноразовое программирование, а поддержка и развитие программного обеспечения в долгосрочной перспективе. - Processes and scale (процессы и масштаб): авторы рассказывают и объясняют смысл процессов и практик, используемых в Google, например, про code review, стратегии тестирования и управление гигантским монорепозиторием. Эти процессы адаптированы к тем нефукнциональным требования и огромным масштабам, которые характерны для Google. - Tools and infrastructure (инструменты и инфраструктура): авторы обсуждают, как специализированные внутренние инструменты и инфраструктура не только поддерживают, но и улучшают сотрудничество и эффективность среди инженеров (примерно про это идет речь в whitepaper "The issue of monorepo and polyrepo in large enterprises", про который я говорил раньше) - Culture and collaboration(культура и сотрудничество): хотя некоторые разделы очень специфичны для Google, книга также подчеркивает важность формирования культуры, которая поощряет эффективное межкомандное сотрудничество и обмен передовым опытом. Частично про это можно почитать в проекте "Google's Project Aristotle", где ребята изучали, а что делает команды продуктивными (я рассказывал про этот проект раньше) - Practical lessons (практические уроки): хотя многие практики уникальны для размера и ресурсов Google, книга содержит ценные сведения о проблемах создания и поддержки крупномасштабного софта В целом, книга рассказывает о принципах создания софта, которые работают на крупном масштабе, но многие из которых уже давно стали стандартом де-факто и которые можно и нужно применять в технологических компаниях независимо от их размера. Условно, когда я рассказываю о лучших инженерных практиках из этой книги и слышу в ответ фразу "Мы же не Google", то у меня возникает вопрос, а точно ли надо быть сотрудником Google, чтобы чистить зубы перед сном или мыть руки перед едой. В следующих постах я кратко расскажу о содержании книги по главам: часть про культуру #Engineering #Management #Software #Development #Processes #Leadership #SRE #DevOps

Giilker Intelligent Four Square Chess (Рубрика #Kids) Жена подарила мне эту игру на новый год. Мы немного поиграли в нее на новогодние праздники, а потом отложили. Но в последнюю неделю я каждый вечер играю со своим старшим сыном в эту игру и она нам очень нравится - у нее простые правила и она динамичная. По картинке видно, что игра представляет из себя поле 5x5, игроки ходят по очереди и должны выставить свои фишки четыре в ряд, побеждает тот, кто сделает это первым. Звучит все достаточно просто, но на самом деле поле состоит из 125 клеток (5*5*5), так как оно трехмерно и фишки можно ставить друг на друга. Поэтому победит тот, кто выставит четыре фишки в любом направлении: вертикальном, горизонтальном или диагональном. Сама игра позволяет играть вдвоем или соревноваться с компьютером - это очень удобно, так как можно потренироваться пока сына нет дома. P.S. Мне так понравилась игрушка, что я купил себе такую же на работу и она приедет ко мне через пару недель:) #ForKids #ForParents #SelfDevelopment #Brain

Analyzing The Impact of UML, BPMN, and ArchiMate Integration from User Perspective (Рубрика #Architecture) Забавный whitepaper про нотации моделирования, к которым я питаю особую любовь еще со времен своего обучения. Авторы решили объединить разные нотации моделирования во благо совместной работы внутри корпораций. Авторы исходят из предпосылок 1) В корпорациях есть много диаграмм разных уровней, созданных при помощи ArchiMate, BPMN и UML и эти диаграммы содеражат большой объем знаний 2) В корпорациях есть много людей, которые умеют использовать эти нотации для проектирования - BPMN для описания бизнес-логики и бизнес процессов - Archimate для описания нюансов корпоративной архитектуры - UML для описания различных приложений и их взаимодействий 3) В корпорациях можно получить значительный буст от объединения этих нотаций между собой Поэтому цель исследования оценить удовлетворение пользователей и удобство использования объединенной нотации. Моя мысль, что большая часть предусловий, на которых строились идеи авторов не выполняются 1) В компаниях нет большого количества актуальных диаграмм с этими нотациями и из них нельзя сформировать общую картину 2) В большинстве компаний нет людей, что легко используют эти нотации (если не считать касты корпоративных архитекторов, которая существует в некоторых больших корпорациях в виде сотен представителей департамента корпоративной архитектуры) 3) Предполагаемый буст достигается за счет использования преимуществ каждой нотации, но вот знающих все три нотации обычно не очень много - я представляю тут диграмму Эйлера-Венна с пересечением кружков-множеств и центральной маленькой частью, которая пренебрежимо мала Интересно, что у меня есть опыт из прошлого, который похож на описанное в статье - в своем магистерском дипломе я описывал реинжиниринг бизнес-процессов в одной организации, используя кастомную нотацию, которую меня попросили собрать. Там мы использовали микс eEPC и IDEF0 - меня попросил их скрестить мой тогдашний руководитель и использовать для моделирования изменений. В общем, кроме меня эту комбинированную нотацию не понимал почти никто, так как большая часть задействованных не знала ни eEPC, ни IDEF0, а также честно говоря им было по...й, так как их интересовали только результаты самих изменений в процессах. С тех пор я решил, что экспериментировать в нотациях моделирования - это не лучшая идея. В итоге, сама идея авторов статьи сомнительна, но ок ... пойдем к тому, а что и как они оценивали 1) Ребята взяли фреймворк FUEML (Framework for Usability Evaluation of Modeling Langueges) из книги "Usability evaluation of modeling languages: An empirical research study" 2) Из этого фреймворка они выбрали lernability, memorability, user satisfaction, по которым решили сравнивать отдельно диаграммы в Architmate и комбо-диаграммы с миксом из трех нотаций - Learnability - это оценка того, насколько просто научиться пользоваться новой нотацией и насколько быстро получается выполнять задачи, какой уровень ошибок, etc - Memorability - насколько устойчиво запоминается информация о нотации, синтаксисе и семантике - User satisfaction - это отзывы пользователей о том, насколько они довольны использованием языка, его полнотой, качеством и удобством 3) Авторы изучали - Насколько быстро респонденты разбирались с двумы диаграммами: базовой A и расширенной B (кстати, диаграмму с комбинацией нотаций у меня открыть не получилось - авторы, видимо, отменили права на шаринг) - Насколько быстро авторы выполняют задачи с использованием моделей - Насколько много ошибок в процессе обучения - Фидбек пользователей В итоге, авторы получили примерно следующее

Overall, respondents thought that the integration of BPMN, ArchiMate, and UML was ”easy”. Modeling complicated systems is another ”very useful” application of this combination.

Правда, их респонденты преимущественно знали все три нотации моделирования:) #Software #Architecture #Engineering #UML #SystemDesign #Whitepaper

Вопросы, для оценки реалистичности стратегии визионера (Рубрика #Strategy) В прошлом посте я рассказывал про Theranos и подход к стратегии от Элизабет ХЗолмс. Там я указал список разных точек зрения, под которыми стоит посмотреть, чтобы попробовать отличить настоящую стратегию от фейковой, а в этом посте я чуть подробнее их раскрою 1) Четкое и реалистичное видение Настоящая стратегия: Представляет ясное, вдохновляющее и достижимое видение, которое соответствует миссии и ценностям организации. Цели конкретны, измеримы и выполнимы. Признаки мошенничества: Слишком расплывчатые или грандиозные заявления без реалистичного плана или осуществимости. Обещания невероятных результатов с минимальными усилиями — тревожный знак. 2) Детальный план реализации - Настоящая стратегия: Включает конкретные шаги, распределение ресурсов, контрольные точки и планы на случай непредвиденных обстоятельств для достижения целей. - Признаки мошенничества: Отсутствие конкретных деталей о том, как будут достигнуты цели, или чрезмерное использование модных слов и абстрактных концепций без четкого плана действий. 3) Участие заинтересованных сторон - Настоящая стратегия: Активно привлекает членов команды и заинтересованных лиц к процессу планирования и принятия решений, способствуя сотрудничеству и прозрачности. - Признаки мошенничества: Действует в изоляции или в условиях секретности, препятствуя участию других. Мошенники часто используют срочность, чтобы избежать проверки. 4) Эмоциональная привлекательность vs. Манипуляция - Настоящая стратегия: Вдохновляет через искреннее общение, эмоциональный интеллект и соответствие общим ценностям. - Признаки мошенничества: Использует тактику давления, страх или чрезмерное возбуждение, чтобы побудить к импульсивным действиям без должной оценки. 5) Соответствие долгосрочным целям - Настоящая стратегия: Учитывает текущие приоритеты в сочетании с долгосрочными целями и демонстрирует адаптивность к изменяющимся обстоятельствам. - Признаки мошенничества: Сосредотачивается на краткосрочных выгодах или нереалистичных обещаниях без учета долгосрочной устойчивости. 6) Прозрачность и доверие - Настоящая стратегия: Вызывает доверие через открытое общение, проверяемые утверждения и надежное руководство. - Признаки мошенничества: Использует чрезмерно сложные структуры для сокрытия намерений или избегает предоставления проверяемой информации об организации или руководстве. 7) Реалистичность обещанных результатов - Настоящая стратегия: Устанавливает достижимые цели, подкрепленные данными, анализом рынка и реалистичными прогнозами. - Признаки мошенничества: Делает преувеличенные заявления о гарантированном успехе или доходах, которые звучат слишком хорошо, чтобы быть правдой. Чем больше красных флажков выскакивает при анализе визионерской стратегии, тем менее вероятно, что это реальная возможность, а не скам:) #Management #Leadership #Strategy

Клубная встреча "Стратегия визионеров" от SouthHub (Рубрика #Management) В один из вечеров на этой неделе я был на клубной встрече SouthHub, где мы обсуждали вопросы миссии, видения, стратегии и того, как эти высокие материии влияют на компанию. Правда, у нас был и практический интерес - как распознать, что тебе про эту миссию, видение и стратегию рассказывает визионер, наподобие, Стива Джобса, Илона Маска, Билла Гейтса или мошенник, наподобие, Элизабет Холмс, Сэма Бэнкман-Фрида или Адама Ноймана. Для подготовки к обсуждению нас попросили перед встречей глянуть документальный фильм "The Inventor: Out for Blood in Silicon Valley" ("Изобретатель. Жажда крови в Силиконовой долине"), который рассказывает историю единорога Элизабет Холмс под названием "Theranos", который обещал изменить сферу медицинских анализов. Сам фильм отлично рассказывает историю в динамике, приводя кусочки публичных интервью с Элизабет, а также остальными ключевыми участниками событий, поэтому рекомендую его посмотреть, если еще не видели - больно история интересная вышла. Если же возвращаться к вопросу про отличия визионера от мошенника, то мы в ходе обсуждений пришли к выводу, что 1) Все высокие материи в виде миссии, видения, стратегии можно свести к высокоуровневым вопросам - Зачем мы что-то делаем? - Миссия - что конкретно мы делаем? - Видение - Как мы это делаем? - Стратегия 2) Визионеры из списка выше (Джобс, Маск, Гейтс) отличаются от мошенников из списка ниже (Холмс, Бэнкман-Фрид, Ноймана) только результатами. Если бы у последних трех все сошлось, то мы бы продолжали говорить о них, как о звездах мира бизнеса. По-факту, многие визионеры топят со своей стратегией до талого и у кого-то получается довести "fake it until make it" до состояния made, а у кто-то остается у разбитого корыта 3) Но результаты визионера - это слишком lagging indicator, то есть мы хотим понять раньше выйдет ли что-то из задумки очередного визионера. Для этого можно задать ряд вопросов к его стратегии и проверить насколько консистентно выглядят ответы. Например, можно посмотреть под разными углами, например, так - Четкое и реалистичное видение - Детальный план реализации - Участие заинтересованных сторон - Эмоциональная привлекательность vs. Манипуляция - Соответствие долгосрочным целям - Прозрачность и доверие - Реалистичность обещанных результатов В следующем посте я чуть подробнее раскрою эти пункты, но В итоге, сразу могу сказать, что по слишком многим из этих пунктов подход Элизабет Холмс к построению визионерской стратегии не выдерживает критики. Возможно, поэтому никто из профессиональных инвесторов и медицинских фондов не вкладывался в эту инициативу, а деньги и влияние привлекались от около-государственных структур и столпов политики. В общем, изначально это было сомнительно, но ок ... а потом стало совсем скамом. #Management #Leadership #Strategy

Стипендия Т-Образования (Рубрика #Edu) Уже в четвертый раз открылась ежегодная стипендиальная программа для талантливых студентов. Она доступна для студентов российских вузов очной формы обучения и любого курса, кроме выпускного. Для попадания в программу нужно будет пройти отбор (экзамен, портфоли и интервью), причем пройти экзамен и подготовить портфолио надо до 7 апреля включительно. В программе есть 2 трека: аналитика и разработка. Для тех, кто получит стипендию будут доступны плюшки в виде - 25к рублей в месяц в течение учебного года - Ментор в виде сотрудника Т-Банка - Доступ к образовательным материалам компании, куда входят курсы, лекции и т.д., а также приглашения на закрытые отраслевые мероприятия - Упрощенный отбор в штат на работу в Т-Банке после окончания стипендии В общем, если бы в мое бытие студентом была такая программа, то я бы точно попробовал в ней поучаствовать (но скорее всего не прошел по конкурсу). P.S. Если вспоминать про стипендиатов прошлых лет, то набор их достижений на школьном и университетском уровне действительно впечатляет. Мне нравится, что мы поддерживаем студентов в их стремлении к получению качественного образования, а также что многие из них после этого попадают к нам в штат и показывают хорошие результаты уже в работе. #Edu #SelfDevelopment

Иллюстрации для статьи "Adaptive Enterprise Architecture: Towards a model". Качество изображений оригинальное (в pdf они были настолько же плохими с точки зрения разрешения)

Adaptive Enterprise Architecture: Towards a model (Рубрика #Architecture) Недавно я решил почитать whitepapers по enterprise architecture и наткнулся на статью ученых из Морокко, где они пытаются скрестить ежа с ужом, а точнее корпоративную архитектуру со скрамом:) В начале статьи авторы отмечают, что текущие подходы к корпоративной архитектуре (TOGAF, Zachman) не обладают необходимой гибкостью для обработки быстрых, разноуровневых изменений, что характерны для модных ныне цифровых трансформаций. Они сосредоточены на реактивных процессах, ориентированных на заполнение кучи документов и с их помощью сложно управлять непредвиденными изменениями. Дальше авторы решают сформулировать набор критериев для адаптивной корпоративной архитектуры, куда входят такие вещи как 1) Support multi-level dynamics (поддержка многоуровневой динамики) - изменения бывают на разных уровнях и идут с разной скоростью, а значит архитектурный процесс должен уметь работать с каждым типом изменений. Авторы отмечают, что стандартный подход с архитектурой as-is и to-be уже не является статичным, а подвергается различным изменениям, что надо учитывать в архитектурных процессах 2) Sensing of change (ощущение изменений) - процесс должен поддерживать ощущение идущих вокруг изменений и позволять планировать свои инициативы для адаптации к изменениям 3) Process of adaptation (процесс адаптации под новые потребности) - это ключевая часть подхода авторов, что называется adaptive enterprise architecture 4) Complexity of change management (комплексность управления изменениями) - TOGAF и Zachman проваливают этот критерий, ребята хотят подход, который будет сильно проще с точки зрения управления изменениями 5) Handling of unforseen changes (обработка непредвиденных изменений) - это нужно для современных корпораций, что сталкиваются с высокими темпами непредвиденных изменений в своем бизнес окружении. 6) Explicit management of adaptability trade-offs - авторы отмечают важность явного управления компромиссами по адаптивности к изменениям. Сейчас это зачастую просто одно из нефункциональных требований или атрибутов качества решений, а в новом подходе им надо управлять явно 7) Evaluation of adaptation (эволюция адаптации) - для управления адаптацией ее надо уметь измерять, а занчит нам нужны метрики внутри процесса корпоративной архитектуры Дальше авторы сравнивают по этим критериям разные подходы к корпоративной архитектуре и оказывается, что все они не удовлетворяют критериям. Они объединяют подходы в группы 1) Approaches based on guidelines (Zachman, TOGAF, Koffi A.D, LEAP, DYA) 2) Integration oriented approaches (Shmidt R & al, Zimmerman A & al) 3) Co-evolution oriented approaches (DEEVA, ACEM, ...) И дальше авторы решают предложить свой подход, который удовлетворяет критериям и полагается на проверенные временем agile подходы, а точнее на Скрам. Дальше они рассказывают о том, какой Скрам замечательный, а потом натягивают его на архитектуру 1) У нас появляется роли architecture owner, business/IT owners. Первый отвечает за стратегический alignment, а вторые за оптимизацию бизнес-процессов и технического решения 2) Работа идет в циклах по 2-4 недели и используются скрам ритуалы: weekly cross-owner syncs, architecture reviews для обеспечения фидбека 3) Появляется архитектурный беклог, в котором приоритизируются изменения корп архитектуры, а также есть KPI и отслеживание движения As-Is / To-Be на графиках Все остальные ритуалы agile про связь бизнеса и IT остаются на месте, просто EA беклог и ритуалы адаптивной корпоративной архитектуры живут рядом. Для меня это whitepaper показался натягиванием совы на глобус без особых объяснений как это будет работать на практике, а не на бумаге:) #Architecture #Software #Management #Governance #Engineering

Обложки книг "Hooked: How to Build Habit-Forming Products" и "На крючке" и несколько иллюстраций самой модели.

Hooked: How to Build Habit-Forming Products (На крючке) (Рубрика #Management) Эта уже классическая книга Нира Эяля рассказывает о том, как создавать продукты, которые захватывают пользователей и становятся неотъемлемой частью их повседневной жизни. В книге представлена модель крючка в виде процесса из четырех зацикленных шагов, что позволяют формировать привычки пользователей. В самой модели следующие четыре части 1) Trigger (триггер): запускает поведение пользователя через внешние сигналы (например, уведомления) или внутренние мотивации (эмоции или мысли). 2) Action (действие): поведение, выполняемое в ожидании вознаграждения, которое должно быть максимально простым для пользователя. 3) Variable reward (переменное вознаграждение): результат действия, который удерживает пользователей благодаря своей непредсказуемой природе. 4) Investment (инвестиция): вклад пользователя в виде времени, данных, усилий или денег, что повышает вероятность возвращения к продукту. Автор утверждает, что использование такой модели позволяет создавать продукты, что создают привычку у пользователей, что повышает лоялность клиентов, а уже это можно использовать монетизируя лояльность и зарабатывая больше. Отдельно автор разбирает этические вопросы и отмечает, что лучше делать продукты, формирующие привычки, которые действительно улучшают жизнь пользователей. Иначе можно скатиться к роли, аналогичной наркодиллеру, который полагается на привычку к продукту, что разрушает жизнь потребителей. Используя эту модель, можно разобрать подходы известных продуктов 1) Duolingo создал формирующий привычку опыт изучения языков: - Триггер: отправляет ежедневные уведомления о целях изучения языка. - Действие: предлагает геймифицированные, легко выполнимые уроки. - Переменное вознаграждение: предоставляет очки опыта и достижения за серии успехов. - Инвестиция: отслеживает прогресс и адаптирует пути обучения на основе результатов пользователя. Я сам пользуюсь duolingo и у меня нерпрерывный streak сейчас в 2 года 2) TikTok стал крайне привлекательным, используя модель hooked: - Триггер: внешние триггеры включают видео, которыми делятся друзья, в то время как внутренние триггеры обращаются к желанию развлечься. - Действие: предлагает простой процесс создания аккаунта и легкий просмотр видео. - Переменное вознаграждение: представляет постоянный поток разнообразных, персонализированных коротких видео. - Инвестиция: позволяет пользователям создавать и делиться своими собственными видео, увеличивая привязанность к платформе. 3) Slack стал популярной платформой для коммуникации на рабочем месте и она тоже применяет модель hooked: - Триггер: использует как внешние, так и внутренние триггеры для привлечения внимания пользователей. - Действие: предлагает удобный интерфейс для легкого обмена сообщениями и участия в каналах. - Переменное вознаграждение: доставляет вознаграждения в виде положительной обратной связи и уведомлений о выполнении задач. - Инвестиция: поощряет вклад пользователей через обсуждения и участие в проектах. Мы использовали Slack до того, как перешли на наш мессенджер Time. Но есть у модели и стандартные проблемы, которые могут уменьшать ее эффективность 1) Несоответствие потребностям пользователей - неспособность понять реальные проблемы пользователей или создание решений для несуществующих проблем. 2) Чрезмерное усложнение модели - слишком сложный UX или слишком много фичей могут оттолкнуть пользователей 3) Неэффективные системы вознаграждений - если вознаграждения слишком предсказуемы, то это плохо. Одновременно плохо, если они неконсистентны между собой и не поддерживают интерес и мотивацию пользователей. 4) Пренебрежение фазой инвестиций - слишком слабое или слишком сильное поощрение вклада пользователей в приложение приведет к тому, что они сорвутся с крючка 5) Этические проблемы - привычки должны приносить пользу клиентам иначе легко провалиться на темную сторону силы #Management #ProductManagement #Econimics #PopularScienceHooked: How to Build Habit-Forming Products (На крючке) (Рубрика #Management)

The issue of monorepo and polyrepo in large enterprises (Рубрика #Architecture) Недавно прочитал старенький whitepaper 2019 года от Nicolas Brousse из Adobe с анализом подходов к управлению репозиториями исходного кода в крупных компаниях. Собственно сравниваются подходы монорепозитория и полирепозитория (множества отдельных репозиториев). Монорепы используют такие компании как Google, Meta, Microsoft, а полирепозитории были в Amazon, Netflix, Lyft и так далее. Автор ссылается на исследование "Advantages and disadvantages of a monolithic repository: a case study at Google", в котором есть хорошее сравнение компромиссов монореп и полиреп и подсвечиватся плюс монорепы вида, что монорепы

Encourages consistent and high-quality code, and empowers engineers to study and learn from the institutional knowledge of their company, crystallized in the form of source code

Дальше автор рассматривает разницу через три призмы 1) Cultural Alignment (культурное соостветствие) Структура репозиториев отражает корпоративную культуру. Монорепы подходят для коллаборативных сред (например, Google с философией «открытого сотрудничества»), а полирепозитории — для культур, ориентированных на автономию (например, Netflix с принципом «свободы и ответственности»). Интересно, что у нас полирепозиторий в Т-Банке 2) Team Cognition (командное познание) Монорепозитории разрушают функциональные силосы, способствуя целостному пониманию задач за счёт видимости общего кода и снижения коммуникационных барьеров, что коррелирует с повышением качества софта. 3) Tradeoffs (компромиссы) Обе модели имеют технические сложности (например, масштабируемость монорепозиториев), но монорепы стимулируют культурные изменения, улучшающие конкурентоспособность через DevOps-практики и инновации без ограничений. В итоге, автор подчеркивает, что технические аспекты важны, но культурные преимущества монореп - Усиление коллаборации - Устранение разрозненности - Оптимизация процессов разработки особенно ценны для крупных компаний, ориентированных на гибкость и качество P.S. На тему различий рекомендую почитать сравнение от Carlos Arguelles, инженера, что долго проработал в Amazon на CI/CD инфрой, потом ушел в Google на несколько лет, а потом вернулся в Amazon. Я раньше уже разбирал его статью "How Amazon and Google view CI/CD in an entirely different way". #CI #SRE #Architecture #Software #Infra #QA