Часто в одном предложении или высказывании можно увидеть как высокоуровневые абстракции, так и детали реализации на конкретном языке программирования. Такое смешение уровней абстракции значительно усложняет восприятие информации и затрудняет коммуникацию. Это довольно распространённая ошибка. И это свидетельствует о наличии "каши в голове».
👍2
Важно отметить, что на самом деле системы, надсистемы и подсистемы — это всё системы. То, чем является система в данный конкретный момент — надсистемой, подсистемой или собственно системой — зависит от уровня рассмотрения и от того, какая именно система интересует нас в данный момент. Чуть позже мы вернёмся к этому вопросу и добавим немного деталей.
В разных источниках системный оператор изображается по-разному. Мне нравится вариант, который представлен в книге Владимира Петрова «Талантливое мышление. ТРИЗ». Он привлекателен тем, что в этом варианте удобно отображать особенности программных систем. И на следующем шаге мы это увидим.
А сейчас приведу цитату из этой книги и ещё немного порассуждаю о системном операторе.
А сейчас приведу цитату из этой книги и ещё немного порассуждаю о системном операторе.
#ИМХО #оффтоп
Немного из практики. Agile уничтожает желание и способность Agile-команд/трайбов учитывать надсистемы и интересы за пределами своих Agile-колодцев. И подходы Scaled Agile, на мой взгляд, не способны исправить ситуацию, так как они предполагают сотрудничество, а сотрудничество в феодальных Agile-структурах невозможно в принципе.
Помимо преимуществ, независимость и автономность может вызывать странные эффекты, истреблять холизм и разрушать целостность систем.
Что это значит на практике? На практике это означает невозможность успешной реализации крупных программ и масштабных кросс-продуктовых инициатив.
Немного из практики. Agile уничтожает желание и способность Agile-команд/трайбов учитывать надсистемы и интересы за пределами своих Agile-колодцев. И подходы Scaled Agile, на мой взгляд, не способны исправить ситуацию, так как они предполагают сотрудничество, а сотрудничество в феодальных Agile-структурах невозможно в принципе.
Помимо преимуществ, независимость и автономность может вызывать странные эффекты, истреблять холизм и разрушать целостность систем.
Что это значит на практике? На практике это означает невозможность успешной реализации крупных программ и масштабных кросс-продуктовых инициатив.
👍5🤔2😱1💯1
В посте выше я употребил термин «холизм». Давайте вспомним, что он означает.
В академических статьях и словарях я не нашёл для себя определения, простого и удобного для объяснения, поэтому скомпилировал определение из разных источников.
"ХОЛИЗМ (греч. holos - целый) - понятие, связанное с разработкой в 20 в. системной методологии и системной парадигмы в познании. ...
Холистическая позиция заключается в приоритетном рассмотрении целого с точки зрения возникающих при взаимодействии элементов в системе новых качеств или целостных свойств, отсутствующих у составляющих систему ингредиентов." (Новейший философский словарь, А. А. Грицанов, 1999 г.)
В википедии даётся уточнение возникновения этого понятия:
"В узком смысле под холизмом понимают «философию целостности», разработанную южноафриканским философом и политическим деятелем Я. Смэтсом, который ввёл в философскую речь термин «холизм» в 1926 году, опираясь на идею, которая восходит к «Метафизике» Аристотеля, что «целое есть нечто помимо частей»".
В академических статьях и словарях я не нашёл для себя определения, простого и удобного для объяснения, поэтому скомпилировал определение из разных источников.
"ХОЛИЗМ (греч. holos - целый) - понятие, связанное с разработкой в 20 в. системной методологии и системной парадигмы в познании. ...
Холистическая позиция заключается в приоритетном рассмотрении целого с точки зрения возникающих при взаимодействии элементов в системе новых качеств или целостных свойств, отсутствующих у составляющих систему ингредиентов." (Новейший философский словарь, А. А. Грицанов, 1999 г.)
В википедии даётся уточнение возникновения этого понятия:
"В узком смысле под холизмом понимают «философию целостности», разработанную южноафриканским философом и политическим деятелем Я. Смэтсом, который ввёл в философскую речь термин «холизм» в 1926 году, опираясь на идею, которая восходит к «Метафизике» Аристотеля, что «целое есть нечто помимо частей»".
👍2
Холистический подход вполне можно назвать системным. Приоритет в этом подходе отдаётся рассмотрению целого. При решении задач, в размышлениях и рассуждениях мы удерживаем в фокусе целое. Мы не сводим систему только к сокупности отдельных её элементов.
Сейчас в разных областях деятельности развивается междисциплинарность. Междисциплинарность предполагает использование холистического подхода.
Хороший пример — междисциплинарная медицина. Холистический подход в медицине предполагает проведение профилактических глубоких исследований и рассмотрение человеческого организма как единого целого, объединяя различные клинические направления.
В сложных, комплексных программных системах мы больше не разделяем операционные/транзакционные и аналитические решения; они представляют собой две взаимосвязанные части системы.
Мы рассматриваем бизнес-архитектуру, архитектуру приложений, архитектуру данных и другие «архитектуры» как разные части единой архитектуры системы.
Хороший пример — междисциплинарная медицина. Холистический подход в медицине предполагает проведение профилактических глубоких исследований и рассмотрение человеческого организма как единого целого, объединяя различные клинические направления.
В сложных, комплексных программных системах мы больше не разделяем операционные/транзакционные и аналитические решения; они представляют собой две взаимосвязанные части системы.
Мы рассматриваем бизнес-архитектуру, архитектуру приложений, архитектуру данных и другие «архитектуры» как разные части единой архитектуры системы.
👍4
Холизм противопоставляется редукционизму. Что такое редукционизм мы рассмотрим в следующих постах.
"РЕДУКЦИОНИЗМ (от лат. reductio) — методологический принцип, согласно которому сложные явления могут быть полностью объяснены на основе законов, свойственных более простым." (Большой Энциклопедический словарь, 2000)
Применяя редукционизм, мы разделяем целое на части и рассматриваем их по отдельности.
Применяя редукционизм, мы разделяем целое на части и рассматриваем их по отдельности.
#тизер #дляайтишников
Мы разберём всю эту теорию на практике, включая её применение к модульным монолитам и микросервисам.
Мы разберём всю эту теорию на практике, включая её применение к модульным монолитам и микросервисам.
Познать сложную систему во всех деталях невозможно.
Мы выполняем декомпозицию, разделяем систему на части и рассматриваем их по отдельности с нужной для решения (текущей) задачи степенью детализации. Вместе с этим мы выполняем абстракцию и рассматриваем эти же части в составе целого, но уже с меньшим уровнем детализации.
Применяя декомпозицию и абстракцию, мы детально рассмотрим эти подходы, и перемещаясь по системным уровням (уровням абстракции), мы управляем сложностью. Это позволяет нам эффективно работать со сложными системами.
Иными словами, мы формируем или воспроизводим структуру системы и управляем сложностью, методично декомпозируя её на части, при этом не рассматриваем их в изоляции и учитываем их связь с целым. Это и есть холистический подход на практике.
Холистический подход также называют целостным.
Мы выполняем декомпозицию, разделяем систему на части и рассматриваем их по отдельности с нужной для решения (текущей) задачи степенью детализации. Вместе с этим мы выполняем абстракцию и рассматриваем эти же части в составе целого, но уже с меньшим уровнем детализации.
Применяя декомпозицию и абстракцию, мы детально рассмотрим эти подходы, и перемещаясь по системным уровням (уровням абстракции), мы управляем сложностью. Это позволяет нам эффективно работать со сложными системами.
Иными словами, мы формируем или воспроизводим структуру системы и управляем сложностью, методично декомпозируя её на части, при этом не рассматриваем их в изоляции и учитываем их связь с целым. Это и есть холистический подход на практике.
Холистический подход также называют целостным.
👍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