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

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

Геннадий Круглов
@GKruglov
Download Telegram
Кстати, нашел только одно определение для 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
#кейс

К посту выше

С помощью ChatGPT за пару вечеров:
- обернул в FastAPI код несложного, но полноценного (не прототипа) приложения на Python, вообще не зная FastAPI на тот момент
- задокументировал API в Swagger, снабдив работающим примером
- упаковал в Docker (это) приложение на FastAPI вместе с зависимостями на Go

При этом, я много лет программировал на Java, а Python использую только изредка в последние годы, в основном ради удовольствия
👍8🔥21
#кейс

ChatGPT упешно решил задачу распределения ответственности (Responsibility Assignment ) и модульного синтеза

Я подавал описания бизнес-сценариев в ChatGPT и просил распределить их по модулям. ChatGPT успешно вывел структуру модулей и идеально (High Cohesion) распределил сценарии между ними. Примечательно, что шаг выведения функционала из сценариев (определение необходимого функционала для реализации сценариев) был пропущен. Сценарии были описаны на английском, что не стоит игнорировать.

Хотя пример был довольно простым, и я не затрагиваю вопрос «владения» сквозными сценариями, результаты всё же показались мне вдохновляющими.

Вполне может оказаться так, что качественно описанные сценарии (и требования в целом) могут принести дополнительный профит в проектировании, потому что они AI-Friendly
👍9🔥1