ArchDays 2024 (Рубрика #Architecture)

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

В общем, если вас интересует архитектура софта, то покупайте оффлайн билет и приходите утром 1 ноября в Radisson Collection Hotel в Москве. Если не получается быть оффлайн, то можно купить онлайн билет и посмотреть все в прямом эфире.

P.S.
Кстати, я выступал на всех конференциях ArchDays, что были до этого с разными докладами на тему архитектуры. По ним даже можно отследить как менялась архитектурная повестка у нас в компании:)
1) 2019 - Эволюция web’а tinkoff.ru за последние 3 года (youtube)
2) 2020 - Архитектура в масштабе или как мы в Tinkoff принимаем архитектурные решения (youtube, статья с расшифровкой)
3) 2021 - Дизайн секции как проверка навыков проектирования систем на собеседованиях (youtube, статья с расшифровкой)
4) 2022 - Как подготовиться и пройти System Design Interview (youtube, статья с расшифровкой)
5) 2022 - Интервью по System Design про бронирование отелей (youtube, статья с расшифровкой)
6) 2023 - Публичное интервью по System Design про простую a/b платформу (youtube)

#SoftwareArchitecture #Architecture #Software #SoftwareDevelopment #SystemDesign #SystemDesignInterview #DistributedSystems

Developer Productivity Engineering Summit (DPE Summit)

Недавно узнал про существование отдельной конференции по теме developer productivity, ссылку на которую мне дали в комментариях к посту про whitepapers.
Keynote сессии обоих дней доступны на Youtube
- DPE Summit Keynote Livestream (Day 1)
- DPE Summit Keynote Livestream (Day 2)
Записи остальных докладов я пока не нашел:) Но в keynote есть крутое выступление Ciera Jaspan и Collin Green из Google, которые являются лидами команды по измерению developer productivity and hapinness, а также ведут колонку "Developer Productivity for Humans", про которую я рассказывал раньше. Это выступление было крутым и я расскажу про него отдельно, а вообще рекомендую почитать темы конференции и посмотреть keynotes, чтобы оценить уровень развития этой темы и попробовать взять что-то к себе в процессы разработки.

#Management #Leadership #Software #SoftwareDevelopment #Architecture #SoftwareArchitecture #Metrics #Devops #Processes

API Improvement Proposals (Рубрика #Architecture)

Я уже рассказывал про whitepaper "API Governance at Scale", по которому скоро будет обзорная статья, а потом еще и выпуск нового подкаста с обзорами whitepaper. Но сегодня я хотел бы рассказать, что у ребят есть публичные артефакты, которые доступны для изучения всем заинтересованным людям
1) API Improvement Proposals (AIPs) - это задокументированный источник правды относительно того, какие правили есть по отношению к дизайну API. Эти AIPs разбиты по следующим категориям: meta, process, API concepts, resource design, operations, fields, design patterns, compatibility, polish, protocol buffers. Их очень интересно изучить
2) API Linter - это автоматизированная проверка соответствия API правилам из AIP (круто, что авторы смогли кодифицировать AIPs и дальше проверять их в этом линтере). Он работает только для API, определенных с помощью protocol buffers.
3) API Readability - программа обучения и сертификации API Design экспертов. Процесс API Readabity в Google похож на другой их процесс, а точнее на code readability, про который я уже рассказывал раньше. Но публичного это процесса нет:)

Отдельно авторы описали как можно внедрить этот процесс у себя "Adopting AIPs in your company" (еще рекомендую почитать Github)

#Architecture #Software #DistributedSystems #SystemDesign #SystemEngineering #API #Governance

Беслатный онлайн-курс по математике для школьников 4-6 классов от Т-Образования (Рубрика #Math)

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

P.S.
Я сам учился в ЗФТШ (заочной физико-технической школе при МФТИ), но это было уже в 10 и 11 классе и помогло мне в свое время поступить на Физтех. Но эта штука не очень масштабировалась, а наше обучение в рамках Тинькофф Поколения сможет охватить больше направлений и помочь большему количеству школьников получить актуальные и полезные знания и навыки. В общем, я считаю, что наши программы обучения - это топчик:)

#Math #Courses #SelfDevelopment #ForKids #Science

ЦЕХ 4 - Урок #20 "Social media marketing (SMM). Эксперт — Олеся Полянская" (Рубрика #Writing)

Очередной урок из курса книгописания и книгоиздания от МИФ вела Олеся Полянская, руководитель команды по социальным сетям в МИФ, которая поделилась опытом и знаниями в области SMM. Мне запомнились следующие тезисы из этой лекции:

1. Соцсети могут помочь в публикации книг и повышении узнаваемости автора и его книг
2. Их можно использовать для коммуникаций с аудиторией, получения обратной связи и монетизации
3. Сейчас уже существует множество блогов и каналов, но уникальность голоса и опыта автора всегда найдет свою аудиторию
4. Для ведения своего блога нужна понятная стратегия и планомерная работа
5. Важно понимать, зачем вы будете вести блог, чтобы не забросить дело на полпути. Цель должна быть вдохновляющей и значимой, а не просто меркантильной.
6. Важно правильно выбирать платформу для публикаций: разные соцсети, мессенджеры и так далее
7. Важно формулировать ключевые идеи и формировать свой стиль, через который виден личный опыт и уникальность
8. Можно делать тематические подборки и инструкции - они работают хорошо
9. Можно использовать бесплатное и платное продвижение для своих блогов, а можно давать рекламу в своем блоге
10. Важно понимать свою аудиторию и правильно формировать контент под своих читателей
11. Можно делегировать работу по развитию своего блога, оставив на себе только создание контента
12. Нужен контентный план публикаций и их ритмичность - иначе аудитория будет отваливаться, особенно, если автор будет пропадать надолго
13. Создание публикаций требует большого количества времени - это надо понимать, решая завести свой блог
14. Надо быть готовым к токсичным комментариям
15. Переводить аудиторию между разными соцсетями достаточно сложно, поэтому стоит диверсифицировать используемые платформы

Предыдущие посты про этот курс писательского мастерства доступны здесь
1. Увидеть свое имя на обложке может каждый
2. Целевая аудитория и ее потребности в создании книги
3. Жанры и стили. Как найти тему для нон-фикшн-книги
4. Как организовать работу
5. Как преодолеть писательские блоки. Практическое занятие
6. Жду музу, а она все не приходит
7. Книга по полочкам
8. MS Word для работы с большими и сложными текстами
9. Рассказываем истории: сторителлинг в книге
10. Саморедактура: работа с текстом, сокращения, фактчекинг
11. Правила сильной книги захватывающего текста
12. Авторская стилистика
13. Как превратить рукопись в сценарий
14. Рукопись готова. Что дальше?
15. Превращение рукописи в издание
16. Авторские права и договор с издательством
17. Дизайн книги.
18. Продвижение в самиздате.
19. Продвижение автора

#SelfDevelopment #PublicSpeaking #Storytelling #Writing

Operationalize a Scalable AI With LLMOps Principles and Best Practices (Рубрика #ML)

Я уже давно заметил, что модность темы можно отследить по наличию связки somethingOps, вот дошла очередь и до LLMOps, про что рассказывается в недавней статье от DZone. Раньше уже была на хайпе темы
- DevOps - тема уже давно на хайпе (подробнее в книге "Accelerate", про которую я рассказывал), сейчас больше говорят про Platform Engineering
- DevSecOps - горячая тема, подробнее в книге "Agile Application Security", про которую я рассказывал или недавней статье "Secure by Design at Google", который я разбирал отдельно
- DataOps - давняя и актуальная тема про выстроенные процессы работы с данными. Они нужна как пререквизиты для эффективной работы над ML-моделями
- MLOps - это очень актуальная тема, которая включает набор практик, которые объединяют ML, DevOps и инженерию данных, которые направлены на создание, деплой и эксплуатацию ML систем в проде надежно и эффеективно. Интересно, что эту тему мы разбирали в выпуске подкаста "MLOps в теории и на практике"
Подробнее про XOps подходы можно посмотреть в докладе "The Pipeline-Driven Organization", про который я уже рассказывал

В этой же статье речь идет про подмножество MLOps подходов, которые сфокусированы именно на LLM приложениях, которые сейчас являются горячей темой. В приведенной ниже статье сначала приводится определение LLMOps. Дальше разбирается разница между MLOps и LLMOps по критериям на чем основной фокус, как выглядит адаптация моделей, оценка качества моделей, управление моделями, включая версионирование и метаданные, как модели деплоятся и как мониторится их работа. Дальше автор разбирает базовые характеристики LLM
- Что они существуют в разных формах: проприетарные модели с платными API, pre-training models, fine-tuned models
- Что существует так называемый prompt engineering, так как многие LLM принимают в качестве входа текст на естественном языке
- Иногда можно добавлять контекст к запросам пользователей (context-based prompt engineering:), чтобы повысить их эффективность, для чего используются новые инструменты, навроде векторных баз данных (про которые был недавно интересный доклад)
- Они достаточно большие, иногда сотни гигабайт, а также им может требоваться GPU не только для тренировок, но и для обработки real-time запросов
- Оценивать их качество достаточно сложно, поэтому часто надо встроить человеческий фидбек прямо в MLOps процесс для оценки и тестирования моделей

Ключевыми моментами приложений с LLM сейчас являются следующие моменты
- Prompt engineering, про который мы говорили выше
- RAG (retrieval augmented generation), который полагается обычно на уже упоминавшиеся векторные базы для семантического поиска, а также на feature store, где хранятся признаки.
- Fine-tuning LLMs - это процесс адаптации предварительно обученной LLM к сравнительно небольшому набору данных, специфичному для отдельной области или задачи.
- Pre-training a model from scratch - это что-то на богатом про процесс обучения языковой модели на большом массиве данных (например, тексте, коде) без использования каких-либо предварительных знаний или весов из существующей модели:)

Дальше автор показывает референсные архитектуры LLM приложений с RAG от Databrics, а финализирует плюсами и минусами LLMOps

+ Minimal changes to base model - большинство LLM приложений можно запустить поверх базовых моделей с небольшими изменениями
+ Easy to model and deploy - LLMOps как раз упрощает использование моделей
+ Advanced language models - можно начинать использовать сложные модели через API, а потом перейти open source модели
- Human feedback - в случае LLM обратная связь от людей необходима, что добавляет сложностей
- Limitations and quotas - при использовании внешних API надо понимать их ограничения и стоимость использования
- Risky and complex integration - при использовании внешних API надо понимать какими данными вы делитесь и насколько это ок

#AI #ML #Software #Architecture #Future

Code of Leadership #21 "A Philosophy of Software Design" (Рубрика #Architecture)

Этот выпуск подкаста посвящен рассмотрению крутой книги Джона Остерхута "A Philosophy of Software Design". В разборе книги  помогает Григорий Скобелев, Java/Go techlead, чей основной профиль это highload приложения, также он является директором программного комитета Podlodka Techlead/Java Crew. А в свободное время он делает свой подкаст/книжный клуб - { между скобок }, LinkedIn

В этой серии рассмотрена первая половина книги, где получилось обсудить темы
- Знакомство с гостем
- История создания книги
- Общее содержание книги
- Философия борьбы со сложностью
- Управление техническим долгом
- Подходы к управлению процессом разработки
- Эволюция и технический долг
- Подходы к приоритизации
- Продуктовый подход и оценка импакта
- Виды сложности и метрики кода
- Когнитивная нагрузка и простота кода
- Принципы обучения и решения задач
- Автоматизация и тесты
- Причины когнитивной сложности
- Исследования в Google
- Стратегическое и тактическое программирование
- Примеры из практики
- Проблемы с накоплением технического долга
- Модуляризация и интерфейсы
- Проблемы с интеграцией через базу данных
- Скрытие информации и абстракции
- Проблемы с монолитными системами
- Генерализованные и специализированные модули
- Централизованное хранилище данных
- Уровни абстракции
- Декораторы и фасады
- Эволюция кода и опыт инженеров

Продолжение обзора книги будет в следующей серии

#Architecture #Processes #Management #Leadership #Software #SystemDesign

Архитектура на старте: подготовка к успеху - Podlodka Techlead Crew (Рубрика #SRE)

Поучаствовал вчера в дискуссии на подлодке насчет проектирования надежных систем. В ней участвовали Олег Бондарь, Филипп Дельгядо и я. Мы поговорили про ключевые принципы для построения надежной архитектуры. Дискуссия была интересной и динамичной. Мы уделили много вопросам observability и я позвал всех участников на конфу T-Observability Day Tech 2024, что пройдет 23 октября в нашем московском офисе T-Space. Кстати, про конфу я уже рассказывал тут в канале

P.S.
Год назад я выступал на конференции с докладом "Проектируем надежные системы — стоит ли игра свеч", про который я уже рассказывал. И тот доклад был основан на солидном списке материалов
- "Site Reliability Engineering" - книга от ребят из Google, с которой началась серия SRE книг и они рассказывают про процесс в общем
- "Building Secure and Reliable Systems" - книга от ребят из Google, где они рассказывают про принципы проектирования надежных систем (продолжает серию SRE книг)
- "AWS Fault Isolation Boundaries" - интересный white paper от AWS на тему границ изоляции сбоев в AWS (здесь интересно написано про инфраструктурные абстракции: зоны, регионы, globl, а также про разделение control plane и data plane при проектировании сервисов и концепцию static stability)
- "A Model-based, Quality Attribute-guided Architecture Re-Design Process at Google" - интересный white paper от ребят из Google, где показано как редизайнится система для повышения ее надежности, причем сам редизайн выполняется достаточно формально, чтобы по модели оценить позитивное влияние на надежность
- "Deployment Archetypes for Cloud Applications" - интересный white paper от ребят из Google, в котором они рассказывают про разные модели deployment приложений, которые позволяют достигать разных уровней availability (зональный, региональный, мультирегиональный, глобальный, гибридный, мультиоблачный)
- Глава про resilience из книги "Continuous Architecture in Practice" - глава крутой книги, в которой буквально на пальцах авторы объясняют чем старый high-availability подход отличается от нового подхода resilience к обеспечению надежности систем
- "Philosophy of Software Design" - отличная книга про то, как бороться со сложностью систем
- "503 Подкаст - System Design в разрезе надежности" - подкаст с Андреем Дмитриевым из JUG Ru Group, где я был гостем и мы обсуждали проектирование надежных систем
- "Architecting for Scale: High Availability for Your Growing Applications" - интересная книга Lee Atchison, где он обсуждает проектирование для масштабирования и затрагивает вопросы обеспечения availability. Книга пережила второе издание и это пошло ей на пользу.
- "Собеседование SRE: Troubleshooting и System Design" - моя статья про найм SRE инженеров в Tinkoff, и про тип интервью, в котором мы проверяем на практике работу инженеров в рамках инцидента
- "Публичное интервью по troubleshooting для SRE-инженеров на конференции Devoops" - публичное интервью с разбором инцидента
- Крутой доклад "Паттерны отказоустойчивой архитектуры" ребят из Яндекса про отказоустойчивые системы

#Software #Engineering #Architecture #SoftwareArchitecture #SystemDesign #DistributedSystems #SRE

Массовое вымирание стартапов: что происходит на глобал tech-рынке и как это влияет на рынок труда (Рубрика #Management)

Интересное интервью Дениса Калышкина, венчурного инвестора из фонда I2BF (инвестируют в американские стартапы) Кире Кузьменко из New HR
Обсуждение было сконцентрировано вокруг тем
— Вымирают ли стартапы или нет?
— Как инвесторы выбирают, куда инвестировать в текущей ситуации?
— Что происходит с внутренними стартапами в крупных компаниях?
— Как оценивать стартап кандидату, который хочет там работать?
— Когда будет дно кризиса и надолго ли текущий кризис с нами?
— Надо ли идти сейчас в предпринимательство вместо найма?

#Startup #Management #Leadership #Invest

Обзор whitepaper "API Governance at Scale" (Рубрика #Architecture)

Я дописал обзор статьи про API Governance от ребят из Google, про которую я уже несколько раз упоминал (1 и 2). В общем, статья получилась интересной и полезной - ее подходы хорошо масштабируются за границы governance именно API, например, мы многое из этого пытаемся применять в процессах architecture governance на уровне компании. В общем, читайте статью, а в следующий понедельник по ней выйдет первая серия подкаста "Research insights made simple", где я буду ее обсуждать со своим коллегой Даниилом Кулешовым.

#Architecture #Management #Governance #SystemDesign #Software #Leadership

Continuous API Management, 2nd Edition (Непрерывное развитие API) (Рубрика #Architecture)

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

1. The Challenge and Promise of API Management - зачем компании хотят управлять своими API, какие проблемы при этом возникают и какие возможности это дает. Здесь авторы рассказывают в общем об основных вопросах, рассмотренных в книге. Отдельно отмечу важность разделения для API интерфейсов (контракты), имплементации (код) и развертывания (инфра)
2. API Governance - глава с фундаментальными концепциями для управления API и какое это значение имеет для принятия решений
3. The API as a Product - глава про важность восприятия API как продуктов (API as a Product). При этом на API можно смотреть с точки зрения целевой аудитории и принимать решения, которые являются лучшими для них
4. The Pillars of an API Product - основные колонны, на которых основаны API. Авторы выделяют следующие области, которые рассматривают детально: strategy, design, documentation, development, testing, deployment, security, monitoring, discovery, change management
5. Continuous API Improvement - глава про то, как жить с непрерывными изменениями и как ими управлять
6. API Styles - здесь авторы рассказывают об основных стилях, которых они насчитывают 5. Вот они: tunnel style (RPC), resource style (REST), hypermedia style (RESTful), query style (graphql), event-based style
7. The API Product Lifecycle - жизненный цикл одного API, который состоит из этапов: create => publish => realize => maintain => retire ... Авторы подробно разбирают как на каждом этапе требуется прорабатывать конкретные pillars
8. API Teams - какие роли нужны в командах для эффективного развития API как продукта. Причем не просто в вакууме, а в зависимости от зрелости самого API
9. API Landscapes - здесь авторы переходят от единичных API к их множеству, которое можно воспринимать как ландшафт. Авторы рассказывают про API Management at Scale, который опирается на принципы, протоколы и практики. Это очень сильно пересекается с paper "API Governance at Scale" от Google, про которое я рассказывал раньше. Плюс авторы вводят модель 8v, которая позволяет управлять ландшафтом, ориентируясь на разные ракурсы. Вот эти восемь V: variety, vocabulary, volume, velocity, vulnerability, visibility, versioning, volatility
10. API Landscape Journey - рассказ о том, а как внедрять API Governance. Авторы предлагают модель enabling team, которая поможет внедрить и раскатить процессы API Governance на всю организацию
11. Managing the API Lifecycle in an Evolving Landscape - здесь авторы пересекают pillars и 8vs и рассказывают о том, как они связаны между собой
12. Continuing the Journey - последняя глава подводит итог книге и готовит читателей к старту Continuous API Management внутри компании

P.S.
Обложки книг представлены в следующем посте.

#Architecture #Software #Governance #Management #Leadership #Processes #Leadership

Как формировать структуру команд под запросы бизнеса (Рубрика #Management)

Недавно меня позвали выступить на митапе с этой темой, которую я рассказывал на YaTalks в 2023 году. Это знаковое для меня выступление, так как я делился основами и принципами дизайна команд, которые помогали мне на протяжении 7 лет работы в Тинькофф. Это приглашение показалось мне отличной причиной рассказать сразу и продолжение о том, как за 2023 и 2024 года мы трансформировали мое подразделение в 1000 инженеров в 5 отдельных самостоятельных технических доменов со своими engineering директорами. Но оказалось, что я не сделал краткого саммари прошлого выступления. Поэтому я решил исправиться и написать расшифровку (а видео досупно на youtube).

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

Вот список рекомендаций для дальнейшего изучения
Принципы и подходы
- Backcasting мы обсуждали в серии Code of Architecture про Technology Strategy Patterns
- Про working backwards написана целая книга
- Про проектный и продуктовый подход у меня есть хорошая статья
- Про Kanban рекомендую почитать пару книг: “Визуализируйте работу” (“Making Work Visible”), про которую я рассказывал, а также "Канбан Метод. Базовая практика", про которую я тоже рассказывал
- Про закон Конвея можно почитать в wikipedia
- Обратный маневр Конвея в 2014 году попал в техрадар от ThoughtWorks
- Про team topologies можно почитать мои краткие саммари: Teams as means of Delivery, Team Topologies that work for flow, Evolving team interactions for innovation and rapid delivery
- Про управление изменениями классно написано в книге "Наш айсберг тает", про которую я уже писал
Отдельные выступления про их применение
- В 2019 году на ArchDays я рассказывал про эволюцию всей связки фронт - бек - система a/b тестов, где фокус больше на архитектурных изменениях
- В 2021 году на Techlead Conf я рассказывал про то "Как мы меняли разработку лучшего* мобильного банка под требования бизнеса"
- В 2022 году на Highload++ Spb я рссказывал доклад "Канал. Продукт. Платформа” или эволюция подходов к развитию мобильного банка Тинькофф"

#Management #Leadership #Project #ProjectManagement #SoftwareDevelopment #Software

Обзор paper "Defining, measuring and managing technical debt" (Рубрика #Architecture)

Я продолжаю читать и писать о статьях из серии developer productivity, о которых рассказывал в обзоре первого whitepaper "A Human-Centered Approach to Developer Productivity". В третьем whitepaper с заголовком "Defining, Measuring, and Technical Debt" речь идет про технический долг и как он влияет на продуктивность разработчиков. Эта тема часто поднимается, но редко когда можно услышать четкое определение термина, а также объяснение как его считать и что с ним делать. Авторы решили закрыть этот пробел и написать как с этим дела в Google. А я решил сделать обзор этой статьи.

#Architecture #Software #Management #Leadership #Engineering

A Brief Outlook of Enterprise Architecture Role in the Digital Age (Рубрика #Architecture)

Когда я выбирал научные статьи с research разделов bigtech компаний, то мне казалось, что большая часть whitepaper интересна. Но тут я решил поискать материалы про enterprise architecture в ACM Digital Library и нашел ... Пока ощущение от их чтения грустное. Конкретно в этой статье 2022 года от Ахмеда из Египта (Ahmed S. Elsheikh) сделано все достаточно топорно и как-то механистически, но давайте ниже я расскажу подробности

1) В абстракте автор начинает с того, что с 1980х годов корпоративная архитектура существует как отдельная дисциплина, которая помогала бороться со сложностью
2) Но с 2010х годов появилась отдельная волна цифровых трансформаций (digital transformation), которая привела к волне подрывных инноваций и бизнес и технологические ландшафты изменились навсегда:)
3) Автор решил исследовать как эти две волны связаны межжду собой через исследование статей на тему digital enterprise architecture
4) Для начала автор рассказывает про святую троицу: Enterprise architecture => TOGAF => Archimate, где корпоративная архитектура - это околонаучная дисциплина, TOGAF - это фреймворк, а Archimate - это фреймворк для моделирования архитектуры. Дальше автор рассказывает про application portfolio management strategy, capability architecture и capability-based planning
5) Но возникает вопрос как это все добро применять с цифровизации, цифровой трансформацией и другими историями про трансформаторов и трансформации:)
6) Автор погуглил словосочетание "digital enterprise architecture" в Clavirate "Web of science" и нашел 55 статей
7) Дальше автор взял базовую статистику по году выхода, авторам, количеству цитат и построил графики - походу статья без графиков не очень научна
😍 Из графиков видно, что с 2015 года пошли не разовые публикации, а косяком, где в 2017 году был пик в 10 публикаций, дальше небольшое проседание и в 2021 году был новый рекорд в 14 публикаций. Из этой статы видно, что исследователи корпоративной архитектуры сразу подхватили тренд цифровой трансформации:)
9) Дальше автор разбил эти 55 статей по 3 группам, выделив отсечку по количеству отсылок к публикациям (количество цитат из них)
10) Получилось 3 группы:
- Взаимное влияние корпоративной архитектуры как отдельной дисциплины и цифровой трансформации как отдельной волны подрывных технологий и бизнес потребностей в одно и то же время
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать корпорации, что цифровые и глобальные одновременно
- Как корпоративная архитектура как отдельная дисциплина может помочь и поддержать цифровые трансформации в разных контекстах и секторах индустрии
11) Автор кратко буквально в одной строке характеризуют каждую статью из этих групп (очень глубокая проработка материала)
12) Напоследок автор формулирует направления для исследования примерно так
- Связь между глобальными цифровыми корпорациями и конкретные трансформации, например, корпоративная архитектура может отличаться между индустриями
- Не хватает некоторых логичных областей (указанные три категории выше не закрывают все сценарии)
- Как отличаются корпоративные архитектуры, когда в основе цифровых трансформаций разные подрывные технологии (автор делает отсылку к блокчейну и бигдата - чуток подпротухшими сейчас кажутся предложенные автором disruptive technologies)
- Как фреймворки для корпоративной архитектуры и фреймворки для цифровых трансформаций (походу и такая дичь штука есть)

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

P.S.
А я подумал, что лучше бы я прочитал еще одну научную статью от Google:)

#SoftwareArchitecture #Architecture #SystemDesign #Software #SoftwareDevelopment