Применение модели Захмана для проектирования ИТ-архитектуры предприятия

ИТ-архитектура предприятия является целостным описанием ключевых стратегий организации, связанных с информацией, прикладными системами и технологиями, а также их влиянием на функции и бизнес-процессы организации.

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

• методики аналитических компаний: Gartner, Giga, META и др.;
• модель Захмана;
• методика TOGAF;
• методика POSIX 1003.23i и др.

Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework).
Методика является инструментом для создания широкого спектра различных архитектур. Она, как правило, включает в себя описание методов проектирования ИТ-архитектуры в терминах использования определенных "строительных блоков", описание того, как эти "строительные блоки" связаны между собой, набор инструментов для описания элементов архитектуры, общий словарь используемых терминов. Методики также могут содержать список рекомендуемых стандартов и совместимых продуктов, которые могут использоваться для реализации различных элементов архитектуры. Важно понимать, что методики не только задают набор документов и планов, необходимых для описания предприятия, но и определяют, как все эти элементы описания связаны между собой. Существуют индустриальные стандарты для описания ИТ-архитектуры предприятия, принятые такими организациями, как IEEE, ISO, описанные в ITIL, COBIT и т.д. Но, ни один из этих стандартов не занимает доминирующего положения. Более того, ни один из них, взятый в отдельности, не дает группам разработчиков ИТ-архитектуры, всех необходимых инструментов с методической точки зрения и с точки зрения шаблонов, используемых для описания архитектуры. Однако этот накопленный арсенал методик и стандартов предоставляет архитекторам широкие возможности выбора моделей, примеров и опыта различных индустрий.
Описание ИТ-архитектуры служит детальным руководством, которое определяет основные, стандартные или типовые элементы ИТ-систем, их взаимосвязи, а также процессы управления информационными системами. Можно сформулировать следующие требования:

• высокий уровень детализации для практического использования * специалистами в области ИТ при разработке новых систем;
• простоту для понимания не специализированной аудиторией;
• динамику рассмотрения (т.е. "Архитектура как есть" – "Краткосрочные и среднесрочные задачи" – "Стратегические планы");
• возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных проектов.

Для формализованного описания ИТ-архитектуры организации могут использовать различные форматы. Важно, чтобы организация использовала такой формат описания, который бы обеспечивал легкий для понимания способ руководства по развитию всех аспектов ИТ в организации.
Многие понятия ИТ-архитектуры являются частными применениями соответствующих более общих понятий, связанных с архитектурой предприятия в целом. Соответственно, для описания и моделирования ИТ-архитектуры могут быть применимы подходы, методологии и инструментальные средства моделирования, разработанные для более общих задач.
Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира. Модель Захмана послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF), Методика описания архитектуры Open Group (TOGAF), Методика описания архитектуры министерства обороны США (DoDAF).
Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив или структур, для описания современных сложных корпоративных систем. В своей работе Дж. Захман определил архитектуру предприятия как "набор описательных моделей, которые применимы для описания предприятия в соответствии с требованиями управленческого персонала и которые могут развиваться в течение определенного периода". Термин "архитектура" здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта – предприятия, и сложного искусственного объекта, такого как здание или космическая станция.
Для удобства описания Захман предложил т.н. модель архитектуры предприятия. Модель преследует две основные цели – с одной стороны, логически разбить все описание архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной архитектуры с выделенных точек зрения или соответствующих уровней абстракции.
В то время, когда были опубликованы работы Захмана, традиционным подходом при формировании описания системы являлось использование концепции "жизненного цикла", включающего такие этапы, как планирование, анализ, проектирование, разработка, документирование, внедрение и промышленная эксплуатация. На каждом из этих этапов рассматриваются вопросы, связанные как с функциями системы, так и с данными. Захман предложил вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, использовать рассмотрение системы с различных перспектив
Исторически модель Захмана впервые была создана именно для ИТ-систем. Этот подход в последующей работе был обобщен для рассмотрения не только ИТ-систем, но и для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа.
Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Для любой достаточно сложной системы общее число связей, условий и правил обычно превосходит возможности для одновременного рассмотрения. В то же время отдельное, в отрыве от других, рассмотрение каждого аспекта системы чаще всего приводит к неоптимальным решениям, как в плане производительности, так и стоимости реализации.
Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рисунке 1. Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.
Перспективы могут, в частном случае, соответствовать различному уровню управления предприятием, если речь идет об архитектуре предприятия или использования информационной системы.
Рис. 1 Модель Захмана
Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки, а также планы и изображения, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень "логической модели" уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам.
Аналогично, в применении к деятельности предприятия верхняя строка "Контекст" соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам менеджеров и владельцев процессов. Третий уровень – тот, на котором менеджеры, аналитики и ИТ-менеджеры должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков
На каждом из этих уровней участники рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, но с различным уровнем абстракции и детализации. В содержание этих колонок входят:

• используемые данные (что?);
• процессы и функции (как?);
• места выполнения этих процессов (где?);
• организации и персоналии–участники (кто?);
• управляющие события (когда?); * цели и ограничения, определяющие работу системы (зачем?);

Основные правила заполнения таблицы следующие:

• каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы ("базис");
• порядок следования колонок несущественен;
• каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или простого описания;
• базовые модели для каждой из колонок являются уникальными;
• соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
• заполнение клеток должно проводиться последовательно "сверху вниз".

Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес (продукты, услуги, клиенты), а также формулируется бизнес-стратегия. Фактически, данная строка определяет контекст всех последующих строк.
Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.
Третий уровень (логическая модель) соответствует рассмотрению с точки зрения системного архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне бизнес-функций
На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.
Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.
Шестой уровень описывает работающую систему. На этом уровне могут быть введены такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk и т.д.. Надо заметить, что в исходной работе Захмана содержание этого уровня не детализируется. При развитии модели, как будет показано ниже, отмечены возможности
рассмотрения аспектов функционирования работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб.
Рассмотрим, как осуществляется последовательная детализация отдельных аспектов описания системы, для чего обратим внимание на различные колонки таблицы. Так, первая колонка отвечает на вопрос "ЧТО?" и определяет используемые в системе данные. На верхнем уровне достаточным будет простое перечисление основных объектов, используемых в бизнесе. На втором уровне данные объекты объединяются в семантическую модель высокого уровня и обычно описываются в виде диаграммы "сущности-связи" с отражением основных связей и наиболее существенных ограничений. На третьем уровне эта модель приводится к нормализованной форме, определяются все атрибуты и ключи. Четвертый уровень представляет собой физическую модель данных в системе. Следующий уровень содержит описание модели на языке управления данными для формирования таблиц, готовые библиотеки классов, табличные пространства СУБД. Последний уровень может описывать фактические наборы данных, в том числе такие характеристики, как журналы доступа, размеры реально занимаемого дискового пространства, статистику обращений и т.п.
Колонка функций (ответ на вопрос "КАК?") предназначена для последовательной детализации описания того, как миссия предприятия реализуется на уровне отдельных операций. В частности, на первом уровне достаточным будет простое перечисление процессов. Второй уровень будет содержать модель процессов, которая впоследствии детализируется в операции над данными и архитектуру приложений (уровень 3), методы классов (уровень 4), программный код (уровень 5) и, наконец, исполняемые модули. При этом, начиная с 4-го уровня, рассмотрение ведется уже не в рамках предприятия в целом, а по отдельным подсистемам или приложениям.
Следующая колонка (вопрос "ГДЕ?") определяет пространственное распределение компонент системы и сетевую организацию. На уровне планирования бизнеса здесь достаточно определить расположение всех производственных объектов. На следующем уровне эти объекты объединяются в модель со связями, характеризующими взаимодействие между собой. На третьем уровне системной архитектуры осуществляется привязка компонент информационной системы к узлам сети. Четвертый уровень служит для определения физической реализации в терминах аппаратных платформ, системного программного обеспечения, а также средств промежуточного уровня, используемых для интеграции различных компонент информационной системы между собой. На пятом уровне определяются используемые протоколы и спецификации каналов связи. Последний уровень описывает функционирование реализованной сети.
Колонка таблицы, отвечающая на вопрос "КТО?", определяет участников процесса. На уровне планирования бизнеса здесь представлен список подразделений предприятия и выполняемые ими функции. На следующем уровне приводится полная организационная диаграмма, а также должны быть определены общие требования к информационной безопасности. Далее последовательно определяются участники бизнес-процессов и их роли, требования к интерфейсам пользователя и правила доступа к отдельным объектам, физическая их реализация на уровне кода или операторов определения доступа к таблицам в СУБД. Последний уровень описывает обученных пользователей системы.
Пятая колонка отвечает на вопрос "КОГДА?" и определяет временные характеристики бизнес-процессов и работы системы. Детализация осуществляется сверху вниз, начиная от календарного плана (уровень 1) и основных параметров, характеризующих выполнение бизнес-процессов (уровень 2). На третьем уровне определяются события, вызывающие изменение состояния информационных объектов и инициацию операций над ними. На следующем уровне эти события транслируются в программные вызовы или передаваемые сообщения. Пятый уровень определяет физическую реализацию обработки таких событий. На 6-м уровне – фактическая история функционирования системы.
Последняя колонка ("ПОЧЕМУ?" или "ЗАЧЕМ?") служит для определения мотивации и задает порядок перехода от задач бизнеса к требованиям и элементам информационных систем. Исходной точкой является бизнес-стратегия, которая затем последовательно транслируется в бизнес-план, затем в правила и ограничения для реализации бизнес-процессов, а на уровне 4 – в соответствующие приложения, необходимые для включения в состав информационных систем и, в дальнейшем, в их физическую реализацию. Такая модель описания полезна для идентификации возможных ограничений. Эти ограничения могут распространяться как от верхних уровней к нижним (например, указание руководства компании о выборе тех или иных средств, продуктов или принципов работы), так и в обратном направлении (например, возможности существующих технологий беспроводной связи в значительной степени определяют спектр предлагаемых услуг и организацию бизнес-процессов у провайдеров этих услуг).
Важным принципом предложенной модели является необходимость последовательного перехода при углублении детализации рассмотрения. Пропуск отдельных элементов почти всегда приводит к неудаче. На практике это часто случается при попытке разработки программы на основании только устного описания требований пользователя. Основные характеристики данной модели:

• простота для понимания как техническими, так и нетехническими специалистами;
• целостность в отношении предприятия;
• поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;
• возможность применения для планирования, позволяющего лучше принимать решения; * применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия предприятия как целого;
• независимость от конкретных инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают.

Созданная модель архитектуры служит простым, но мощным инструментом по применению системного подхода для планирования работ по созданию и использованию информационных систем и их стыковки. Схема архитектуры позволяет концентрироваться на отдельных аспектах системы и в то же время не терять ощущения общего контекста, то есть, взгляда на предприятие в целом.
Рассмотрим, как может использоваться такой подход на практике. Во-первых, данную модель удобно применять для классификации всей информации, описывающей предприятие и
информационные системы этого предприятия, выявления "белых пятен" и координации работ. Во-вторых, данную модель можно использовать на метауровне – для сравнения различных реализаций создания архитектур предприятия. Наконец, она может являться удобным средством для использования в отдельных проектах. Например, в проекте по созданию корпоративного информационного портала необходимо определить элементы в строках 3-5 колонки 4 – соответственно, требования пользователей к представлению данных, интерфейсы и спецификацию по разграничению доступа с учетом существующих "унаследованных" компонент информационной системы. Эта существующая технологическая архитектура, в свою очередь, рассматривается в ячейке на пересечении четвертой строки и третьего столбца таблицы.