Выступление Игоря Беспальчука, нашего руководителя проектов дирекции архитектуры, на заседании русского отделения INCOSE (9 ноября 2016 года, Москва). Видеозапись выступления: https://vimeo.com/190918892

1. Опыт применения
метода ATAM
для оценки архитектуры
Игорь Беспальчук
Руководитель проектов дирекции архитектуры
09.11.2016

2. Группа компаний CUSTIS
 20 лет на российском ИТ-рынке
 Масштабные проекты для отраслевых лидеров
и организаций с высокой динамикой бизнес-процессов: Банка
России, Газпромбанка, ГК «Спортмастер»
(розничных сетей «Спортмастер», O'STIN, FUNDAY)
 Работа на стратегическое развитие клиентов,
решение критически важных бизнес-задач средствами ИТ,
поддержка передовых технологических проектов
2 | 17

3. О чем доклад
 В индустрии существуют методы
оценки архитектуры софта
 Мы пробовали применять самый известный из них
(ATAM — Architecture Tradeoff Analysis Method)
 Расскажем о том, что получилось
 Если совсем коротко о результатах:
 Польза есть
 Есть и сложности

4. Оценка архитектуры
Что это и зачем нужно

5. Архитектурный подход

6. Зачем нужна оценка архитектуры?
 Прямое назначение:
 Позволяет выявить/смягчить риски
до старта массированной разработки
 Вынуждает проверять соответствие архитектуры
требованиям и трассировку к бизнес-целям
 Вынуждает обосновывать принятые решения, выявлять
недостатки и совершенствовать архитектуру

7. Зачем нужна оценка архитектуры?
 Сопутствующие выгоды:
 Проявляет архитектуру, форсирует ее коммуникацию и
понимание
 Проявляет/улучшает качество и полноту входных материалов
(архитектурно-значимых требований/драйверов),
выявляет конфликты/дыры в исходных требованиях
 Проявляет недостатки многих смежных процессов

8. Опыт CUSTIS
до ATAM

9. Процедура «Защита архитектуры»
 Разрабатывалась в 2013 году
 Проводилась несколько раз
 Все придумывали сами
(как мы это любим)
 Перед этим были на семинаре
Питера Хрущки,
где был краткий обзор ATAM
и где подхватили саму идею

10. Что получилось в результате
самодеятельности?
Хорошее
 Архитектура проявлялась
 Архитектура обсуждалась
 Архитектура улучшалась
 Риски всплывали
 Сомнительные решения
 Потеря трассировки
к бизнес-целям
 Дырки в требованиях
Плохое
 Было очень долго
 Было неуправляемо
 Риторика «защиты»
демотивировала
 Ценность результатов для
управленца не всегда ясна
 Плохо тиражируемо

11. Когда ничего не получается –
прочитай инструкцию учебник
 Книжку купили в 2013 году
 Прочитали — в 2015…

12. “
”
Еще в 1970-х стало понятно, что при
организации сессий оценки дизайна нельзя
просто посадить людей в одну комнату
и попросить оценить дизайн. Вместо этого
нужно давать задания, для выполнения
которых дизайн должен быть хорошим
Нестрогая цитата из книжки
* Кстати, ту же логику организации коллективной работы
мы видим на стратегических сессиях c методологами школы СМД

13. Про ATAM
Architecture Trade-off Analysis Method
Теория

14. Отличия ATAM от «самоделки CUSTIS»
 Строгая процедура, роли и порядок действий
 Четко обозначенные предметы рассмотрения
(атрибуты и сценарии качества)
 Жесткие форматы бизнес-значимых результатов,
которые нужно получить
(риски, компромиссы, etc)
 Риторика «совместного исследования»

15. Коротко про историю ATAM
 Разработан в Software Engineering Institute (CMU SEI)
 Практическое применение — с 1998 года,
оригинальная статья-отчет — 2000 года
 Не первый метод, но самый известный
и широко используемый

16. Этапы ATAM
Этап Операции Описание Участники Длительность
(вариант)
0 Подготовка Достижение договоренностей
и планирование. Определение
проекта, области анализа, состава
участников
Руководство группы
оценки,
ответственные за
проект
По ситуации
1 Оценка Выявление требований к качеству,
анализ архитектурных подходов,
создание дерева полезности
Группа оценки,
ответственные за
проект
1 день,
перерыв
2-3 недели
2 Оценка Верификация дерева полезности
стейкхолдерами, анализ
архитектурных подходов с их
точки зрения
Группа оценки,
ответственные
за проект,
стейкхолдеры
2 дня
3 Доработка Представление сводного отчета Группа оценки,
заказчик оценки
1 неделя

17. Основная часть ATAM (этапы 1 и 2) по шагам
 Подготовка (презентации)
1. Презентация ATAM
2. Презентация бизнес-драйверов
3. Презентация архитектуры
 Исследование и анализ (оценка ключевых атрибутов качества)
4. Выявление архитектурных решений
5. Генерация дерева полезности и сценариев качества
6. Анализ архитектурных решений
 Тестирование (представление текущих результатов стейкхолдерам)
7. Мозговой штурм и приоритизация сценариев
8. Анализ архитектурных решений
 Составление отчетов
9. Представление результатов
17

18. Атрибуты качества
18

19. Сценарии качества
19

20. Дерево полезности
20

21. Основная часть ATAM (этапы 1 и 2) по шагам
 Подготовка (презентации)
1. Презентация ATAM
2. Презентация бизнес-драйверов
3. Презентация архитектуры
 Исследование и анализ (оценка ключевых атрибутов качества)
4. Выявление архитектурных решений
5. Генерация дерева полезности и сценариев качества
6. Анализ архитектурных решений
 Тестирование (представление текущих результатов стейкхолдерам)
7. Мозговой штурм и приоритизация сценариев
8. Анализ архитектурных решений
 Составление отчетов
9. Представление результатов
21

22. Пример
анализа
одного
сценария
22

23. Основная часть ATAM (этапы 1 и 2) по шагам
 Подготовка (презентации)
1. Презентация ATAM
2. Презентация бизнес-драйверов
3. Презентация архитектуры
 Исследование и анализ (оценка ключевых атрибутов качества)
4. Выявление архитектурных решений
5. Генерация дерева полезности и сценариев качества
6. Анализ архитектурных решений
 Тестирование (представление текущих результатов стейкхолдерам)
7. Мозговой штурм и приоритизация сценариев
8. Анализ архитектурных решений
 Составление отчетов
9. Представление результатов
23

24. Опыт применения ATAM в SEI
 SEI провел ~500 (!) сессий оценки в самых разных
коммерческих, государственных, военных проектах
 Есть интересная статистика по результатам оценок
 Статья 2006 года
«Risk Themes Discovered Through Architecture
Evaluations»

27. Какие другие методы оценки есть?
 ATAM — риски, коллаборация со стейкхолдерами
 LAAAM — сравнение двух вариантов дизайна через
систему весов, много offline
 См. доклад от NVision нв SECR 2013
 CBAM — рационализация выбора между вариантами
через финансовые модели
 ARID — легкая оценка небольших фрагментов
 QAW — разработка сценариев качества

28. ATAM в CUSTIS
От теории — к практике

29. Цели
 Попробовать более структурированный метод оценки
 Если получится хорошо, то:
 Использовать в проектах
 Растить имидж
 Предлагать клиентам

30. Состав участников
 Ведущий, фасилитатор
 Заказчик оценки, менеджер дивизиона
 Архитектор
 Группа оценки, смежные архитекторы
 Приглашенные «и. о. стейкхолдеров»

31. Хронология
 Июль 2015 — первые предложения применить ATAM
 Август 2015 — решение об апробации,
создана рабочая группа
 Октябрь 2015 — выбор проекта «Витрина учета»
 22.12, 24.12, 30.12, 21.01 — 4 дня по 4 часа
и 08.02 – 1.5 часа
Сложность №1. Для любого коллаборативного
метода тяжело согласовать время со всеми
участниками

32. Отличия от «эталонного» ATAM
 Без реальных стейкхолдеров
 Не так жестко были ограничены расписанием —
продлевали там, где не успевали
(начальный тайминг составлял 2 дня по 4 часа)

33. День 0 (17.11.2016)
Вводная встреча
 2 часа, широкий круг участников (9 человек)
 Рассказ про метод
 Рассказ про проект
 Ответы на вопросы

34. День 1 (22.12.2016)
Технический анализ
 4 часа, узкий состав участников (5 человек) —
заказчик, архитектор, группа оценки
 Еще раз вспомнили про проект
 Заслушали доклад про архитектуру
(задавали много вопросов, заглублялись, затянулось)
 Выписали архитектурные драйверы
(самые значимые требования, цели, ограничения)
 Выделили архитектурные решения
 Начали генерировать дерево качества
и сценарии (и хорошо пошло)

35. День 2 (24.12.2016)
Технический анализ (продолжение)
 4 часа, узкий состав участников (5 человек) —
заказчик, архитектор, группа оценки
 Продолжили генерацию сценариев
 Провели приоритизацию
(с применением техники голосования получилось быстро,
организованно и достаточно убедительно)
 Провели анализ одного (!) сценария

37. Сценарий #: 12 Сценарий:
ZZZ отработало 1 год. Суммарный объем данных 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а увеличивает хранимый объем данных, с другой стороны асинхронный характер взаимодействия

38. День 3 (30.12.2016)
Технический анализ (окончание)
 4 часа, узкий состав участников (5 человек) —
заказчик, архитектор, группа оценки
 Пообсуждали неясные места в методе
и его применимость (~50 мин)
 Посмотрели «домашнее задание» архитектора —
анализ второго сценария
(это оказалось очень скучно!)
 Провели анализ еще двух сценариев
 В одном — уткнулись в отсутствие модели производительности
 В другом — уткнулись в непроработанность требований
по перевыгрузке

39. День 4 (21.01.2016)
Опрос «стейкхолдеров»
 4 часа, широкий состав участников (8 человек) —
включая «и. о. стейкхолдеров»
 Напомнили про метод
 Напомнили про проект
 Показали по диагонали предыдущие результаты
(непонятно, было ли полезно)
 Провели мозговой штурм среди стейкхолдеров,
сгенерировали еще десяток сценариев
(акцент оказался на совсем других атрибутах качества!)
 Приоритизировали новые сценарии
(также путем голосования)

40. День 5 (08.02.2016)
Анализ последнего сценария
 1.5 часа, узкий круг участников
 Провели анализ еще одного сценария,
самого приоритетного из второй порции сценариев

41. Результаты
Что мы получили за эти дни?

42. Виды результатов (очевидные)
 Презентация проекта
 Описание архитектуры
 Аудио-запись (лучше сразу делать видео)
с рассказом о проекте, системе и архитектуре
 …продолжение на следующем слайде…

43. Виды результатов (предписанные ATAM)
 Каталог значимых архитектурных решений (вырос вдвое)
 Сценарии качества (дерево качества) с приоритетами
 Перечень рискованных решений
(создающих угрозу для значимых атрибутов качества)
 Перечень компромиссных решений
(улучшающих одни значимые атрибуты качества за счет других)
 Перечень сильных решений, удерживающих качество
 Перечень проблемных вопросов и рисков
за границей методики оценки
 …продолжение на следующем слайде…

44. Виды результатов (дополнительные)
 Выявлены и зафиксированы
 Пропущенные стейкхолдеры и требования
 Скрытые решения в архитектуре
 Конфликт интересов с клиентом, значимый для архитектуры
 Темные места и отсутствующие модели в архитектуре
 Исправление неверных ожиданий
 Дополнительные вопросы для анализа и обсуждения с СМ
 Некоторые архитектурные решения изменены
 Некоторые архитектурные модели разработаны в процессе
 (+ неартифицируемые результаты
лучшего понимания и коммуникации)

45. Пример риска с обоснованием
 Решение № 30: Изменения «неучетных» аналитик
отражаются потребителям в последующих порциях
сторнированием исходящих операций со старым
значением и созданием новых с новым значением
 В сценарии с быстрым (10 ч*ч) добавлением новой
для ZZZ аналитики это решение рискованно:
 Требуется написание логики → мы можем не уложиться
в целевые трудозатраты
 Добавление же «учетной» аналитики решается
настройкой справочников инженерами

46. Примеры измененных решений
Было Стало Причина
Хранение входящих
операций в операционном
слое атрибутным
хранением
Для хранения используется
оригинальный формат
XML, в котором ZZZ
получает сообщения от
модулей-источников
Поиск по атрибутному
хранению,
инстанцирование
сущностей и пр. более
медленные. Возможности
работы с XML современных
СУБД впечатляют, в т. ч.
есть индексирование
Все входящие события
идут в единый
операционный слой (и
события учетных систем, и
события неучетных систем)
За частью данных ZZZ все
же сам обращается
к модулям-источникам
Сокращение трудозатрат
ZZZ хостится на тех же
серверах, что и YYY
Заменили на XXX Нагрузка на ZZZ
приличная, причем
большая часть потока
данных — от XXX. Сервера
XXX значительно более
мощные

47. Пример компромисса
 Решение № 28: Сообщения через BBB передаются
в «человекочитаемом» формате (XML или JSON), но сжимаются
 «Человекочитаемый» формат предпочтителен для удобства
поддержки (сокращение времени поддержки)
 Но требует в разы больше места для передачи/хранения,
чем бинарный или сжатый формат
 Сжатие
 Решает проблему размера сообщения и производительности
BBBа
 Решает проблему размера БД ZZZ (сценарий 12)
 Но либо ломает удобство поддержки (сценарии 23, 24): время
разбирательств увеличивается
 Либо требует не заложенных в проект затрат на доработки
BBB.API и BBB.Монитора

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

49. Пример ошибочных ожиданий
 Начальная оценка в одном из сценариев
модифицируемости — 10 ч*ч
 Оценка после анализа — 40 ч*ч

50. Затраты
 План: 115 ч*ч
 Факт: 168 ч*ч
 Защиты «по старинке»
тоже стоили от 100 до 200 ч*ч
 Преимущества ATAM
 Планируется легче
 Движение структурировано
 Затраты управляемы
Сложность №2. Любое коллаборативное
мероприятие стоит дорого
33,75 33,5
31,67 30,83
18
6,5 6 6
2
0
5
10
15
20
25
30
35
40

51. Это много или мало?
 Уместно вспомнить исследование Барри Боэма
“The ROI of System Engineering”
Размер
проекта
(KSLOC)
Оптимальные
затраты
на СИ, %
Снижение
затрат
за счет СИ, %
10 5 18
100 20 38
1000 26 63
10000 33 92
*СИ — практики системной инженерии

52. Субъективные впечатления
Главное от каждого участника

53. Заказчик оценки
 Для маленьких проектов (~1000ч*ч) — дорого,
если удастся сохранить объемы затрат (~160ч*ч),
это вполне посильно для проектов в 5000ч*ч
 Более структурно и системно организованно,
чем предыдущие попытки оценки архитектуры,
ощущение более предсказуемого результата на
выходе
 Есть мысль, что все-таки основная ценность наших
проектов в правильном проектировании СТА/ИА, и
хорошо бы такие или похожие практики научиться
делать для СТА/ИА

54. Архитектор
 В результате обсуждения некоторые решения сразу «поплыли»,
а некоторые были изменены уже после проведения оценки
 После оценки:
 Были проработаны структуры данных всех компонентов
 Атрибутное хранение заменено на XML
 Проработано сопоставление входных операций 1:M
 Некоторые существующие диаграммы перерисованы проще и понятнее,
в целом картина стала более связной
 Неожиданные результаты:
 Тема производительности БД «выплыла» как потенциально рисковая.
До оценки требование к производительности декларировалось,
но не прорабатывалось
 Обнаружили, что для расчетной нагрузки ZZZ начальную инициализацию провести
за оговоренный срок невозможно
 Необходимость процедур переинициализации и сверки остатков

55. PM, эксперт группы оценки
 Медленно двигались по процессу из-за периодических «сваливаний»
в обсуждения и проектирований решений. Нужно более жесткое
модерирование
 Были проблемы с подготовленными шаблонами — местами в них
была заложена излишняя жесткость, некоторые сценарии работы
с артефактами были не предусмотрены
 В процессе оценки были подняты важные вопросы, о которых ранее
не думали; выявлены недоработки документации и проектирования;
спроектированы новые и выявлены скрытые архитектурные решения
 Все это позволило лучше понимать, почему принято то или иное решение;
осознать существующие риски; повысить качество документации.
Работа проделана с пользой
 После оценки я:
 Иначе «порезал» скоуп проекта в поисках оптимизации трудозатрат
 Иначе смотрю на проект в целом и его архитектуру в частности

56. И. о. стейкхолдера №1
 В целом создалось ощущение правильной идеи мероприятия.
Подумал, что если бы некое подобное действо было проведено
на старте проекта X, это позволило бы вскрыть ключевые
проблемы предполагавшейся архитектуры, в результате
проект мог бы пойти в совершенно другой плоскости либо
мотивированно мог быть свернут в самом начале
 Но как и в любом деле тут главное — «без фанатизма», чтобы
вложенные усилия (а учитывая кол-во вовлеченного народу,
трудозатраты распухают очень быстро) оправдались
результатом. Для небольших проектов возможно стоит
сознательно отказаться от заглубления в детали
и пробегаться большим составом лишь «по верхам», при этом
не стремясь прийти к какому-то согласованному результату,
рассматривая мероприятие лишь как способ получения сырья
для детальной проработки в более тесном составе

57. И. о. стейкхолдера №2
 Выступала в роли представителя службы
сопровождения системы
 Понравилось, что на каком-то этапе в голосе людей,
проектировавших систему, слышалось удивление
и удовлетворение. Значит, удалось поднять какие-то
неожиданные вопросы, показавшиеся им полезными
 Интересна идея с голосованием за важность разных
кейсов. Если проводить такое голосование открыто
среди заказчиков, то процесс эксплуатации, возможно,
будет более осознанным

58. Фасилитатор
 Тезис про «нужно выдавать задания, а не рассказывать
и не задавать общие вопросы» проявился во всей красе
 Динамика группы и включенность участников была очень
неоднородна по процессу — этим нужно уметь играть
 Нужно смелее реконструировать метод и использовать
отдельные его части для сборки под конкретный проект
(вспоминаем ситуационную инженерию методов)
 Например, в нашей ситуации без внешних стейкхолеров
можно было быстрее переходить к анализу, сильно сократив
обзор проекта и архитектуры
 Другой пример: режим работы «один сделал — остальные
смотрят и проверяют» на порядок менее эффективен,
чем совместная работа
Сложность №3. Метод надо пересобирать
под ситуацию, не все части всегда одинаково
полезны

59. Что дальше?

60. Что дальше? Пока только идеи
 Пробовать еще, на других проектах
 Жестче управлять таймингом,
смотреть, как это повлияет на результаты
 Выделять отдельные практики,
в частности — генерации сценариев (QAW)
 И использовать их на этапе проектирования архитектуры
 Пробовать облегченные варианты
(Lightweight ATAM, LAAAM, etc)
 Попробовать что-то похожее для оценки СТА/ИА
 Выявление требований и сценариев
 Подходы к организации процесса
 Трассировка решений к бизнес-ценности
 Смелее адаптировать процедуру под ситуацию,
после того, как стали понятны механизмы

61. Выводы

62. Выводы
 Изучать методы отрасли крайне полезно
(хотя бы после того, как сам наступил на грабли)
 В том числе вдаваться в детали, читать книги, учиться,
потому что поверхностного понимания может не хватить
для результата
 Оценка архитектуры — необходимый хотя бы в малом объеме
элемент процесса проектирования
(если вообще применяется архитектурный подход)
 ATAM во многих аспектах лучше «самоделки» CUSTIS
(с другими технологиями и методологиями обычно происходит то же самое)
 Хотя это, конечно, не панацея и не серебряная пуля,
никакого волшебства. И не покрывает всех аспектов
 В чистом виде ATAM (как любой метод) малоприменим (тяжеловат)
 Но если подойти с пониманием, разобрать и пересобрать
под ситуацию конкретного проекта, то принесет большой
и приемлемый по затратам (окупаемый вдолгую) профит

63. Где почитать подробнее про ATAM
и другие методы оценки архитектуры?
 Кратко на русском — в книге
«Архитектура ПО на практике» Л.Басса и др.

64. Как организовать у себя?
 Это сложно (особенно в первый раз), но посильно
 Есть книги, презентации, статьи, тренинги
 Есть опыт других компаний

65. Спасибо за внимание!
Игорь Беспальчук
bespalchuk@custis.ru
www.linkedin.com/in/iamhere2
Видео-канал CUSTIS
https://vimeo.com/custis