 |
В общем виде под архитектурой предприятия (Enterprise Architecture, ЕА) понимается всестороннее и исчерпывающее описание всех ключевых элементов предприятия и межэлементных отношений [1-4].
Согласно 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 этапов (см. таблицу), определяющих состав и структуру слоев и элементов архитектуры, а также план ее проектирования, обеспечивающий реализацию как традиционных требований к архитектуре, так и специфических требований конкретного предприятия.
Эти этапы организованы в виде следующей четырехуровневой схемы:
- уровень 1 (исходная позиция) — выработка решений, которые необходимо принять для реализации соответствующей архитектуры предприятия, и определение состава необходимого для реализации инструментария;
- уровень 2 (анализ текущего состояния) — определение точки отсчета для преобразования существующей архитектуры в целевую, а также
формирование временного графика перехода;
- уровень 3 (планируемая перспектива) — определение технических деталей перспективной архитектуры (данные, приложения и технологии);
- уровень 4 — формирование плана реализации перспективной архитектуры.
Более подробно — см. врезку.
Цикл выстраивания архитектуры предприятия основными участниками процесса приведен на рис. 2. Отметим, что в состав рабочей группы должен входить выделенный относительно новый ролевой участник — архитектор, фактически являющийся постановщиком задач на архитектурные изменения на основании как изменившихся внешних условий, так и понимания недостатков существующего положения дел.
ИНСТРУМЕНТАРИЙ МОДЕЛИРОВАНИЯ ЕА
Требования к среде моделирования
Среда моделирования архитектуры предприятия должна включать следующие четыре компонента. Блок элементарных объектов предприятия:
- описания (представления) элементарных объектов (например, конкретного продукта/услуги, производимого на предприятии в настоящее время);
- средства, используемые для порождения таких представлений (т. е. данных по объектам) согласно определенным правилам (например, ERP, SCM, CRM, СУБД).
Блок моделей архитектуры предприятия:
- собственно модели различных видов (процессно-функциональные, информационные, ресурсные, организационные и другие), состоящие из элементов, абстрактно отображающих элементарные объекты;
- средства моделирования, обеспечивающие анализ, проектирование и использование моделей.
:Блок языков и методологий моделирования:
- общемодельные конструкции;
- процессы моделирования архитектуры;
- средства, поддерживающие процесс определения и модификации методологий и языков.
Блок языков мета-моделирования и мета-методологий, которые предназначены, соответственно, для описания концепции, синтаксиса и семантики языков моделирования, и методологий их применения, а также для описания процессов построения этих языков и методологий.
Существующие среды моделирования EA можно классифицировать следующим образом:
- универсальные интегрирующие среды (например, Zachman Framework, GERAM);
языки моделирования предприятий (например, IDEF, ARIS, BPML);
- программные среды моделирования (например, ARIS 6 Collaborative Suite, Popkin System Archi
tect, METIS);
- мета-модели и языки мета-моделирования (например, UML Profile for Business Process Definition, UEML).
Первая проблема
Следует отметить, что моделирование архитектуры предприятий является инженерной дисциплиной, требующей комбинированного использования программных сред, языков и методологий моделирования. Однако большинство из перечисленных инструментов фактически являются фрагментарными подходами, покрывающими лишь различные части описанных требований к среде моделирования 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-модели и состоит из сущностей данных, каждая из которых имеет атрибуты и отношения с другими сущностями.
Этап содержит четыре шага:
- формирование списка кандидатов в сущности (трудозатраты — 10%);
- определение сущностей, атрибутов и отношений (трудозатраты — 60%);
- сопоставление сущностей и бизнес-функций (трудозатраты — 20%);
- анализ результатов (трудозатраты — 10%).
Целью первого шага является идентификация всех потенциальных сущностей, необходимых для поддержки бизнеса. Здесь осуществляется распределение бизнес-модели по членам команды (в разрезе деятельностей и бизнес-процессов), подготовка каждым из участников списка кандидатов в сущности, формирование общего списка кандидатов.
Целью второго шага является создание стандартного определения и описания каждой сущности, обеспечение графической иллюстрации их взаимодействий. Здесь сущности определяются и документируются, осуществляется построение ER-модели, производится сопоставление файлов и БД из IRC с сущностями.
Целью третьего шага является сопоставление сущностей с бизнес-функциями и приложениями, результатами которого являются матрица сущности-функции и матрица сущности-приложения. При этом для каждой функции нижнего уровня детализации идентифицируется вид каждой из затрагиваемых ей сущностей (создается, изменяется, используется), а приложения сопоставляются с сущностями по входам, выходам, файлам и БД.
Целью четвертого шага является подготовка, распространение и анализ отчета по архитектуре данных.
Формирование архитектуры приложений
На этом этапе определяются основные виды приложений, необходимых для управления данными и поддержки бизнес-функций. Архитектура приложений не является ни системным проектом, ни детальными требованиями к системам. Она только определяет, какие приложения будут управлять данными, и снабжает соответствующей информацией исполнителей бизнес-функций.
Основными шагами этапа являются:
- формирование списка кандидатов в приложения (трудозатраты — 10%);
- определение приложений (трудозатраты — 50%);
- сопоставление приложений и функций (трудозатраты — 15%);
- анализ применимости существующих приложений (трудозатраты — 15%);
- анализ результатов (трудозатраты — 10%).
Целью первого шага является идентификация каждого из возможных приложений и формирование их списка, при этом особое внимание уделяется приложениям, которые могут улучшить бизнес или обеспечить конкурентные преимущества.
Цель второго шага — снабдить каждое приложение стандартным описанием (определением) и построить графическую схему архитектуры приложений. Основными задачами шага являются:
- распределение приложений между членами команды;
- определение каждого приложения (включая имя, номер, цель, общее описание и возможности, бизнес-преимущества);
- упрощение сложных приложений и ликвидация избыточности;
- выработка предварительных предложений по применимости имеющегося на рынке ПО и технологических платформ;
- построение схемы архитектуры приложений;
- оценка качества архитектуры приложений (понимаемость, полнота и состоятельность, прочность-устойчивость).
Целью третьего шага является идентификация бизнес-функций, поддерживаемых или выполняемых приложениями. Здесь для каждого приложения формируется матрица приложения-функции, а также перечень функций, не поддерживаемых ни одним приложением (с объяснением причин), а также матрица приложения-организационные единицы.
Целью четвертого шага является определение соответствия архитектуры приложений и существующими на предприятии приложениями. Здесь осуществляется сопоставление каждого приложения из архитектуры приложений и существующих систем, определенных в IRC, а также контроль полноты сопоставления (каждое существующее приложение из IRC должно быть соотнесено по крайней мере с одним из архитектурных приложений), строится таблица соответствий архитектуры приложений и существующих приложений.
На пятом шаге производится подготовка, распространение и анализ отчета по архитектуре приложений.
Формирование технической архитектуры
Этот этап определяет основные виды технологий, необходимых для обеспечения окружения приложений, управляющих данными. Техническая архитектура не является ни проектом сетевого оборудования и ПО, ни детальными требованиями к ним. Она только определяет виды технических платформ, поддерживающих бизнес.
Основными шагами этапа являются:
- идентификация технических принципов и платформ (трудозатраты — 15%);
- определение платформ и их распределение (трудозатраты — 50%);
- сопоставление платформ с приложениями и бизнес-функциями (трудозатраты — 20%);
- анализ результатов (трудозатраты — 15%).
Целью первого шага является формулирование общих принципов для технических платформ и идентификация потенциальных кандидатов в платформы.
Цель второго шага — на основании сформулированных выше принципов определить стратегию распределения приложений и данных, технические платформы. Его основными результатами является распределение данных и приложений, конфигурация технических платформ, оценка концептуальной архитектуры.
Основными задачами шага являются:
- определение мест размещения бизнес-функций;
- распределение данных и приложений;
- определение конфигурации технических платформ (рабочие станции, сеть, архитектура бизнес-систем);
- оценка концептуальной технический архитектуры.
Цель третьего шага — обоснование технологических платформ путем их соотнесения с использующими бизнес-функциями, формирование таблицы платформы-приложения, таблицы платформы-бизнес-функции.
На четвертом шаге производится подготовка, распространение и анализ отчета по технической архитектуре.
Разработка плана реализации
Этап включает следующие основные шаги:
- формирование последовательности реализации приложений;
- оценка трудозатрат и ресурсов, построение плана;
- оценка стоимости и достоинств плана;
- определение факторов успеха и рекомендаций по их достижению.
Целью первого шага является установка приоритетов и формирование последовательности реализации приложений (например, приложения, порождающие данные, должны быть реализованы перед реализацией приложений, использующих эти данные). Его основными результатами служат: матрица приложение-сущности данных, список упорядоченных по приоритетам приложений, план модификации и/или замены существующих систем, группировка приложений в проекты, последовательность реализации технологии. Основными задачами этого шага являются:
- сопоставление приложений и сущностей (на основе бизнес-функций);
- преобразование матрицы приложения-сущности к виду, позволяющему определить последовательность реализации, управляемую данными с помощью соответствующей оптимизационной процедуры (установление зависимости данных);
- формирование критериев (количественных и качественных) к последовательности реализации;
- формирование последовательности модификации существующих систем и приобретения технологий.
Остальные шаги этапа традиционны для задачи планирования и здесь не рассматриваются.
Заключительное планирование
На этом этапе осуществляется подготовка окончательного отчета по ЕА, подготовка и проведение презентации.
Переход к реализации
Основными шагами этапа являются:
- планирование перехода (спецификация целей перехода, формирование плана перехода, назначение ответственности за переход, определение руководителя-лидера);
- адаптация подхода (методологии, инструменты);
- наведение порядка с компьютерными ресурсами (приобретение необходимого, обеспечение надежности хранилища);
- чистка архитектуры (ревизия, добавление деталей и обновление);
- изменение организационно-штатной структуры;
- рекрутинг персонала;
- проведение обучения;
- введение стандартов на программирование;
- введение процедурных стандартов;
- разработка детальных планов по приложениям;
- определение и утверждение даты завершения перехода.
Все эти шаги являются достаточно традиционными и не представляют интереса в рамках настоящей статьи.
|
Языки моделирования предприятий. К наиболее распространенными в настоящее время относятся языки 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.
Об авторе:
Калянов Георгий Николаевич — профессор, докт. техн. наук, заведующий лабораторией ИПУ РАН.
|
|
