Абстрактные модели архитектуры предприятия

Для описания предприятия, его бизнес-процессов, информационных сис-тем и информации на каждом уровне абстракции могут использоваться как ди-намические, так и статические модели. Одной из наиболее общих моделей архитектуры предприятия является разработка Дж. Захмана. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира. Модель Захмана послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF), Методика описания архитектуры Open Group (TOGAF), Методика описания архитектуры министерства обороны США (DoDAF).

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

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

Рис. 2.6. Матрица Захмана

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

На рис. 2.6 представлена русская интерпретация англоязычной оригинальной модели (см. подробнее http://www.zachman.com/about-the-zachman-framework). Стоит обратить особенное внимание, что в оригинале данная матрица называется «framework», что в переводе означает «каркас или структура», что и определяет суть данного подхода: он не дает конкретных инструментов описания, зато предлагает определенную последовательность рассмотрения, которая позволяет при дальнейшем развитии получить описания определенной организации.

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

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

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

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

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

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

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

Таблица (матрица) Захмана имеет и определенные правила заполнения:

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

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

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

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

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

· заполнение клеток должно проводиться последовательно "сверху вниз".

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

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

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

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

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

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

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

· простота для понимания как техническими, так и нетехническими специалистами;

· целостность в отношении предприятия;

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

· возможность применения для планирования, позволяющего лучше принимать решения;

· применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия предприятия как целого;

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

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

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

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

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

Например, на основе модели Захмана выстроена методология TOGAF(The Open Group Architecture Framework), разработанная консорциуумом The Open Group). Она появилась в последние два десятилетия с целью стать стандартом разработки в данной сфере. Изначально данная методология не воплощала целостную концепцию архитектуры предприятия. Первоначально (версии с 1 по 7) TOGAF включала только технические аспекты архитектуры, однако недавно в эту инфраструктуру была добавлена предметная область архитектуры бизнеса (версия 8, Enterprise Edition), в результате TOGAF быстро переместилась на передний план современных вариантов инфраструктур архитектуры предприятий.

На момент включения в TOGAF бизнес-архитектуры[O1] (рис. 2.7), эта инфраструктура уже имела солидную технологическую основу в виде своих предметных областей. Включение в TOGAF предметной области архитектуры бизнеса способствовало дальнейшему росту ее популярности, тогда как для других инфраструктур, у которых сначала не было архитектуры технологии, началось трудное время разработки этой предметной области. Захман, Спивак и некоторые другие намеренно поддерживали высокий уровень абстракции, что негативно повлияло на их восприятие, поскольку они не смогли получить поддержку технического сообщества.

Рис. 2.7. Архитектура предприятия в модели TOGAF

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

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

Кроме собственно структуры самой EA данный подход предлагает и конкретную методику ее построения (Architecture Development Method, метод ADM). В архитектурном смысле модель TOGAF дополняет подход Захмана. Последний показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.

В модели TOGAF мир архитектуры предприятия рассматривается как континуум архитектур (Enterprise Continuum) то есть некоторый набор готовых моделей, от максимально обобщенных до максимально специализированных. Процесс создания конкретной архитектуры предприятия, рассматривается как переход от общей архитектуры к специализированной. Методика разработки архитектуры в модели TOGAF представляет собой процесс осуществления такого перехода.

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

На рис. 2.8 структурно показана суть методики подхода TOGAF.

Рис. 2.8. Континуум предприятия и методика разработки

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

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

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

Задача предварительной фазы (Preliminary Phase, ее на рисунке нет) - выявление заинтересованных в процессе реализации лиц и обсуждение с ними задач архитектуры предприятия. На этой фазе вырабатываются Руководящие принципы архитектуры (Architecture Guiding Principles), которые основываются на бизнес-принципах организации и описывают процессы и критерии для наблюдения за процессом реализации архитектуры предприятия.

Рис. 2.9. Методика ADM

Фаза А этого процесса предназначена для выражения видения архитектуры предприятия. Артефакт Видение архитектуры (Architecture Vision) использует движущие силы бизнеса, чтобы обозначить цель действий по созданию архитектуры предприятия и создать описания первого реза для базовой и целевой среды. Если задачи бизнеса не ясны, то часть задания этой фазы - помочь бизнесу идентифицировать свои главные задачи и соответствующие процессы, которые должна поддерживать архитектура предприятия. Документ Архитектурное задание (Statement of Architectural Work), который также создается в этой фазе, очерчивает область действия и условия архитектуры предприятия и представляет собой план архитектурного задания.

Фаза B предназначена для детальной разработки архитектуры предметной области бизнеса. И базовая, и целевая архитектура, которые очерчены в документе Видение архитектуры, детализируются, чтобы получить полезные входные данные для технического анализа. Моделирование бизнес-процессов, моделирование бизнес-объектов и моделирование прецедентов - вот лишь некоторые методики, которые используются для создания архитектуры бизнеса, которая, в свою очередь, включает анализ просчетов желательного состояния.

Фаза С связана с созданием архитектуры предметных областей Приложение и Данные (Информация). Эта фаза использует базовую и целевую архитектуры, которые были запущены в фазе А (Архитектурное представление) и результатах анализа просчетов (компонента архитектуры бизнеса), чтобы передать архитектурам данных и приложения информацию о текущей и проектной средах, в пределах области применения и в соответствии с планом, очерченным в Документе "Архитектурное задание".

Фаза D завершает работу над детализацией архитектуры цикла метода ADM созданием архитектуры технологии. Как и в предыдущих фазах, в качестве основы используется анализ просчетов и черновые варианты архитектур, так же, как и руководящие принципы архитектуры, выработанные в подготовительной фазе. В этой фазе для создания различных точек зрения активно используется нотация моделирования UML.

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

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

После утверждения спецификации проекта фокус перемещается на формулирование более конкретных условий и рекомендаций для каждого из проектов реализации. На протяжении фазы G устанавливается связь между упрвляющей архитектурой (TOGAF) и разрабатывающей организацией (которая может быть настроена при помощи RUP и Project Management Body of Knowledge (PMBOK), например, или каких-либо еще методологий управления проектом, а выбранные проекты реализуются под управлением формальной архитектуры. На выходе этой фазы мы имеем Архитектурные контракты, которые утверждаются организацией-разработчиком. Конечным выходом фазы G являются решения, совместимые с архитектурой.

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

Не смотря на большую проработанность данной методологии по сравнению с моделью Захмана, надо понимать, что подход TOGAF имеет и ряд недостатков. Метод ADM не является законченным процессом; это инфраструктура, и, по сути, для каждой конкретной организации, требуется адаптация. Адаптация предполагает глубокое знание модели бизнеса и методологии - специалиста с такими качествами не всегда легко найти. Ситуация осложняется тем, что даже не последняя версия TOGAF версия 8.0, Enterprise Edition (2006) и новая версия 9 (2009)- это сравнительно новый подход с ограниченным количеством практических наработок.

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

Несмотря на недавние усовершенствования и выход новой версии, инфраструктура TOGAF не так детализирована, как другие методологии, особенно в главной сфере взаимодействия бизнеса и технологии. Например, TOGAF не включает ни функций, подобных Rational Method Composer или MyRUP, ни такой комплексной библиотеки периодических изданий.

Зрелые организации, особенно те, которые в повседневной работе используют управление проектами и методологию жизненного цикла программного обеспечения (PMBOK, RUP, Scrum и ITIL) обычно добиваются большего успеха в реализации архитектуры предприятия. Можно порекомендовать сотрудникам организации перед тем, как включить в свой инструментарий TOGAF, хорошо изучить несколько методик, нотаций и методологий жизненного цикла программного обеспечения из тех, что показаны на рисунке 2.10.

Рис. 2.10. Применение методики TOGAF для «зрелой» организации

Среди прочих потенциальных угроз успешной реализации TOGAF - отсутствие стандартного инструмента для фиксации и управления артефактами архитектуры предприятия и отсутствие стандартной нотации.