Завтра мы в клубе Code of Architecutre будем обсуждать новую книгу.
В этом выпуске к нам присоединится Николай Голов, Head of data engineering в ManyChat.
Мы обсудим введение, в котором автор рассказывает про целевую аудиторию данной книги и что он в ней расскажет.
Дальше мы перейдем к обсуждению первой главы "Architect and Strategist", в которой автор расскажет про то, в чем заключаются задачи архитектора и стратега и почему в наше время эти роли сильно схожи. Также разберем пятишаговый алгоритм для проведения стратегического анализа и представления результатов.
Во второй главе "Analysis" мы поговорим про фундаментальные паттерны для проведения анализа, в которые входят MECE lists, Logic Tree, Hypothesis. И обсудим как ими пользоваться в свой работе.

P.S.
Кстати, я уже как-то писал про эту книгу в нашем "Книжном кубе" и в статье на Medium

#ExternalReview #Software #Strategy #Architecture #Patterns

Путешествие по системному ландшафту (A Journey Through the Systems Landscape)

Книга Гарольда "Бада" Лоусона интересна, но достаточно сложна для чтения:)
Возможно это потому, что системная инженерия просто сложна сама по себе, а может быть дело в том, что Гарольд - один из создателей стандарта ISO 15288 по системной инженерии. А если вы читали стандарты, то понимаете насколько они "увлекательны"🙂
Если говорить по существу, то книга достаточно старая (2013 года) и больше похожа на учебник и состоит из восьми глав, а также четырех реальных примеров.

Вот список глав с комментариями:
1. Введение в системы - краткое введение во всю книгу, основные вопросы: системы повсюду, их классификация, системное мышление и системная инженерия, целевые системы, управления изменениями и работа со сложностю системы
2. Мышление на языке систем - про системное мышление, жесткие и мягкие системы, моделирование и модели
3. Деятельность на языке систем - про циклы OODA (Observe - Orient - Decide - Act) и PDCA (Plan - Do - Check - Act), а также модели и процессы жизненного цикла систем
4. Система: описания и реализации - про преобразования на протяжении жизненного цикла, ключевые факторы успеха, архитектуру систем
5. Управление изменениями - кибернетика и как собирать показатели функционирования систем (Measure of Effectiveness, Measure of Performance, Balanced Score Card (с KPI), зрелость процессов), дальше про принятие решений (SWOT, Decision Trees, феномен энтропии), а дальше про внесение изменений
6. Управление жезненным циклом систем - V-модель, спиральная модель. Роли и ответственные на протяжении жизненного цикла. Отдельно про жизненные циклы продукции
7. Данные, информация и знания - сначала про таксономии и антологии, а потом про креативное мышление (синектику, концепт-карты) и обучающуюся организацию
8. Организация и предприятие как системы - про то, как все рассказанное до этого перекладывается на предприятие. Немного про архитектуру предприятия

Вот список экскурсий (реальных примеров) с комментариями:
1. пример из области кризисного управления - рождение SWAT отделов в Лос-Анджелесе как ответ полиции криминалу, с которым не справлялись линейные отделы
2. пример из области организационного развития - децентрализованная культура круупного шведского Банка Handelsbanken
3. пример из области архитектурных концепций и принципов - внедление автоматизированной системы управления поездами в Швеции
4. пример из области управления жизненным циклом онтологии - самый сккучный пример про разработку онтологии с учетом рекомендаций ISO 15288
-------------------------------------
В общем, книга хорошая, но сложная для изучениия.
С момента старта чтения и до его окончания у меня прошло порядка 2х месяцев:)

#SystemEngineering #Engineering #SystemDesign

Доклад с 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