TOGAF 10. Краткий обзор

25 апреля 2022 года The Open Group выпустила версию 10 TOGAF. (Основная ссылка: Digital Edition of the TOGAF Standard) Это важная веха не только для The Open Group, но и для дисциплины архитектуры предприятия в целом. Стандарт TOGAF обновлялся нечасто (см. рисунок ниже). Появился он в 1995 году. Предыдущая большая версия с номером 9.0 вышла в 2009-м и обновлялась в 2011 и 2018 году. Именно в момент второго обновления, одновременно с выходом версии 9.2, было объявлено намерение превратить этот стандарт в некоторую открытую обновляемую библиотеку документов. Предполагалась, что в стандарте будет стабильное ядро, расширяемое отдельными рекомендациями и описаниями лучших практик. С выходом 10-ой версии это произошло. Но обо всем по порядку.

Многоликий Арчи

Евгений Погребняк доработал перевод истории отношений двух корпоративных архитекторов (обоих зовут Арчи) и руководителя бизнес-подразделения — Лоретты. Мы уже вспоминали этот текст  THE FUTURE ENTERPRISE ARCHITECT с сайта The Open Group, но в прошлый раз с переводом как-то не задалось (см. Архитектор Предприятия AS IS и TO BE ). Есть повод вернуться к этой истории

БУДУЩЕЕ КОРПОРТАТИВНОЙ АРХИТЕКТУРЫ

Оригинал статьи: https://blog.opengroup.org/2019/08/20/the-future-enterprise-architect/

Статья Терри Блевинса, члена The Open Group и корпоративного архитектора в Enterprise Wise LLC; отредактировал Шервин Микер, член The Open Group и главный консультант по управлению в IBM

Open Agile Architecture (запись вебинара 5 ноября 2020)

Первые впечатления от нового стандарта архитектуры предприятия Open Agile Architecture™ от международного технологического консорциума The Open Group

Слайды в telegram-канале «Архитектура ИТ-решений» https://t.me/it_arch/946

Рационализация портфеля приложений

В прошлом году у меня появился новый учебный курс «Практики Архитектуры Предприятия». Формальное описание и программу курса можно посмотреть на сайте https://www.itexpert.ru/eap/, а здесь я хочу дать ему менее формальную характеристику и расставить основные акценты. Уложиться в три предложения я не смог и в итоге получилось пять основных вещей, которые я должен отметить

Во-первых, это курс о рационализации портфеля корпоративных приложений. Под рационализацией или оптимизацией часто понимают сокращение затрат или полный отказ от дальнейшего развития приложения. Это не совсем так. Если разработка целевой архитектуры для вашего приложения привела к подобным последствиям, то вы просто попали не в ту часть списка. Для других приложений результатом рационализации является либо привлечение дополнительных ресурсов и инвестиций, либо, как минимум, толерантное к нему отношение. Знаменитый гартнеровский TIME анализ – это аббревиатура: Tolerate, Invest, Migrate and Eliminate (см., например, Application Portfolio Triage: TIME for APM, Jim Duggan, August 2009). Впрочем, есть и более современные источники, например, вышедший в 2019-м Application rationalization playbook американского Federal Chief Information Officers (CIO) Council.

The Digital Practitioner Body of Knowledge

Я давно обещал написать немного об этой книжке, имеющей необычный подзаголовок: The Open Group Snapshot. Пора это сделать, тем более, что согласно уверениям авторов 15 января 2019 года это руководство может превратиться в тыкву. Так что успейте скачать и посмотреть http://pubs.opengroup.org/dpbok/snapshot/ Но главная причина моего интереса к DPBoK, конечно, не в этом. The Open Group выпускает много всяких текстов туманно-абстрактного содержания, читать которые могут заставить себя только настоящие ИТ-архитекторы. Свод знаний цифрового практика не похож на такие работы. Перед нами цельная, неплохо структурированная и довольно конкретная книжка, вобравшая в себя основные темы предыдущего десятилетия так или иначе связанные с развитием цифровых продуктов. Какие-то вещи банальны, другие спорны, но в общем и целом текст (кстати, с картинками) в полной мере претендует на то, чтоб называться Body of Knowledge. Его можно использовать как справочник, можно как учебник, при условии некой толики критичного отношения или, как минимум, как набор полезных ссылок.

Что не так с 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, не доходит до тысячи. В общем вышла очередная версия, ну и ладно.

Объясняем матрицу Захмана

Видео: https://youtu.be/oUhOPcHginY

Матрица Захмана, пожалуй, является наиболее ранним и наиболее показательным примером того, когда большая и сложная картинка скрывает суть вещей, которые она, по идее, должна пояснять. Помню своё первое знакомство с этим творением человеческой мысли. Если что-то и привлекает внимание при беглом взгляде на эту картинку, то это карта США в третьем верхнем квадрате, которая в более поздних версиях уступит вое место карте мира. Оторвав взгляд от тридцати разноцветных картинок, кое-где повторяющихся, можно заставить себя прочитать название столбцов и строк, приведенные, по традиции, очень мелким шрифтом. Если названия столбцов, содержащие слова «что», «где», «когда», еще пробуждают какие-то ассоциации, то названия строк: контекстуальный, концептуальный, логический, физический и уж совсем непонятно какой ассоциируются, разве что, с некоторыми уровнями абстракции. Думаю, на этом большинство зрителей этой картинки решают, что всё понятно и какого-либо более глубоко разбирательства просто не предпринимают. Но сегодня я хочу немного злоупотребить вашим вниманием и поговорить о матрице Захмана чуть подробнее.

Микросервисы в контексте корпоративной архитектуры

Обычно, чтоб убедить кого-нибудь в том, что микросервисная архитектура — это хорошо, её сравнивают с монолитом. Даже картинку специальную рисуют (см. ниже): с левой стороны база данных, сервер приложений и пользовательский интерфейс – это монолит(подразумеваем, что монолит — это плохо), а с правой стороны паутина фигурок и стрелочек между ними (типа, вот это хорошо). Не знают, убедит ли такая картинка случайного собеседника, но архитектор, будучи до конца честен сам с собой, должен сказать, что хорошо – это то что слева. И есть достаточное количество экспертов, которые критически восприняли идеи микросервисной архитектуры и постарались обратить наше внимание не только на достоинства, но и на недостатки такого подхода.

Управление портфелем ИТ проектов

На недавнем вебинаре: ИТ-архитектура и управление изменениями. Обновление процесса CHG мы рассматривали процесс изнутри. Надеюсь, что это было полезным и содержательным. Однако взгляд с такой точки зрения сопровождается одним допущением – запросы на изменения поступают к нам из внешней среды случайным образом и в случайные моменты времени. Безусловно, это не так и в реальной жизни мы знаем о количестве и содержании будущих запросов на изменения немного больше, чем ничего. Особенно если наши бизнес-заказчики ведут плановое хозяйство, собирают свои пожелания на следующий год как-то устанавливают их приоритеты, классифицируют изменения, отделяют главное от самого главного, важное от срочного, появление новых продуктов от улучшения существующих.

Несколько замечаний о корпоративной архитектуре

По примеру старших товарищей я решил сделать в блоге обновляемое сообщение. Я периодически буду возвращаться к этой заметке, что-то добавлять, что-то вычеркивать, а еще что-то переписывать заново. Если изменения будут существенными, то я стану поднимать это сообщение вверх и повторно размещать ссылку на него в соц.сетях и не буду этого делать при незначительных изменениях. Тема, о которой пойдет речь, может быть озаглавлена «Роль ИТ-архитектора в организации», как это было сделано в одной из презентаций (см. https://www.slideshare.net/MxSmirnov/ss-31232067) или Когда, кому и зачем нужна Архитектура Предприятия, как в одноименном из сообщений этого блога.