Рассуждать о том, что является API, а что нет, очень удобно в контексте зависимостей. От чего возникает зависимость при взаимодействии с дата-продуктом?
👍1
Ещё одна мысль
Структуры данных в API - это часть интерфейса. Через разные методы интерфейса могут быть доступны разные данные.
Структура данных в дата-продукте - это часть продукта. Данные одного и того же дата-продукта могут быть доступны через разные интерфейсы, например, JDBC, ODBC, в топике Kafka (CDC)
Структуры данных в API - это часть интерфейса. Через разные методы интерфейса могут быть доступны разные данные.
Структура данных в дата-продукте - это часть продукта. Данные одного и того же дата-продукта могут быть доступны через разные интерфейсы, например, JDBC, ODBC, в топике Kafka (CDC)
👍6
Хочу отметить, что последние посты напрямую связаны с промышленной архитектурой, так как без контрактов и интерфейсов немыслимо построение модульных систем. Мы будем регулярно возвращаться к этим вопросам в будущем.
Забегая вперёд, скажу, что стало понятно: под контрактами мы часто подразумеваем спецификации, в том числе машиночитаемые (WSDL, Swagger Definition, ProtoBuf), и не различаем контракты и оферты.
В моих планах — увязать между собой контракты, оферты и спецификации, а также простыми словами объяснить суть этих понятий. Важно отметить, что на практике уже можно наблюдать, как реализуются оферты и как к ним привязываются спецификации.
Напомню, что наличие машиночитаемых спецификаций — это основа для Automated Governance.
Забегая вперёд, скажу, что стало понятно: под контрактами мы часто подразумеваем спецификации, в том числе машиночитаемые (WSDL, Swagger Definition, ProtoBuf), и не различаем контракты и оферты.
В моих планах — увязать между собой контракты, оферты и спецификации, а также простыми словами объяснить суть этих понятий. Важно отметить, что на практике уже можно наблюдать, как реализуются оферты и как к ним привязываются спецификации.
Напомню, что наличие машиночитаемых спецификаций — это основа для Automated Governance.
👍7❤🔥1👏1
В своих постах я сознательно избегаю изобилия технических терминов и примеров кода, хотя примеры кода тоже будут. Вместо этого, я опираюсь на общеупотребительные понятия, такие как контракт, оферта или спецификация.
Многие концепции уже давно "вызрели" в других областях, так почему бы их не использовать? Кроме того, стоит отметить, что многие значимые работы в нашей сфере по своей сути являются философскими.
Для иллюстрации приведу цитату из статьи Джима Грея, который ввёл понятие транзакции. В своих трудах, например, он использует такие понятия, как сделка и контракт:
"The transaction concept derives from contract law. In making a contract, two or more parties negotiate for a while and then make a deal."
(“The Transaction Concept: Virtues and Limitations,” Jim Gray, June 1981)
Ссылка: https://www.cs.purdue.edu/homes/bb/cs542-06Spr-bb/TCVL-Gray-81.pdf
Многие концепции уже давно "вызрели" в других областях, так почему бы их не использовать? Кроме того, стоит отметить, что многие значимые работы в нашей сфере по своей сути являются философскими.
Для иллюстрации приведу цитату из статьи Джима Грея, который ввёл понятие транзакции. В своих трудах, например, он использует такие понятия, как сделка и контракт:
"The transaction concept derives from contract law. In making a contract, two or more parties negotiate for a while and then make a deal."
(“The Transaction Concept: Virtues and Limitations,” Jim Gray, June 1981)
Ссылка: https://www.cs.purdue.edu/homes/bb/cs542-06Spr-bb/TCVL-Gray-81.pdf
👍7
#предсказание
Побуду в роли оракула
Микросервисная архитектура в чёткий архитектурный стиль так и не сложилась. Под микросервисами понимается всё, что угодно. В пределе - любое распределённое приложение.
Архитектура MASA от Gartner, на мой взгляд, лишь демонстрирует кризис идей. Акцент на гранулярности сервисов (macro, mimi, micro — multigrained) — это опасное заблуждение, которое ярко проявляется в MASA.
“MASA: Create Agile Application Architecture With Composable Apps, APIs and Services”, Gartner, Aug. 2024
При этом постоянно появляются направления архитектурной мысли, нацеленнные на продление жизни микросервисной архитектуры. На одно из них я хочу обратить внимание — это MACH Architecture: https://macharchitecture.com/
Gartner, комментируя MACH Architecture, говорит "правильные'' слова и как бы "притрагивается" к инженерии:
"The definitions used in MACH are not exactly aligned to some industry definitions — for example, the "microservices" in MACH refer to independent modular business services commonly provided as API-first SaaS services."
https://www.gartner.com/en/documents/5366163
Весьма вероятно, следующим архитектурным стилем станет SOA 2.0, где важными отличиями от (старой доброй) SOA будут:
- децентрализованное владение
- федеративный Governance
- платформизация
Я считаю, что концепция сервисной ориентированности является крайне удачной. Сервисная ориентированность подразумевает фокус на ценности (value) и удовлетворении потребностей. Этому вопросу я посвящу отдельный пост.
Думаю, стоит попытаться достичь цели «business and IT alignment» на новом витке развития IT.
Главное, что необходимо сделать на следующем этапе, — децентрализовать SOA, сблизить её с бизнес-архитектурой и внедрить инженерные практики, унаследовав при этом паттерны построения распределённых решений с независимой поставкой (ценности) компонентов, порождённые за годы «межвременья» микросервисов.
Технически новые архитектурные стили будут тяготеть к облачным технологиям, функциональному программированию и событийной ориентированности. В идеале, реализации SOA 2.0 будут облачно-нативными (cloud native) и реактивными, что мне особенно импонирует.
Побуду в роли оракула
Микросервисная архитектура в чёткий архитектурный стиль так и не сложилась. Под микросервисами понимается всё, что угодно. В пределе - любое распределённое приложение.
Архитектура MASA от Gartner, на мой взгляд, лишь демонстрирует кризис идей. Акцент на гранулярности сервисов (macro, mimi, micro — multigrained) — это опасное заблуждение, которое ярко проявляется в MASA.
“MASA: Create Agile Application Architecture With Composable Apps, APIs and Services”, Gartner, Aug. 2024
При этом постоянно появляются направления архитектурной мысли, нацеленнные на продление жизни микросервисной архитектуры. На одно из них я хочу обратить внимание — это MACH Architecture: https://macharchitecture.com/
Gartner, комментируя MACH Architecture, говорит "правильные'' слова и как бы "притрагивается" к инженерии:
"The definitions used in MACH are not exactly aligned to some industry definitions — for example, the "microservices" in MACH refer to independent modular business services commonly provided as API-first SaaS services."
https://www.gartner.com/en/documents/5366163
Весьма вероятно, следующим архитектурным стилем станет SOA 2.0, где важными отличиями от (старой доброй) SOA будут:
- децентрализованное владение
- федеративный Governance
- платформизация
Я считаю, что концепция сервисной ориентированности является крайне удачной. Сервисная ориентированность подразумевает фокус на ценности (value) и удовлетворении потребностей. Этому вопросу я посвящу отдельный пост.
Думаю, стоит попытаться достичь цели «business and IT alignment» на новом витке развития IT.
Главное, что необходимо сделать на следующем этапе, — децентрализовать SOA, сблизить её с бизнес-архитектурой и внедрить инженерные практики, унаследовав при этом паттерны построения распределённых решений с независимой поставкой (ценности) компонентов, порождённые за годы «межвременья» микросервисов.
Технически новые архитектурные стили будут тяготеть к облачным технологиям, функциональному программированию и событийной ориентированности. В идеале, реализации SOA 2.0 будут облачно-нативными (cloud native) и реактивными, что мне особенно импонирует.
macharchitecture.com
MACH Architecture Articles and Insights
MACH is a modern architecture based on Microservices, API-First, Cloud-Native and Headless
👍10🤯3❤1
Важное уточнение
Любые инициативы, связанные с централизацией, включая создание федеративных структур, невозможны без устранения Agile-силосов и «дефеодализации» компаний. К сожалению, большинство компаний к этому не готовы, так как ещё не насытились сполна последствиями провалов крупных инициатив. Даже грома недостаточно, чтобы мужик перекрестился.
«Business and IT alignment» станет возможен, а SOA 2.0 приобретёт смысл лишь тогда, когда архитектурная функция будет поднята на стратегический уровень и наделена необходимыми полномочиями. Без выравнивания полномочий между бизнесом и IT достичь этой цели не получится.
А пока нужно запастись терпением и крепчать методологически, чтобы пережить безвременье в IT, с его бесшабашным Эджайлом и шальными микросервисами.
Любые инициативы, связанные с централизацией, включая создание федеративных структур, невозможны без устранения Agile-силосов и «дефеодализации» компаний. К сожалению, большинство компаний к этому не готовы, так как ещё не насытились сполна последствиями провалов крупных инициатив. Даже грома недостаточно, чтобы мужик перекрестился.
«Business and IT alignment» станет возможен, а SOA 2.0 приобретёт смысл лишь тогда, когда архитектурная функция будет поднята на стратегический уровень и наделена необходимыми полномочиями. Без выравнивания полномочий между бизнесом и IT достичь этой цели не получится.
А пока нужно запастись терпением и крепчать методологически, чтобы пережить безвременье в IT, с его бесшабашным Эджайлом и шальными микросервисами.
👍4🔥2🤔2😁1
#datamesh #datafabric #dataproduct
Коллеги проделали значительную работу, проанализировав материалы по темам Data Products, Data Mesh и Data Fabric: https://link.springer.com/article/10.1007/s12599-024-00876-5
Эта статья оказалась очень своевременной и принесла моей душе умиротворение. Авторам удалось весьма удачно интегрировать эти концепты.
В конце статьи представлен полезный список источников. Рекомендую
Коллеги проделали значительную работу, проанализировав материалы по темам Data Products, Data Mesh и Data Fabric: https://link.springer.com/article/10.1007/s12599-024-00876-5
Эта статья оказалась очень своевременной и принесла моей душе умиротворение. Авторам удалось весьма удачно интегрировать эти концепты.
В конце статьи представлен полезный список источников. Рекомендую
SpringerLink
Data products, data mesh, and data fabric
Business & Information Systems Engineering -
🔥2
Когда_пора_заняться_архитектурой.pdf
1.1 MB
Готовлюсь к интервью в канале друзей. Будут вопросы про монолитную архитектуру.
Планирую рассказать, почему само понятие монолитной архитектуры — это своего рода миф. В реальности не существует «монолитной архитектуры»; может быть монолитная конструкция и изделие, но не архитектура. И разработка не исключение.
Тем временем хочу поделиться презентацией с моего доклада на конференции «Подлодка». В этом докладе я анализирую разные определения термина «архитектура» и прихожу к выводу, что в самом широком смысле под этим термином следует понимать.
Планирую рассказать, почему само понятие монолитной архитектуры — это своего рода миф. В реальности не существует «монолитной архитектуры»; может быть монолитная конструкция и изделие, но не архитектура. И разработка не исключение.
Тем временем хочу поделиться презентацией с моего доклада на конференции «Подлодка». В этом докладе я анализирую разные определения термина «архитектура» и прихожу к выводу, что в самом широком смысле под этим термином следует понимать.
🔥10❤1
Конец високосного года выдался особенно жарким. Поделюсь выводами, которые сделал за эту неделю.
Мне кажется, большая ошибка — внедрение практик, пререквизитом для которых является изменение культуры.
У нас красная страна, красная культура, и большинство наших компаний — красные. Это следствие нашей истории, наша объективная реальность. В этом наша сила и наша слабость.
Нужно внедрять практики, которые соотвествуют красной культуре. Розовые пони в нашей саванне долго не живут.
Применительно к архитектуре необходим сильный архитектурный комплаенс (Architecture Compliance). Причём вряд ли он должен строиться строго по TOGAF — комплаенс должен быть независимым от продуктовых команд.
Комплаенс должен быть максимально автоматизированным, а лучше полностью автоматическим.
Все уже привыкли к тому, что роботы "заворачивают" кредиты. Вот пусть роботы и некачественные релизы "заворачивают". На робота сложнее "надавить", чем на человека.
У нас красная страна, красная культура, и большинство наших компаний — красные. Это следствие нашей истории, наша объективная реальность. В этом наша сила и наша слабость.
Нужно внедрять практики, которые соотвествуют красной культуре. Розовые пони в нашей саванне долго не живут.
Применительно к архитектуре необходим сильный архитектурный комплаенс (Architecture Compliance). Причём вряд ли он должен строиться строго по TOGAF — комплаенс должен быть независимым от продуктовых команд.
Комплаенс должен быть максимально автоматизированным, а лучше полностью автоматическим.
Все уже привыкли к тому, что роботы "заворачивают" кредиты. Вот пусть роботы и некачественные релизы "заворачивают". На робота сложнее "надавить", чем на человека.
❤6🤔4💯2👍1🤯1
Концепция_системы_управления_архитектурой_информационных_систем.pdf
1.1 MB
Продолжаю делиться наработками.
Автоматизировать архитектурный комплаенс лучше на основе цифрового двойника информационных систем.
Несколько лет назад я разработал концепцию системы управления архитектурой информационных систем, центральным элементом которой выступает цифровой двойник.
С тех пор понимание этой темы существенно эволюционировало, и стали заметны некоторые недочёты первоначальной версии концепции. Несмотря на это, я убеждён, что данный документ будет полезен многим.
Приведу цитату:
- Цифровая модель — это представление того, как мы видим систему.
- Цифровая тень — это отражение того, как система реализована на практике.
- Цифровая тень помогает выявлять расхождения между цифровой моделью и реальным состоянием системы.
В данной концепции содержится неявный ответ на вопрос, входит ли архитектурный репозиторий в состав цифрового двойника.
Сам по себе репозиторий не является частью цифрового двойника, однако модели архитектуры, которые хранятся в репозитории, являются. При этом структура репозитория, которая во многом определяется метамоделями разных аспектов архитектуры, по сути определяет структуру (интегрированной) цифровой модели.
Автоматизировать архитектурный комплаенс лучше на основе цифрового двойника информационных систем.
Несколько лет назад я разработал концепцию системы управления архитектурой информационных систем, центральным элементом которой выступает цифровой двойник.
С тех пор понимание этой темы существенно эволюционировало, и стали заметны некоторые недочёты первоначальной версии концепции. Несмотря на это, я убеждён, что данный документ будет полезен многим.
Приведу цитату:
- Цифровая модель — это представление того, как мы видим систему.
- Цифровая тень — это отражение того, как система реализована на практике.
- Цифровая тень помогает выявлять расхождения между цифровой моделью и реальным состоянием системы.
В данной концепции содержится неявный ответ на вопрос, входит ли архитектурный репозиторий в состав цифрового двойника.
Сам по себе репозиторий не является частью цифрового двойника, однако модели архитектуры, которые хранятся в репозитории, являются. При этом структура репозитория, которая во многом определяется метамоделями разных аспектов архитектуры, по сути определяет структуру (интегрированной) цифровой модели.
👍7
В этом и следующих постах я расскажу, как части цифрового двойника соотносятся со стратегией и архитектурой.
Обратимся к книге Генри Минцберга «Стратегическое сафари». Согласно ей, реализуемая стратегия всегда представляет собой сочетание запланированной (Intended strategy) и возникающих (Emergent strategies) стратегий.
Запланированная стратегия – это стратегия, которая осмысленно формируется стратегами и передаётся вниз по организации для реализации.
Возникающие стратегии – это результат инициатив на местах.
На практике реализуемая стратегия никогда не совпадает полностью с запланированной: что-то идёт не по плану, отдельные элементы стратегии улучшаются локально или игнорируются, нередко на местах возникают совершенно новые концепции, продукты или варианты развития.
Это расхождение между запланированной и возникающими стратегиями важно замечать и учитывать.
Цифровая модель отражает видение «будущих» систем и их версий, а цифровая тень содержит объективную информацию о том, какие системы и как именно реализованы.
Сравнивая цифровую модель и цифровую тень, мы можем выявлять расхождения и формировать более точное представление о реальности.
Обратимся к книге Генри Минцберга «Стратегическое сафари». Согласно ей, реализуемая стратегия всегда представляет собой сочетание запланированной (Intended strategy) и возникающих (Emergent strategies) стратегий.
Запланированная стратегия – это стратегия, которая осмысленно формируется стратегами и передаётся вниз по организации для реализации.
Возникающие стратегии – это результат инициатив на местах.
На практике реализуемая стратегия никогда не совпадает полностью с запланированной: что-то идёт не по плану, отдельные элементы стратегии улучшаются локально или игнорируются, нередко на местах возникают совершенно новые концепции, продукты или варианты развития.
Это расхождение между запланированной и возникающими стратегиями важно замечать и учитывать.
Цифровая модель отражает видение «будущих» систем и их версий, а цифровая тень содержит объективную информацию о том, какие системы и как именно реализованы.
Сравнивая цифровую модель и цифровую тень, мы можем выявлять расхождения и формировать более точное представление о реальности.
👍8❤2
В программной инженерии дела обстоят так же, как и в стратегии.
Существует намеченная/запланированная архитектура (Intentional Architecture) и возникающая архитектура (Emergent Architecture). Однако мы, конечно, понимаем, что архитектура всегда одна. Подобно реализуемой стратегии, архитектура, как свойство системы, всегда едина.
При этом архитектура формируется на разных уровнях, различными стейкхолдерами и на разных этапах жизненного цикла.
Намеченная архитектура
Намеченную архитектуру мы фактически проектируем: создаём её модели, часто в виде диаграмм.
Архитектуру мы проектируем на достаточно высоких системных уровнях (уровнях абстракции).
Можно сказать, что намеченная архитектура — это High-Level Design (как процесс и как результат), и её мы выполняем Upfront (авансом/заранее), то есть до программирования.
Намеченную архитектуру также называют Up-Front Design.
Возникающая архитектура
Возникающая архитектура формируется в процессе конструирования.
Напомню, что в программной инженерии конструирование выполняется в рамках программирования/разработки (на эту тему скоро выйдет статья).
В процессе проектирования структуры модулей, интерфейсов и других абстракций, то есть в рамках Low-Level Design, создаётся конструкция системы (программы). При этом High-Level Design часто пересматривается: на практике выявляются его ограничения и возможные пути улучшения.
Нередко приходится идти на компромиссы, включая принятие технического долга, что приводит к отклонениям от намеченной архитектуры.
Баланс между между намеченной и возникающей архитектурой
Ключевая задача - нахождение баланса между Intentional Architecture и Emergent Architecture предполагает определение оптимальной глубины проработки в Up-Front Design и отказ от BUFD (Big Up-Front Design).
Этому вопросу стали уделять внимание в современной литературе.
Рекомендации
Немного почитать об Intentional Architecture и Emergent Architecture можно здесь: https://pubs.opengroup.org/architecture/o-aa-standard/architecture-development.html
Эта статья, как и весь стандарт, не отличается стройностью изложения, но зато там нет недостатка в H2O.
Источники, приведённые в статье, также стоит читать с изрядной долей скептицизма.
Про Balancing Intentional и Emergent Design можно прочитать здесь: https://scaledagileframework.com/agile-architecture/
Стоит обратить внимание, что в данном источнике говорится не об Architecture, а о Design. Впрочем, как вы можете убедиться, с отсутствием единства терминологии у коллег нет совершенно никаких проблем.
Существует намеченная/запланированная архитектура (Intentional Architecture) и возникающая архитектура (Emergent Architecture). Однако мы, конечно, понимаем, что архитектура всегда одна. Подобно реализуемой стратегии, архитектура, как свойство системы, всегда едина.
При этом архитектура формируется на разных уровнях, различными стейкхолдерами и на разных этапах жизненного цикла.
Намеченная архитектура
Намеченную архитектуру мы фактически проектируем: создаём её модели, часто в виде диаграмм.
Архитектуру мы проектируем на достаточно высоких системных уровнях (уровнях абстракции).
Можно сказать, что намеченная архитектура — это High-Level Design (как процесс и как результат), и её мы выполняем Upfront (авансом/заранее), то есть до программирования.
Намеченную архитектуру также называют Up-Front Design.
Возникающая архитектура
Возникающая архитектура формируется в процессе конструирования.
Напомню, что в программной инженерии конструирование выполняется в рамках программирования/разработки (на эту тему скоро выйдет статья).
В процессе проектирования структуры модулей, интерфейсов и других абстракций, то есть в рамках Low-Level Design, создаётся конструкция системы (программы). При этом High-Level Design часто пересматривается: на практике выявляются его ограничения и возможные пути улучшения.
Нередко приходится идти на компромиссы, включая принятие технического долга, что приводит к отклонениям от намеченной архитектуры.
Баланс между между намеченной и возникающей архитектурой
Ключевая задача - нахождение баланса между Intentional Architecture и Emergent Architecture предполагает определение оптимальной глубины проработки в Up-Front Design и отказ от BUFD (Big Up-Front Design).
Этому вопросу стали уделять внимание в современной литературе.
Рекомендации
Немного почитать об Intentional Architecture и Emergent Architecture можно здесь: https://pubs.opengroup.org/architecture/o-aa-standard/architecture-development.html
Эта статья, как и весь стандарт, не отличается стройностью изложения, но зато там нет недостатка в H2O.
Источники, приведённые в статье, также стоит читать с изрядной долей скептицизма.
Про Balancing Intentional и Emergent Design можно прочитать здесь: https://scaledagileframework.com/agile-architecture/
Стоит обратить внимание, что в данном источнике говорится не об Architecture, а о Design. Впрочем, как вы можете убедиться, с отсутствием единства терминологии у коллег нет совершенно никаких проблем.
pubs.opengroup.org
Open Agile Architecture™
👍6❤4🔥3
Меня часто спрашивают, что почитать, чтобы погрузиться в архитектуру. Могу предложить не так много.
Рекомендовать для старта «классические» книги было бы нечестно. Они не дают прочного фундамента при минимальных усилиях. Впрочем, их важно упомянуть, чтобы получить представление о «классике».
Архитектурная классика (масштабная и местами архаичная, не для начинающих):
- «Software Architecture in Practice», Len Bass, Paul Clements, Rick Kazman
- «Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives», Nick Rozanski, Eóin Woods
Книги по конструированию ценны, но они больше подходят опытным программистам и вряд ли с них стоит начинать погружение в архитектуру:
- «Code Complete», Steve McConnell
- «Clean Architecture», Robert C. Martin
С чего же следует начать?
«Азбука системного мышления», Донелла Медоуз
Эта книга поможет понять важность структур и познакомит с системным подходом:
https://www.litres.ru/book/donella-medouz/azbuka-sistemnogo-myshleniya-33388675/
«Modern Software Engineering», Jez Humble
Даст представление о ключевых инженерных принципах, критически важных в работе архитектора:
https://www.amazon.com/Modern-Software-Engineering-Better-Faster/dp/B0BLXCXT3R/
Эти книги создадут основу для понимания всего остального, что вы прочтёте в других книгах из этого поста, а именно познакомят вас с системным и инженерным подходами.
В завершении поста приведу пару цитат из последней книги в немного изменённой последовательности:
"Craft can produce good things, but only within certain bounds.
Engineering discipline in virtually all human endeavors increases quality, reduces costs, and generally provides more robust, resilient, and flexible solutions."
"This is not about more bureaucracy; it is about enhancing our ability to create high-quality software more sustainably and more reliably."
Рекомендовать для старта «классические» книги было бы нечестно. Они не дают прочного фундамента при минимальных усилиях. Впрочем, их важно упомянуть, чтобы получить представление о «классике».
Архитектурная классика (масштабная и местами архаичная, не для начинающих):
- «Software Architecture in Practice», Len Bass, Paul Clements, Rick Kazman
- «Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives», Nick Rozanski, Eóin Woods
Книги по конструированию ценны, но они больше подходят опытным программистам и вряд ли с них стоит начинать погружение в архитектуру:
- «Code Complete», Steve McConnell
- «Clean Architecture», Robert C. Martin
С чего же следует начать?
«Азбука системного мышления», Донелла Медоуз
Эта книга поможет понять важность структур и познакомит с системным подходом:
https://www.litres.ru/book/donella-medouz/azbuka-sistemnogo-myshleniya-33388675/
«Modern Software Engineering», Jez Humble
Даст представление о ключевых инженерных принципах, критически важных в работе архитектора:
https://www.amazon.com/Modern-Software-Engineering-Better-Faster/dp/B0BLXCXT3R/
Эти книги создадут основу для понимания всего остального, что вы прочтёте в других книгах из этого поста, а именно познакомят вас с системным и инженерным подходами.
В завершении поста приведу пару цитат из последней книги в немного изменённой последовательности:
"Craft can produce good things, but only within certain bounds.
Engineering discipline in virtually all human endeavors increases quality, reduces costs, and generally provides more robust, resilient, and flexible solutions."
"This is not about more bureaucracy; it is about enhancing our ability to create high-quality software more sustainably and more reliably."
Литрес
Системное мышление. Как создавать и улучшать системы в бизнесе и жизни — Донелла Х. Медоуз | Литрес
Новое издание классической работы о системном мышлении – навыке, который помогает менять себя и мир всерьез и надолго. И об устройстве сложных систем – от футбольных команд и живых организмов до корп…
👍6🔥5❤3🤝1
Хочу отдельно отметить, что в прошлом году Каты выиграла команда, которая для описания архитектуры использовала фреймворк от авторов книги Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives, Ника Розански и Юэна Вудса:
https://www.viewpoints-and-perspectives.info/home/viewpoints/
Этот фреймворк я считаю наиболее удачным для описания архитектуры решений, несмотря на то, что подходы к описанию архитектуры в целом нуждаются в модернизации.
https://github.com/Profitero-Data-Alchemists/katas-2023
https://www.viewpoints-and-perspectives.info/home/viewpoints/
Этот фреймворк я считаю наиболее удачным для описания архитектуры решений, несмотря на то, что подходы к описанию архитектуры в целом нуждаются в модернизации.
https://github.com/Profitero-Data-Alchemists/katas-2023
www.viewpoints-and-perspectives.info
Software Systems Architecture
Software Systems Architecture by Nick Rozanski and Eoin Woods
👍9
Что мне понравилось в книге Донеллы Медоуз?
Автор наглядно демонстрирует, как разные силы воздействуют на системы, используя примеры из различных сфер.
Для демонстрации воздействия разных сил на системы в книге используются понятия запасов и потоков. Поток, по сути, представляет собой силу, которая, как векторная величина, имеет и величину, и направление.
Вот ключевая цитата:
"Если вы понимаете динамику запасов и потоков, то есть их изменение с течением времени, то хорошо разбираетесь в поведении сложных систем."
Перенесём это в нашу область. Заказчиков можно рассматривать как силы, порождающие потоки требований, которые приводят к изменению системы. Эти потоки бывают различной интенсивности и характеризуются неравномерностью.
Менеджеров и финансовых директоров можно представить как силы, создающие потоки управляющих воздействий.
На заказчиков, менеджеров и финансовых директоров, в свою очередь, тоже воздействуют какие-то силы.
Рыночные тренды, рынок труда, законодательная деятельность, инновации — всё это силы, которые воздействуют на системы. Заметьте, я говорю о силах, а не о стейкхолдерах и их "интересах", и пока не разделяю силы на внутренние и внешние.
При прочтении книги можно прийти к важному выводу: структура системы определяет её способность справляться с воздействием разных сил. Система с ригидной или хрупкой структурой рискует разрушиться под воздействием новой значимой силы.
Этот принцип применим и в программной инженерии. То, как вы спроектируете конструкцию программы, особенно структуру её модулей, определит её устойчивость к изменениям под воздействием разных сил.
Именно понимание взаимосвязи структуры и устойчивости системы делает книгу Медоуз столь полезной.
Автор наглядно демонстрирует, как разные силы воздействуют на системы, используя примеры из различных сфер.
Для демонстрации воздействия разных сил на системы в книге используются понятия запасов и потоков. Поток, по сути, представляет собой силу, которая, как векторная величина, имеет и величину, и направление.
Вот ключевая цитата:
"Если вы понимаете динамику запасов и потоков, то есть их изменение с течением времени, то хорошо разбираетесь в поведении сложных систем."
Перенесём это в нашу область. Заказчиков можно рассматривать как силы, порождающие потоки требований, которые приводят к изменению системы. Эти потоки бывают различной интенсивности и характеризуются неравномерностью.
Менеджеров и финансовых директоров можно представить как силы, создающие потоки управляющих воздействий.
На заказчиков, менеджеров и финансовых директоров, в свою очередь, тоже воздействуют какие-то силы.
Рыночные тренды, рынок труда, законодательная деятельность, инновации — всё это силы, которые воздействуют на системы. Заметьте, я говорю о силах, а не о стейкхолдерах и их "интересах", и пока не разделяю силы на внутренние и внешние.
При прочтении книги можно прийти к важному выводу: структура системы определяет её способность справляться с воздействием разных сил. Система с ригидной или хрупкой структурой рискует разрушиться под воздействием новой значимой силы.
Этот принцип применим и в программной инженерии. То, как вы спроектируете конструкцию программы, особенно структуру её модулей, определит её устойчивость к изменениям под воздействием разных сил.
Именно понимание взаимосвязи структуры и устойчивости системы делает книгу Медоуз столь полезной.
👍6🔥3❤1
Идентификация разных сил, воздействующих на систему, и учёт их возможного влияния в архитектуре — главная задача архитектора.
Иногда, кстати, видно сразу, что системе уже ничего не поможет в достижении успеха. В основном потому, что влиятельные силы в её успехе по-настоящему не заинтересованы.
И лучшее решение для инженера: не тратить своё время на такие активности.
Стоит ли инженерам тратить время на то, что заведомо обречено не иметь успех? Такие вещи можно делать и кустарным способом.
Иногда, кстати, видно сразу, что системе уже ничего не поможет в достижении успеха. В основном потому, что влиятельные силы в её успехе по-настоящему не заинтересованы.
И лучшее решение для инженера: не тратить своё время на такие активности.
Стоит ли инженерам тратить время на то, что заведомо обречено не иметь успех? Такие вещи можно делать и кустарным способом.
👍6
На мой взгляд, понятие «stakeholder», особенно в переводе, не способствует системному мышлению и препятствует построению адекватных ментальных моделей.
В английском языке существуют более точные синонимы, которые лучше описывают участников, влияющих на систему, — это «player» или «actor».
Например, пользователи — это заинтересованная сторона, то есть «stakeholder». Пользователи заинтересованы, по меньшей мере, в удобстве работы с системой. Однако часто на практике их мнение остаётся неучтённым — они фактически не имеют власти, их интересы игнорируются.
Совсем другое дело — руководители смежных подразделений, которые занимаются разработкой разных частей системы. Их интересами безболезненно пренебречь не получится, так как они являются влиятельными участниками процесса.
Но важно понимать, что часто на практике их сложно назвать заинтересованными сторонами в полном смысле этого слова. Их может не интересовать успех или даже существование системы как целого. Судьба системы как целого, для них надсистемы, может интересовать их меньше всего, если вообще хоть сколько-нибудь интересует.
В этом случае они выступают в роли игроков, движимых локальными целями, которые нередко находятся в непрерывном конфликте.
Таких игроков можно назвать незаинтересованными лицами, но при этом активными actors в контексте системы, внутренними силами. При этом они, безусловно, владеют значительными «долями» системы, весомыми стейками.
Актор — это значимый субъект, играющий заметную роль в том или ином процессе, в тех или иных условиях, а не какой-то стейкхолдер, «держатель интереса» или «обладатель доли», если эта доля ничтожна.
Как мне кажется, такой взгляд позволяет точнее разграничить роли и учитывать влияние различных участников на систему.
Да, есть признаки, по которым роли, группы людей или отдельных игроков относят к стейкхолдерам. Но из моей практики, такой процесс "классификации" часто утопает в бесконечных дискуссиях и ни к чему полезному в итоге не приводит.
В английском языке существуют более точные синонимы, которые лучше описывают участников, влияющих на систему, — это «player» или «actor».
Например, пользователи — это заинтересованная сторона, то есть «stakeholder». Пользователи заинтересованы, по меньшей мере, в удобстве работы с системой. Однако часто на практике их мнение остаётся неучтённым — они фактически не имеют власти, их интересы игнорируются.
Совсем другое дело — руководители смежных подразделений, которые занимаются разработкой разных частей системы. Их интересами безболезненно пренебречь не получится, так как они являются влиятельными участниками процесса.
Но важно понимать, что часто на практике их сложно назвать заинтересованными сторонами в полном смысле этого слова. Их может не интересовать успех или даже существование системы как целого. Судьба системы как целого, для них надсистемы, может интересовать их меньше всего, если вообще хоть сколько-нибудь интересует.
В этом случае они выступают в роли игроков, движимых локальными целями, которые нередко находятся в непрерывном конфликте.
Таких игроков можно назвать незаинтересованными лицами, но при этом активными actors в контексте системы, внутренними силами. При этом они, безусловно, владеют значительными «долями» системы, весомыми стейками.
Актор — это значимый субъект, играющий заметную роль в том или ином процессе, в тех или иных условиях, а не какой-то стейкхолдер, «держатель интереса» или «обладатель доли», если эта доля ничтожна.
Как мне кажется, такой взгляд позволяет точнее разграничить роли и учитывать влияние различных участников на систему.
Да, есть признаки, по которым роли, группы людей или отдельных игроков относят к стейкхолдерам. Но из моей практики, такой процесс "классификации" часто утопает в бесконечных дискуссиях и ни к чему полезному в итоге не приводит.
👍5
Что, например, это может значить на практике?
Нужно стремиться усиливать игроков, которые представляют интересы пользователей.
Или создавать механизмы, делающие невыгодным и рискованным достижение локальных целей в ущерб общим.
И это можно делать с помощью «архитектуры». Архитектура неразрывно связана с выстраиванием производственных процессов, организационных структур, систем мотивации и контроля.
На самом деле, всё это и есть какая-то система, только высокого уровня.
Нужно стремиться усиливать игроков, которые представляют интересы пользователей.
Или создавать механизмы, делающие невыгодным и рискованным достижение локальных целей в ущерб общим.
И это можно делать с помощью «архитектуры». Архитектура неразрывно связана с выстраиванием производственных процессов, организационных структур, систем мотивации и контроля.
На самом деле, всё это и есть какая-то система, только высокого уровня.
👍12❤1
Хочу оформить пятничный пост как вишенку на торте.
Донелла Медоуз в «Азбуке системного мышления» описывает примеры, где в принимаемых для решения локальных задач мерах было проигнорировано их влияние на систему в целом, что в итоге привело к ее деградации или разрушению.
При этом она упоминает ограниченную рациональность, введённую нобелевским лауреатом Гербертом Саймоном.
Приведу цитату:
«Ограниченная рациональность — это логика, которая приводит к решениям или действиям, имеющим смысл в рамках одной части системы, но не являющимся рациональными в более широком контексте»
Рекомендую всем разобраться с ограниченной рациональностью.
Генри Минцберг также часто опирается на ограниченную рациональность в своих суждениях, но при этом нередко критикует другие результаты Герберта Саймона.
Но на самом деле «вишенка» не об этом.
Почему я всё же решил поднять вопрос узости понятия «stakeholder»?
Мы создаём и развиваем системы на огромном игровом поле, где наиболее влиятельные участники процесса используют любые возможности, чтобы обходить правила игры.
Именно в этой игре кроются истинные причины провалов проектов, а не в том, что кто-то выбрал RabbitMQ вместо Kafka.
Вот почему я плавно ввёл понятие «player»: процесс создания и развития системы можно рассматривать как игру, что делает возможным применение теории игр.
Напомню, что игрок в теории игр — это рациональный индивид, имеющий заинтересованность в исходе игры и возможности воздействовать на него.
Дальше я отрефлексирую эту ветку рассуждений и подведу итоги. После этого «пройдусь» по отдельным моментам из книги «Modern Software Engineering».
Донелла Медоуз в «Азбуке системного мышления» описывает примеры, где в принимаемых для решения локальных задач мерах было проигнорировано их влияние на систему в целом, что в итоге привело к ее деградации или разрушению.
При этом она упоминает ограниченную рациональность, введённую нобелевским лауреатом Гербертом Саймоном.
Приведу цитату:
«Ограниченная рациональность — это логика, которая приводит к решениям или действиям, имеющим смысл в рамках одной части системы, но не являющимся рациональными в более широком контексте»
Рекомендую всем разобраться с ограниченной рациональностью.
Генри Минцберг также часто опирается на ограниченную рациональность в своих суждениях, но при этом нередко критикует другие результаты Герберта Саймона.
Но на самом деле «вишенка» не об этом.
Почему я всё же решил поднять вопрос узости понятия «stakeholder»?
Мы создаём и развиваем системы на огромном игровом поле, где наиболее влиятельные участники процесса используют любые возможности, чтобы обходить правила игры.
Именно в этой игре кроются истинные причины провалов проектов, а не в том, что кто-то выбрал RabbitMQ вместо Kafka.
Вот почему я плавно ввёл понятие «player»: процесс создания и развития системы можно рассматривать как игру, что делает возможным применение теории игр.
Напомню, что игрок в теории игр — это рациональный индивид, имеющий заинтересованность в исходе игры и возможности воздействовать на него.
Дальше я отрефлексирую эту ветку рассуждений и подведу итоги. После этого «пройдусь» по отдельным моментам из книги «Modern Software Engineering».
👍12🔥1