Документирование архитектуры: введение (remastered)

Прочел статью Документирование архитектуры: введение и решил описать изложенное с другим подходом.

Диаграммы не буду расписывать в текст, попробуйте прочесть их на языке Archimate. Представьте, что вы расшифровываете египетское иероглифическое письмо. Вот подсказка — набор символов для расшифровки Summary of Language Notation

Напомню введенное ранее мной определение:

Архитектура – это проектное решение, которое набор проектных решений организует в Систему, соответствующую целевому назначению.

Значит нужно определится с целевым назначением системы. Напрямую цели и требования нам не заданы, но можно рассмотреть всё более масштабно используя подход JTBD.

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

При этом сервисы «Комментирование» и «Управление комментариями» пока не будут использоваться, так как модерация требует ресурсов времени.
Для ведения блогов есть много платформ, «с нуля» ничего реализовывать не нужно. Для выбора конкретной платформы нужно на основании требований (которые, увы, не заданы) составить сравнительную таблицу. Можно дополнить ее другими критериями. Тут я думаю всё понятно. Допустим выбрали Ghost CMS, Apache HTTP Server и MySQL.

Теперь нужно размесить это всё в какой-нибудь инфраструктуре, которую тоже выберем по соответствующим критериям. Пусть будет GCP.

Ну вот как бы и всё. Да, я понимаю, что мало объяснений, и я не указал пользователей/роли, может быть позже сделаю. Тут главное не это, а стыковка слоев и аспектов.

Какие еще могут возникнуть вопросы:
1) Можно ли разместить всю информацию на одном изображении?
Ответ: Можно, если требуется проконтролировать связанность. Но нужно соблюдать баланс и аккуратно стыковать слои (бизнес, прикладной и технологический и др.). Чем меньше различных диаграмм вы создадите, тем меньше вероятность получить рассогласование. Чем больше элементов на диаграмме, тем сложнее понять смысл. Поэтому нужен баланс.
2) Нужно ли использовать концепцию Viewpoint?
Ответ: Да, но следите чтобы диаграммы (Views) непротиворечиво стыковались друг с другом, иначе потом придется согласовывать людей, которые прочли ваши диаграммы. Ну см. п. 1)

Резюме