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

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

В своём микроисследовании я буду опираться на две ранние работы автора: «A framework for information systems architecture» by J. A. Zachman, IBM System Journal, 1987  и «Extending and formalizing the framework for information systems architecture» by J. F. Sowa J. A. Zachman, IBM System Journal, 1987 и сразу же хочу обратить ваше внимание на то, что и в первой и во второй работе речь идет об архитектуре информационных систем. Термин архитектура предприятия (Enterprise Architecture) обретет популярность позже и еще лет десять корпоративные архитекторы будут пытаться оторвать фреймворк Захмана от информационных систем и обобщить его до масштабов предприятия. Пока же, автор явно указывает в своей первой статье, что рассмотрение стратегии бизнеса и ИТ находится за границами его работы:

Although information systems architecture is related to strategy, both information strategy and business strategy, this paper deliberately limits itself to architecture and should not be construed as presenting a strategic planning methodology

Впрочем, считать матрицу Захмана инструментом системной архитектуры будет не вполне корректно, так как предметом работы, во-первых, являются информационные системы созданные и используемые в интересах производственной деятельности предприятия, а решаемой проблемой – разобщенность и несогласованность данных, возникающая при интеграции корпоративных систем или их отдельных модулей – во-вторых. Речь скорее идет о том, что мы сегодня называем архитектурой ИТ-решений (Solution Architecture). Просто во времена ранних работ Захмана количество информационных систем в ИТ-ландшафте организаций было не так велико, как сейчас и задача согласования данных и спрямления взаимодействий между ними не выглядела столь утопичной как сегодня.

Но приступим к восстановлению логики автора, спрятанного за картинкой.  Прежде всего следует удалить три правых столбца, озаглавленных Who, When и Why. Они отсутствовали в первоначальной работе и появились только во второй. Исходная матрица представлена на рисунке. В ней по-прежнему сложно что-либо разглядеть, потому я позволю выписать названия строк и дать по каждой из них некоторые пояснения.  Выглядело это первоначально вот так:

  1. Bubble charts
  2. Architect’s drawings
  3. Architect’s plans
  4. Contractor’s plans
  5. Shop plans
  6. Buildings

Речь, как нетрудно заметить, в этом списке идет об этапах работ при строительстве загородного дома. Сначала архитектор обсуждает с заказчиком что необходимо построить. Пузырьковая диаграмма (в оригинальном тексте слово bubble часто используется в кавычках, т.е. речь идет не о традиционной пузырьковой диаграмме). При этом он рисует на салфетке квадратики и кружочки, напоминающие функциональные или ландшафтные карты, о которых так много написано в этом блоге (см., например: Вебинар: визуализация постановки задачи  или Карта ИТ-ландшафта). В результате первой беседы получается такая зарисовка(картинка взята из первой статьи Захмана).

Далее архитектор удаляется на некоторое время, чтоб поразмыслить над поставленной задачей и возвращается с эскизом (architect’s drawings). Для именования подобных картинок я предпочитаю термин «технический рисунок»(в кавычках) или общий обзор решения. Эскизы, как и первоначальная картинка, предназначены для обсуждения с заказчиком и детализация их должна соответствовать этой цели.

Архитектурные планы имеют другую задачу. Они «нарезаны» по видам деятельности и материалам (фундамент и стены, электропроводка, сантехника и пр. Захман указывает, что в традиционном строительстве присутствует 16 категорий, но не перечисляет их все). Эти модели предназначены для переговоров с генеральным подрядчиком и определения структуры работ проекта. В ответ на эти планы генеральный подрядчик предлагает свое видение: contractor’s plans

Следующий раздел – это «технические задания» подготовленные субподрядчиками, каждым в зоне своей ответственности и компетенций. И, наконец, последним представлением является готовое здание.

В соответствии со «строительной» метафорой и появились строки матрицы Захмана. В общем нечего сложного. Последнюю строчку, очевидным образом опустили, а предыдущим пяти дали соответствующие названия. Далее в статьях приводятся замечания, что речь не идет об уровнях детализации, а рассмотренные представления адресованы разным типам заинтересованных лиц и акцентируются на разных аспектах (Помните историю про архитектурные виды и представления Architectural Blueprints — The “4+1” View Model of Software Architecture? ) Но думаю, что дальше все понятно и эту заметку уже можно понемногу завершать.

Впрочем, я же чуть не забыл рассказать про столбцы. Здесь все еще проще. При строительстве дома они называются: Material, Function и Location. Конечно, в таком виде для описания информационных систем использовать их нельзя. По крайней мере для первого столбца необходимо придумать другое название. Пусть речь идет об информации. И если вещество определяется у нас структурой своих молекул, то информация будет характеризоваться структурой данных (это уже отсебятина). В общем все становится логично и просто и остается для каждой из пятнадцати клеток придумать рекомендации по содержанию моделей и используемой нотации. В итоге имеем:

В первой сточке поля заполняются списками: важных для бизнеса понятий, процессов и географических позиций (архитектура клиент-сервер распространится еще только лет через пять). Во второй: диаграмма «сущность-связь», диаграмма процессов и граф телекоммуникационной сети. В третьей: модель данных (не бизнес-сущности, как уровнем выше, а логическая модель), диаграмма потоков данных и детальное описание инфраструктуры (процессора, диски, в общем характеристики узлов). На самом деле, уже здесь модель начинает немного перекашивать. Впрочем, в отличие от таблицы Менделеева для заполнения ячейки нам не надо открывать соответствующий элемент, а достаточно придумать еще одно представление.

Не продолжая дальнейший детальный разбор строк и не объясняя отброшенные в начале три правых столбца, хочу обратить ваше внимание на несколько моментов. Последовательность работ, приведенные в матрице в строках, в последующих реинкарнациях архитектурного фреймворка, таких как TAFIM и TOGAF свернется в известное нам кольцо этапов architecture development method. Три столбца первоначальной модели еще встретятся нам в виде столбцов нотации  Archimate, как впрочем и идея связи между элементами моделей из разных клеточек, о которой мы сегодня не поговорили. Ну а другие идеи статьи прямиком попадут в IEEE-1471, который преобразуется уже в 2000-ые годы в ISO-42010, а в наши времена и подвергнется переводу на русский язык в виде ГОСТ Р 57100-2016

Является ли полезной модель Захмана? Да, безусловно! По крайней мере до тех пор, пока мы не начинаем её обобщать до инструмента описания галактик и вселенной, а используем по непосредственному назначению – для анализа и проектирования корпоративных информационных систем.

Ответы на вопросы и продолжение в Telegram-канале: https://t.me/it_arch

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

  1. Спасибо! Я до этого читала про матрицу Захмана, но никакой ясной картины не сложилось. Теперь стало гораздо более понятно, особенно мне было полезно прочитать отсыл к первоначальным работам.

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

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

Логотип WordPress.com

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

Google+ photo

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

Фотография Twitter

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

Фотография Facebook

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

Connecting to %s