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

Обратимся к книге Генри Минцберга «Стратегическое сафари». Согласно ей, реализуемая стратегия всегда представляет собой сочетание запланированной (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

Что мне понравилось в книге Донеллы Медоуз?

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

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

Вот ключевая цитата:

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

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

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

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

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

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

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

Именно понимание взаимосвязи структуры и устойчивости системы делает книгу Медоуз столь полезной.

Идентификация разных сил, воздействующих на систему, и учёт их возможного влияния в архитектуре — главная задача архитектора.

Иногда, кстати, видно сразу, что системе уже ничего не поможет в достижении успеха. В основном потому, что влиятельные силы в её успехе по-настоящему не заинтересованы.

И лучшее решение для инженера: не тратить своё время на такие активности.

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

На мой взгляд, понятие «stakeholder», особенно в переводе, не способствует системному мышлению и препятствует построению адекватных ментальных моделей.

В английском языке существуют более точные синонимы, которые лучше описывают участников, влияющих на систему, — это «player» или «actor».

Например, пользователи — это заинтересованная сторона, то есть «stakeholder». Пользователи заинтересованы, по меньшей мере, в удобстве работы с системой. Однако часто на практике их мнение остаётся неучтённым — они фактически не имеют власти, их интересы игнорируются.

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

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

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

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

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

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

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

Что, например, это может значить на практике?

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

Или создавать механизмы, делающие невыгодным и рискованным достижение локальных целей в ущерб общим.

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

На самом деле, всё это и есть какая-то система, только высокого уровня.

Хочу оформить пятничный пост как вишенку на торте.

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

При этом она упоминает ограниченную рациональность, введённую нобелевским лауреатом Гербертом Саймоном.

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

«Ограниченная рациональность — это логика, которая приводит к решениям или действиям, имеющим смысл в рамках одной части системы, но не являющимся рациональными в более широком контексте»

Рекомендую всем разобраться с ограниченной рациональностью.

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

Но на самом деле «вишенка» не об этом.

Почему я всё же решил поднять вопрос узости понятия «stakeholder»?

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

Именно в этой игре кроются истинные причины провалов проектов, а не в том, что кто-то выбрал RabbitMQ вместо Kafka.

Вот почему я плавно ввёл понятие «player»: процесс создания и развития системы можно рассматривать как игру, что делает возможным применение теории игр.

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

Дальше я отрефлексирую эту ветку рассуждений и подведу итоги. После этого «пройдусь» по отдельным моментам из книги «Modern Software Engineering».

Год подходит к концу, и скоро придёт время подводить итоги. Скорее всего, займусь этим в последние дни.

А пока хочу поделиться мыслями, которые появились у меня после доклада Евгения Никанорова «Новые измерения корпоративной архитектуры (по мотивам EDGY)», прозвучавшего на конференции Arch.Conf by Sber.

Мы разрабатываем информационные системы в контексте сложных социотехнических систем, движимых бизнесом.

Как архитекторы и инженеры, мы создаём модели, на основе которых принимаем решения.

Наши модели охватывают разные аспекты бизнеса, включая его способности (Business Capabilities), процессы (Business Processes) и клиентские пути (Customer Journeys).

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

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

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

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

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

Евгений выстроил такой "язык коммуникаций" на основе языка моделирования EDGY. И не просто выстроил, а подтвердил его эффективность на практике в глубоком взаимодействии с бизнесом. Чем он и поделился в своём докладе.

Важно отметить, что EDGY — это не нотация. Как и ArchiMate или UML, это язык моделирования.

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

В завершение хочу поблагодарить организаторов конференции Arch.Conf by Sber, Евгения Крысанова, Евгения Пьянзова и Алесю Клюеву, за отличную возможность погрузиться в атмосферу архитектурной мысли и приятного общения.

Когда я узнал, что EDGY базируется на триадной модели, был приятно удивлён. Ведь в основе моей диссертации тоже была триадная модель.

Цитата из https://enterprise.design/wiki/EDGY:References

"EDGY uses three base elements to express any Enterprise Design. This triad is inspired by the Function Behaviour Structure Ontology, a design theory that conceptualises design objects in three ontological categories: function or desired outcomes, behaviour or observable activities, and the structure of objects.

The theory describes the process of designing using only these categories, and applies to modelling enterprises across all facets."

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

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

Приведу несколько примеров таких моделей:
- сущность (Entity), атрибут (Attribute), значение (Value).
- функция (Function), поведение (Behavior), структура (Structure).
- знания (Knowledge), навыки (Skills), установки (Attitudes).
- объём работ (Scope), сроки (Time), бюджет (Cost).
- родитель (Р), взрослый (В), ребёнок (Ре).
- две противоположности и нейтралитет (каждый день видим на перекрёстках).

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

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

Уважаемые друзья!
Рад поздравить вас с наступающим Новым годом! ☃️❄️🎄
Спасибо вам, что читаете мой канал, для меня это очень важно! 🤗❤️ Хочется и дальше делиться знаниями и мыслями, расти как автор 💪🥳
Пусть в новом году вас ждут новые высоты! Желаю вам здоровья, воодушевления и энергии!🍾🥂🎉

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

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

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

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

Как бы там ни было, с момента моего последнего поста я не сидел сложа руки. Вчера был опубликован мой первый лонгрид на Хабре, которым и поделился в предыдущем посте. Публикация этой статьи вряд ли бы состоялась без помощи и поддержки коллег из комьюнити Сбера, за что им огромное спасибо!

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

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

Всё это мы уже проходили в эпоху SOA, которая во многом и «умерла» из-за того, что «упёрлась» в ёмкость интеграционных команд.

Поучаствовав в ряде дискуссий на эту тему, я посчитал, что нужно «апнуть» ссылку на свой доклад:

в Youtube https://www.youtube.com/watch?v=ZM0PgXmu0V4

или в ВК: https://vkvideo.ru/video-211773358_456239086

Выпущу скоротечный пост – мне это важно сейчас.

Агентные/мультиагентные системы в мейнстриме предлагается строить на основе OODA Loop. Не буду приводить ссылки, проваливаться в историю и приводить пруфы – всё легко гуглится.

Приведу лишь краткую цитату навскидку: "The OODA Loop is a decision-making framework that consists of four stages: observation (O), orientation (O), decision (D), and action (A)."

https://thedecisionlab.com/reference-guide/computer-science/the-ooda-loop

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

Агенты, как и люди, чаще всего будут сталкиваться с рутинными ситуациями. А как мы действуем в рутинных ситуациях? На автомате.

Я уверен, что в подавляющем большинстве случаев агенты будут применять паттерны, выполнять pattern matching, сопоставлять входную информацию с шаблонами (аппроксимируя входные данные).

Больше того, агенты будут использовать старые добрые продукции: IF 𝑃 THEN 𝑄, где P – это условная часть (антецедент), а Q – заключение или действие (консеквент). Ничего не узнаёте?

Вместо OODA я бы предложил триаду: информация, решение, действие.

А чтобы отразить ориентацию/анализ в онтологии, нужно детализировать элементы этой триады, повышая при этом гранулярность онтологии.

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

#потокиценности #цифровыедвойники

Решая прикладную задачу, я углубился в картирование потоков создания ценности. Моя задача — дать рекомендации по инкапсуляции при разработке API для сервисов. Я нашёл несколько инсайтов, но это тема для отдельного, непростого разговора.

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

Прежде чем озвучить свои выводы, приведу пару цитат из книги "Mapping the Total Value Stream: A Comprehensive Guide for Production and Transactional Processes», Mark a. Nash and sheila r. Poling:

"In organizations that use traditional methods for mapping their processes, the outcome can very easily become a stitched-together picture of each worker’s own perception added to all the other employees’ thoughts as to how the process works."

"Not seeing the whole picture can result in 'analysis paralysis,' or it can create a situation where project teams are constantly suboptimizing processes by attacking only what they think is important."

Выводы из моих наблюдений:
- Проблемы (боли) проявляются в процессах, но часто это лишь симптомы.
- Создание цифровых двойников только процессов не позволит получить целостный, холистический взгляд на компанию, начиная от её целей, и будет приводить к принятию субоптимальных решений (про ценности не говорю: в нашей культуре это лозунги, в которые никто не верит).
- Компании готовы платить только за устранение болей (only what they think is important). В результате они (вечно) будут устранять симптомы, а не причины проблем.

Прямо сейчас наша индустрия переживает стремительные изменения, связанные с внедрением AI-агентов.

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

AI-агенты конструктивно представляют собой те же функциональные узлы или модули: они реализуют определенные (бизнес-) функции, инкапсулированы и имеют интерфейсы. Они также эволюционируют, их интерфейсы развиваются, и их необходимо размещать в определенных окружениях на соответствующей инфраструктуре.

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

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

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

А для полного понимания их устройства важны детали. Ими я и буду делиться, помимо прочего, в дальнейших постах.

Мой следующий (контентный) пост будет о том, почему известные методы картирования потоков создания ценности (value stream mapping) не дают ответа на вопрос, как отразить потоки именно ценности и какое отношение это имеет к AI-агентам

Дам немного книг.

Книга, которую можно считать бестселлером по VSM, на которую ссылаются в большинстве источников по теме: "Learning to See: Value Stream Mapping to Add Value and Eliminate MUDA 1st Edition", by Mike Rother, John Shook.

https://www.amazon.com/Learning-See-Stream-Mapping-Eliminate/dp/0966784308/

У неё есть неплохой, с моей точки зрения, перевод: "Учитесь видеть бизнес-процессы. Построение карт потоков создания ценности", Майк Ротер, Джон Шук.

https://www.litres.ru/book/dzhon-shuk/uchites-videt-biznes-processy-postroenie-kart-potokov-sozdaniya-16898027/

Пререквизитом к этой книге я бы порекомендовал классику, причём сразу в переводе: "Бережливое производство: Как избавиться от потерь и добиться процветания вашей компании", Джеймс Вумек, Дэниел Джонс.

https://www.litres.ru/book/dzheyms-vumek/berezhlivoe-proizvodstvo-kak-izbavitsya-ot-poter-i-dobitsya-17356452/

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

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

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

И в завершение приведу книгу, где можно ознакомиться с особенностями картирования транзакционных потоков: "Mapping the Total Value Stream: A Comprehensive Guide for Production and Transactional Processes 1st Edition", Mark A. Nash.

https://www.amazon.com/Mapping-Total-Value-Stream-Comprehensive/dp/1563273594/

Однако не стоит рассчитывать, что чтение этой книги принесёт яркие озарения.

Пару воскресных постов, философско-юмористических

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