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

1. Архитектура: что это?
Михаил Заборов
Москва, 2013

2. больших (40–100 человеко-лет)
корпоративных
информационных систем
на заказ
2/60(65)
занимается разработкой

3. Обо мне
 >10 лет в компании
 Участвовал
в существенной части
проектов компании
в качестве руководителя
и архитектора
 Работаю в одной из групп
развития бизнеса
3/60(65)

4.  Понятно ли вам, что такое архитектура?
 Конечно, понятно, это 100500 раз описано в стандартах
 Мне все понятно, но я замечаю, что некоторые имеют
в виду что-то другое
 В теории понятно, а на практике есть проблемы
 Это Buzzword (как ERP, SOA и т. д.).
Все про него говорят, но никто точно не знает, что это
 У меня есть свое истинное определение
 Не думал об этом
 Свой вариант
Вопросы слушателям
4/60(65)

5. Архитектура как Buzzword
 Разговоры с упоминанием архитектуры ведутся
постоянно и повсеместно
 Каждый понимает под этим словом что-то свое
 Известно несколько сотен формальных
определений архитектуры
 Многие формулировки носят характер скорее
эмоциональных высказываний, чем определений
 Многие определения существенно неполны
(описывают только один из аспектов)
 Существующие стандарты описывают, что такое
архитектура, слишком абстрактно и интуитивно
5/60(65)

6. 6/60(65)
Когда у нас слишком абстрактное
и интуитивное представление
об объекте, мы не можем с ним
реально ничего сделать.
А если этот объект критически
влияет на успех проекта, то мы
становимся заложниками случая
и стечения обстоятельств.
Мы не можем существенно влиять
на результат.
!

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

8. ArchLabs 2009
8/60(65)

9. ArchLabs 2009
9/60(65)

10. http://www.slideshare.net/AndreyVerbitsky/ss-2738439
ArchLabs 2009
10/60(65)

11. Наша попытка сформулировать
понятие об архитектуре
как об объекте более строго
 В какой системе находится
 С чем взаимодействует
 Как устроена внутри
 Какие функции выполняет
 Каковы последствия от ее отсутствия
11/60(65)

12. Система,
в которой находится архитектура
Большая часть терминов
заимствована из стандарта
ISO/IEC/IEEE 42010
12/60(65)
i

13. Архитектура приложения
и архитектура предприятия
(Enterprise Architecture)
 TOGAF
 Захман
 FEAF
 Over 9000
 ISO/IEC/IEEE 42010
 IEEE 1471:2000
13/60(65)

14. Stakeholder, который хочет что-то
сделать с изделием
14/60(65)

15. Stakeholder’ов много
и у них много разных интересов
15/60(65)

16. Перейдем к ИТ
16/60(65)

17. 17/60(65)
Выпуск
релизов
Система производства приложения
(простой вариант)

18. Риски
18/60(65)

19. Система производства приложения
(более сложный вариант)
Выпуск
релизов

20. Система представлений
о внутреннем устройстве приложения
 Состоит из решений
(мы используем термин утверждение)
о внутреннем устройстве (конструкции)
приложения
 Решения находятся в отношении
зависимости
20/60(65)

21. Решение B зависит от решения A
 Изменение A неизбежно влечет за собой
пересмотр B
 Бывают ситуации когда не очевидно какое
решение базовое
21/60(65)
A
B
Базовое
Зависимое (детализирующее)

22. Зависимости между решениями
22
Решения выстраиваются
в цепочки
Решение может зависеть
от нескольких решений
A
B
C A B C
D

23. Граф решений
23/60(65)
Более
базовые
Более
детальные
Сложнее (дороже) пересматривать
Проще (дешевле) пересматривать

24. Слои графа решений
24/60(65)
Граф решений

25. Grady Booch, Martin Fowler:
Архитектура – это все решения, которые,
сделав однажды, затем трудно изменить.
25/60(65)

26. Вывод
26/60(65)
У приложения нет архитектуры;
она есть у людей, которые его
модифицируют.

27. 27/60(65)
Вывод:
Слои архитектуры имеют
собственную логику построения
и зависят не только от прихоти
архитектора.
!

28. 28/60(65)
Вывод:
Одна из главных задач архитектора –
чувствовать последствия решений.
(что будет действительно важным,
а что нет).
!

29. Решения удобно формировать
группой (в виде моделей)
29/60(65)

30. При этом модель может фиксировать
решения разных уровней значимости
30/60(65)

31. Одна из самых важных моделей –
схема функциональных модулей
31/60(65)

32. 32/60(65)
Software Engineering Institute:
Архитектура – это структура вычислительной
системы, которая включает программные
компоненты, внешние свойства этих
компонентов, а также отношения между ними.

33. Архитектура – сложный объект
33/60(65)
View
Аспекты
Слои
Viewpoint

34. Стандарты по архитектуре
(предприятия)
 Таксономия и образцы моделей
 Zachman Framework
 FEAF
 TEAF
 Методы разработки архитектуры
 TOGAF (ADM)
 FEAF
 EAP
34/60(65)

35. Функции архитектуры
в процессе производства
35/60(65)
Изменение системы
производства
Запрос
на изменение
Δ изменения
продукта

36. Функции архитектуры
1. Используется как модель приложения
2. Нормирование и технологизация работ
по проектированию
3. Минимизация рисков
4. Используется как контракт в части SCOPE
36/60(65)

37. 1. Архитектура как модель приложения
Модель объекта – это что-то,
что позволяет отвечать
на вопросы об объекте
37/60(65)

38. Декомпозиция работ по изменению
 Разделение работы на независимые части
 Запуск параллельных потоков работ
 Интеграция результатов работ
Подзадача 1
Подзадача 2
Подзадача 3
Результат
38/60(65)
Исходная
задача

39. Анализ зависимостей (что будет, если)
Incredible Machine

40. Оценка масштаба (класса)
предлагаемых изменений
 Просто или сложно?
http://domvsegda.ru/
40/60(65)

41. 2. Нормирование и технологизация
работ по проектированию
41/60(65)

42. Локализация места модификации
приложения
42/60(65)

43. Минимизация пересмотра принятых
ранее решений
A’
43/60(65)
Приложения с хорошей
архитектурой меньше
подвержены постоянным
переделкам

44. 44/60(65)
Определение с сайта SEI (какой-то индус ):
A good architecture is that which is totally secured,
which can accommodate future changes without
affecting the software as a whole, and which has no
redundant functionalities.

45.  Возможность посмотреть вперед и представить,
как будет выглядеть изделие в целом
Минимизация пересмотра принятых
ранее решений
Continuous Refactoring
45/60(65)

46. Согласование действий
проектировщиков
 Благодаря принятым более
высокоуровневым решениям
 Минимизация объема
проектирования для типовых задач
46/60(65)

47. 47/60(65)
Питер Хрущка:
Архитектура – способ координировать умы.

48. 3. Минимизация рисков
48/60(65)

49. Описание работоспособной
конструкции в целом
49/60(65)
Нарисованная архитектура –
гарантия того, что это
вообще будет построено

50. 50/60(65)
Андрей Вербицкий:
Хорошая архитектура – это удачный
компромисс между желаниями
и ограничениями.

51. Определение ключевых элементов
конструкции, обеспечивающих
качество продукта
Несущие стены
51/60(65)

52. 52/60(65)
Анатолий Левенчук:
Архитектура – это то, каким образом
конструкция поддерживает требуемую
функцию/назначение системы.

53. 4. Архитектура как контракт
в части SCOPE
53/60(65)

54. Фиксация назначения и границ продукта
А также задач, которые
в принципе могут этим
продуктом решаться
54/60(65)

55. Определение реальных
потребительских свойств приложения
55/60(65)

56. 56/60(65)
Качество архитектуры определяется
ее способностью выполнять
перечисленные функции.
!

57. 57/60(65)
В результате мы получили
модель, которая позволяет
вести более содержательные
разговоры об архитектуре
Например, задавать вопросы по конкретным
функциям и диагностировать проблемы
более точно
«С архитектурой все плохо»

58. Типичные проблемы с архитектурой
 Не отражает актуальное внутреннее устройство
приложения
Не работает как модель приложения
 Структура модулей – «поперек» возникающих задач
Не помогает декомпозировать большие задачи
 Внесение изменений приводит к непредсказуемым
последствиям
Не помогает локализовать изменения
 Необходимые изменения в системе требуют
постоянного пересмотра базовых решений
Не обеспечивает минимизацию пересмотра решений
 «Разношерстные» решения типовых задач
Не выполняет функцию координации 58/60(65)

59. Типичные проблемы
с управлением архитектурой
 Случайные решения становятся базовыми
Решение приняли походя, а от него теперь многое зависит.
Нет осознанного управления архитектурой
 Проектировщики нижнего уровня
не руководствуются базовыми решениями
Не выполняется функция нормирования. Теряется
целостное представление об устройстве приложения
 Базовые решения не пересматриваются вовремя
Воспринимаются как жесткие ограничения. Несмотря
на очевидные проблемы при принятии решений на более
детальном уровне
59/60(65)

60. 60/60(65)
Спасибо!
Вопросы?

61. 61/60(65)
Бонус-
слайды

62. 62/60(65)

63. Соответствие
архитектуры и продукта
63

64. Связь технологии и архитектуры
 Деятельность архитектора направлена
на изготовление конкретного (одного)
изделия. Архитектура описывает именно его
 Деятельность технолога направлена
на повышение эффективности и качества
процесса изготовления изделия (обычно
для массовых операций)
 Технология предоставляет архитектору
кирпичи (материал), из которого архитектор
может делать все более сложную
архитектуру
64/60(65)

65. Возможность
не принимать решение повторно
65/60(65)
Решения,
определяемые
технологией