Напомню, что главная часть работы по обнаружению и классификации заинтересованных лиц у нас происходит на Фазе A: Architecture Vision цикла проектирования изменения TOGAF ADM. Второй шаг этой фазы Identify stakeholders, concerns, and business requirements, по сути, является воронкой для создания потенциального списка стейкхолдеров. Другие шаги этапа: подтверждение бизнес-целей, движущих сил (drivers) и ограничений, а также оценка готовности к осуществлению изменения – уточняют этот список и кластеризуют группы заинтересованных лиц. Делается это все с одной, довольно конкретной целью: определить границы изменения (6-ой шаг: Define scope). Некоторая часть стейкхолдеров после этого остается внутри границы, а все остальные со своими болями и пожеланиями в рамки нашего изменения не попадают. Это не значит, что они исчезнут и перестанут влиять на наш архитектурный проект. Скорее, это значит, что воплощение их ожиданий, на наш взгляд, маловероятно или же не принесет сколь-либо ощутимой пользы. Заинтересованными лицами они останутся и влиять на наше изменение, безусловно, продолжат. Но цели их мы себе не возьмем, потому как ценности реализация их целей никому не принесет.
Подробнее про ведение каталога заинтересованных лиц написано в третьей главе Stakeholder Management книжки ADM Techniques, да и в ряде текстов из TOGAF Series Guides. Таблицы с разными атрибутами заинтересованных лиц, Mendelow’s Matrix и другие подобные инструменты описаны более или менее неплохо. А вот что в этой истории остается за кадром я постараюсь сформулировать ниже.
Многочисленные концепции из TOGAF и мотивационной модели https://pubs.opengroup.org/architecture/archimate31-doc/chap06.html Archimate не только атрибутируют заинтересованных лиц, но и часто их опосредуют. Т.е. у архитектора нет возможности непосредственно поговорить с представителями той или иной заинтересованной стороны. Мы видим только их цели и движущие силы, сформулированные и озвученные кем-то другим. Например, от лица клиента говорят специалисты по развитию пользовательского опыта (customer experience), а топ-менеджеры выступают от лица собственников. Т.е. один стейкхолдеры говорят от имени других стейкхолдеров. Причем не просто говорят, а часто овеществляют эти высказывания в виде некоторых объектов: целей, требований, драйверов или ограничений. Например:
– Акционеры нам поставили цель – говорят топ-менеджеры.
– Пользователи хотят получать нашу еженедельную рассылку – вторят им маркетологи.
– Партнеры с удовольствием сделают скидку и подождут оплаты полгода – замечают специалисты по закупкам
Не то чтоб мы таким высказыванием не доверяем, но людям ведь свойственно принимать желаемое за объективное. Потому полезно лишний раз перепроверить себя и других. Потому последующие этапы архитектурных работ изобилуют шагами по формальному и неформальному подтверждению у заинтересованных лиц тех или иных утверждений.
Это я и назвал термином слоеный пирог стейкхолдеров. Причем в качестве слоев могут выступать не только непосредственно стейкхолдеры, говорящие от имени других стейкхолдеров, но и воплощение мотивов заинтересованных лиц
Диаграмма взята из ArchiMate Cookbook by Eero Hosiaisluoma
Еще раз подчеркну, что для архитектора не всегда уместно явно усомниться, например, в желании пользователя видеть в своем мобильном приложении партнерскую рекламу, как это утверждает товарищ из маркетинга. Но его всегда можно переспросить: «Как нам убедиться в таком желании клиента? Может быть есть результаты каких-то интервью или фокус групп, подтверждающих такую потребность? Нет. Тогда может переформулируем это высказывание в виде продуктовой гипотезы и запланируем A/B тесты?» – типичный пример такого диалога.
Мы не всегда можем привлечь к проектированию изменения представителей всех нужных стейкхолдеров. Мы не всегда может быть уверены в целях, движущих силах и мотивах сформулированных опосредовано. Но мы можем оценить степень своей уверенности в тех или иных утверждениях и придумать способы подтверждения неочевидных или анонимных запросов
]]>Картинка выше (надеюсь, цитируя её, я не нарушаю авторских прав) иллюстрирует тот очевидный факт, что дизайн любого решение включает в себя ландшафт данных. Такой ландшафт описывает как данные создаются, собираются, передаются, обрабатываются, хранятся, используются и, в конечном счете, уничтожаются. Причем, в каждом конкретном решении могут быть задействованы существующие приложения или же потребоваться разработка новых средств работы с данными. А еще сами данные могут быть довольно разными по своей природе: документы и контент, следы операций в виде событий, основные и справочные данные.
Чуть ниже автор сетует, что возможно его способ представления выглядит несколько запутанным и слегка неуклюжим, но в оправдание замечает, что в реальных проектах приходится сталкиваться с не менее сложными проблемы в части извлечения и обработки данных.
Все это именно так и, конечно, если вам интересно, то конечно обратитесь к соответствующей главе в первоисточнике. Но уже отвечая на вопрос я вспомнил, что в самом начале года Alan McSweeney опубликовал большой набор слайдов Data Architecture For Solutions Я обещал поделиться ссылкой на него, что сейчас и делаю
Увлекательного изучения!
]]>Solution architect Семён получил новую задачку: расширить функционал простенького сервиса обработки заявок. Ничем не примечательный сервис предоставляет HTTP API, с коллекцией request, в которую можно опубликовать заявку. Проведя пару проверок и обогатив заявку данными из внешних систем, сервис отправляет заявку в очередь сообщений. Семён недавно работает в компании и хотя, по его мнению, задачка довольно простая, решает посоветоваться с Enterprise architect-ом Евгением. Тем более, что на днях Евгений собрал всех solution-ов и рассказал им о записях архитектурных решений (architecture decision record). Теперь каждый архитектор должен не только набросать небольшой эскиз, но и выложить набор решений в виде adr-файлов в версионное хранилище.
К удивлению Семёна вечно занятый Евгений был на рабочем месте. Дорисовывая очередной слайд он бросил Семёну:
– Что у тебя?
– Доработка сервиса обработки заявок, – пробурчал Семён.
– И в чём вопрос? – поинтересовался Евгений.
– Оформляю архитектурные решения, хочу посоветоваться.
Евгений посмотрел эскиз, поморщился и выдал свой любимый вопрос:
– Альтернативы придумал?
– Дорабатываем существующий сервис – Семён слегка замешкался. – Или пишем новый.
В этот момент к разговору внезапно присоединились еще два участника. Проектный менеджер Пётр, курирующий все доработки внутренних приложений в рамках программы цифровизации административной и внтурихозяйственной деятельности и продуктовый менеджер Павел. Эти двое всегда ходили вместе и постоянно спорили между собой.
– Не надо нам ничего переписывать! – не здороваясь начал Пётр. – Всё должно было заработать уже вчера! Десятки заявок в день вручную приходится разгребать.
– Это потому, что Борис накосячил, – включился в разговор Павел. – Вручную разгребаются заявки, которые не обработались с первого раза.
– Ну вот и подвернулась возможность Борису реабилитироваться, – не сдавался Пётр.
Не дожидаясь, пока эти двое окончательно втянутся в бесконечный спор, Евгений встал, подошёл к доске и рисуя квадратики принялся увещевать участников импровизированного совещания:
– У нас несколько вариантов реализации этой задачки. Самый простой, но не самый правильный состоит в том, чтоб сделать ещё одну очередь и написать новый компонент, который будет перекладывать сообщения из старой очереди в новую. Попутно он будет трансформировать ваши заявки.
– Не вариант! – прервал Евгения Павел. – Половина заявок в этот момент уже лежит в очереди ошибочных сообщений и разгребать их будет не ваш волшебный сервис, а рота сотрудников службы поддержи.
Павел покосился на Петра, ища у него поддержки. Вопреки традиции постоянно спорить с Павлом Пётр закивал.
– Хорошо! Вариант номер два, – не отступал Евгений. – Подменяем существующий сервис новым, с таким же интерфейсом, что и сервиса Бориса. Он будет обрабатывать все заявки. Некоторые сразу сбрасывать в очередь, а часть отдавать в старый сервис.
Павел одобрительно закивал:
– Меньшую часть, я надеюсь, – удовлетворенно заметил Павел.
– Как получится, – включился в разговор Семён, про которого все уже, казалось, забыли. – Этот вариант не решит никаких проблем, только создаст новые!
Участники разговора повернулись к Семёну, стали разглядывать его с некоторой нехорошей настороженностью. Семён, уже с меньшей уверенностью, продолжал:
– Наша проблема в чём? Вот в этих синхронных вызовах внешних апи, – Семён указал рукой в правую часть доски, на которой могли бы быть нарисованы интерфейсы внешних систем, используемые для обогащения заявок дополнительными данными. – Сервис Бориса почему тормозит? Потому, что внешние системы ему медленно отвечают. Что новый сервис, что старый, работать всё будет так же плохо! Только дополнительный синхронный вызов воткнем, а по существу ничего не изменится.
Настороженность во взглядах собеседников стала преобразовываться в легкую злобу. Особенно у Евгения, предложившего, как ему казалось, такой отличный вариант.
– Ну и что с этим делать? – первым взял себя в руки Павел.
– Реплики данных из внешних систем, – предположил Семён
– И кто за это заплатит? – поинтересовался Пётр.
…
В общем, в этот день коллеги так ни о чем и не договорились. Евгений отправил Семёна писать adr. Семён быстренько накатал файлик с двумя вариантами: доработать существующий сервис или написать новый. А проблема осталась ждать своего решения
Дальше все в полном соответствии с компьютерной метафорой. Рабочая память (в русском языке её часто называю краткосрочной) имеет крайне ограниченный объем. Семь плюс-минус два – это про неё. Зато рабочая память быстрая, может оперировать информацией непосредственно поступающий от органов чувств в виде образов. Но хранятся эти образы в памяти недолго и нужны то они непосредственно для текущего действия. Малейшие изменения в окружающем нас пространстве, новый громкий звук, яркий свет, удар сзади мешком по голове переключат наше внимание на другие образы, а старая картинка, еще мгновенье назад присутствующая в рабочей памяти, растворится.
А вот долговременная память устроена иначе. Информацию она хранит организованной в виде схем. Новые данные ложатся на старые схемы, лишь иногда и слегка модифицируя их. Собственно когнитивная нагрузка и создается необходимостью построения таких схем и сохранения в них образов из рабочей памяти. Это не слишком сложно если у нас уже есть подобные текущим образам схемы. И даже небольшая их адаптация сработает. Но в какой-то момент интерфейс между рабочей и долгосрочной памятью перегружается и поток образов просто сбрасывается в /dev/null Не стану дальше рассусоливать компьютерную метафору. Статья в Википедии о теории когнитивной нагрузки для первого знакомства с ней вполне подойдет.
Моя сегодняшняя заметка о другом. Я не понимаю почему архитекторы предприятия до сих пор не провели аналогию между человеком и организацией и не применили теорию когнитивной нагрузки к предприятию. Множество совещаний и встреч, митинов и дейликов, обсуждений на ногах или за чашкой кофе наполняют рабочую память организации. Эта регулярная деятельность повторяясь день за днем, неделя за неделей, год за годом оставляет за собой весьма призрачный след. Запоминается только то, что овеществляется в виде документов, поручений, тикетов в информационных системах. И вот этот переход, так же требует преобразования образов в схемы. Долгосрочная память организации структурирована в виде процессов, проектов, продуктов и прочих вещей, схематизируемых метамоделью корпоративной архитектуры. Вещей этих, кстати, в реальном окружающем нас мире не существует. Наши разговоры и соглашения делают их реальными. Не важно, что за событие произошло внутри или вовне организации. Запомнится оно только в связи с конкретным проектом, процессом, подразделением или продуктом. Вне привязки к каким-либо категориям оно пролетит фокус нашего внимания и после канет в небытие.
Думаю, что идея понятна. Развивать её и достраивать аналогии можно до бесконечности. Схемы Джона Свеллера для людей – это почти как диаграммы корпоративной архитектуры для предприятия. Что думаете?
Update: Пара дополнительных замечаний
Косвенным подтверждением теории Свеллера является любовь человечества к всяким псевдонаучным теориям, в основе которых лежат простые дискретные схемы. Многие HR-ы, например, верят в теорию поколений: иксы, игреки, миллениалы. В Советском союзе и СНГ популярна была соционика, классифицирующая людей на 16 типов переработки информации, которые хуже или лучше взаимодействуют между собой. Марк Ричардс в своих книжках, таких как Фундаментальный подход к программной архитектуре, пишет о восьми архитектурных то ли стилях, то ли паттернах (в формате pdf здесь). А в роликах на YouTube вынужден потом придумывать гибридные стили.
Все эти схемы проникают в наш разум не потому, что они хорошо соответствуют действительности, а только потому, что их проще запомнить. В какой-то степени и теорию когнитивной нагрузки следует отнести к подобным схемам. Нельзя сказать, что подобная стратегия неправильна. У нас просто не может быть какой-то другой.
]]>Обсуждаем модный термин #PlatformEngineering. Пытаемся понять о чем речь:
Слайды: telegram-канал Архитектура ИТ-решений
Ссылки:
]]>
Краткий обзор, видеоролик и ответы на основные вопросы можно посмотреть по этой ссылке
]]>В 2019 году появились сразу два новых архитектурных стандарта 42020 и 42030 (Architecture processes и Architecture evaluation framework). Про двадцатый стандарт я обязательно напишу более подробно в одном из следующих сообщений. Как выглядит архитектурный процесс и как он вписывается в другие активности и виды деятельности – вопрос важный. Но здесь я в большей мере хочу акцентироваться на влияние двух этих стандартов на 42010. Этот стандарт тоже обновился в ноябре прошлого, 2022 года. (ссылка на актуальную версию)
Кстати, по ссылкам, которые я привел выше, доступны короткие preview документов. В частности, десятый стандарт включает краткий обзор изменений и основные определения. А я постараюсь дать свой обзор случившихся изменений.
Начнем с предмета стандарта. Предыдущая версия посвящена архитектуре системы. Стандарт 2011 года определял описание архитектуры системы, архитектурный фреймворк и язык описания архитектуры. Система, вернее системы, остались в названии стандарта, но исчезли из определения архитектуры. Сравните:
architecture fundamental concepts or properties of an entity in its environment and governing principles for the realization and evolution of this entity and its related life cycle processes
вместо:
architecture (system) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution
Система поменялась на entity, элементы и отношения между ними исчезли, дизайн поменялся на реализацию, зато появилась завязка с процессами жизненного цикла. Вообще, определения в архитектуре — это то, что трогать следует в самую последнюю очередь. С ними и так немереное количество проблем. А когда они начинают меняться… Единственное, что может как-то нас обнадежить, так то, что еще лет десять потребуется на обновление этого определения во всех связанных c ним работах. Посмотрим, когда это случится, например, в TOGAF (ссылка на определение).
Кто такой entity объясняется ниже. В разделе 3.12 приводится такой список примеров entities: enterprise, organization, solution, system (including software systems), subsystem, process, business, data (as a data item or data structure), application, information technology (as a collection), mission, product, service, software item, hardware item, product line, family of systems, system of systems, collection of systems, collection of applications. Ну, а в названии стандарта список покороче: программное обеспечение, системы и энтерпрайзы. Все перечисленные выше вещи и раньше можно было трактовать как частные случаи систем. Но новая версия стандарта явно обозначило своё право предписывать пути развития архитектуре ПО, архитектуре предприятия, solution архитектуре, ну и всему остальному заодно. Теперь и без подсказки системного инженера мы будем знать, что все это примеры систем, а их архитектура описывается обсуждаемым стандартом
Вообще, толкованию термина архитектура много внимание уделено в стандарту о процессе 42020. Причем в разных местах документа. Во введении см. 0.2 Use of the term architecture in this document поясняется, что термин архитектура может быть использован в общем смысле или уточнен тем или иным квалификатором (system, enterprise,…). Но иногда рядом с термином архитектура используется не наименование той или иной сущности, а subject of interest, например: security architecture, functional architecture, etc. А еще бывает, что перед словом архитектура указывается purpose, как в выражении integration architecture. Но еще более интересный разговор про виды и типы архитектур ожидает нас в приложении E.4 Architecture kinds, views and style. Во-первых, это перечисление и описание разных типов архитектур: референсная(эталонная), целевая, доменная, системная, текущая и даже архитектура данных. Во-вторых, список архитектурных представлений (views): концептуальное, функциональное, логическое, физическое и т.п. И наконец, (сюрприз-сюрприз) список архитектурных стилей: client server, event-driven, layered, object-oriented и даже service-oriented… Разве что микросервисной архитектуры нет.
Но вернемся к стандарту на описание архитектуры. Следующее изменение, случившееся в новой редакции, это расширение истории про архитектурные представления (views) и точки зрения(viewpoints) концепциями aspects и stakeholder perspectives (cм. картинку выше). Первое, что следует отметить про понятие перспективы, это то, что они отличаются от понятия перспектив из известной книжки Rozanski N., Woods E., «Software Systems Architecture: Working with Stakeholders Using Viewpoints and Perspectives». Стандарт говорит, что разные заинтересованные лица часто объединяются в группы на основании ролей, опыта, схожих предрассудков суждений и всяких прочих характеристик. Именно такая группировка, возникающая как общность способа осмысления системы (извините, entity) в контексте и называется перспективой. В примеры уходить не буду, обращу лишь внимание на то, что в одном из многочисленный приложений к стандарту ставится знак равенства между слоями-уровнями нотации Archimate и перспективами в обсуждаемом стандарте (см. картинку ниже). А вот аспектами в ISO 42010 называется, как правильно заметил проницательный читатель, столбцы этой самой картинки.
На сегодня стоит, пожалуй, остановиться. 42-ой стандарт никогда не являлся простым и развлекательным чтением. Но в наше время, вплетенный в систему других стандартов, он превращается в настоящий квест. Оставим блуждание по 10-му стандарту на потом, а в следующий раз, как я и обещал, погрузимся в 20-ый стандарт, описывающий процессы энтитийной архитектуры.
]]>