Что не так с 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.

2 ответ. на "Что не так с TOGAF 9.2"

  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 «наклонит» к себе подкомитет, выпустивший этот стандарт …

Добавить комментарий

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

Логотип WordPress.com

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

Google+ photo

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

Фотография Twitter

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

Фотография Facebook

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

Connecting to %s