#тизер #дляайтишников
Мы разберём всю эту теорию на практике, включая её применение к модульным монолитам и микросервисам.
Мы разберём всю эту теорию на практике, включая её применение к модульным монолитам и микросервисам.
Познать сложную систему во всех деталях невозможно.
Мы выполняем декомпозицию, разделяем систему на части и рассматриваем их по отдельности с нужной для решения (текущей) задачи степенью детализации. Вместе с этим мы выполняем абстракцию и рассматриваем эти же части в составе целого, но уже с меньшим уровнем детализации.
Применяя декомпозицию и абстракцию, мы детально рассмотрим эти подходы, и перемещаясь по системным уровням (уровням абстракции), мы управляем сложностью. Это позволяет нам эффективно работать со сложными системами.
Иными словами, мы формируем или воспроизводим структуру системы и управляем сложностью, методично декомпозируя её на части, при этом не рассматриваем их в изоляции и учитываем их связь с целым. Это и есть холистический подход на практике.
Холистический подход также называют целостным.
Мы выполняем декомпозицию, разделяем систему на части и рассматриваем их по отдельности с нужной для решения (текущей) задачи степенью детализации. Вместе с этим мы выполняем абстракцию и рассматриваем эти же части в составе целого, но уже с меньшим уровнем детализации.
Применяя декомпозицию и абстракцию, мы детально рассмотрим эти подходы, и перемещаясь по системным уровням (уровням абстракции), мы управляем сложностью. Это позволяет нам эффективно работать со сложными системами.
Иными словами, мы формируем или воспроизводим структуру системы и управляем сложностью, методично декомпозируя её на части, при этом не рассматриваем их в изоляции и учитываем их связь с целым. Это и есть холистический подход на практике.
Холистический подход также называют целостным.
👍3
#ИМХО #оффтоп
Современная литература по архитектуре программных систем, включая книги по эволюционной литературе - это сплошной редукционизм. Рассмотрение архитектуры ведётся от кода, от кодовой базы. Авторы не просто за деревьями леса не видят, они не видят деревьев за ветками и листьями. Это, на мой взгляд, серьезная проблема.
У меня есть только одна гипотеза, почему так происходит. Я думаю, что литература "от кода" имеет потенциально больший охват и, конечно, продажи. Это подход, ориентированный на продажи.
Современная литература по архитектуре программных систем, включая книги по эволюционной литературе - это сплошной редукционизм. Рассмотрение архитектуры ведётся от кода, от кодовой базы. Авторы не просто за деревьями леса не видят, они не видят деревьев за ветками и листьями. Это, на мой взгляд, серьезная проблема.
У меня есть только одна гипотеза, почему так происходит. Я думаю, что литература "от кода" имеет потенциально больший охват и, конечно, продажи. Это подход, ориентированный на продажи.
👍4
А теперь вернёмся к системному оператору и разберёмся с сутью его «экранов». Также обсудим, в чём заключается преимущество системного оператора и что он не показывает в явном виде.
Понял, что нужны примеры. Не терпится их привести. После работы сегодня поделюсь несколькими кейсами системного (холистического) подхода и несистемного (Как бог на душу положит)
👍4
#кейс
Неудачный кейс:
Запросы к базе данных выполняются медленно, и производительность ухудшается.
Меры:
Оптимизация запросов, тюнинг базы данных.
Ошибка:
Изоляция наблюдаемого явления — медленное выполнение запросов и постоянная деградация производительности — и попытка устранения этой «проблемы» изолированно.
Результат:
Возможности оптимизации запросов и тюнинга базы данных исчерпаны, но выполнение запросов продолжает замедляться. Время потеряно...
В системном подходе:
Посмотреть на проблему шире, в целом. Возможно, стоит оптимизировать алгоритмы или сценарии бизнес-процессов (на более высоком уровне, в надсистеме), чтобы устранить такие «тяжелые» запросы (в рассматриваемой системе) в принципе. Или, например, проанализировать характер запросов и рассмотреть возможность смены типа базы данных, допустим, с реляционной на колоночную.
Неудачный кейс:
Запросы к базе данных выполняются медленно, и производительность ухудшается.
Меры:
Оптимизация запросов, тюнинг базы данных.
Ошибка:
Изоляция наблюдаемого явления — медленное выполнение запросов и постоянная деградация производительности — и попытка устранения этой «проблемы» изолированно.
Результат:
Возможности оптимизации запросов и тюнинга базы данных исчерпаны, но выполнение запросов продолжает замедляться. Время потеряно...
В системном подходе:
Посмотреть на проблему шире, в целом. Возможно, стоит оптимизировать алгоритмы или сценарии бизнес-процессов (на более высоком уровне, в надсистеме), чтобы устранить такие «тяжелые» запросы (в рассматриваемой системе) в принципе. Или, например, проанализировать характер запросов и рассмотреть возможность смены типа базы данных, допустим, с реляционной на колоночную.
👍2
#кейс
Неудачный кейс:
Миграция с монолита на модульное, компонуемое решение (Composable Architecture). Технически, переход с монолита на микросервисы (почему микросервисы, это фейк, увидим позже).
Ошибка:
Разделили функционал монолита на отдельные части (продукты) и передали их реализацию (на микросервисах) разным автономным кросс-функциональным командам. Редукционизм...
Результат:
Разрывы клиентских путей, негативный пользовательский опыт, проблемы при интеграции, трудности или невозможность реализации кросс-продуктовых сценариев, ухудшение качества данных (противоречивость, нарушение целостности и пр.), дорогая реализация SSO или его отсутствие, долгое разрешение инцидентов в интеграционных сценариях и т.д.
В системном подходе:
Выстроить (в надсистеме) федеративное управление (например, проектное поверх продуктовой разработки), централизовать архитектуру, предусмотреть платформенные инициативы.
Неудачный кейс:
Миграция с монолита на модульное, компонуемое решение (Composable Architecture). Технически, переход с монолита на микросервисы (почему микросервисы, это фейк, увидим позже).
Ошибка:
Разделили функционал монолита на отдельные части (продукты) и передали их реализацию (на микросервисах) разным автономным кросс-функциональным командам. Редукционизм...
Результат:
Разрывы клиентских путей, негативный пользовательский опыт, проблемы при интеграции, трудности или невозможность реализации кросс-продуктовых сценариев, ухудшение качества данных (противоречивость, нарушение целостности и пр.), дорогая реализация SSO или его отсутствие, долгое разрешение инцидентов в интеграционных сценариях и т.д.
В системном подходе:
Выстроить (в надсистеме) федеративное управление (например, проектное поверх продуктовой разработки), централизовать архитектуру, предусмотреть платформенные инициативы.
На первый взгляд, последний кейс не выглядит архитектурным. Возможно, но только если вы не архитектор, отвечающий за всю миграцию.
Следующий кейс будет посложнее, но удачный (где всё правильно сразу).
Следующий кейс будет посложнее, но удачный (где всё правильно сразу).
Что забавно, на конференциях по высоконагруженным приложениям рассказывают про оптимизацию работы со строками, а на практике, как правило, реализация бизнес-процессов «в лоб» кладёт базу данных.
Локальная оптимизация кода дает выигрыш в процентах, тогда как запросы к базе данных или излишние сетевые взаимодействия просаживают время отклика на порядки.
Наверное, это можно объяснить тем, что оптимизировать код или тюнить БД интересней и «дешевле» для мозга, чем системно решать задачи.
И, что немаловажно, за "думание" мало кто платит, тогда как системный подход требует значительных мыслительных усилий.
Локальная оптимизация кода дает выигрыш в процентах, тогда как запросы к базе данных или излишние сетевые взаимодействия просаживают время отклика на порядки.
Наверное, это можно объяснить тем, что оптимизировать код или тюнить БД интересней и «дешевле» для мозга, чем системно решать задачи.
И, что немаловажно, за "думание" мало кто платит, тогда как системный подход требует значительных мыслительных усилий.
👍7
#кейс
Удачный кейс
Создание архитектуры ритейлового продукта в компании, которая имеет опыт исключительно разработки продуктов для корп клиентов.
Контекст:
Требований нет, бизнес-процессы не известны, есть установка - максимально переиспользовать текущие системы.
Меры:
Формирование гипотез бизнес-процессов и нефункциональных требований (НФТ) к системе, согласование их с бизнесом. Исследование результатов нагрузочного тестирования текущих систем (в окружении) и существующих процессов разработки.
Выводы:
По результатам тестов и исследования процессов разработки и орг структур стало понятно, что ни одну текущую систему переиспользовать нельзя (не выдержат нагрузкук) и нужно выстраивать новую орг структуру и процессы разработки (релизный цикл в квартал не подходит).
Дальнейшие действия:
Рядом с текущей, устоявшейся и вполне успешно решающей задачи поддержки существующих систем орг структурой, выстроена продуктовая "модальность" с короткими релизными циклами (итерациями), внедрены новые технологии и запущена разработка с нуля.
Удачный кейс
Создание архитектуры ритейлового продукта в компании, которая имеет опыт исключительно разработки продуктов для корп клиентов.
Контекст:
Требований нет, бизнес-процессы не известны, есть установка - максимально переиспользовать текущие системы.
Меры:
Формирование гипотез бизнес-процессов и нефункциональных требований (НФТ) к системе, согласование их с бизнесом. Исследование результатов нагрузочного тестирования текущих систем (в окружении) и существующих процессов разработки.
Выводы:
По результатам тестов и исследования процессов разработки и орг структур стало понятно, что ни одну текущую систему переиспользовать нельзя (не выдержат нагрузкук) и нужно выстраивать новую орг структуру и процессы разработки (релизный цикл в квартал не подходит).
Дальнейшие действия:
Рядом с текущей, устоявшейся и вполне успешно решающей задачи поддержки существующих систем орг структурой, выстроена продуктовая "модальность" с короткими релизными циклами (итерациями), внедрены новые технологии и запущена разработка с нуля.
👍4
Этот кейс вроде бы совсем не «архитектурный». Но это совершенно не так, этот кейс максимально «архитектурный».
Архитекторам часто приходится решать задачи за рамками проектирования архитектуры (High-level design) и уж тем более низкоуровневого проектирования (Low-level design).
Архитектурные решения должны приводить к достижимому результату. А для этого нужно учитывать контекст, в которой будет помещена система, причём на всех этапах её жизненного цикла.
Надсистемы (системы выше по иерархии) и смежные системы, то есть окружение системы, определяют контекст и прежде всего задают ограничения.
В кейсе выше были не просто выявлены ограничения, но и (проактивно) изменена надсистема и созданы предпосылки для удачной реализации системы.
Архитекторам часто приходится решать задачи за рамками проектирования архитектуры (High-level design) и уж тем более низкоуровневого проектирования (Low-level design).
Архитектурные решения должны приводить к достижимому результату. А для этого нужно учитывать контекст, в которой будет помещена система, причём на всех этапах её жизненного цикла.
Надсистемы (системы выше по иерархии) и смежные системы, то есть окружение системы, определяют контекст и прежде всего задают ограничения.
В кейсе выше были не просто выявлены ограничения, но и (проактивно) изменена надсистема и созданы предпосылки для удачной реализации системы.
👍1
#ИМХО #оффтоп
Инженеры часто работают в проектах, у которых на старте нет никаких шансов на успех. И вот чтобы повысить шансы на успех, можно (при желании) воздействовать на окружение и прежде всего на надсистему.
Да, опытным архитекторам часто приходится создавать предпосылки для успешной реализации системы (способствовать feasibility).
И шансы на успех во-многом зависят от полномочий и возможностей по эскалации (изменить надсистему, как и смежные системы, без эскалаций практически невозможно). Решения придётся продавливать, так как системы сопротивляются изменениям.
Инженеры часто работают в проектах, у которых на старте нет никаких шансов на успех. И вот чтобы повысить шансы на успех, можно (при желании) воздействовать на окружение и прежде всего на надсистему.
Да, опытным архитекторам часто приходится создавать предпосылки для успешной реализации системы (способствовать feasibility).
И шансы на успех во-многом зависят от полномочий и возможностей по эскалации (изменить надсистему, как и смежные системы, без эскалаций практически невозможно). Решения придётся продавливать, так как системы сопротивляются изменениям.
👍2
#юмор
Важная причина провалов проектов по разработке заключается в Законе Круглова, который гласит: «Структура программных систем копирует структуру амбиций и политических притязаний руководителей»
Важная причина провалов проектов по разработке заключается в Законе Круглова, который гласит: «Структура программных систем копирует структуру амбиций и политических притязаний руководителей»
🔥8🤔1
Амбиции руководителей и их политические прятязания формируют политический ландшафт компании, который, в свою очередь, во-многом определяет структуру коммуникаций.
Если вспомнить закон Конвея, становится ясно, почему эта шутка имеет долю истины: «организации создают системы, которые отражают структуру их коммуникаций».
[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?
Что это значит для практиков? Если мы хотим влиять на качество систем, нужно влиять на амбиции и политические притязания.
Если вспомнить закон Конвея, становится ясно, почему эта шутка имеет долю истины: «организации создают системы, которые отражают структуру их коммуникаций».
[O]rganizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations.
— Melvin E. Conway, How Do Committees Invent?
Что это значит для практиков? Если мы хотим влиять на качество систем, нужно влиять на амбиции и политические притязания.
🔥5
Я уже неоднократно упоминал "структуры" в цитатах и размышлениях. Позже мы подробно разберёмся с этим понятием, но сейчас важно подчеркнуть: "качество структур определяет качество систем, включая их способность развиваться и эволюционировать."
Не случайно Генри Минцберг, признанный гуру стратегического менеджмента, назвал один из своих бестселлеров «Структура в кулаке». И не просто так Донелла Медоуз в другом бестселлере "Азбука системного мышления" уделяет структурам особое внимание.
Не случайно Генри Минцберг, признанный гуру стратегического менеджмента, назвал один из своих бестселлеров «Структура в кулаке». И не просто так Донелла Медоуз в другом бестселлере "Азбука системного мышления" уделяет структурам особое внимание.
👍2
Теперь мы возвращаемся к "экранам" системного оператора Альтшуллера, чтобы рассмотреть их с позиции когнитивной психологии.
Но прежде важно отметить, что системный оператор представляет собой модель структуры системы — точнее, одну из моделей, одной из структур.
Но прежде важно отметить, что системный оператор представляет собой модель структуры системы — точнее, одну из моделей, одной из структур.
👍3
В 2008 году я защитил диссертацию по приложению методов искусственного интеллекта в технической диагностике.
Тема моей работы начиналась со слов: "Триадная фреймовая модель представления знаний в технической диагностике..."
В целом, я занимался вопросами построения систем поддержки принятия решений в технической диагностике.
В начале 2000-х было принято начинать изучение ИИ с основ, включая когнитивную психологию. Тогда считалось нормальным — читать книги.
Кстати, в 2002 году мы обучили нашу первую нейронную сеть. Но оказалось, что для наших задач "нейронки" не подходят. В итоге я переключился на семантические модели и, если говорить современным языком, на графы знаний.
Тема моей работы начиналась со слов: "Триадная фреймовая модель представления знаний в технической диагностике..."
В целом, я занимался вопросами построения систем поддержки принятия решений в технической диагностике.
В начале 2000-х было принято начинать изучение ИИ с основ, включая когнитивную психологию. Тогда считалось нормальным — читать книги.
Кстати, в 2002 году мы обучили нашу первую нейронную сеть. Но оказалось, что для наших задач "нейронки" не подходят. В итоге я переключился на семантические модели и, если говорить современным языком, на графы знаний.
🔥4
Опираясь на свои знания, хочу сказать, что "экран" системного оператора, который на самом деле отражает единицу декомпозиции системы, причём с учётом фактора времени, кажется очень удобным для представления структуры знаний, которую мы можем одновременно удерживать в памяти.
На мой взгляд, "экран" — это удачное название для элемента декомпозиции системы с точки зрения когнитивной психологии.
Когда мы рассматриваем отдельный элемент модели системы, мы "загружаем" в память соответствующую структуру знаний о нём (экран). Затем мы смещаем фокус (рассмотрения системы) на другой элемент и заменяем структуру знаний в памяти на новую (другой экран).
Если знания меняются, изменяем их структуру в памяти (экран).
На мой взгляд, "экран" — это удачное название для элемента декомпозиции системы с точки зрения когнитивной психологии.
Когда мы рассматриваем отдельный элемент модели системы, мы "загружаем" в память соответствующую структуру знаний о нём (экран). Затем мы смещаем фокус (рассмотрения системы) на другой элемент и заменяем структуру знаний в памяти на новую (другой экран).
Если знания меняются, изменяем их структуру в памяти (экран).
👍4
Очень важно, чтобы «структура знаний» в нашей памяти содержала все необходимые детали для рассуждений и принятия решений в рамках конкретной задачи и не включала «лишней» информации, чтобы не расходовать впустую драгоценную память и другие когнитивные ресурсы, которые у нас, людей, весьма ограничены.
Здесь я возвращаюсь к декомпозиции и абстракции. Ещё чуть-чуть, через шаг, и я дам определение этим понятиям. На следующем шаге мы, однако, рассмотрим фреймы Марвина Минского
Здесь я возвращаюсь к декомпозиции и абстракции. Ещё чуть-чуть, через шаг, и я дам определение этим понятиям. На следующем шаге мы, однако, рассмотрим фреймы Марвина Минского
🔥3👍2
Intelligent Systems Architecture
Опираясь на свои знания, хочу сказать, что "экран" системного оператора, который на самом деле отражает единицу декомпозиции системы, причём с учётом фактора времени, кажется очень удобным для представления структуры знаний, которую мы можем одновременно удерживать…
#оффтоп
На практике, однако, мы видим, что часто в памяти макароны замещаются лапшой, и ещё чаще лапша непрерывно смешивается с макаронами
На практике, однако, мы видим, что часто в памяти макароны замещаются лапшой, и ещё чаще лапша непрерывно смешивается с макаронами
😁3
#оффтоп #литература
Читаю сейчас книгу Data Mesh in Action: https://www.amazon.com/Data-Mesh-Action-Jacek-Majchrzak/dp/1633439976/.
Ценная работа, в которой сформулированы многие идеи, которые давно хотел увидеть в литературе.
Особое внимание привлекла глава 4.2: «Applying ownership using domain decomposition.», особенно раздел 4.2.1 «Domain, subdomain, and business capability», где авторы проводят сравнение доменов из DDD с бизнес-возможностями. Не со всем согласен, но пост не об этом.
В этой главе авторы весьма ёмко выразили мысль о том, как следует формулировать названия бизнес-возможностей и определять их в целом.
Приведу пару цитат:
"A business capability is what a business can do. It focuses on what, not how or who. It is defined by its outcome, which is usually expressed as a qualitative rather than quantitative measure."
"...Therefore, we should also focus on the outcome (qualitative), not the output (quantitative)."
For example, if we organize a birthday party for children, it doesn’t really matter how many cakes, toys, chairs, and tables we prepare (quantitative output). What matters is happy and smiling kids after the party (qualitative outcome); how we achieve that is of secondary concern."
И далее приводится пример "правильного" результата (outcome):
"Produce good-enough quality movies and series desired by the audience. This is a proper outcome. It is a qualitative measure and is focused on the impact that should be made (a series desired by the audience)."
Читаю сейчас книгу Data Mesh in Action: https://www.amazon.com/Data-Mesh-Action-Jacek-Majchrzak/dp/1633439976/.
Ценная работа, в которой сформулированы многие идеи, которые давно хотел увидеть в литературе.
Особое внимание привлекла глава 4.2: «Applying ownership using domain decomposition.», особенно раздел 4.2.1 «Domain, subdomain, and business capability», где авторы проводят сравнение доменов из DDD с бизнес-возможностями. Не со всем согласен, но пост не об этом.
В этой главе авторы весьма ёмко выразили мысль о том, как следует формулировать названия бизнес-возможностей и определять их в целом.
Приведу пару цитат:
"A business capability is what a business can do. It focuses on what, not how or who. It is defined by its outcome, which is usually expressed as a qualitative rather than quantitative measure."
"...Therefore, we should also focus on the outcome (qualitative), not the output (quantitative)."
For example, if we organize a birthday party for children, it doesn’t really matter how many cakes, toys, chairs, and tables we prepare (quantitative output). What matters is happy and smiling kids after the party (qualitative outcome); how we achieve that is of secondary concern."
И далее приводится пример "правильного" результата (outcome):
"Produce good-enough quality movies and series desired by the audience. This is a proper outcome. It is a qualitative measure and is focused on the impact that should be made (a series desired by the audience)."
👍7