#кейс

К посту выше

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

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

#кейс

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

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

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

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

#оффтоп #комментирую

Начал читать «Implementing Data Mesh» Жана-Жоржа Перрина и Эрика Броды.

В главе 5, Driving Data Products with Data Contracts, авторы говорят о том, что создание доверия является основой для работы с дата-продуктами: «First, we try to nurture an honest and positive relationship with our customers.»

Они высказывают очень важную мысль: «When you think about a good product, probably one of the most important considerations is that you have trust in it.»

Перед этим они отмечают: «Trust is the foundation. Harvard Business Review (HBR) published a piece on how trust can be materialized.» и ссылаются на статью «The 3 Elements of Trust» Джека Ценгера и Джозефа Фолкмана (ссылка: https://hbr.org/2019/02/the-3-elements-of-trust).

Я тут же прочитал эту статью и был настолько взволнован, что решил не откладывать пост и сразу поделиться своими комментариями. В статье утверждается, что доверие базируется на трёх элементах: Positive Relationships, Good Judgement/Expertise и Consistency.

И у меня есть что сказать. В нашем с Алексеем Маркеловым стартапе (и моём первом стартапе) одним из элементов идеи была соцсеть, где связи планировалось взвешивать по уровню доверия. Мы исследовали тему доверия, опрашивая разных экспертов, до кого могли «дотянуться», и в итоге пришли к двум выводам:
- Оценка доверия не поддаётся алгоритмизации.
- Доверие — это результат совместного позитивного опыта.

Максимальное доверие рождается, когда люди вместе проходят "огонь и воду". При этом все три компонента доверия из статьи Harvard Business Review справедливы.

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

Ну а книгу однозначно рекомендую к ознакомлению: https://www.oreilly.com/library/view/implementing-data-mesh/9781098156213/

#забегаювперёд #важно

Понятие Data API неприменимо к дата-продуктам и вообще является довольно спорным.

По отношению к дата-продуктам я бы не использовал слова "API" и "интерфейс", а говорил только о контрактах.

Почему так?

Потому что дата-продуктом, например, может быть набор данных в CSV-файле, который хранится в объектном хранилище, и это никакое не приложение, у него нет своего интерфейса. Мы получаем CSV-файл целиком через интерфейс S3.

С витринами данных то же самое: мы получаем данные таких дата-продуктов через интерфейсы СУБД.

В дата-продуктах можно наблюдать инверсию отношений между контрактом и интерфейсом.

Применительно к API, API реализует контракт в подходе Contract-First, да и в принципе — если контракт существует. Но момент создания контракта интерфейса ещё нет.

Применительно к дата-продуктам контракт описывает способ предоставления дата-продукта, способ получения данных, протокол (например, СУБД или объектного хранилища) и т. д. На момент создания контракта интерфейс существует и нужно его учесть в спецификации/дефиниции контракта

Иными словами, при взаимодействии с дата-продуктом мы взаимодействуем не с его приложением, а с хранилищем, и для этого используем интерфейсы хранилища. Поэтому букву A и, наверное, букву P из API можно смело исключить.

В потоковых (streaming) продуктах это интерфейсы брокеров/Pub-Sub систем, а не хранилищ, но сути это не меняет.

Хотя, конечно, дата-продукт может быть неотъемлемой частью какой-то системы.

Рассуждать о том, что является API, а что нет, очень удобно в контексте зависимостей. От чего возникает зависимость при взаимодействии с дата-продуктом?

Ещё одна мысль

Структуры данных в API - это часть интерфейса. Через разные методы интерфейса могут быть доступны разные данные.

Структура данных в дата-продукте - это часть продукта. Данные одного и того же дата-продукта могут быть доступны через разные интерфейсы, например, JDBC, ODBC, в топике Kafka (CDC)

Хочу отметить, что последние посты напрямую связаны с промышленной архитектурой, так как без контрактов и интерфейсов немыслимо построение модульных систем. Мы будем регулярно возвращаться к этим вопросам в будущем.

Забегая вперёд, скажу, что стало понятно: под контрактами мы часто подразумеваем спецификации, в том числе машиночитаемые (WSDL, Swagger Definition, ProtoBuf), и не различаем контракты и оферты.

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

Напомню, что наличие машиночитаемых спецификаций — это основа для Automated Governance.

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

Многие концепции уже давно "вызрели" в других областях, так почему бы их не использовать? Кроме того, стоит отметить, что многие значимые работы в нашей сфере по своей сути являются философскими.

Для иллюстрации приведу цитату из статьи Джима Грея, который ввёл понятие транзакции. В своих трудах, например, он использует такие понятия, как сделка и контракт:

"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

#предсказание

Побуду в роли оракула

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

Архитектура 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) и реактивными, что мне особенно импонирует.

Важное уточнение

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

«Business and IT alignment» станет возможен, а SOA 2.0 приобретёт смысл лишь тогда, когда архитектурная функция будет поднята на стратегический уровень и наделена необходимыми полномочиями. Без выравнивания полномочий между бизнесом и IT достичь этой цели не получится.

А пока нужно запастись терпением и крепчать методологически, чтобы пережить безвременье в IT, с его бесшабашным Эджайлом и шальными микросервисами.

#datamesh #datafabric #dataproduct

Коллеги проделали значительную работу, проанализировав материалы по темам Data Products, Data Mesh и Data Fabric: https://link.springer.com/article/10.1007/s12599-024-00876-5

Эта статья оказалась очень своевременной и принесла моей душе умиротворение. Авторам удалось весьма удачно интегрировать эти концепты.

В конце статьи представлен полезный список источников. Рекомендую

Готовлюсь к интервью в канале друзей. Будут вопросы про монолитную архитектуру.

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

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

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

Конец високосного года выдался особенно жарким. Поделюсь выводами, которые сделал за эту неделю.

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

У нас красная страна, красная культура, и большинство наших компаний — красные. Это следствие нашей истории, наша объективная реальность. В этом наша сила и наша слабость.

Нужно внедрять практики, которые соотвествуют красной культуре. Розовые пони в нашей саванне долго не живут.

Применительно к архитектуре необходим сильный архитектурный комплаенс (Architecture Compliance). Причём вряд ли он должен строиться строго по TOGAF — комплаенс должен быть независимым от продуктовых команд.

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

Все уже привыкли к тому, что роботы "заворачивают" кредиты. Вот пусть роботы и некачественные релизы "заворачивают". На робота сложнее "надавить", чем на человека.

Продолжаю делиться наработками.

Автоматизировать архитектурный комплаенс лучше на основе цифрового двойника информационных систем.

Несколько лет назад я разработал концепцию системы управления архитектурой информационных систем, центральным элементом которой выступает цифровой двойник.

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

Приведу цитату:

- Цифровая модель — это представление того, как мы видим систему.
- Цифровая тень — это отражение того, как система реализована на практике.
- Цифровая тень помогает выявлять расхождения между цифровой моделью и реальным состоянием системы.

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

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

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

Обратимся к книге Генри Минцберга «Стратегическое сафари». Согласно ей, реализуемая стратегия всегда представляет собой сочетание запланированной (Intended strategy) и возникающих (Emergent strategies) стратегий.

Запланированная стратегия – это стратегия, которая осмысленно формируется стратегами и передаётся вниз по организации для реализации.

Возникающие стратегии – это результат инициатив на местах.

На практике реализуемая стратегия никогда не совпадает полностью с запланированной: что-то идёт не по плану, отдельные элементы стратегии улучшаются локально или игнорируются, нередко на местах возникают совершенно новые концепции, продукты или варианты развития.

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

Цифровая модель отражает видение «будущих» систем и их версий, а цифровая тень содержит объективную информацию о том, какие системы и как именно реализованы.

Сравнивая цифровую модель и цифровую тень, мы можем выявлять расхождения и формировать более точное представление о реальности.

В программной инженерии дела обстоят так же, как и в стратегии.

Существует намеченная/запланированная архитектура (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. Впрочем, как вы можете убедиться, с отсутствием единства терминологии у коллег нет совершенно никаких проблем.

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

Рекомендовать для старта «классические» книги было бы нечестно. Они не дают прочного фундамента при минимальных усилиях. Впрочем, их важно упомянуть, чтобы получить представление о «классике».

Архитектурная классика (масштабная и местами архаичная, не для начинающих):
- «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 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