Предпосылки использования архитектурного подхода при создании информационных систем. Общая схема модели (таблицы, матрицы) Захмана.

Почему вопросы разработки ИТ-стратегии и формирования ИТ-архитектуры становятся особенно актуальны именно сейчас? Объяснение может основываться на целой совокупности факторов, основные из которых связаны с:

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

Разработка архитектуры предприятия включает в себя компоненты, связанные с функциональной архитектурой (бизнесом), информационными технологиями и управлением архитектурным процессом. Приведенная ниже диаграмма отражает подход NASCIO (Национальной Ассоциации CIO США), которая наглядно отражает то, как различные компоненты взаимодействуют и влияют друг на друга.

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

Существуют различные подходы или рамочные модели, методики (frameworks) к описанию архитектуры предприятия.:

методики, опубликованные аналитическими компаниями, такими как Gartner, GigaGroup, META Group и другими;

модель Захмана;

методика TOGAF;

методика POSIX 1003.23, которая основывается на разработках компании CapGemini, переданных для публичного использования в 1996 году.

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

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

Если говорить формально, то существуют индустриальные стандарты на описание архитектуры предприятия, принятые такими организациями, как Институт инженеров электрики и электроники (IEEE – InstituteofElectricalandElectronicsEngineers), международная организация стандартизации (ISO – InternationalOrganizationforStandardization), TheOpenGroup и т.д.

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

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

достаточно высокий уровень детализации для практического использования специалистами в области информационных технологий при разработке новых систем;

простоту для понимания бизнес-аудиторией;

динамику рассмотрения (т.е. "Архитектура как есть" – "Краткосрочные и среднесрочные задачи" – "Стратегические планы");

возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов.

Первое определение говорит о том, что "архитектура – это описание некоторой сложной системы в определенный момент времени". Оно аналогично схемам описания и чертежам здания, города, сада или компьютерной сети. Этому определению архитектуры соответствует центральная секция таблицы. Данная часть таблицы описывает два представления архитектуры: существующее и будущее состояния. Второе определение говорит, что "архитектура – это процесс, т.е. набор руководств, правил и/или стандартов, которые применяются в процессе построения новых систем" (правая секция таблицы). То есть второй смысл архитектуры – в создании системы правил, обеспечивающих направленный переход из текущего состояния информационных систем в будущие. Одним из элементов архитектуры при этом является модель технологической архитектуры, которая задает список утвержденных для закупки технологий. Выбор этих правил, узаконенных архитектурой, определяется принципами, которые должны быть сформулированы как часть всего архитектурного процесса.

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

Модель Захмана

Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (John A.Zachman).С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как GeneralMotors, BankofAmerica и др. Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США, Методика описания архитектуры OpenGroup, Методика описания архитектуры министерства обороны США. Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. Итак, в своей работе Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (ZachmanFrameworkforEnterpriseArchitecture). Модель преследует две основные цели – с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой – обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

Собственно модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рисунке 8.2. Заметим, что в модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.

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

Две верхние строки соответствуют наиболее общим представлениям и достаточно широко описывают существующее окружение, планы и цели. Если проводить аналогию со строительством, то эти уровни содержат сведения о местонахождении и назначении постройки ("особняк" для отдыха в престижном коттеджном поселке в элитной зоне), а также диаграммы, планы и картинки, которые архитектор обсуждает с хозяином будущего дома. Следующий уровень "логической модели" уже является более конкретным, но все равно еще достаточно абстрактным. Это схемы, которые архитектор дома должен показывать подрядчикам.

Аналогично, в применении к деятельности предприятия верхняя строка "Контекст" соответствует уровню интересов высшего руководства и собрания акционеров. Второй уровень соответствует интересам бизнес-менеджеров и владельцев процессов. Третий уровень – тот, на котором бизнес-менеджеры, бизнес-аналитики и менеджеры, отвечающие за ИТ, должны работать вместе. Уровни с четвертого и далее описывают детали, которые представляют интерес для ИТ-менеджеров, проектировщиков, разработчиков.

На каждом из этих уровней участники, вообще говоря, рассматривают одни и те же категории вопросов, соответствующих столбцам в таблице, – только с различным уровнем абстракции и детализации. В содержание этих колонок входят:

используемые данные (что?)

процессы и функции (как?)

места выполнения этих процессов (где?)

организации и персоналии–участники (кто?)

управляющие события (когда?)

цели и ограничения, определяющие работу системы (зачем?)

В конце концов, как отмечает Захман, коммерческие предприятия и государственные организации должны понимать, что путь к эффективным информационным системам требует систематических подходов в проектировании (engineering). Если вы, например, занимаетесь большими проектами, связанными с интеграцией государственных информационных систем, то "...назначить одного ответственного человека – это еще не решение проблемы. Никакого чуда просто так не произойдет. В какой-то момент вы поймете, что настоящий процесс проектирования должен быть реализован для того, чтобы интегрировать эти объекты".

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

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

порядок следования колонок несущественен;

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

базовые модели для каждой из колонок являются уникальными;

соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;

заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования).

Основные понятия модели Захмана: аспекты, заинтересованные лица («игроки»), «взгляд» («перспектива»), элемент архитектурного представления.Вторая редакция модели Захмана - архитектура предприятия (EnterpriseArchitecture).

В 1987 году Джон Захман опубликовал полезную схему развития архитектуры информационной системы. Она создает контекст для описания различных представлений архитектуры разрабатываемой системы. Эти представления соответствуют тому, как видит систему (точка зрения какого-либо участника(игрока) проекта по созданию системы - строка) ее

· заказчик

· проектировщик

· разработчик

причем в разрезе трех выбранных аспектов (колонок). Эти три аспекта:

· данные,

· функции и

· сетевая структура.

Это первая редакция:

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

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

Модель Захмана – модель информационной структуры. Он рассматривает ее с различных «перспектив» (точек зрения) различных «игроков», заинтересованных и участвующих в создании ИС.

Строки – это результат такого рассмотрения. Их 2 вида. Верхняя группа 2-3 отражает функциональные слои бизнеса (заказчика)(взгляды топ-менеджеров и экспертов). Нижняя группа (оставшееся) – представления профессиональной иерархии исполнителя.

Т.о., модель Захмана представляет собой совокупность «видений» системы вышеперечисленной группы участников создания информационной системы.

Логическое объединение этих различных «видений» системы в единую структуру, осуществлено Захманом за счёт общей для всех точек зрения используемой совокупности так называемых архитектурных «аспектов», каждый их которых является ответом на один из вопросов, определяющих любой вид деятельности: что, как, где, (в первом варианте модели Захмана) кто, когда, с какой целью? (дополнительно включены во втором варианте модели).

 

Вторая редакция таблицы, показанная на рисунке ниже, предложеннаЗахманом в 1992 году, она дополнена тремя новыми аспектами:

· Люди (кто?)

· Время (когда?)

· Цель(мотивация) (почему?)

Итоговая модель представляется в виде таблицы, имеющей пять строк и шесть столбцов, которая приведена на рисунке ниже. В модели именно пять строк, просто отображенная на рисунке шестая строка соответствует уже не уровню описания архитектуры, а уровню работающей системы или предприятия в целом.

1. Первая строка соответствует уровню планирования бизнеса в целом (бизнес-модель). На этом уровне вводятся достаточно общие основные понятия, определяющие бизнес – например, продукты и услуги, клиенты, расположение объектов бизнеса, а также формулируется бизнес-стратегия (колонка 6 – мотивация). Фактически, данная строка определяет контекст всех последующих строк.

2. Вторая строка (концептуальная модель) предназначена для определения в терминах бизнеса структуры организации, ключевых и вспомогательных бизнес-процессов.

3. Третий уровень (логическая модель) соответствует рассмотрению с точки зрения Системного Архитектора. Здесь бизнес-процессы описываются уже в терминах информационных систем, включая различные типы данных, правила их преобразования и обработки для выполнения определенных на уровне 2 бизнес-функций.

4. На четвертом уровне – технологической или физической модели – осуществляется привязка данных и операций над ними к выбранным технологиям реализации. Например, здесь может быть определен выбор реляционной СУБД, или средств работы с неструктурированными данными, или объектно-ориентированной среды.

5. Пятый уровень соответствует детальной реализации системы, включая конкретные модели оборудования, топологию сети, производителя и версию СУБД, средства разработки и собственно готовый программный код. Многие из работ на данном уровне часто выполняются субподрядчиками.

6. Последний, шестой уровень описывает работающую систему. На этом уровне могут быть введены, в том числе, такие объекты, как инструкции для работы c системой, фактические базы данных, работа службы HelpDesk. В исходной работе Захмана содержание этого уровня не детализируется. При развитии модели, отмечены возможности рассмотрения аспектов функционирования работающей системы с точки зрения, например, конечного пользователя или эксплуатирующих служб.