ArchInsight в Лемана Тех - Панельная дискуссия про архитектуру

Пару недель назад я ездил в Лемана Тех на их первый офлайн-митап архитекторов под названием ArchInsight, где поучаствовал в дискуссию про будущее архитекторов и архитектуры. Буквально сегодня появилась запись дискусии, а также пост ребят о самом мероприятии в их tg канале. Напомню, что мы за час успели обсудить следующие темы
1. Управление архитектурными изменениями в быстро меняющемся мире
2. Сложные кейсы архитектуры: что делать, когда все не так, как должно быть?
3. Архитектурный репозиторий: как сделать его инструментом для всех?
4. Архитектор как посредник между бизнесом и ИТ: как говорить на одном языке?
5. Эффективное управление архитектурными изменениями: от идеи до внедрения

В дискуссии мы вспоминали много разных тем и конкретно книгу "The Software Architect Elevator" Gregor Hohpe, про которую я писал раньше. Суть была в том, что архитектору не стоит отрываться от земли и уходить в фантазии на N-том этаже своей башни, а стоит быть поблжие к земле и спускаться в машинный зал, где работают инженеры. Забавно, что после окончания конфы спикерам раздали подарки в сумке "Do it yourself", где были шуруповерты. В общем, я понял намек на то, что слова не должны расходиться с делами и обязательно воспользуюсь этим инструментом:)

P.S.
Спасибо организаторам за мероприятие - мне понравилось общение с другими участниками панельной дискуссии и всего митапа в целом, а также понравился подарок:)

#Architecture #Software #Management #Leadership

Large-Scale Automated Refactoring Using ClangMR (Рубрика #Architecture)

В последнее время я много изучаю, как Gen AI помогает в SDLC. Но иногда надо вернуться на шаг назад и понять, а как мы жили до генеративного интеллекта и что делали для повышения эффективности рефакторинга. И если копнуть туда, то видно, что эти старые и проверенные подходы активно используются в современности для обеспечения предсказуемых результатов комбинации стохастических и детерминированных подходов. Собственно, именно так я дошел до чтения короткого whitepaper 2013 года ребят из Google. Здесь они рассказывали про крупномасштабный рефакторинг своей кодовой базы на C++, например, со старой версии стандарта на более новую. Интересно, что их масштаб кодовой базы потребовал сразу учитывать возможность распараллеливания работы, для чего они использовали Map Reduce (именно это означает MR в конце названия ClangMR). Но теперь пора перейти к основным идеям из этой статьи

Собственно, суть в том, что фреймворк ClangMR решает проблему технического долга в крупных C++ кодовых базах через семантически безопасный рефакторинг, который хорошо параллелится. Ключевыми моментами подхода является
- Использование AST (abstract syntax tree), абстрактных синтаксических деревьев. В отличие от regex-инструментов, это позволяет гораздо точнее описывать изменения ,например, легко можно различить методы с одинаковыми именами в разных классах
- Масштабируемость. Распределенная обработка через MapReduce сокращает время рефакторинга с месяцев до часов.
- Повторяемость. Поддержка инкрементных изменений, когда авторы использовали инструмент итеративно для рефакторинга десятков тысяч файлов частями

Сама реализация ClangMR основана на трех китах
- Indexing (индексация): компиляция кодовой базы в AST с хранением в распределенной БД (e.g., Google's Bigtable).
- Node matching (сопоставление узлов): Разработчики определяют AST-шаблоны (например, memberExpr(hasName("OldMethod")) и коллбэки для генерации правок. Интересно, что эта часть состоит из описания паттерна для матчинга частей дерева, а также callback для применения изменений (причем callback может решить, что изменений не требуется)
- Sorce code refactorer (применение изменений): Локальное применение правок с разрешением конфликтов и автоформатированием через ClangFormat.

Эта статья и подход, описанный в ней, привели к нескольким последствиям
- Развитие Clang/LLVM: Компоненты вроде AST matcher API стали основой для Clang-Tidy и Clang refactoring engine
- Смена практик рефакторинга: Популяризация AST-подходов, повлиявшая на инструменты вроде Coccinelle для ядра Linux.
- Эволюция стандартной библиотеки: Ускоренное внедрение современных возможностей создало давление на вендоров компиляторов.

В общем, статья была очень интересной для 2013 года. Но если говорить про микс этого подхода с Gen AI, то можно посмотреть доклад ребят из Uber 2024 года "This Year in Uber’s AI-Driven Developer Productivity Revolution", в котором они рассказывали среди прочего про миграцию с Java на Kotlin, где активно использовался микс AST matcher, а также Gen AI, который помогал генерировать правила трансформации:) Подробнее можно почитать в моем обзоре этого доклада (1 и 2)

#Architecture #Leadership #Software #SoftwareDevelopment #AI #Engineering

AchDays 2024 "Архитектура в Т-Банке: вчера, сегодня, завтра" - Александр Поломодов (Рубрика #Architecture)

Наконец-то появилась запись моего выступления про наши подходы к проектированию и построению архитектуры систем. Я в компании уже 8 лет и видел как эти процессы эволюционировали во времени, а также знаю к чему мы пришли. Я выделил следующие четыре стадии и объяснил как и почему они сменяли друг друга во времени
1. COTS (commercial of the shelf)
2. Свой собственный софт
3. Platform Engineering
4. Большие мегапроекты и governance
Напоследок я рассказал про подходы корпораций и технологических компаний к должностям/ролям архитекторов, а также поделился своим видением того, как нам дальше стоит развиваться. У меня есть расшифровка этого выступления в отдельной статье

#Architecture #Software #Evolution #Management #SystemDesign #Engineering

CTO Conf X и Teamlead Conf (Рубрика #Management)

Я уже рассказывал раньше про конференцию CTO Conf X, которая пройдет этим летом, в программном комитете которой я состою. А программный комитет так устроен, что его участники ревьювят все заявки на конференцию и выбирают лучшие доклады. Сейчас у нас уже есть порядка 120 заявок на примерно 20 мест, то есть конкурс 6 к 1, что достаточно солидно. В итоге, нам приходится повышать требования по качеству и стараться искать доклады, которые принесут что-то новое и интересное нашей аудитории. И одним из критериев для меня является сравнение с тем, а как заявленную тему раньше раскрывали на другой конференции Онтико, которая идет уже давно и где обычно обсуждались темы менеджмента и эта конференция "Teamlead Conf". Я сам выступал на ней несколько раз, а также знаю многих спикеров и членов программного комитета, то есть конференция достойная. Теперь представьте, что ко мне попадает заявка про создание самой перформящей команды, которая мотивирована на достижение результата, причем именно такого что нужен бизнесу. Вроде звучит хорошо, но можно чекнуть, а что рассказывали на конференции Teamlead Conf про это, а дальше спросить у потенциального спикера, а что он хочет добавить к тому, что уже было рассказано. Такой вопрос сразу переводит общение в плоскость конкретики и можно начинать говорить не просто за все хорошее против всего плохого, а по сути:)

Кстати, вот список докладов, что я нашел на Teamlead Conf, которые неплохо укладываются в заданную в качестве примера тему
- Культура как основа для масштабирования команды х2 каждый год
- Мотивация, делегирование и автоматизация: рецепт создания суперкоманды
- Пошаговый алгоритм создания самоорганизующейся команды
- Как вовлечь команды разработки в бизнес компании
- Развиваем доверие в командах
- Как внедрять инженерные практики в сопротивляющихся командах
- Методы мотивации сотрудников. Способы выращивания сотрудников с нуля
- Научный руководитель vs бизнес-менеджер: как управлять R&D

В общем, рекомендую канал конференции Teamlead Conf - там есть много интересных выступлений. Ну а на конференции для CTO и тем, кто им сочувствует, мы как программный комитет соберем бомбическую программу в этом году - нам хватает потенциальных спикеров и хороших заявок, но кажется уже не хватает для них мест, так как половина программы уже собрана. В итоге, дело осталось за вами - приходите на конференцию 6 июня.

#Management #Leadership #Strategy #PlatformEngineering #Engineering #Software #Architecture

Code of Leadership #31 - Hooked: how to build habit-forming products (Рубрика #Management)

Новый эпизод подкаста посвящён обсуждению книги Нира Эяля «На крючке» и её модели создания продуктов, формирующих привычки. Для обсуждения книги пришел Евгений Сергеев (S0ER), который поделился опытом применения модели в разработке ПО, обсуждения её этических аспектов и влияния на пользователей. В общении мы затронули темы поведенческих триггеров, адаптации продуктов к привычкам пользователей, а также эволюции технологий, программирования и роли разработчиков. Особое внимание уделили важности обратной связи, доверия пользователей и интеграции продуктов в экосистемы.

Евгений уже много лет публикует хорошие видео на Youtube на канале S0ER, а также у него есть каналы в tg (@softwareengineervlog и @soer_live). Он много рассказывает про хард скиллы в обще, а также про проектирование и архитектуру в частности.

Выпуск подкаста доступен в Youtube, VK Video, Podster.fm, Ya Music.

#Architecture #Software #Engineering #ProductManagement #Management #Economics

Clean Architecture (Чистая архитектура) (Рубрика #Architecture)

Я прочитал эту книгу Дяди Боба (Роберта С. Мартина) шесть-семь лет назад и нашел концепции достаточно интересными, а по самым интересным частям я даже сделал подробные разборы: "Дизайн и архитектура, парадигмы программирования" и "Принципы дизайна модулей и разделения по компонентам", но все это было до старта этого канала. Поэтому сегодня я решил исправить это недоразумение и рассказать об этой книге, в которой Дядя Боб подчеркивает важность разделения ответственности и независимость от фреймворков, баз данных и пользовательских интерфейсов. Дядя Боб это делает очень ультимативно, что сильно подрывает веру в его подход. Ключевыми идеями являются следующие
Правило зависимостей: зависимости исходного кода должны указывать только внутрь, в направлении высокоуровневых политик. Это создает систему, в которой бизнес-правила не зависят от технических деталей.
Слоеность архитектуры: при реализации этого правила у нас появляются отдельные слои
- Entities (cущности) - основные бизнес-объекты и корпоративные бизнес-правила
- Use cases (варианты использования) - бизнес-правила конкретного приложения. Тут забавно, что этот термин взят из UML, где так называется один из видов диаграмм, про которые я рассказывал раньше
- Interface adapters (адаптеры интерфейса) - контроллеры, презентеры и шлюзы
- Framework & drivers (фреймворки и драйверы) - внешние инструменты, базы данных, UI-фреймворки
Этот архитектурный подход близок к гексагональной архитектуре (hexagonal architecture) или порты и адаптеры и луковая архитектура (onion architecture). Она также активно включает принципы SOLID, особенно принцип инверсии зависимостей, на котором строится вся слоистость и правило зависимостей. Боб говорит о том, что архитектура должна "кричать" о своем назначении — при взгляде на структуру кодовой базы она должна отражать бизнес-домен, а не технические детали.

С точки зрения применимости clean architecture наиболее полезна в следующих сценариях:
- Сложные или долгоживущие приложения, где поддерживаемость является критически важной
- Системы, где доменную модель решили выделить отдельно и использовать стиль DDD (domain driven design)
- Проекты, требующие четкого разделения между бизнес-логикой и инфраструктурой
Она помогает создавать системы, которые могут развиваться со временем в соответствии с изменяющимися бизнес-потребностями, и обеспечивает гибкость для замены фреймворков, баз данных или UI-технологий с минимальным влиянием на основную бизнес-логику.

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

Итого, я видел подходы к применению Clean Architecture для повышения качества кода в существующих проектах, но я уже активно не писал код сам, когда Uncle Bob явил свою концепцию миру. Именно поэтому я не могу оценить из первых рук насколько с ней получаются хорошие приложения:) Но мне кажется, что это как с любым подходом - можно сделать хорошо, а можно тяп-ляп ... Чистая архитектура тут не исключение.

#Architecture #Software #Engineering #DistributedSystems #SystemDesign

Vibe Coding Is The Future (Рубрика #AI)

Интересное видео от Y Combinator с обсуждением vibe coding, подхода к программированию, который описал Андрей Карпаты, сооснователь OpenAI и бывший директор по ИИ в Tesla. В феврале 2025 года он опубликовал твит, описав личный опыт использования Cursor Composer с интеграцией Whisper для голосового управления. В итоге, ребята из Y Combinator решили разобрать насколько этот подход к разработке меняет правила игры. Основные моменты обсуждения следующие

1) Роль инженера в эпоху ИИ
Согласно опросу YC, 25% основателей утверждают, что 95% их кодовой базы генерируется ИИ. Это не означает исчезновения технических навыков, но переопределяет приоритеты и ключевая компетенция смещается в сторону продуктового мышления - умения определять, что строить, а не как это кодировать. Интересно, что мы недавно именно это обсуждали с S0ER в подкасте Code of Leadership
2) Инструменты и рабочие процессы
Cursor и Windsurf стали фаворитами благодаря интеграции с кодовой базой и автономному анализу файлов. Gemini выделяется длинным контекстным окном, позволяя загружать всю кодовую базу для исправления ошибок. Sonnet и Deepseek конкурируют в качестве движков для генерации, тогда как Devin пока ограничен простыми задачами. При этом отладка остаётся слабым звеном: ИИ часто неспособен исправить ошибки, требуя полной перегенерации кода. Основатели сравнивают это с перегенерацией изображений в Midjourney с тем же промптом - вместо точечных правок код переписывается с нуля.
3) Трансформация найма и образования
Классические алгоритмические собеседования устаревают. Компании вроде Stripe и Gusto переходят к оценке практической продуктивности, например, созданию прототипа за 3 часа. Однако для масштабирования проектов критически важны системные архитекторы - специалисты, способные оптимизировать инфраструктуру под высокие нагрузки. Поколение Z, начинающее карьеру с ИИ-инструментами, демонстрирует уникальные преимущества. Обученные в «цифровой среде», они избегают классического синтаксического бремени, фокусируясь на логике и продуктивности. Однако без фундаментального понимания архитектуры (как в случае с Twitter и его проблемами масштабирования) даже генерируемый код рискует стать "техническим долгом".
4) Будущее разработки: Рекомендации и риски
- Интеграция ИИ в образование: Учебные программы должны совмещать генерацию кода с глубоким пониманием системного дизайна.
- Пересмотр метрик найма: Акцент на навыках отладки, код-ревью и продуктовом видении вместо алгоритмических головоломок.
- Инвестиции в инструменты отладки: Текущие LLM слабы в анализе ошибок - это направление станет ключевым для следующих версий моделей.

Все эти тезисы авторы подкаста подтверждают цитатами из общения с основателями стартапов, что входят в Y Combinator.

#AI #Software #Engineering #Management #SystemDesign #ProductManagement #Productivity #Architecture

[1/3] A Prompt Pattern Sequence Approach to Apply Generative AI in Assisting Software Architecture Decision-making (Рубрика #Architecture)

В декабре 2024 года вышел whitepaper на тему использования Gen AI в архитектуре. Я заинтересовался этой темой и решил прочитать что же придумали ребята. Оказалось, что это некоторый co-pilot для архитекторов, который помогает правильные решения. Для этого авторы предлагают использовать паттерны промптинга, что объединяются в цепочку подготовки, анализа и принятия архитектурных решений. Основные паттерны здесь следующие
- Software architect persona pattern
- Architectural project context pattern
- Quality attribute question pattern
- Technical premises pattern
- Uncertain requirement statement pattern
- Prompt pattern sequence
Эти паттерны авторы исследования опробовали на 3 компаниях - двух настоящих (leading automobile financing bank's technological portal и leading retail pharmacy network) и одной вымышленной компании, что по легенде делает cloud-based CRM.

В самом начале авторы рассказывают как выглядит их подход к описанию указанных выше паттернов, куда входят как стандартные аттрибуты вида: Name, Context, Problem, Forces, Solution, Rationale и Consequences, а также расширенный список
- Specializes: описывает, как текущий стандарт специализируется или расширяет существующие стандарты, уточняя их связь и адаптацию для решения конкретных задач или контекстов.
- Statement template: предоставляет краткое описание или структурированное резюме стандарта, позволяя быстро понять его суть.
- Concrete statement example: приводит реальный пример использования шаблона описания, демонстрируя его применение на практике.
- Related patterns: содержит информацию о других паттернах, связанных с текущим, включая зависимости, предпосылки и рекомендации по совместному использованию (связанные паттерны вынесены в приложение к статье)
- Usage example: приводит практический пример из реальной жизни, показывающий применение паттерна и его полезность в конкретной ситуации.
- Known uses: представляет исторические или текущие примеры успешной реализации паттернов, подтверждая их эффективность и предоставляя ссылку на выполненный запрос для получения дополнительных деталей.

Сам flow работы с паттернами и Gen AI инструментами по мнению авторов статьи выглядит так
1) Архитектор ищет подходящие паттерны из списка выше
2) Дальше он применяет их для своего конкретного проекта и получает подсказки и предложения
3) Дальше он принимает решения после анализа сгенерированных подсказок и своего знания проекта

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

#Architecture #GenAI #AI #ML #Software #Engineering #SystemDesign #DistributedSystems #Project

How To Build The Future: Aravind Srinivas (Рубрика #AI)

Интересное интервью CEO и ко-основателя Perplexity ребятам из Y Cominator. Я сам с большим удовольствием пользуюсь Perplexity как основным поисковым движком, а также ассистентом для размышлений. Именно поэтому мне было интересно глянуть историю о том, а как была создана компания, как она развивалась и куда идет сейчас. В итоге, основные идеи этого выступления примерно следующие

1) Происхождение Perplexity и путь основателя
Аравинд начал свой путь в ИИ с обучения в Индии, после чего переехал в США, где стажировался в OpenAI под руководством Ильи Суцкевера. Именно Суцкевер указал ему на важность обучения без учителя и обучения с подкреплением. После работы в Беркли над неконтролируемыми и генеративными моделями и стажировки в Google, Аравинд пришел к идее, что создание компании с ИИ и разработка продукта неразрывно связаны. Идея Perplexity родилась из поста Дэниела Гросса о создании следующего Google и концепции улучшения формулировки запросов с помощью суффиксов. Первоначально команда экспериментировала с вертикальным поиском и базами данных, используя модели OpenAI Codex для создания SQL-запросов. Это был продукт b2b для поиска по базам данных внутри компаний-закачиков
2) Эволюция продукта
Первый прототип Perplexity был создан за выходные и вдохновлен статьей WebGPT. Хотя изначально использовалась медленная модель 175 AGP, команда применила эвристический подход, выбирая первые k ссылок и краткие описания из кэша. Аравинд отмечает парадоксальный момент: "глупый подход сработал, когда модели стали лучше следовать инструкциям". Это позволило решить проблемы с задержкой в пользовательском интерфейсе, сократив время ответа с 7 секунд до приемлемого значения. Ключевым фактором успеха стала возможность задавать дополнительные вопросы, что удвоило время взаимодействия пользователей с продуктом.
3) Конкурентное преимущество и стратегия
Аравинд не видел прямой конкуренции с Google из-за перегруженности их интерфейса, хотя запуск чата Bing от Microsoft вызвал некоторое беспокойство. В отличие от Google, Perplexity фокусируется на том, что "пользователь всегда прав", требуя уточнений от ИИ. Потребительские продукты, по мнению Аравинда, должны быть проще и удобнее для пользователей.
4) Корпоративная культура и подход к разработке
Основной показатель эффективности компании — количество запросов в день. Еженедельные и ежемесячные данные помогают управлять командой без жесткой иерархии. Компания активно использует Twitter для общения с клиентами, ценя прямолинейную критику больше, чем комплименты. Аравинд подчеркивает важность "дотошных и одержимых людей в команде" и постоянной "борьбы с энтропией" для поддержания качества.
5) Будущее и видение
Аравинд видит Perplexity как "более интеллектуальный поиск", чем Google, стремясь создать место для полного пользовательского опыта. Он планирует построить систему из небольших моделей и графов знаний, уделяя особое внимание управлению ИИ и новым моделям монетизации. В отличие от Google, компания позиционирует себя как организация, "заботящаяся о пользователях и продукте", способная быстро внедрять новейшие модели и обучать их. Это дает Perplexity преимущество в конкуренции с технологическими гигантами, которым сложнее интегрировать инновации из-за их размера и устоявшихся бизнес-моделей.

#AI #Software #Engineering #Storytelling #ML #Architecture

[3/4] What Improves Developer Productivity at Google? Code Quality. (Рубрика #DevEx)

Продолжим рассмотрение статьи про developer productivity (1 и 2) обсуждение независимых переменных, а также построением самой модели.

Независимые переменные
Авторы взяли в качестве гипотезы 42 независимые переменные, которые по их мнению могли влиять на продуктивность. Эти 42 переменные схлопнулись до 39 после проверки на мультиколлинеарность. Эти данные были доступны из логов и результатов опросов. Все эти переменные были разбиты на 6 категорий
1) Code quality & technical debt - эти факторы связаны с качеством кода и техническим долгом, которые дальше разбираются в деталях. Кстати дальше авторы написали отдельные интересные статьи
- "Developer productivity for Humans, Part 7: Software Quality" - статья про качество, которую я уже разбирал
- "Defining, measuring and managing technical debt" - которую я разбирал с Димой Гаевским в подкасте Research Insights Made Simple, а также разбирал в отдельной статье
2) Infrastructure tools & support - здесь история про выбор инструментов, а также работу инфраструктуры. Часть из этих факторов были разобраны отдельно
- "Build Latency, Predictability, and Developer Productivity" - статья про важность не просто build time, а его предсказуемости и как это влияет на продуктивность, о которой я уже рассказывал
3) Team communication - здесь авторы говорят про коммуникации, дистанцию от менеджеров, код ревью. Кое-что авторы из этого разобрали в дальнейших статьях
- "Developer Productivity for Humans, Part 2: Hybrid Productivity" - это статья про то, как удаленная работа и удаленные коммуникации во время COVID повлияли на продуктивностьЯ рассказывал про нее раньше
- "Developer Productivity for Humans, Part 5: Onboarding and Ramp-Up" - это статья про то, как работает процесс онбординга и как на него повлиял COVID. Я рассказывал про нее раньше
4) Goals & priorities - это про ясность целей и про изменение приоритетов
5) Interruptions - здесь авторы замеряют влияние встреч
6) Organizational & process factors - проблемы из-за процессов, реорганизации и перемещения людей

Дальше авторы использовали квази-экспериментальный метод использования панельных данных для построения связи между воспринимаемой инженерами продуктивностью и независимыми переменными: 𝑦𝑖𝑡 =𝛼𝑖 +𝜆𝑡 +𝛽 * 𝐷𝑖𝑡 + 𝜖𝑖𝑡
Где
- 𝑦 - это самооценка продуктивности для инженера i в момент t
- 𝛼 - это независимые от времени необозреваемые параметры инженера, такие как образование или уровень навыков
- 𝜆 - это независимые от инженера эффекты от времени, например, изменение политики на всю компанию или сезонные эффекты (как январские каникулы в России)
- 𝐷𝑖𝑡 - это измеренные факторы продуктивности для инженера i в момент времени t
- 𝛽 - это причинно-следственныые эффекты факторов продуктивности 𝐷𝑖𝑡 в момент времени t
- 𝜖𝑖𝑡 - это ошибка во время t

Дальше авторы берут производную и получают формулу Δ𝑦𝑖𝑡 = Δ𝜆𝑡 + 𝛽 * Δ𝐷𝑖𝑡 + Δ𝜖𝑖𝑡 , где
- Δ𝜆𝑡 = 𝛾0 + 𝛾1 * 𝑇 и Δ означает разницу между соседними временными промежутками
- T - это категорийная переменная, что означает разницу между периодами
- после дифференцирования 𝛼𝑖 исчезает из уровнения, а Δ𝜆 можно явно контролировать, что говорит о том, что 𝛼𝑖 и 𝜆𝑡 не искажают результаты

Дальше авторы берут метод Feasible Generalized Least Squares (FGLS) и строят корреляции между зависимой и независимыми переменными и оценивают абсолютный эффект и статистическую значимость. Про результаты и ограничения исследования будет в последней части обзора.

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