Масштабные проекты для отраслевых лидеров и организаций с высокой динамикой бизнес-процессов: Банка России, Газпромбанка, ГК «Спортмастер» (розничных сетей «Спортмастер», O'STIN, FUNDAY) Работа на стратегическое развитие клиентов, решение критически важных бизнес-задач средствами ИТ, поддержка передовых технологических проектов 2 | 17
софта Мы пробовали применять самый известный из них (ATAM — Architecture Tradeoff Analysis Method) Расскажем о том, что получилось Если совсем коротко о результатах: Польза есть Есть и сложности
риски до старта массированной разработки Вынуждает проверять соответствие архитектуры требованиям и трассировку к бизнес-целям Вынуждает обосновывать принятые решения, выявлять недостатки и совершенствовать архитектуру
форсирует ее коммуникацию и понимание Проявляет/улучшает качество и полноту входных материалов (архитектурно-значимых требований/драйверов), выявляет конфликты/дыры в исходных требованиях Проявляет недостатки многих смежных процессов
несколько раз Все придумывали сами (как мы это любим) Перед этим были на семинаре Питера Хрущки, где был краткий обзор ATAM и где подхватили саму идею
Архитектура обсуждалась Архитектура улучшалась Риски всплывали Сомнительные решения Потеря трассировки к бизнес-целям Дырки в требованиях Плохое Было очень долго Было неуправляемо Риторика «защиты» демотивировала Ценность результатов для управленца не всегда ясна Плохо тиражируемо
сессий оценки дизайна нельзя просто посадить людей в одну комнату и попросить оценить дизайн. Вместо этого нужно давать задания, для выполнения которых дизайн должен быть хорошим Нестрогая цитата из книжки * Кстати, ту же логику организации коллективной работы мы видим на стратегических сессиях c методологами школы СМД
порядок действий Четко обозначенные предметы рассмотрения (атрибуты и сценарии качества) Жесткие форматы бизнес-значимых результатов, которые нужно получить (риски, компромиссы, etc) Риторика «совместного исследования»
Достижение договоренностей и планирование. Определение проекта, области анализа, состава участников Руководство группы оценки, ответственные за проект По ситуации 1 Оценка Выявление требований к качеству, анализ архитектурных подходов, создание дерева полезности Группа оценки, ответственные за проект 1 день, перерыв 2-3 недели 2 Оценка Верификация дерева полезности стейкхолдерами, анализ архитектурных подходов с их точки зрения Группа оценки, ответственные за проект, стейкхолдеры 2 дня 3 Доработка Представление сводного отчета Группа оценки, заказчик оценки 1 неделя
Подготовка (презентации) 1. Презентация ATAM 2. Презентация бизнес-драйверов 3. Презентация архитектуры Исследование и анализ (оценка ключевых атрибутов качества) 4. Выявление архитектурных решений 5. Генерация дерева полезности и сценариев качества 6. Анализ архитектурных решений Тестирование (представление текущих результатов стейкхолдерам) 7. Мозговой штурм и приоритизация сценариев 8. Анализ архитектурных решений Составление отчетов 9. Представление результатов 17
Подготовка (презентации) 1. Презентация ATAM 2. Презентация бизнес-драйверов 3. Презентация архитектуры Исследование и анализ (оценка ключевых атрибутов качества) 4. Выявление архитектурных решений 5. Генерация дерева полезности и сценариев качества 6. Анализ архитектурных решений Тестирование (представление текущих результатов стейкхолдерам) 7. Мозговой штурм и приоритизация сценариев 8. Анализ архитектурных решений Составление отчетов 9. Представление результатов 21
Подготовка (презентации) 1. Презентация ATAM 2. Презентация бизнес-драйверов 3. Презентация архитектуры Исследование и анализ (оценка ключевых атрибутов качества) 4. Выявление архитектурных решений 5. Генерация дерева полезности и сценариев качества 6. Анализ архитектурных решений Тестирование (представление текущих результатов стейкхолдерам) 7. Мозговой штурм и приоритизация сценариев 8. Анализ архитектурных решений Составление отчетов 9. Представление результатов 23
сессий оценки в самых разных коммерческих, государственных, военных проектах Есть интересная статистика по результатам оценок Статья 2006 года «Risk Themes Discovered Through Architecture Evaluations»
со стейкхолдерами LAAAM — сравнение двух вариантов дизайна через систему весов, много offline См. доклад от NVision нв SECR 2013 CBAM — рационализация выбора между вариантами через финансовые модели ARID — легкая оценка небольших фрагментов QAW — разработка сценариев качества
Август 2015 — решение об апробации, создана рабочая группа Октябрь 2015 — выбор проекта «Витрина учета» 22.12, 24.12, 30.12, 21.01 — 4 дня по 4 часа и 08.02 – 1.5 часа Сложность №1. Для любого коллаборативного метода тяжело согласовать время со всеми участниками
участников (5 человек) — заказчик, архитектор, группа оценки Еще раз вспомнили про проект Заслушали доклад про архитектуру (задавали много вопросов, заглублялись, затянулось) Выписали архитектурные драйверы (самые значимые требования, цели, ограничения) Выделили архитектурные решения Начали генерировать дерево качества и сценарии (и хорошо пошло)
состав участников (5 человек) — заказчик, архитектор, группа оценки Продолжили генерацию сценариев Провели приоритизацию (с применением техники голосования получилось быстро, организованно и достаточно убедительно) Провели анализ одного (!) сценария
данных ZZZ и данных систем- источников, специально хранящихся для выгрузки в ZZZ, занимает менее 200 Гб в оперативном хранилище. Атрибут(ы) Хранимые данные Условия Стимул Реакция Архитектурные решения Чувствительность Компромисное решение Риск Без риска 17. События изменения рейса приводят к генерации сторнирующих и обновляющих операций в журнале исходящих операций конкретного потребителя, по операциям относящимся к данному рейсу S1 NR1 1. Выделение единого Модуля консистентности (ZZZ) S2 NR2 2. Интеграция учетных систем / Дисп и ZZZ через шину (BBB) S3 T1 NR3 7. Системы источники передают, а операционный слой хранит данные в формате систем-источников, преобразование данных в формат получателей выполняет адаптер для потребителя S4 NR4 20. Для разных потребителей готовятся отдельные порции, с отдельным журналом связи порций и сообщений S5 T3 NR5 24. Предусмотрена архивация входящих и исходящих данных ZZZ NR6 6. Обогащение данными для каждого получателя делается индивидуально (отдельное API), с уникальными интерфейсами в системах-источниках S6 T2 NR7 S1 — Зависимость от необходимого горизонта изменения задним числом. NR1-NR3 — Не является рисковым, т. к. по оценке на 60 дней нужно 162 Гб для хранения событий/операций с учетом четырехкратного дублирования в ZZZ. S2 — Дублирование учетных событий источников в ZZZ создает существенный объем данных, порядок которого соответствует граничному размеру. S3, T1 — Использование BBBа увеличивает хранимый объем данных, с другой стороны асинхронный характер взаимодействия
состав участников (5 человек) — заказчик, архитектор, группа оценки Пообсуждали неясные места в методе и его применимость (~50 мин) Посмотрели «домашнее задание» архитектора — анализ второго сценария (это оказалось очень скучно!) Провели анализ еще двух сценариев В одном — уткнулись в отсутствие модели производительности В другом — уткнулись в непроработанность требований по перевыгрузке
участников (8 человек) — включая «и. о. стейкхолдеров» Напомнили про метод Напомнили про проект Показали по диагонали предыдущие результаты (непонятно, было ли полезно) Провели мозговой штурм среди стейкхолдеров, сгенерировали еще десяток сценариев (акцент оказался на совсем других атрибутах качества!) Приоритизировали новые сценарии (также путем голосования)
вдвое) Сценарии качества (дерево качества) с приоритетами Перечень рискованных решений (создающих угрозу для значимых атрибутов качества) Перечень компромиссных решений (улучшающих одни значимые атрибуты качества за счет других) Перечень сильных решений, удерживающих качество Перечень проблемных вопросов и рисков за границей методики оценки …продолжение на следующем слайде…
и требования Скрытые решения в архитектуре Конфликт интересов с клиентом, значимый для архитектуры Темные места и отсутствующие модели в архитектуре Исправление неверных ожиданий Дополнительные вопросы для анализа и обсуждения с СМ Некоторые архитектурные решения изменены Некоторые архитектурные модели разработаны в процессе (+ неартифицируемые результаты лучшего понимания и коммуникации)
аналитик отражаются потребителям в последующих порциях сторнированием исходящих операций со старым значением и созданием новых с новым значением В сценарии с быстрым (10 ч*ч) добавлением новой для ZZZ аналитики это решение рискованно: Требуется написание логики → мы можем не уложиться в целевые трудозатраты Добавление же «учетной» аналитики решается настройкой справочников инженерами
операционном слое атрибутным хранением Для хранения используется оригинальный формат XML, в котором ZZZ получает сообщения от модулей-источников Поиск по атрибутному хранению, инстанцирование сущностей и пр. более медленные. Возможности работы с XML современных СУБД впечатляют, в т. ч. есть индексирование Все входящие события идут в единый операционный слой (и события учетных систем, и события неучетных систем) За частью данных ZZZ все же сам обращается к модулям-источникам Сокращение трудозатрат ZZZ хостится на тех же серверах, что и YYY Заменили на XXX Нагрузка на ZZZ приличная, причем большая часть потока данных — от XXX. Сервера XXX значительно более мощные
в «человекочитаемом» формате (XML или JSON), но сжимаются «Человекочитаемый» формат предпочтителен для удобства поддержки (сокращение времени поддержки) Но требует в разы больше места для передачи/хранения, чем бинарный или сжатый формат Сжатие Решает проблему размера сообщения и производительности BBBа Решает проблему размера БД ZZZ (сценарий 12) Но либо ломает удобство поддержки (сценарии 23, 24): время разбирательств увеличивается Либо требует не заложенных в проект затрат на доработки BBB.API и BBB.Монитора
какая-либо модель производительности, позволяющая делать оценки — сделана после мероприятия Никак не прорабатывались сценарии начальной инициализации и перезагрузки данных — при высоких рисках можно не влезть в разумное время и объемы данных — требования были уточнены позже
“The ROI of System Engineering” Размер проекта (KSLOC) Оптимальные затраты на СИ, % Снижение затрат за счет СИ, % 10 5 18 100 20 38 1000 26 63 10000 33 92 *СИ — практики системной инженерии
удастся сохранить объемы затрат (~160ч*ч), это вполне посильно для проектов в 5000ч*ч Более структурно и системно организованно, чем предыдущие попытки оценки архитектуры, ощущение более предсказуемого результата на выходе Есть мысль, что все-таки основная ценность наших проектов в правильном проектировании СТА/ИА, и хорошо бы такие или похожие практики научиться делать для СТА/ИА
некоторые были изменены уже после проведения оценки После оценки: Были проработаны структуры данных всех компонентов Атрибутное хранение заменено на XML Проработано сопоставление входных операций 1:M Некоторые существующие диаграммы перерисованы проще и понятнее, в целом картина стала более связной Неожиданные результаты: Тема производительности БД «выплыла» как потенциально рисковая. До оценки требование к производительности декларировалось, но не прорабатывалось Обнаружили, что для расчетной нагрузки ZZZ начальную инициализацию провести за оговоренный срок невозможно Необходимость процедур переинициализации и сверки остатков
периодических «сваливаний» в обсуждения и проектирований решений. Нужно более жесткое модерирование Были проблемы с подготовленными шаблонами — местами в них была заложена излишняя жесткость, некоторые сценарии работы с артефактами были не предусмотрены В процессе оценки были подняты важные вопросы, о которых ранее не думали; выявлены недоработки документации и проектирования; спроектированы новые и выявлены скрытые архитектурные решения Все это позволило лучше понимать, почему принято то или иное решение; осознать существующие риски; повысить качество документации. Работа проделана с пользой После оценки я: Иначе «порезал» скоуп проекта в поисках оптимизации трудозатрат Иначе смотрю на проект в целом и его архитектуру в частности
идеи мероприятия. Подумал, что если бы некое подобное действо было проведено на старте проекта X, это позволило бы вскрыть ключевые проблемы предполагавшейся архитектуры, в результате проект мог бы пойти в совершенно другой плоскости либо мотивированно мог быть свернут в самом начале Но как и в любом деле тут главное — «без фанатизма», чтобы вложенные усилия (а учитывая кол-во вовлеченного народу, трудозатраты распухают очень быстро) оправдались результатом. Для небольших проектов возможно стоит сознательно отказаться от заглубления в детали и пробегаться большим составом лишь «по верхам», при этом не стремясь прийти к какому-то согласованному результату, рассматривая мероприятие лишь как способ получения сырья для детальной проработки в более тесном составе
сопровождения системы Понравилось, что на каком-то этапе в голосе людей, проектировавших систему, слышалось удивление и удовлетворение. Значит, удалось поднять какие-то неожиданные вопросы, показавшиеся им полезными Интересна идея с голосованием за важность разных кейсов. Если проводить такое голосование открыто среди заказчиков, то процесс эксплуатации, возможно, будет более осознанным
и не задавать общие вопросы» проявился во всей красе Динамика группы и включенность участников была очень неоднородна по процессу — этим нужно уметь играть Нужно смелее реконструировать метод и использовать отдельные его части для сборки под конкретный проект (вспоминаем ситуационную инженерию методов) Например, в нашей ситуации без внешних стейкхолеров можно было быстрее переходить к анализу, сильно сократив обзор проекта и архитектуры Другой пример: режим работы «один сделал — остальные смотрят и проверяют» на порядок менее эффективен, чем совместная работа Сложность №3. Метод надо пересобирать под ситуацию, не все части всегда одинаково полезны
проектах Жестче управлять таймингом, смотреть, как это повлияет на результаты Выделять отдельные практики, в частности — генерации сценариев (QAW) И использовать их на этапе проектирования архитектуры Пробовать облегченные варианты (Lightweight ATAM, LAAAM, etc) Попробовать что-то похожее для оценки СТА/ИА Выявление требований и сценариев Подходы к организации процесса Трассировка решений к бизнес-ценности Смелее адаптировать процедуру под ситуацию, после того, как стали понятны механизмы
того, как сам наступил на грабли) В том числе вдаваться в детали, читать книги, учиться, потому что поверхностного понимания может не хватить для результата Оценка архитектуры — необходимый хотя бы в малом объеме элемент процесса проектирования (если вообще применяется архитектурный подход) ATAM во многих аспектах лучше «самоделки» CUSTIS (с другими технологиями и методологиями обычно происходит то же самое) Хотя это, конечно, не панацея и не серебряная пуля, никакого волшебства. И не покрывает всех аспектов В чистом виде ATAM (как любой метод) малоприменим (тяжеловат) Но если подойти с пониманием, разобрать и пересобрать под ситуацию конкретного проекта, то принесет большой и приемлемый по затратам (окупаемый вдолгую) профит