- Построение архитектуры предприятия
- СОСТАВ И СТРУКТУРА ЕА
- ПРОЦЕСС ВЫСТРАИВАНИЯ ЕА
- ИНСТРУМЕНТАРИЙ МОДЕЛИРОВАНИЯ ЕА
- Требования к среде моделирования
- Первая проблема
- Инициация планирования
- Предварительное бизнес-моделирование
- Формирование снимка предприятия
- Описание текущих систем и технологий
- Формирование архитектуры данных
- Формирование архитектуры приложений
- Формирование технической архитектуры
- Разработка плана реализации
- Заключительное планирование
- Переход к реализации
- Вторая проблема
- ЗАКЛЮЧЕНИЕ
- ЛИТЕРАТУРА
- Бизнес-события
- Подписка на Менеджмент.Дайджест
Построение архитектуры предприятия
Раздел: Информационные технологии | |
Автор(ы): Г.Н. Калянов, журнал «Корпоративные системы» (№3, 2005) | размещено: 04.12.2006 обращений: 54059 |
| ||||
В общем виде под архитектурой предприятия (Enterprise Architecture, ЕА) понимается всестороннее и исчерпывающее описание всех ключевых элементов предприятия и межэлементных отношений 1. Согласно ISO 15704 («Industrial Automation Systems — Requirements for Enterprise-Reference Architectures and Methodologies. 1999») архитектура предприятия должна включать роль людей, описание процессов (функции и поведение) и представление всех вспомогательных технологий на протяжении всего жизненного цикла предприятия. В соответствии с документом «Federal Enterprise Architecture Framework. Dev. by: The Chief Information Officers Council (USA)» архитектура является стратегической информационной основой, которая определяет:
СОСТАВ И СТРУКТУРА ЕААрхитектуру предприятия принято представлять в виде следующих слоев (рис. 1):
Корпоративные миссия и стратегия определяют основные направления развития предприятия и ставят долгосрочные цели и задачи. Бизнес-архитектура на основании миссии, стратегии развития и долгосрочных бизнес-целей определяет необходимые бизнес-процессы, информационные и материальные потоки, а также поддерживающую их организационно-штатную структуру. Системная архитектура определяет совокупность методологических, технологических и технических решений для обеспечения информационной поддержки деятельности предприятия, определяемой его бизнес-архитектурой. Системная архитектура включает в себя архитектуру приложений, архитектуру данных и техническую архитектуру. Архитектура приложений в свою очередь включает в себя:
Архитектура данных включает в себя:
Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ. Сетевая архитектура включает:
Архитектура платформ включает:
ПРОЦЕСС ВЫСТРАИВАНИЯ ЕАРассматриваемый далее метод выстраивания архитектуры предприятия базируется на концепции EAP (Enterprise Architecture Planning) и современных подходах к выполнению консалтинговых проектов в области информационных технологий. В основе метода лежит процесс планирования, ориентированный на создание архитектуры для поддержки бизнеса предприятия (на основе того, какие конкретно данные, приложения и технологии наиболее полно отвечают его потребностям), а также на разработку плана реализации воплощения этой архитектуры. При этом предполагается, что созданию архитектуры предприятия предшествует разработка бизнес-стратегии, включающей миссию, бизнес-цели и способы их достижения. Предлагаемый метод декларирует 10 этапов (см. таблицу), определяющих состав и структуру слоев и элементов архитектуры, а также план ее проектирования, обеспечивающий реализацию как традиционных требований к архитектуре, так и специфических требований конкретного предприятия. Эти этапы организованы в виде следующей четырехуровневой схемы:
Более подробно — см. врезку. Цикл выстраивания архитектуры предприятия основными участниками процесса приведен на рис. 2. Отметим, что в состав рабочей группы должен входить выделенный относительно новый ролевой участник — архитектор, фактически являющийся постановщиком задач на архитектурные изменения на основании как изменившихся внешних условий, так и понимания недостатков существующего положения дел. ИНСТРУМЕНТАРИЙ МОДЕЛИРОВАНИЯ ЕАТребования к среде моделированияСреда моделирования архитектуры предприятия должна включать следующие четыре компонента. Блок элементарных объектов предприятия:
Блок моделей архитектуры предприятия:
: Блок языков и методологий моделирования:
Блок языков мета-моделирования и мета-методологий , которые предназначены, соответственно, для описания концепции, синтаксиса и семантики языков моделирования, и методологий их применения, а также для описания процессов построения этих языков и методологий. Существующие среды моделирования EA можно классифицировать следующим образом:
Первая проблемаСледует отметить, что моделирование архитектуры предприятий является инженерной дисциплиной, требующей комбинированного использования программных сред, языков и методологий моделирования. Однако большинство из перечисленных инструментов фактически являются фрагментарными подходами, покрывающими лишь различные части описанных требований к среде моделирования EA, в том числе:
Универсальные интегрирующие среды. Эти среды являются наиболее продвинутыми в части покрытия обозначенных требований. Например, Zachman Framework отличается гармоничным и комплексным учетом всех архитектурно-существенных факторов, позволяя концентрироваться на отдельных аспектах архитектуры, но не теряя при этом взгляда на предприятие как на единое целое. Эта среда легка для понимания, логически полна и согласована, нейтральна по отношению к инструментарию, является, пожалуй, самой распространенной. С другой стороны, Zachman Framework не поддерживает представление динамики развития предприятия и его информационных систем (отсутствие оси времени) , является достаточно поверхностной референсной моделью (в смысле степени детализации), относительно бедна с технических позиций. Конкурирующая среда GERAM (Generalised Enterprise Reference Architecture and Methodology) определяет комплекс концепций, методов и моделей, необходимых для проектирования и сопровождения современного предприятия любого типа в течении всего времени его существования. Обеспечивается поддержка всех представленных элементов среды моделирования архитектуры на базе концепций, которые:
Одно из главных преимуществ GERAM — его мощность в решении задач, связанных с изменениями (реинжиниринг, CPI/TQM). Один из главных недостатков — концептуальный характер, среда снабжает методологическими руководствами, но не обеспечивает ни языком моделирования, ни соответствующими инструментальными средствами. В настоящее время прослеживается тенденция к обогащению подходов в части покрытия среды моделирования. Например, одна из последних разработок университета г. Бордо GRAI-GIM (GRAI Integrated Methodology) обеспечивает референсную модель с концепцией, языком, графическим формализмом и инженерным методом реализации методологии. Инициация планированияЭтап включает в себя семь шагов, цели, задачи и основные результаты которых описаны далее. Назначение первого шага состоит в формальном определении области и целей планирования архитектуры для понимания участниками проекта того, что будет достигнуто. К его результатам относятся перечень согласованных и утвержденных целей, а также список причастных к проекту подразделений предприятия. Основными задачами шага являются:
Целью второго шага является исследование предприятия, системных входов/выходов и вариантов на основании встреч с менеджментом. Результатами являются согласованное и утвержденное видение предприятия, а также политическая поддержка менеджмента. Основными задачами шага являются:
Целью третьего шага является адаптация методологии планирования и создание руководства по методологии. Основными задачами шага являются:
Целью четвертого шага является наведение порядка с компьютерными ресурсами и оценка инструментария создания ЕА. Основными задачами шага являются:
Цель пятого шага — создание проектной команды. Основными задачами шага являются:
Цели шестого и седьмого шагов — подготовка рабочего плана и его презентация и утверждение. Основные задачи этих шагов традиционны, а их рассмотрение выходит за рамки статьи. В результате должен быть сформирован рабочий план и утвержден бюджет выполнения работ. Предварительное бизнес-моделированиеЦелью бизнес-моделирования является обеспечение полной и исчерпывающей базой знаний всех участников проекта для ее использования при определении архитектуры и плана ее реализации. Бизнес-моделирование осуществляется в два этапа-построение предварительной бизнес-модели, за которым следует построение полной бизнес-модели. Предварительная бизнес-модель идентифицирует функции, дает их описания и идентифицирует организационные единицы — исполнителей функций. По оценкам ряда экспертов этап требует 25-30% всех трудозатрат на моделирование, он осуществляется в три шага. Первый шаг — документирование организационной структуры предприятия — в качестве результатов получают обновленные организационные схемы, перечень ролей и мест их выполнения, оценку количества сотрудников по ролям. Основными задачами шага являются:
Второй шаг — определение структуры бизнес-модели (идентификации и определения бизнес-функций) — в качестве результатов получают определенные функции, каждая из которых: имеет имя, имеет краткое описание или декомпозирована на подфункции, является результатом работы, по крайней мере, одной организационной единицы. Основными задачами шага являются:
Целью третьего шага является документирование бизнес-модели и ее распространение для верификации. Основными задачами шага являются:
Формирование снимка предприятияЭтап включает в себя следующие три шага:
При планировании интервью осуществляется формирование списка интервьюируемых (с датами и временем проведения) и его согласование, распределение интервьюирующих по деятельностям и бизнес-процессам (функциональным направлениям), подготовка инструкции для конкретных участников (задачи и цели, кто, когда, где, какие вопросы и т. д.), а также, при необходимости, корректировка плана создания ЕА. Подготовка интервью включает разработку форм для управления процессом интервьюирования и фиксации результатов (прежде всего, для определения функций и информационных источников). Главной целью собственно интервьюирования является выявление необходимых данных по бизнес-модели. На следующих шагах осуществляется обработка результатов интервью, построение детальной модели, ее анализ, формирование пакета отчетов и проведение презентации. Описание текущих систем и технологийЦелью этапа является документирование всех используемых на предприятии системных и технологических платформ, т. е. создание так называемого каталога информационных ресурсов IRC (Information Resource Catalog), по-другому — системной энциклопедии, являющейся высокоуровневым объектом, а не детальным словарем данных. Целью первого шага является определение видов данных для IRC и проектирование форм для сбора данных. Основные задачи шага включают:
Целью второго шага является сбор данных для IRC и их ввод (заполнение форм), а также сопоставление приложений и функций. Основные задачи шага включают:
Цель третьего шага состоит в интегрировании и верификации информации по текущим приложениям и технологическим платформам, разработке потоковых диаграмм по каждой системе. Основными его результатами являются верифицированный IRC и пакет отчетов по IRC, а также предложения по его улучшению на основе проведенных обсуждений. На четвертом шаге осуществляется подготовка к администрированию и сопровождению IRC для его поддержки в актуальном состоянии. Здесь разрабатывается регламент поддержки, политики и процедуры сопровождения IRC, назначается ответственный по его сопровождению. Формирование архитектуры данныхНа этом этапе идентифицируются и определяются основные разновидности данных, поддерживающих бизнес-функции. Архитектура данных представляется с помощью ER-модели и состоит из сущностей данных, каждая из которых имеет атрибуты и отношения с другими сущностями. Этап содержит четыре шага:
Целью первого шага является идентификация всех потенциальных сущностей, необходимых для поддержки бизнеса. Здесь осуществляется распределение бизнес-модели по членам команды (в разрезе деятельностей и бизнес-процессов), подготовка каждым из участников списка кандидатов в сущности, формирование общего списка кандидатов. Целью второго шага является создание стандартного определения и описания каждой сущности, обеспечение графической иллюстрации их взаимодействий. Здесь сущности определяются и документируются, осуществляется построение ER-модели, производится сопоставление файлов и БД из IRC с сущностями. Целью третьего шага является сопоставление сущностей с бизнес-функциями и приложениями, результатами которого являются матрица сущности-функции и матрица сущности-приложения. При этом для каждой функции нижнего уровня детализации идентифицируется вид каждой из затрагиваемых ей сущностей (создается, изменяется, используется), а приложения сопоставляются с сущностями по входам, выходам, файлам и БД. Целью четвертого шага является подготовка, распространение и анализ отчета по архитектуре данных. Формирование архитектуры приложенийНа этом этапе определяются основные виды приложений, необходимых для управления данными и поддержки бизнес-функций. Архитектура приложений не является ни системным проектом, ни детальными требованиями к системам. Она только определяет, какие приложения будут управлять данными, и снабжает соответствующей информацией исполнителей бизнес-функций. Основными шагами этапа являются:
Целью первого шага является идентификация каждого из возможных приложений и формирование их списка, при этом особое внимание уделяется приложениям, которые могут улучшить бизнес или обеспечить конкурентные преимущества. Цель второго шага — снабдить каждое приложение стандартным описанием (определением) и построить графическую схему архитектуры приложений. Основными задачами шага являются:
Целью третьего шага является идентификация бизнес-функций, поддерживаемых или выполняемых приложениями. Здесь для каждого приложения формируется матрица приложения-функции, а также перечень функций, не поддерживаемых ни одним приложением (с объяснением причин), а также матрица приложения-организационные единицы. Целью четвертого шага является определение соответствия архитектуры приложений и существующими на предприятии приложениями. Здесь осуществляется сопоставление каждого приложения из архитектуры приложений и существующих систем, определенных в IRC, а также контроль полноты сопоставления (каждое существующее приложение из IRC должно быть соотнесено по крайней мере с одним из архитектурных приложений), строится таблица соответствий архитектуры приложений и существующих приложений. На пятом шаге производится подготовка, распространение и анализ отчета по архитектуре приложений. Формирование технической архитектурыЭтот этап определяет основные виды технологий, необходимых для обеспечения окружения приложений, управляющих данными. Техническая архитектура не является ни проектом сетевого оборудования и ПО, ни детальными требованиями к ним. Она только определяет виды технических платформ, поддерживающих бизнес. Основными шагами этапа являются:
Целью первого шага является формулирование общих принципов для технических платформ и идентификация потенциальных кандидатов в платформы. Цель второго шага — на основании сформулированных выше принципов определить стратегию распределения приложений и данных, технические платформы. Его основными результатами является распределение данных и приложений, конфигурация технических платформ, оценка концептуальной архитектуры. Основными задачами шага являются:
Цель третьего шага — обоснование технологических платформ путем их соотнесения с использующими бизнес-функциями, формирование таблицы платформы-приложения, таблицы платформы-бизнес-функции. На четвертом шаге производится подготовка, распространение и анализ отчета по технической архитектуре. Разработка плана реализацииЭтап включает следующие основные шаги:
Целью первого шага является установка приоритетов и формирование последовательности реализации приложений (например, приложения, порождающие данные, должны быть реализованы перед реализацией приложений, использующих эти данные). Его основными результатами служат: матрица приложение-сущности данных, список упорядоченных по приоритетам приложений, план модификации и/или замены существующих систем, группировка приложений в проекты, последовательность реализации технологии. Основными задачами этого шага являются:
Остальные шаги этапа традиционны для задачи планирования и здесь не рассматриваются. Заключительное планированиеНа этом этапе осуществляется подготовка окончательного отчета по ЕА, подготовка и проведение презентации. Переход к реализацииОсновными шагами этапа являются:
Все эти шаги являются достаточно традиционными и не представляют интереса в рамках настоящей статьи. |
Языки моделирования предприятий. К наиболее распространенными в настоящее время относятся языки IDEF, ARIS и BPML.
Основными недостатками IDEF являются:
- наличие всего трех типов моделей — функциональной, информационной и процессной, остальные аспекты архитектуры если и могут быть отображены, то на недостаточном уровне;
- отсутствие интеграции даже для перечисленных трех типов моделей (при этом отсутствует как концепция интеграции, так и какая-либо реализация даже на уровне инструментов одного и того же производителя).
ARIS в целом преодолевает перечисленные недостатки IDEF, однако его методология по сути является методологией-оболочкой: нет четко описанных регламентов действий, не предлагается уникального подхода к проблеме моделирования архитектуры предприятия. Сам язык включает более 100 типов моделей, 90% из которых практически никогда не используются, инструментальная поддержка осуществляется продуктом той же компании — разработчика методологии. Этот продукт имеет цену на порядок превышающую стоимость инструментов аналогичного класса для аналогичных платформ, и огромные трудозатраты на его разработку, что вряд ли позволит создать когда-либо конкурирующий инструментарий, поддерживающий данный язык.
BPML (Business Process Modeling Language) — специальный язык, ориентированный на моделирование бизнес-процессов, — является одной из последних разработок в данной области. Этот язык обеспечивает построение абстрактной исполняемой модели взаимодействующих процессов на основе концепции конечного автомата (машины конечных состояний). BPML представляет бизнес-процессы посредством объединения описания взаимодействий управляющих потоков, потоков данных и потоков событий с дополнительными ортогональными средствами моделирования бизнес-правил, ролей, контекста взаимодействия. Он поддерживает синхронные и асинхронные распределенные транзакции, поэтому может быть использован как исполняемая модель для встраивания существующих приложений в качестве процессных компонент внутрь е-бизнес-процессов.
Вторая проблема
Еще одна важная проблема заключается в том, что многие из перечисленных инструментов поддерживают аналогичные концепции (с различными названиями), которые трудно сравнивать из-за различного синтаксиса и семантики языков моделирования (часто точно не определенных). Собственный синтаксис и ограниченная семантика (ориентированная на поддерживающий инструментарий), различные графические нотации приводят к основной языковой проблеме — отсутствию интеграции моделей, разработанных на различных языках моделирования.
Решением данной проблемы занимается рабочая группа, целью деятельности которой является создание унифицированного языка моделирования UEML (Unified Enterprise Modeling Language) с четко определенными синтаксисом, семантикой и правилами взаимоотношений (отображений) между различными языками моделирования архитектуры предприятий. Проект UEML включает разработку:
- общего, визуального, базированного на шаблонах языка для коммерческих инструментальных средств моделирования предприятий и программных систем класса workflow;
- стандартизованных, независимых от инструментов механизмов передачи знаний (моделей) между проектами;
- репозитория моделей предприятий.
ЗАКЛЮЧЕНИЕ
Значение архитектуры предприятия постоянно увеличивается за счет обеспечения возможностей эффективного использования существующих и эволюционного перехода к новейшим технологиям. В некоторых странах правительственные директивы требуют, чтобы предприятия имели четко описанную архитектуру.
В среднем каждый из вендоров осуществляет продажи программного обеспечения на сумму от 7 до 15 млн. долларов в год (исключение составляет IDS Scheer: объявленный ею доход за 2002 г. составил 211 млн. долларов, он включает не только продажи ПО, но и консалтинг, обучение, выполнение проектов и т. п.).
По прогнозам ведущих консалтинговых компаний, через несколько лет архитектура превратится для предприятия в одно из главных средств управления изменениями, обеспечивая при этом:
- оказание помощи менеджерам при анализе потенциальных изменений и их реализации;
- предоставление основы для совместной работы бизнес-менеджеров и ИТ-менеджеров над целями, бизнес-процессами и выстраиванием предприятия в целом;
- предоставление единого хранилища всей информации о предприятии;
- обеспечение менеджерам поддержки в принятии решений — они могут обозревать отношения, задавать вопросы, идентифицировать проблемы,
- выполнять моделирование и т. д.
Фактически, создание архитектуры предприятия является первым шагом на пути к предприятию, которое может реагировать на изменения в реальном времени.
ЛИТЕРАТУРА
- Калянов Г. Н. Архитектура предприятия и инструменты ее моделирования // Автоматизация в промышленности. — 2004 — №7. — С. 9-12.
- Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. М.: — Горячая линия — Телеком. — 2004.
- Электронное правительство: рекомендации по внедрению в Российской Федерации. Под ред. В. И. Дрожжинова и Е. З. Зиндера. М.: ЭКО-ТРЕНДЗ. — 2004.
- Spewak S.H. Enterprise Architecture Planning. N.Y.: John Wiley&Sons Inc. — 2003.
Об авторе:
Калянов Георгий Николаевич — профессор, докт. техн. наук, заведующий лабораторией ИПУ РАН.
Искусственный интеллект: современный подход (AIMA-2) | |
Верховный алгоритм. Как машинное обучение изменит наш мир | |
Технологии. Используй их, чтобы реализовать свой потенциал |
Отзывы |
Евгений, exp00@bk.ru Спасибо за четкую систематизацию материала. Но Ваши наукоёмкие в одном месте «репозитария», а в другом «репозитория» или «рекрутинг, реинжениринг» или «сущности» приводят к закипанию. Зачем говорить: — «менеджеры в бизнес-кафе едят бизнес-ланч», вы прочтите, все что написали своей маме. Я был участником разработки математических моделей летательных аппартов для расследования летных происшествий. Участвовали множество смежников — ведущих НИИ и КБ(модель шасси разрабатывали ведущие ОКБ по шасси; работу автопилотов и авионики — моделировали ведущие аппаратные ОКБ и т.д.). Масса ТЗ, требований к входным и выходным данным, приемам борьбы с ошибками. Все блоки надо было согласовывать, испытывать и стыковать в один вычислительный комплекс. О сязи с полунатурными тренажерами я уже не говорю. Все проблемы, которые вы встретите через 10..12 лет мы решали в 75. 85-е годы. Даже выработаны ГОСТы к составу и содержанию документации и тд. и т.п. Например, модели содержали стохастические подходы как к моделированию внешней среды, так и к моделированию деятельности экипажа. Даже тогда мы поняли, что разработанные подходы могут быть применимы для управления любыми динамическими объектами, пусть это будет беспилотный ЛА, огибающий рельеф местности, атомный реактор или мануфактура. Давайте учиться вместе. С уважением — Е.В. |
МЕТОДОЛОГИЯ: Стратегия, Маркетинг, Изменения, Финансы, Персонал, Качество, ИТ АКТУАЛЬНО: Новости, События, Тенденції, Интервью, Бизнес-образование, Комментарии, Рецензії, Консалтинг СЕРВИСЫ: Бизнес-книги, Работа, Семинары, Форумы, Глоссарий, Цитаты, Рейтинги, Ресурсы, Статьи партнеров ПРОЕКТЫ: Блог, Видео, Визия, Визионеры, Бизнес-проза, Бизнес-юмор |
Copyright © 2001-2021, Management.com.ua
Портал создан и поддерживается Strategic
Подписка на Менеджмент.Дайджест
Получайте самые новые материалы на свой e-mail (1 раз в неделю)
Источник