Что не так с TOGAF 9.2

Несмотря на то, что с появления версии 9.2 фреймворка архитектуры предприятия TOGAF прошло уже несколько месяцев, обзорных статей на эту тему появилось не очень много. А ведь появления очередной, то ли 10-ой то 9.2 версии ждали аж 2011 года. Те, кто последовательно критиковал деятельность The Open Group, продолжили это делать (см., например Svyatoslav Kotusev TOGAF Version 9.2: What’s new?). Приверженцы отметились небольшими «дежурными» статьями. Но общий фон представляется мне довольно спокойным. Количество просмотров большинства коротких видео, подготовленных Open Group и опубликованных на YouTube, не доходит до тысячи. В общем вышла очередная версия, ну и ладно.

Я бы рекомендовал всем интересующимся архитектурой предприятия посмотреть первое видео из упомянутой серии The Open Group — The TOGAF Standard, Version 9.2: Part 1. Не для того, чтоб узнать, что случилось в TOGAF в очередной версии, а в качестве примера, демонстрирующего архитектурный стиль изложения: рассказать про долгосрочные цели и светлое будущее, а потом вернуться в реальность, используя эту сказочную историю в качестве обоснования скромного первого шага.

Но давайте разберемся с тем, что же там у них происходит. Я не буду акцентировать ваше внимание на размывании границ фреймворка, заключающегося в том, что некоторое количество страниц из тела документа вынесли в отдельные книжки. Объем основного документа это уменьшило незначительно, а понятность его от этого действия особо не возросла. Было почти семь сотен страниц, стало пятьсот с лишним. Возможно, это приятно тем, кто предпочитает книжную версию фреймворка. Я предпочитаю использовать веб-версию и мне, в общем, более-менее не важно сколько текста находится под ссылкой, по которой я так не перешел. Зато исключенные главы, вместе с множеством других текстов, большинство из которых были ранее опубликованы, вошли в так называемую библиотеку. Т.е. теперь вы можете доставать любой документ из соответствующего раздела сайта Open Group, находить на сотой странице какой-то тезис и утверждать, что: «в TOGAF написано…». Но это не столь существенно, потому коснемся содержания, хотя бы тезисно:

Невооруженным глазом видно, что в разделе бизнес-архитектура продолжаются изменения, активно добавляются новые понятия, появляются отдельные книжки. Отмечу появление руководств: Capability-Based Planning и Business Capabilities Guide, Business Scenarios Guide, Value Streams Guide. Хотелось бы верить в то, что это признак гармонизации с бизнес-архитектурой в понимании BIZBOK гильдии бизнес-архитектуры Business Architecture Guild(мне этот подход несомненно ближе), но боюсь, что это не совсем так. Просто TOGAF собирает в свою орбиту всё, что вращается вокруг той или иной темы. Не знаю, как появление этих понятий в TOGAF найдет своё отражение в Archimate. В прошлый раз, при внесении в него понятия business capability, получилось как-то не очень здорово(См. обсуждение Missing from ArchiMate: (Business) Capability?  и сравните с результатом в ArchiMate® 3.0.1 Specification. 7.3.1 Capability ). Скорее всего при очередном обновлении просто добавят новых пиктограмм, чем еще больше запутают практикующих архитекторов.

В общем, я бы не стал использовать TOGАF в качестве руководства по описанию бизнес-архитектуры, отдав предпочтение отраслевым стандартам и более конкретным техникам типа бизнес-сценариев или потоков создания ценности. Внятного ответа на типичную реплику бизнеса при рассматривании архитектурных картинок: «Откуда вы это взяли? В реальности всё абсолютно не так», он не дает и потому с каждым конкретным доменом придется разбираться отдельно.

Похожая ситуация и с остальными слоями: прикладной, информационной и технологической архитектурой. Представьте себе – приходите вы в ИТ современной организации и говорите: ребята, у нас у Enterprise Architects есть следующие базовые понятия: технологический компонент, который то ли элемент инфраструктуры, то ли класс решений, а еще прикладной компонент, например CRM, и прикладная платформа – набор технологических компонент, на которых всё это крутится. Есть ненулевая вероятность, что айтишники вам на это ответят: а у нас не так! Расскажут, что в ИТ есть разработка и эксплуатация, быть может книжкой IT4IT от того же автора потрясут перед носом; порассуждают про разницу между application и app, расскажут про ЦОДы, менеджеры виртуальных машин, контейнеры и облачные сервисы, выскажут легкое недоумение относительно работы The Open Group: Microservices Architecture и обязательно про devops и agile.

Что же делать корпоративному архитектору в сложившейся ситуации? Да то же, что и всегда. Прежде всего принять, что в каждой отрасли ив каждой компании будет своя метамодель. Если заказчик говорит, что организационная структура у него это трайбы и гильдии или же «поезда» SAFe ART, а ИТ-ландшафт состоит из информационных систем, функциональных подсистем и программных комплексов, то так оно и есть. И это все надо аккуратно изучать, описывать, анализировать и использовать в качестве карты для маршрута будущих изменений. В определенном смысле здесь будет полезней ГОСТ Р 57100-2016 ISO/IEC/ IEEE 42010:2011, над которым я немного подтрунивал в этой заметке ГОСТ Р 57100. Описание архитектуры. По крайне мере Приложение А даст ответы на вопрос как придумывать представления и согласовать посредством связей множественные модели объекта. А вообще, всё зависит от целей. Там, где продавец недвижимости повторяет мантру: «Location, location, location», архитектор предприятия, безусловно, должен бормотать: purpose, purpose, purpose.

  1. Есть известная архитектурная эвристика — проблема понимается лучше после работы над решением этой проблемы. Я думаю, что у них попытка найти следующий WHY из 4 или 5 рекомендованных.

  2. Да, TOGAF продолжает «пылесосить» все, что лежит вокруг его v.8. Поэтому да, «purpose, purpose, purpose», но хорошо бы это был второй шаг. А первый чтобы «values & values harmonization» (s на конце values принципиально). Будет лучше для WHY. Иначе это всё еще в большой степени отношение архитекторов ИТ-систем, а не enterprise. Не случайно BIZBOK с таким ударением фокусирует на том, что он (и бизнес-архитектура) — «это про бизнес» ))
    Да, отраслевую специфику (а если есть стандарты — то и их) конечно надо выделять и в явном виде использовать, в т.ч. в метамоделях и даже фреймвоке. Но часто нужно еще больше: уже на этом мета уровне отражать еще и специфику конкретного предприятия.
    Интересно, что упомянуты стандарты, пришедшие из SW. Поэтому надо отметить также и взгляд enterprise в ИСО 15704, и проект разработки новой версии этого стандарта. Важно, насколько ISO/IEC JTC1 «наклонит» к себе подкомитет, выпустивший этот стандарт …

  3. Здравствуйте, Максим! Подскажите, пожалуйста, в сухом остатке, есть ли смысл сдавать экзамен TOGAF? С одной стороны, его спрашивают на собеседованиях. С другой стороны, получается, что в реальной жизни он не применим.

  4. Геннадий, поделитесь, в каких компаниях спрашивают про экзамен TOGAF? Мне такие компании на попадались ни разу, поэтому очень интересно. Тем более после сдачи экзамена TOGAF9 Certified.

Добавить комментарий для EZ Отменить ответ

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s