Intelligent Systems Architecture – Telegram
Intelligent Systems Architecture
1.06K subscribers
29 photos
6 files
54 links
Про архитектуру и принципы построения систем на основе искусственного интеллекта — от моделей до AI-платформ.

Контент в канале защищён авторским правом.

Геннадий Круглов
@GKruglov
Download Telegram
В IcePanel собрали пару ссылок на тексты из серии Modelling vs diagramming и дополнили их новыми словами и картинками. Но, на мой взгляд, не сделали главного, а именно не собрали в одну линию эскизы, модели, представления, исходники, работающее приложение, изменения. Обошли стороной вопросы когда и зачем нужны модели или диаграммы

В этом плане, даже матрица Захмана 1987 года, прокладывающая логику от набросков на салфетке до готовой системы, смотрится более целостной.

Ссылки:
[1] Comparison - C4 modelling vs diagramming
[2] Ardoq Compared to Drawing, Modeling, and Data Visualization Tools
[3] Modelling vs diagramming software architecture
👍1
#критика

Противопоставлять моделирование и diagramming нельзя в принципе, потому что:
1. Диаграммы порождаются в процессе моделирования, проектирования, документировании и тп.
2. Диаграммы всегда являются моделями, без исключений; почему именно — рассмотрим в деталях позже.

Когда человек утверждает, что выполняет диаграмминг (diagramming), он часто не до конца осознает, что делает на самом деле (см. п.1).

Создавая диаграммы, мы создаем модели. А в одном из значений, построение и изучение моделей реальных объектов и явлений — это и есть моделирование.

Противопоставлять создание моделей моделированию - пустое занятие.
👍8😁1🤔1
Кстати, нашел только одно определение для diagramming:
«Diagramming - providing a chart or outline of a system
...
type of: representation»
https://www.vocabulary.com/dictionary/diagramming

При этом, chart (диаграмма) - это модель. И можно сказать, что модель это представление (representation) некоего объекта, предназначенное для рассмотрения определённых его аспектов (в разных целях).

Мы создаем модели в виде диаграмм в рамках таких процессов, как моделирование или проектирование. Даже скетчи (эскизы) мы рисуем не ради художественного самовыражения, а в более практичных целях (это тоже модели).
👍3
#миф
Ну а о блеске и нищете C4 Model мы поговорим отдельно и расскажем, как пытались разработать метамодель для моделей в C4 Model. Это далось непросто.

Кстати, авторы C4 Model благоразумно не называют её нотацией. Они говорят: "The C4 model is an "abstraction-first" approach to diagramming software architecture,...
The C4 model is notation independent, and doesn't prescribe any particular notation"
https://c4model.com/#Notation

И да, относить C4 Model к нотациям действительно неверно — это миф.
👍9
Посты в этом канале я публикую по контент-плану, включающему мои многолетние наработки, которыми хочу поделиться. Правда стало понятно, что развитие мысли уводит от плана.

Иначе и быть не может, ведь развитие не происходит точно по плану.

Сейчас я пересматриваю контент-план и работаю над созданием навигации по каналу. При этом не хочется нарушать динамику и важно продолжать делиться мыслями.

Погружаясь в тему стратегий, у меня возникла идея сформулировать архитектурные максимы, по аналогии с максимами в управлении и стратегии.

Максима — это правило поведения, выраженное в краткой формуле.
🔥5👍3
#максима

Не приступайте к разработке нового функционала без стабилизации текущего.

Многие современные системы быстро становятся легаси. Это часто происходит из-за непомерного технического долга. Непомерный технический долг приводит к утрате контроля над сложностью, когда методы управления сложностью уже не работают.

https://news.1rj.ru/str/IndustrialSoftwareArchitecture/90

Строители не начинают возводить стены, пока не застынет фундамент. Мы же почему-то считаем, что законы в «софте» не работают и долги отдавать не нужно.

Если вы перестали понимать, как работает система, или не можете спрогнозировать реакцию системы на очередные изменения, значит, вы утратили контроль над сложностью, и ваше решение теперь легаси.
👍3💯3❤‍🔥2🔥1
#FYI
Легаси (от англ. legacy — наследие) — в одном из значений это решение, в котором разобраться чрезвычайно трудно или вовсе невозможно. Такое решение практически не поддаётся развитию и зачастую рациональнее его «переписать», чем пытаться развивать.
👍2🤔1
Решение может стать легаси по разным причинам, не только из-за непомерного технического долга. Например, команда может уйти, не оставив документации, или используемые технологии могут устареть.

Легаси — это именно наследие, не обязательно наследство от предыдущей команды или вендора. Это также наследие наших собственных решений, бездействия и недальновидности.

В широком смысле легаси — это решение, которое невозможно или нецелесообразно развивать.
👍8
Там, где начинается легаси, заканчивается инженерия.

Напомню, инженерия это: «Творческое применение научных принципов для проектирования или конструирования машин, аппаратов или производственных процессов или эксплуатации их с полным пониманием их устройства; или прогнозирования их поведение…»

https://news.1rj.ru/str/IndustrialSoftwareArchitecture/45
👍7🔥3🤨1
#максима

Сначала создайте коммерческий продукт, и только потом мигрируйте на него.

Если перед вами одновременно стоят задачи миграции легаси и коммерциализации итогового решения, начните с разработки коммерческого продукта.

Миграция, в целом, — это вынужденный и болезненный шаг, сопряжённый с выживанием, который редко приносит позитивный опыт. Цель при миграции — выжить, и целеполагание соответствующее.

Коммерческий же продукт, который принят рынком, будет и внутренних пользователей радовать.

Важные условия: решение должно быть модульным; коммерциализация всего функционала без исключения не обязательна; действовать стоит итеративно.

Эта формула (максима) применима, однако, только если есть ресурсы — время и деньги.
👍41🤔1
Коммерческий продукт, лишённый лицензий, обновлений и поддержки, — это легаси. Такой продукт развивать невозможно.
👍2❤‍🔥1
Хочу поделиться видео Жени Лукьянова про микросервисы.

В начале этого видео Женя рассказывает историю появления микросервисов как архитектурного стиля и объясняет, откуда взялось это название, что уже представляет интерес.

Я же считаю, что с точки зрения инженерии микросервисы – это автономные модули. Эту точку зрения я подробно объясню в разделе, посвящённом конструированию, после обсуждения тем моделирования и проектирования.

Тем не менее, уже сейчас могу отметить, что многое из того, что Женя говорит о микросервисах, также применимо и к автономным модулям, хотя я и не со всем согласен безоговорочно.

https://youtu.be/ZwkoGV-4rSw?si=VvuC8hscN9yMhGak
🔥5👍3🤓21
Наконец-то появилась возможность подвести итоги написанных постов. Начинаю публиковать резюме по разделам и выстраивать навигацию.
👍1🔥1
#итоги

Промышленная архитектура программных систем: Параллели со строительством и ключевые черты

В разделе вводится новый архитектурный стиль в программной инженерии "Промышленная архитектура программных систем" и проводятся параллели с аналогичным стилем в строительстве.

Основные моменты:

- В программной инженерии, как и в строительстве, существуют архитектурные стили, которые отражают исторический контекст и требования своего времени, и способствуют распространению и применению лучших практик для их реализации.
- Промышленная архитектура в строительстве ориентирована на проектирование зданий для производственных нужд, с акцентом на функциональность, экономическую эффективность, инновационность, надёжность, безопасность, модульность и автономность.
- Промышленная архитектура программных систем так же направлена на создание промышленных решений и сохраняет те же акценты.
- Общим трендом для промышленной архитектуры как в строительстве, так и в разработке программных систем является проектирование с учётом будущих изменений и обеспечение эволюционности

Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/15
👍51
Intelligent Systems Architecture pinned «#итоги Промышленная архитектура программных систем: Параллели со строительством и ключевые черты В разделе вводится новый архитектурный стиль в программной инженерии "Промышленная архитектура программных систем" и проводятся параллели с аналогичным стилем…»
#итоги

Системы и инженерия: Промышленная архитектура как элемент возрождения инженерных подходов в разработке программных систем

В разделе вводятся понятия системы и эмерджентности, инженерии; обсуждаются технические системы и современные вызовы, связанные с использованием Эждайл и микросервисной архитектуры. Также рассматриваются свойства программных систем в контексте промышленной архитектуры и принципы, которыми должны руководствоваться инженеры.

Основные моменты:

- Системы порождают эмерджентность — системный эффект, при котором возникают свойства, не характерные для её отдельных элементов.
- Понимание системного эффекта и применение инженерных подходов являются ключевыми факторами для успешного проектирования сложных программных решений.
- Ключевые свойства программных систем, как технических систем, выполненных в стиле Промышленной архитектуры: наличие потребительских качеств и выполнение полезных функций, способность к многократным изменениям состояния, многоэлементность и наличие множества связей между элементами, иерархичность.
- Применение Эджайл-методов и микросервисной архитектуры часто приводит к хаосу и непредсказуемости в эксплуатации и развитии систем.
- В настоящее время появилась необходимость в систематизации инженерных практик в архитектуре программных систем для создания предсказуемых, экономически эффективных и безопасных решений. В связи с этим предлагается новый стиль — «Промышленная архитектура программных систем».

Начало раздела: https://news.1rj.ru/str/IndustrialSoftwareArchitecture/26
👍5🔥1
#оффтоп #холизм

Счёл важным привести пример системного подхода в одном из величайших трудов по стратегии «О войне», Клаузевица:

«В нашем предмете, более чем в каком-либо другом, вместе с частью должно мыслиться целое»

Что важно, автор задаёт эту установку (холизм) с самого начала, во вступительной части.
👍8
Forwarded from Сообщество Архитекторов (CommunityManager)
57-й выпуск дайджеста для ваших выходных!
 
Understanding and implementing micro-frontends
on AWS

Руководство от Amazon в части формирования понимания архитектуры микрофронтенда и создания решений микрофронтенда на Amazon Web Services (AWS).
 
Apache Kafka Cluster Type Deployment Strategies
Несколько кластеров Kafka являются нормой, а не исключением. Варианты использования включают гибридную интеграцию, агрегацию, миграцию и аварийное восстановление. В этой записи
блога рассматриваются реальные истории успеха и кластерные стратегии для различных развертываний Kafka в разных отраслях.
 
Building A Generative AI Platform
Интересная статья про концептуализацию знаний про приложения с генеративным ИИ. Автор изучил, как компании внедряют приложения генеративного ИИ, и выделил много сходств в их платформах.
В этой статье он описываются общие компоненты платформы генеративного ИИ, что они делают и как они реализуются.
 
Thinking Like an Architect
Не устаревающая со временем концепция о роли архитектора от Gregor Hohpe. Автор книги «The Software Architect Elevator» недавно делал доклад «Thinking Like an Architect» на конференции
QCon London 2024. Эта статья представляет собой доклад, который начинается с объяснения ролей архитектора и концепции соединения уровней.
 
Control Flow—The Other Half of Integration Patterns
Еще одна статья от Gregor Hohpe. Он рассматривает концепцию Control Flow (поток управления) в части механизма реализации асинхронных взаимодействий.
 
Остальные статьи этого выпуска можно найти на Confluence.
Читаем
 
5
#оффтоп #комментирую

Прокомментирую пост выше.

Про микрофронтенды

В статье про микрофронтенды сочетание BFF и API Gateway заставляет задуматься: https://docs.aws.amazon.com/prenoscriptive-guidance/latest/micro-frontends-aws/introduction.html

Важный момент - микрофронты, это прежде всего орг паттерн.

В представленном варианте вслед за BFF у команды может появиться, да почти точно появится, свой бэкенд. Если это конечно «чисто фронтовая» команда и бэкенда у неё до сих пор не было.

В иных случаях, от BFF могут «пойти» запросы в обход API Gateway к «своим микросервисам».

Почему так? Потому что появление BFF у отдельной команды может говорить о том, что развитие API (выставленного через API Gateway) и бизнес-логики под ним, не успевает за потребностями команды (на сами деле за потребностями клиентов/заказчиков)

Про Control Flow

Статью Грега Хоупа про Control Flow читать обязательно: https://www.enterpriseintegrationpatterns.com/ramblings/queues_control_flow.html

Грег Хоуп - выдающийся автор.

Напомню, Грег один из авторов книги, которая по сути заложила стандарт (паттерны + набор символов) в интеграции: https://www.enterpriseintegrationpatterns.com/
Кто не читал, читать обязательно!!!

Данная статья - дальнейшее развитие темы интеграции Грегом.
👍6🤝1
#оффтоп

Итоги подводятся с трудом

Пытаюсь переварить нестыковки в терминологии. Похоже никто этим всерьёз не занимался. Не складывается целостная онтология.

А пока, чтобы подать признаки жизни, поделюсь своими наблюдателями и выводами в работе с ChatGPT (AI)

Наблюдения:
1. AI хорошо переводит код с одного языка на другой, если код написан хорошо; похоже, если человеку легко читать код, то и AI воспринимает его без проблем, вероятно, благодаря качественным обучающим данным, на которых он обучен
2. AI прекрасно помогает траблшутить (выявлять и устранять проблемы), но для этого нужно уметь траблшутить и задавать правильные вопросы, что требует опыта
3. AI хорошо генерирует примеры, если запросы точно сформулированы, но это также требует навыков и опыта

Выводы:
1. Уже не мыслю свою деятельность без AI, как помощника
2. AI как помощник в решении сложных задач пока пригоден только для опытных специалистов, поскольку умение задавать правильные вопросы требует глубокого понимания предмета
3. В обозримом будущем AI вряд ли сможет помочь в решении задач, сложнее тех, которые человек способен решить без AI
👍6