Доклад с ArchDays 2021 "Описание архитектуры текстом" от Бориса Романова

Достаточно интересный доклад, в котором были следующие основные мысли
1. Модель коллективного архитектора, когда ответственность за архитектуру несет вся команда, неплохо работает в не слишком сложных случаях (простые изменения в продукте, небольшие проекты)
2. В более сложных случаях требуется выделение архитектора, который будет нести ответственность за целостность архитектуры
3. Для того, чтобы обеспечить эту целостность, требуется фиксировать принятые технические решения
4. Фиксировать можно в произвольном формате, но для сложных случаев лучше использовать стандартные нотации
5. Использовать стандартные нотации можно в "рисовалках" (визуальных редакторах) или в средствах моделирования, которые помимо картинок знают и про семантику модели
6. Автор оказался в ситуации, когда ему требуется решение для описания архитектуры, которое удовлетворяет свойствам
6.1 Поддержки стандартных нотаций
6.2 Управления изменениями с хранением истории и сравнением версий
6.3 Централизованным репозитории с моделями
6.4 Возможностью просмотра без дополнительного/сложного софта
7. Выбор пал на plantuml и git, которые вместе закрыли проблемы автора

Этот доклад интересен тем, что многие в итоге для похожих целей останавливаются на этой связке plantuml + git, которая практична, расширяема и бесплатна.
Например, у нас в компании эта связка в почете.

#Architecture #Conference #Video #Software

Пионеры Кремниевой долины

Прочитал за пару дней книгу Максима Котина про первый стартап из России, покоривший мир.
Очень интересная история про Степана Пачикова, советского ученого, вахтера в общежитии зарубежных переводчиков, создателя первого компьютерного клуба "Комьютер", ..., вице-президента Silicon Graphics International и создателя Evernote. Рассказ про то, как этот первый компьютерный клуб, созданный при помощи Гарри Каспарова, стал место притяжения всех ранних it'шников Москвы, которые создавали свои проекты под крылом "ПараГрафа". Дальше контракт с Apple на предмет системы распознования для их планшета Newton, который опередил время, но так и не полетел. Эммиграция части команды в США и дальнейшая крутая история, которая достойна экранизации ... или прочтения.

В общем, это интересная книга, в которой появляются известные персонажи западного it'шного мира, в котором проложили свою дорогу пионеры из Советского Союза.
Правда, полный happy end не наступил, но Степан не опустил руки и создал Evernote, но это уже другая история.

#BusinessStory #Software

На этой неделе мы в рамках клуба Code of Architecture начали читать новую книгу “Technology Strategy Patterns”.
В первом эпизоде мы вместе с Николаем Головым, Head of data engineering в ManyChat, обсуждали первые главы:
— Chapter 1. Architect and Strategist
— Chapter 2. Analysis
Все артефакты уже доступны:
- Статья с кратким обзором
- Запись стрима
- Miro доска с презентацией

Ждем вас в следующий четверг, где мы продолжим обсуждать эту книгу.


#SoftwareArchitecture #Strategy #ExternalReview #Patterns

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

Я люблю читать бумажные книги, сидя в кресле с кружечкой горячего мятного чая.
И вот мне доехала книга по философии ... философии software design (A Philosophy of Software Design) за авторством John Ousterhout, стэнфордского профессора и одного из создателей RAFT.
Я уже как-то рекомендовал видео с его выступлением на эту тему, а теперь хочу отметить, что эта книга просто восхитительна.
Думаю, что мы ее когда-нибудь разберем в рамках нашего клуба Code of Architecture, возможно, сразу после окончания разбора книги Technology Strategy Patterns.

#SoftwareDevelopment #SoftwareArchitecture #Software #SystemDesign #Philosophy #Architecture

Доклад с ArchDays 2021 "Язык на пути к DevArch: разгонная полоса или лежачий полицейский?" от Игоря Беспальчука

Достаточно интересный и дискуссионный доклад, в котором автор размышляет над текущим состоянием дел в мире разработки и архитектуры ПО и задает классические вопросы "кто виноват" и "что делать". Отдельно отмечу, что автор сразу очервивает границы своих размышлений корпоративным software и мейнстримными объектоно-ориентированными языками.
Начинает автор с того, что говорит о том, как обычно пытаются понять систему - с точки зрения функциональной декомпозиции, выделяя части системы с значимой функцией и областью ответственности, а также рассматривая связи между такими частями. Автор говорит о том, что это основа системного мышления, но разработчикам такой взгляд на систему дается сложно, так как мешает их стандартный язык, а точнее следующее
- В ООП по мнению автора практически отсутствует способ выражения целое/часть
- В современных ООП языках слишком многое смешано в универсальном понятии "класс"
- Язык определяет сознание, поэтому разработчикам на ООП языках сложно думать о программном обеспечении системно
Дальше автор делает историческую ретроспективу, рассматривая как развивались подходы к языкам программирования и паттернам
- Начиналось все с компьютерных вычислений (а лямбда исчисления как основу функционального подхода еще Алонсо Черч придумал в 30х годах 20 века для анализа проблемы вычислимости)
- Потом появилось структурное программирование (спасибо Дейкстре)
- Потом появились ООП языки (тут большой вклад Алана Кея)
- Функциональное программирование было давно, но оно сейчас проникает в мейнстрим, но все таки в чистом виде оно не слишком распространено по сравнению с ООП
С использованием этих подходов люди строили системы и дальше начали появляться паттерны, которые решали часть проблем, которые появлялись при росте размера системы и долговременном ее развитии. Многие слышали паттерны вида
- GRASP
- SOLID
- CQS/CQRS
- DDD

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

Автор предлагает для улучшения ситуации подумать об общем языке, который сблизит архитектуру и разработку. И вот собственно мысли автора на этот счет
- Надо ценить достижения языков ООП и ФП, но отказаться от крайностей
- Надо добавить специализации "классам" в языке от уже известных паттернов (превратить паттерны в языковые конструкции)
- Добавить новый паттерн: герметичный компонент с рядом новых запретов и гарантий

А дальше автор приводит ряд примеров и предлагает подумать о большем.
Ну и напоследок приводит свой vision по развитию этой области на 5-10 лет вперед.

#SystemDesign #SoftwareArchitecture #Software #Conference

Team Topologies

Три года назад вышла интересная книга за авторством Matthew Skelton и Manuel Pais, которые предлагают использовать Team-First подход при проектировании архитектуры программных систем, так и организации. Полтора года назад я с большим интересом прочел книгу и написал краткое саммари в трех частях
— Teams as means of Delivery
— Team Topologies that work for flow
— Evolving team interactions for innovation and rapid delivery

А на днях ко мне доехала бумажная версия книги и я наконец-то смог ее полистать не только в планшете или ноутубуке
Бумажные книги - это совсем другие ощущения:)

P.S.
В бумаге книга выглядит прикольно.

#Management #Team #Processes #Architecture #SoftwareArchitecture

Критическая цепь (Critical Chain)

Эта книга Голдратта написана в жанре производственного романа. С одной стороны этот формат крайне просто воспринимается, а вот с другой - он кажется излишне упрощенным:)
В книге рассматривается применение теории ограничений в контексте управления проектами. Вводится понятие критическая цепь, которое расширяет общепринятое понятие критический путь.
В общем, прочтение книги оказалось полезным и интересным.

Например, в классическом project management'е используется структурная декомпозиция работ (WBS) в том числе для уменьшения стандартного отклонения в оценке длительности проекта за счет применения закона больших чисел и центральной предельной теоремы. Объясню на примере:
Если у нас:
1) N задач в WBS
2) оценка длительности задач в WBS приблизительно одинакового масштаба
3)они слабо зависимы и случайно распределены с одинаковым стандартным отклонением x (для простоты)
То:
1) общая оценки длительности проекта равна сумме оценок длительности задач
2) стандартное отклонение оценки длительности проекта равно x делить на корень из N
3) то есть теоретически мы получаем оценку длительности проекта довольно точно
Но в книге Годратта показывается, что обычно в проектах: "Опоздание одного элемента полностью передается следующему элементу. Выигрыш по времени достигнутый одним элементом, как правило, разбазаривается". Если это действительно так (а это очень похоже на правду для многих проектов), то оптимистичный прогноз стандартного отклонения для оценки длительности проекта, указанный выше, уже не срабатывает:) Что приводит к проблемам в запаздывании проектов.
Таких интересных идей в книге довольно много, поэтому её можно рекомендовать к прочтению. Благо читается она легко и быстро.

#Management #Processes #Project #ProjectManagement

Теория ограничений Голдратта (Goldratt's Theory of Constraints: A Systems Approach to Continuous Improvement)

Сразу после производственных романов Голдратта стоит прочитать эту книгу Уильяма Детмера - в ней в структурированном виде изложены те идеи, которые сам Голдратт подавал через свои истории.
Книга начинается с введения в теорию ограничений, дальше идет базис по формальной логике, а именно то, что называется Критериями проверки логических построений.
Дальше читатель знакомится с деревьями текущей и будущей реальности, хотя между ними в книге пролегает диаграмма разрешения конфликта:) а соединяет их дерево перехода:)
Дальше дерево перехода превращается волшебным движением руки в план преобразований.
А финализируется книга групповой динамикой при использовании метода рассуждений Голдратта.

P.S.
Понравились практические упражнения на последних страницах книги, размещенные в приложениях.
Особенно понравилось приложение 5, где предлагают построить дерево будущей реальности, основанное на решении о вступлении в брак:)
Забавно, что это практическое упражнение могло бы помочь многим людям, а не только апологетам теории ограничений Голдратта:)

#ProjectManagement #Management #Processes

Завтра в 18:00 по Москве на Youtube у нас будет трансляция второго эпизода по книге Technology Strategy Patterns

В этот раз нашим гостем станет Андрей Иванов, с которым мы вместе работали в Тинькофф и делали часть сервисов для привлечения, про которые я рассказывал на ArchDays 2019.
Сейчас Андрей, VP of Engineering в Chattermill, руководит командами разработки. Компания занимается интеллектуальным анализом обратной связи клиентов для таких брендов как Uber, H&M, Спортмастер, MTS и других.


На втором стриме вместе с ним мы обсудим третью и четвертую главы и поделимся своими мыслями и историями про инструменты, которые рекомендуют автор книги
В третьей главе "World Context" это будут паттерны
— PESTEL - фреймворк для аналази общей ситуации в мире без привязки к какой-то конкретной индустрии
— Scenario Planning - инструмент для планированя возможных сценариев для ответа на вопросы вида "А что если ..."
— Future Funnels - инструмент для красивой визуализации результатов сценарного планирования
— Backcasting - мой горячо любимый инструмент, который популяризируется в книге "Working Backwards: Insights, Stories, and Secrets from Inside Amazon" ребятами из Amazon. Работа в рамках этого инструмента начинается с определения целевого образа будущего и реверсивно планируется к текущему настоящему.

В четвертой главе "Industry Context" это будут паттерны
— SWOT-анализ - инструмент для анализа сильных и слабых сторон организации, возможностей и опастностей в рамках инжустрии;
— Пять сил Портера (Porter's Five Forces) - канонический инструмент для рассмотрения ситуации с точки зрения появления новых участников рынка, опасности появления продуктов заменителей, баланса сил со стороны покупателей нашего продукта и наших поставщиков и как вишенка на торте уровня конкуренции на рынке, где работает наша компания;
— Матрица роста Ансоффа (Ansoff Growth Matrix) - этот инструмент позволяет взглянуть на стратегии с точки зрения улучшения существующего продукта или создания нового, а также с точки зрения работы на существующем рынке или выхода на новый рынок

В общем, приходите - будет интересно. Ждем вас этот четверг 10 ноября в 18:00 (по Москве) на нашем ютуб-канале.

#Software #Strategy #Architecture #Patterns

Проектный бизнес - Адаптированная модель для России

Эту книгу Сергея Мишина, вышедшую в 2006 году, я читал 15 лет назад и она мне сильно помогла разобраться с темой управления проектами.
Суть в том, что в этой книге автор помимо практических советов еще и объясняет почему стоит делать именно так. Например, в посте про книгу Критическую цепь я рассказывал про связь WBS (Work Breakdown Structure) и закон больших чисел - про это я узнал из это книги Мишина.
Кроме того, автор в первой части своей книги рассказывает о мифах проектного управления, общую модель проектного бизнеса, аспекты общего управления, вопросы позиционирования, система и иерархия моделей проектного бизнеса, продукты, ресурсы, среда проекта и субъекты управления. Здесь же автор проводит некоторое сравнение моделей IPMA и PMI (правда сами версии, которые сравнивает автор уже сильно устарели).
Во второй части книги автор приводит свою версию минимальной модели, которая требуется для введения практики проектного бизнеса в компании:
- проведение аудита текущей системы
- введение предложенной автором минимальной модели, включающей разработанные им стандарты, формы и методические рекомендации, которые можно и нужно подстроить под бизнес компании.

Итого:
- книга действительно хорошая и актуальна большей частью до сих пор
- книга в виде pfg доступна на личном сайте автора

#ProjectManagement #Processes #Project #Management