Архитектура предприятия Джона Захмана

Размещено на http://www.allbest.ru/

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

Реферат

по дисциплине:

Оптимизация и реинжинеринг бизнес-процессов

на тему:

Архитектура предприятия Джона Захмана

Введение

Понятие «архитектура предприятия» впервые появилось в 1987 г. в статье Дж. А. Захмана «Структура архитектуры информационных систем», опубликованной в журнале IBM Systems Journal. В этой статье автор изложил свое видение архитектур предприятий и связанных с ними проблем, которое задало направление развития на последующие 20 лет. В качестве проблемы было обозначено управление сложностью распределенных систем. Захман говорит:

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

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

Захман внес основной вклад в разработку архитектуры предприятия Министерством обороны США. Эта попытка была предпринята в 1994 г., а сама концепция получила название «Базовая архитектура технического обеспечения для управления информацией».

Архитектура предприятия изначально предназначалось для решения двух следующих проблем.

Сложность систем -- организации тратили все больше денег на построение ИТ-систем.

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

2007 год ознаменовался 20-летним юбилеем методологий построения архитектуры предприятия. За это время было разработано множество методологий. Сегодня доминирующее положение занимают четыре методологии: структура Захмана для архитектуры предприятий, методология TOGAF (The Open Group Architecture Framework), архитектура федеральной организации (FEA) и методология Gartner (ранее именуемая Meta Framework).

1. Описание модели Захмана

Значительный вклад в развитие концепции архитектуры предприятия был сделан Дж. Захманом (John A. Zachman). С момента публикации "модель Захмана для описания архитектуры предприятия" прошла определенную эволюцию в своем развитии и стала основой, на базе которой многие организации создавали свои собственные методики описания информационной инфраструктуры предприятия. С 1987 года, когда была предложена первая версия этой модели, расширенная впоследствии в работах 1992-96 гг., она была использована достаточно большим количеством крупных компаний, входящих в список 2000 крупнейших корпораций мира, такими, например, как General Motors, Bank of America и др. Модель Захмана также послужила основой для создания целого ряда других методик и моделей описания архитектуры предприятия, таких как Федеральная Архитектура США (FEAF - Federal Enterprise Architecture Framework), Методика описания архитектуры Open Group (TOGAF - The Open Group Architecture Framework), Методика описания архитектуры министерства обороны США (DoDAF - Department of Defence Architecture Framework). Отметим, что в данном случае в исторически сложившемся переводе названия на русский язык используется именно термин "модель", отражающий прежде всего четкую формальную структуру предложенной Захманом конструкции, хотя по глубине подхода и значимости, скорее, должен был быть применен перевод оригинала "framework" как "методики".

Модель Захмана основана на дисциплине классической архитектуры и обеспечивает общий словарь и набор перспектив, или структур (framework), для описания современных сложных корпоративных систем. По большому счету описание Архитектуры предприятия следовало принципам, заложенным в модели Захмана.

Итак, в своей работе Дж. Захман определил Архитектуру предприятия как "набор описательных представлений (моделей), которые применимы для описания Предприятия в соответствии с требованиями управленческого персонала (качество) и которые могут развиваться в течение определенного периода (динамичность)". Термин "архитектура" здесь не случаен, он подчеркивает существующую аналогию между внутренней структурой абстрактного объекта - предприятия и сложного искусственного объекта, такого как здание или орбитальная международная космическая станция (МКС). архитектура предприятие джон захман

Для удобства описания Захман предложил так называемую Модель архитектуры предприятия (Zachman Framework for Enterprise Architecture). Модель преследует две основные цели - с одной стороны, логически разбить все описание Архитектуры на отдельные разделы для упрощения их формирования и восприятия, с другой - обеспечить возможность рассмотрения целостной Архитектуры с выделенных точек зрения или соответствующих уровней абстракции.

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

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

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

2. Таблица Захмана

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

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

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

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

В качестве основных аспектов построения архитектур рассматриваются следующие:

- цели, бизнес-правила (мотивация того, почему функционирует система);

- объекты (что проходит преобразования);

- функции (как осуществляется преобразование в процессе);

- участники (субъекты) процесса (кто осуществляет процесс);

- место (где выполняется процесс);

- время (временные требования к выполнению процесса, событиям).

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

Примеры заполнения ячеек таблицы Захмана.

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

Начнем пояснения с первого столбца матрицы: цели (почему?).

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

Позиция пользователя (собственника). Цель и стратегия предприятия, которые составляют основную мотивацию для деятельности предприятия и принятия решений. Создание бизнес-плана. Бизнес-план в основном ориентирован на проблемы управления, но в нем также должно уделяться внимание вопросам мотивации деятельности.

Позиция проектировщика. Логическая модель реализации бизнес-правил предприятия в терминах намерений и ограничений.

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

Второй столбец матрицы: люди (кто?)

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

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

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

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

Третий столбец: функции (архитектура приложений).

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

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

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

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

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

Четвертый столбец: объекты-данные (архитектура данных).

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

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

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

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

Позиция разработчика (технологическая модель). Описывается физическая модель данных. Модель отражает технологические ограничения или физическое представление объектов и целей предприятия. Стиль модели зависит от технологии реализации. Если выбрана реляционная технология, модель данных имеет табличную структуру, чтобы поддерживать реляционные модели. В случае объектно-ориентированных нотаций это будет иерархическая/ассоциативная модель.

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

Заключение

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

Основные характеристики данной модели:

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

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

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

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

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

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

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

Список использованной литературы

1. Методический материал «Методология и практические рекомендации по построению автоматизированных систем трансформирующихся государственных предприятий»/ Под общ. ред. Е. З. Зиндера, Фонд ФОСТАС, 2003 год.

2. Тельнов Ю. Ф. Реинжиниринг бизнес - процессов. - М.: Финансы и статистика, 2003. - 256 с.

3. Данилин А. Архитектура и стратегия / А. Данилин, А. Слюсаренко. - М. Интернет-Ун-т Информ. Технологий, 2005. - 504 с.

Размещено на Allbest.ru