Исходя из этой публикации, я создал сводку к чеклисту о возможностях Онто по сравнению с другими инструментами. Я всегда подчеркиваю, что архитектура – это история о реестрах и чеклистах, а не о цветных картинках. Таким образом, архитектор может использовать drawio, visio или miro для создания схем, только если ему не нужно обеспечивать их поддержку или если нет других инструментов. Однако, в отличие от других архитектурных репозиториев, Онто предлагает уникальный синергетический эффект внутри команды, который мы описываем как "мыслить вместе", независимо от времени и места.

https://docs.google.com/spreadsheets/d/1HjQodfYXw-VtFVdzL2xErvMjj6HVdmEQBV0oQee5riU/edit?usp=sharing

Однажды автор C4 model Саймон Браун подготовил A software architecture diagram review checklist.

Мне нравится С4 модель, вернувшая чересчур абстрактные подходы UML в домен информационных технологий. Мне нравятся чек-листы – простой способ направить ту или иную деятельность в нужное русло и проверить степень готовности результата этой деятельности. Но я думаю, что существует некоторая опасность, заключающая в формальном отношении к чек-листам. Это обстоятельство может все испортить.

Возьмем, например, пункт: «каждая диаграмма должна иметь заголовок» - кто бы с этим спорил. Большинство архитектурных диаграмм имеет заголовок. Значительная часть заголовков выглядит примерно так: «С4 Container Diagram». Ценность такого заголовка колеблется в районе нуля, плюс-минус. Место на диаграмме и внимание при её разборе занимает, а пользы не приносит. В кратком анонсе Браун пишет, что заголовок диаграммы должен описывать её тип и границы и в качестве примера приводит "System Context diagram for My Software System". Думаю, это не вполне подходит.

Я бы сказал, что заголовок должен привязывать диаграмму к месту, времени и автору. Т.е. мало указать диаграмму чего мы рисуем: системы, проекта или изменения. Во-первых, потому что имена вещей могут пересекаться. А во-вторых, практически всегда, абстрактные идентичности (системы, проекты и тем более изменения) имеют очень неявные границы. Под термином веб-сайт продукта может скрываться все что угодно. Далее, со временем вещи (и их границы) меняются. Да и само понятие время штука довольно сложная (вспомните грамматику любого иностранного для вас языка). Есть нечто свершившееся, нечто запланированное и что-то происходящее прямо сейчас. А есть еще наши планы, которые были сформулированы в отношении будущего и должны были реализоваться вчера, но мы не знаем случилось ли это или нет. Для описания подобных времен нужная специальная бюрократическая грамматика. Ну, да ладно. И завершающий момент: архитектурные представления (особенно представления будущего) вещь крайне субъективная. Потому без указания автора диаграмма утрачивает значимую часть своей убедительности. Иногда эта часть заголовка заменяется подписью руководителя. Впрочем, оптимальный вариант – заголовок в виде гиперссылки, ведущий на страницу описания изменения со всеми перечисленными выше реквизитами. Если это невозможно, то можно добавить пару срок с датой, автором и назначением диаграммы рядом с заголовком или в любом месте картинке.

(Много слов получилось. В следующий раз сокращу или сделаю пост в блоге)