Комментарии 3
Есть другие альтернативы?
Вообще, как то странно называть TOGAF стандартом и не упоминать "ГОСТ Р 57100-2016/ISO/IEC/IEEE 42010:2011. Системная и программная инженерия. Описание архитектуры".
Так или иначе, что бы разобраться в терминологии TOGAF нужно её от куда то брать... по крайней мере, в ГОСТ (9000, 15288, 15504, 15704 итд) терминология +/- согласована и один термин определяется по средствам других.
Может всё таки "Системы", а не "Проекта"?? Да и терминология во фреймворке не единая, она там на английском, а русская версия перевод А. Левенчука... я конечно надеюсь на него, но подтверждения нет))
А сколько раз в своей жизни вам приходилось рисовать в Archi?? Как вы заставили адекватных руководителей его выучить? Про поддержку модели, как картинки, я вообще молчу... тут не проще чем в ARIS'е дело обстоит. Без "Электронной Спецификации" тут делать нечего... у нас в BPMN переходы редко кто по нормальному идентифицирует, не то что процессы.
примечания
Спасибо за материал и разбор.
Хотел бы добавить ещё один взгляд на критику TOGAF через призму ArchiMate. Бывает, что ArchiMate применяют в отрыве от методологического контекста TOGAF, и это создаёт определённые перекосы. Модели получаются визуально корректными, но лишёнными стратегического обоснования, логики трансформации и связи с архитектурными артефактами. В результате часть критики, адресованной TOGAF, по сути относится к попытке использовать вспомогательный инструмент без опоры на сам фреймворк. Это как проектировать здание, имея только AutoCAD, но без архитектурного замысла и плана поэтапного строительства.
Важно понимать и другое: TOGAF не претендует на статус жёсткого регламента. Последняя версия уже включает работу с гибким подходом (agile). Несмотря на репутацию «корпоративного монолита», он может быть адаптирован под задачи не только крупных, но и средних организаций. Главное понимать, какие компоненты фреймворка уместны в контексте и иметь желание структурировать корпоративную архитектуру.
Мы, например, сейчас опираемся на TOGAF при проработке архитектуры нового структурного подразделения. Команда очень маленькая (и амбициозная), но за счёт заимствования ключевых элементов (view): мотивационной модели, набросков процессов, capability map и высокоуровневого взгляда на архитектурные домены, получается зафиксировать обоснованную и понятную конструкцию. В будущем ее будет проще масштабировать. Это позволяет сразу скоординировать взгляды бизнеса, ИТ и операционного блока на то, как должна работать новая единица. Построение диаграмм облегчает разговор с бизнесами, потому что позволяет говорить с ними на более понятном им языке. Не просто кидаться набором артефактов, а объяснить логику размещения, связей и тд. В этом плане помогают best practice ArchiMate с расположением объектов по слоям.
TOGAF в этом смысле не является догмой, а являет собой некий методический шкаф: заполняешь именно те полки, которые нужны под твой проект. Да, здесь можно сделать оговорку о необходимости понимать что и зачем ты заполняешь. Но это относится к любому инструменту :)
А так ли хорош TOGAF?