Comic Agile - Aligning Teams (Рубрика #Humor)

Как-то из выступления Manuel Pais, автора Team Topologies, я узнал про этот ресурс. Мануэль показывал в своей презентации комикс про Team Topologies, а я вечером наткнулся на другой прикольный комикс про aligning teams, который тоже смешной и одновременно грустный.

#Management #Leadership #Software

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

[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

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

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

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

Residuality Theory, random simulation, and attractor networks (Рубрика #Architecture)

Недавно прочитал этот whitepaper Barry O'Reilly, который он написал еще в 2022 году. Я решил изучить этот whitepaper после двух выступлений автора, о которых я уже рассказывал ранее
1) An Introduction to Residuality Theory
2) The Philosophy of Architecture
Мне показались его выступления на тему его resudiality theory интересными и я прочитал paper, про который хочу рассказать кратко ниже
1) Барри придумал новый подход к архитектуре софта, который фокусируется на создании систем, способных адаптироваться к непредвиденным вызовам и сложностям.
2) Предыдущие подходы в основном основывались на requirements management и risk management, которые должны были конвертировать неизвестные неизвестные во что-то более управляемое, но конечно не могли это сделать
3) Подход автора включает в себя random simulation как ключевой компонент для выявления и решения потенциальных проблем заранее.
4) Random simulation включает в себя моделирование различных случайных стрессоров для наблюдения за паттернами и прогнозирования потенциальных "residues" или новых состояний, возникающих из этих стрессоров (метод Монте-Карло)
5) Анализ стрессоров выглядит примерно так: инженеры выявляют и анализируют случайные стрессоры, с которыми софт может столкнуться в предполагаемой среде. Это помогает в проектировании систем, способных справляться с неожиданными событиями или ситуациями.
6) Под влиянием различных стрессоров система стремится к устойчивым состояниям, аттракторам. Выявление этих аттракторов помогает понять, как система будет вести себя в различных условиях.
7) Гиперлиминальность описывает как упорядоченная система (софт) живет внутри неупорядоченной (бизнес-среда). Эта концепция включает в себя понимание перехода от текущего состояния к новому состоянию (residue) из-за стрессора. Одновременно, автор определяет hyperliminality coupling так

If two nodes in a network each have a relationship with a third node, then those two nodes are very likely to have a relationship. Therefore, if a stressor in the wider hyperliminal system interacts with two software components, then those two components can be considered coupled.

8 ) Если кратко описывать основные утверждения теории автора, то они выглядят так

1. Enterprise software systems are ordered systems that live in disordered environments - hyperliminal systems.
2. These systems will experience stress that they have not been designed for because the disorderedenvironment is by definition unpredictable.
3. The system’s future is a function of residue, whatever is left over after it is stressed.

9) Архитектуру Барри описывает, используя Boolean Networks (Kauffman Networks), где есть три параметра NKP (N - количество нод, K - наибольшее количество связей ноды в сети, P - bias в сторону конкретного результата при обработке сигнала). Барри матчит это на архитектуру софта так
- N - относится к программным компонентам
- K - описывает связи или вызовы между компонентами
- P - увеличивается при использовании контрактов, схем, политик или уменьшении сложности кода (количества ветвлений в нем)
Собственно, эти параметры определяют какие аттракторы будут в сети и сколько их будет. Для описания всего это добра нужны adjacency matrices для маппинга компонентов одного типа между собой, а также incidence matrices, где описывается маппинг стрессоров на компоненты
10) Процесс использования подхода выглядит так
- Сначала надо спроектировать наивную архитектуру и провести random simulation для нее
- Дальше надо использовать incidence matrices для отображения стрессоров относительно residues, процессов, потоков и компонентов программного обеспечения.
- Стоит разделять стрессоров на обучающие и тестовые наборы для валидации процесса проектирования и расчета индекса остаточности (Ri).

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

#Architecture #Software #SystemDesign #Engineering #DistributedSystems

The Creative Programmer (Креативный программист) (Рубрика #SelfDevelopment)

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

Если возращаться к самой книге, то автор выделяет следующие столпы креативности
- Technical knowledge (технические знания): без hard skills в инженерии никуда - сложно быть креативным без знания технической базы. Я уже как-то рассказывал про путь в сторону staff engineer и как прокачивать харды для становления крутым IC (individual contributor)
- Collaboration (сотрудничество): это то, что обычно называют soft skills, а точнее тут про эффективное общение в команде и обмен идеями. Недавно у меня был доклад как раз на эту тему
- Constraints (ограничения): часто именно наличие ограничений стимулирует инновации для их преодолениея
- Critical thinking (критическое мышление): сомнение в предположениях и улучшение решений. У меня есть целая подборка ресурсов про критическое мышление
- Curiosity (любознательность): стремление к постоянному обучению и разнообразным интересам
- Creative state of mind (творческое состояние ума): развитие концентрации и внутренней мотивации
- Creative techniques (творческие техники): методы, такие как использование метафор и мозговой штурм

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

В последней главе есть много креативных практик из инструментария писателя, художника и инженра. Поэтому желающий повысить свою креативность может взять эти инструменты и начать их практиковать. А для отслеживания прогресса можно взять Creative Programming Problem Solving Test, позволяющий отслеживать и измерять прогресс в развитии креативности.

P.S.
Вопросы креативности в software engineering очень важны, например, ребята из Google исследовали их и недавно написали интересный whitepaper "Developer Productivity for Humans, Part 8: Creativity in Software Engineering", который я уже разбирал раньше.

#Thinking #Engineering #SelfDevelopment #Software #Brain

Measuring developer productivity: A clear-eyed view (Рубрика #Management)

Интересная интервью на тему developer productivity, которое брал Кент Бек у Аби Нода,. Оба джентельмена - уважаемые люди в среде разработчиков
- Кент Бек - автор XP (extrem programming), подписант Agile Manifesto, адепт TDD (test driven development). Недавно я рассказывал про его интересное выступление "Tidy First", а до этого делал подробный разбор этой свежей книги "TIdy First"
Аби Нода - cооснователь и генеральный директор DX - платформы аналитики для оценки и улучшения продуктивности и опыта разработчиков. Также Аби - соавтор исследований про Developer Experience, про которые я рассказывал раньше: "DevEx: What Actually Drives Productivity" и "DevEx in Action"

Инетереса этому интервью придавало то, что Кент Бек всегда выступал последовательным критиком метрик вокруг developer productivity, а Аби Нода строит на этом свой бизнес. И вот, что они обсудили

1) Goodhart’s Law (Закон Гудхарта)
В интервью подчеркивается, что когда метрика становится целью, она теряет свою эффективность — это основная идея закона Гудхарта. Это приводит к тому, что чрезмерная зависимость от одной числовой метрики может привести к искажению стимулов, из-за чего команды будут стремиться «обойти систему», а не реально улучшать качество работы. Аби Нода про это знает, поэтому у него целая четверка метрик, что балансируют друг друга: speed, effectiveness, quality, impact. Отдельно Аби отмечает три важных момента при внедрении системы измерения developer productivity

- Communicating and following through on being an ally to developers
- Never measuring metrics like diffs per engineer at the individual level - that's something we stipulate in our framework and build into our product
- Using it within this basket of metrics - developer experience is as important as speed, and quality balances both

2) Developer experience (опыт разработчиков)
Основное внимание уделяется созданию поддерживающей и комфортной среды для разработчиков. Вместо того чтобы просто измерять результаты, акцент делается на предоставлении разработчикам необходимых инструментов, процессов и культуры для их успеха, что в итоге повышает продуктивность и качество работы.
3) Using benchmarks (использование бенчмарков)
Аби Нода предлагает использовать отраслевые или внутренние бенчмарки как ориентир для понимания того, где находится команда относительно лучших практик. Однако подчеркивается, что бенчмарки следует адаптировать к уникальному контексту команды, так как различия в типе проектов, составе команды и рабочей культуре требуют гибкого подхода. Это очень важные ремарки относительно бенчмаркинга - если сравнивать теплое с мягким, то получить осмысленные результаты не получиться
4) Implementing metrics (реализация метрик)
При проектировании и внедрении метрик продуктивности акцент делается на сбалансированном подходе, который избегает узкой фокусировки только на количественных результатах. Лучшие практики включают определение метрик, которые эмпирически обоснованы, и использование их как ориентиров для постоянного улучшения, а не как самоцели. Общая рекомендация — применять рефлексивный и итеративный процесс разработки метрик с учетом обратной связи от разработчиков и руководства.

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

P.S.
Я подписан на рассылку от платформы Аби Нода GetDX, где попадаются хорошие материалы на тему продуктивности инженеров. Рекомендую.

#Productivity #Engineering #Metrics #DevOps #DevEx #Software

The Engineering Unlocks Behind DeepSeek | YC Decoded (Рубрика #AI)

Интересный 13 минутный разбор DeepSeek R1 от ребят из Y Combinator, который фокусируется не на хайпе, а на инженерных вещах. Основные моменты разбора такие

1) Deepseek анонсировала логическую модель R1, которая обеспечивает сопоставимую производительность с OpenAIo1 при меньших затратах.
2) Это вызвало панику в социальных сетях и снижение рыночной капитализации Nvidia на 600 миллиардов долларов.
3) Но DeepSeek - это не новый игрок на рынке. Они публикуют результаты своих исследований и модели весов, в отличие от других крупных лабораторий, таких как OpenAI и Google DeepMind. И многие результаты уже были опубликованы ранее, например, они оптимизировали обучение в fp8 и исправление накопления ошибки
4) Важно различать модели DeepSeek-R1 и DeepSeek-V3
- DeepSeek V3 обеспечивает производительность, сопоставимую с GPT-4 и другими базовыми моделями.
• R1 является reasoning моделью, построенной на основе V3, и достигает производительности, сравнимой с OpenAI o1 и Google Gemini Flash 20.
5) В V3 они использовали архитектуру, что активирует только 37 миллиардов параметров для каждого предсказания, что экономит массу вычислений, а также использовали технологии multi-head latent attention (mla) для уменьшения объема памяти и увеличения пропускной способности.
6 ) Для R1 они придумали интересную схему обучения с подкреплением (reinforcement learning)
7) Часть хайпа вокруг R1 была свзяана с доступностью модели через веб-сайт и приложение Deepseek. Сама модель предлагала сравнимую производительность за небольшую часть стоимости других моделей.
8 ) Большая часть шумихи связана с ошибочными представлениями о стоимости обучения, сумма была указана для финального обучения модели без
9) Методы DeepSeek можно воспроизвести для создания своих моделей, например, Лаборатория Калифорнийского университета в Беркли применила эти методы для создания небольших reasoning моделей всего за 30 долларов.
10) Так как это видео от Y Combinator, то они заканчивают идеей о том, что на переднем краю развития AI есть место для новых игроков, которые могут подвинуть старожилов за счет оптимизации рабочих нагрузок GPU, улучшения софта и так далее. А все это приводит к уменьшению стоимости внедрения AI в конечные продукты, что делает текущий момен подходящим временем для создания стартапа.

#AI #Engineering #Software #ML #Architecture

Cross-layer Enterprise Architecture Evaluation: An Approach to Improve the Evaluation of TO-BE Enterprise Architecture (Рубрика #Architecture)

Продолжая изучать статьи по архитектуре, я наткнулся на статью про подходы к оценке целевого состояние корпоративной архитектуры. Статья уже довольно старенькая, но ключевые слова, что интересовали меня в ней оказались. Если обобщать эту статью, то авторы фокусируются на процессе оценки, но описывают и процессы EA (enterprise architecture) в общем, а также показывают как процесс evaluation выглядит в разных подходах, а потом предлагают свой:) Все конечно выглядит супер-бюрократично и мало применимо, но знать про эти концепции может быть полезно

Ребята описывают процесс EA в общем
1) Infortmation technology strategic planning - фактически это стратегическая часть для создания vision в плане развития IT для поддержания миссии и стратегии всей компании
2) Enterprise architecture planning - это часть с планированием корпоративной архитектуры, что состоит из построения версии AS-IS, построения целевой версии TO-BE, а такжее создания плана для преодоления разрыва между этими состояними
3) Enterprise architecture execution - эта часть корпоративных архитекторов обычно уже не интересует, так как с их стороны "пули вылетели"

Процесс оценки архитектуры появляется на втором шаге и важен он тем, чтобы убедиться, что в целевой архитектуре учтены все quality attributes (атрибуты качества). Но все усложняется тем, что в корпоративной архитектуре ребята любят слои и предлагают размышлять отдельно про stgrategy, business, information, application, technology. А предыдущие подходы к оценке целевой корпоративной архитектуры хоть и предлагали некоторые атрибуты качества и способы их измерения делали это не консистентно.
Это как в Простоквашино: почему Печкин злой был - у него велосипеда не было. А тут не было консистентного подхода к оценке, но авторы этого исследования предлагают свой процесс.

Надо критерии оценивать сквозь все уровни и по следующей методологии
1) Recognition phase - здесь предполагается, что quality attributes уже известны в компании, поэтому надо просто подобрать для них критерии оценки, изучая стандарты, референс модели и документацию. Важно сделать это по всем уровням, упомянутым выше
2) Analysis phase - для каждого из критериев, определенных на предудущем этапе, надо определить метрики для измерения
3) Mapping phase - здесь надо сделать маппинг артефакты из EA на индикаторы для измерения quality attributes. Если артефактов нет для оценки какого-то из атрибутов качества, то надо запустить процесс его создания (звучит бюрократически)

Вот такие бенефиты авторы выделяют в своем подходе

- This approach improves the comprehensiveness and integrity of the evaluation by considering the details of all EA layers.
- This approach allows us to examine and determine the maturity level of each layer of the EA. Therefore, the evaluation of EA plans with different scopes is possible by this approach.
- This approach can improve the EA plan by applying all criteria, metrics and corresponding indicators defined in the process of evaluation the EA plan.
- This approach simplifies tracing of EA imperfections.

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

#Whitepaper #Architecture #EA #Software #Engineering #SystemDesign #Engineering

Драйв (Drive: The Surprising Truth About What Motivates Us) (Рубрика #Management)

Недавно я прочитал эту классическую книгу Даниэля Пинка (обложки в отдельном посте), которая была написана в конце 2000-х годов. В то время она звучала свежо и бросала вызов традиционным представлениям о мотивации, особенно подходу «кнут и пряник», основанному на вознаграждениях и наказаниях. Дэниель смешал фокус на внутренней мотивации, а не внешних стимулах. Автор хорошо вплетал в свое повествование результаты исследований ученых, таких как Дэниеля Канемана и его книгу "Thniking, Fast and Slow" (подробности в моем посте) или Дэна Ариели и его книгу "Predictably Irrational" (подробности в моем посте).

По-факту, Дэниэль Пинк предлагает модель мотивации 3.0, которая основывается на трех столпах
1) Автономия: Желание контролировать свою работу и принимать собственные решения. Пинк подчеркивает, что автономия способствует вовлеченности и креативности, позволяя людям самостоятельно направлять свои усилия.
2) Мастерство: Стремление улучшать свои навыки и достигать совершенства в значимых задачах. Это требует постоянного обучения и упорства.
3) Цель: Необходимость вносить вклад во что-то большее, чем собственные интересы. Связь работы с более высокой миссией усиливает мотивацию и удовлетворение.

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

В итоге, по Пинку есть 3 модели мотивации
1) Мотивация 1.0 — выживание
2) Мотивация 2.0 — вознаграждения/наказания
3) Мотивация 3.0 - внутренняя мотивация на основе автономии, мастерства и цели
Собственно, надо стремиться с мотивации 3.0, но для этого компании должны «платить достаточно, чтобы убрать деньги с повестки дня», чтобы сотрудники могли сосредоточиться на более значимых стимулах. Чем-то эти уровни мотивации напоминают пирамиду Маслоу

Пинк выделяет два типа поведения у людей
1) Тип X - внешне мотивированные
2) Тип I - внутренне мотивированные.
Поведение типа I более устойчиво, так как опирается на возобновляемые внутренние ресурсы, такие как страсть и любопытство.

Книга Пинка написана очень просто и достаточно популярна, но к ней и ряд замечаний
1) Автор по кругу повторяет мысли про автономию, мастерство и цели без особых изменений и развития темы
2) Автор упоминает исследования, что поддерживают его мысли, но почти не упоминает исследования, которые могли бы опровергнуть его выводы, создавая впечатление предвзятости.
3) Некоторые рецензенты считают описание мотивации на рабочем месте слишком упрощенным. Например, Пинк предполагает, что развитие внутренней мотивации автоматически улучшит производительность, игнорируя такие факторы как обучение сотрудников или различия в индивидуальных целях.
4) Центральный аргумент о переходе к внутренней мотивации кажется некоторым критикам преувеличенным. Они отмечают важность внешних стимулов во многих рутинных или некреативных профессиях, которые Пинк практически не рассматривает.
5) Многие рецензенты указывают на то, что *Drive* лишь популяризирует уже существующие психологические теории (особенно теорию самодетерминации), не добавляя существенных новых идей.
6) Книга критикуется за недостаток конкретных шагов по внедрению идей в реальной практике.
7) Акцент на автономии как ключевом факторе мотивации может быть неактуален для всех культур. Критики отмечают ограниченную применимость модели Пинка в странах с более строгими рабочими структурами или другими культурными нормами. Рекомендую почитать на тему разнообразия культур книгу "The culture map" (подробнее в моем посте)

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

#Psychology #Economics #Brain #SelfDevelopment