Современные подходы к построению корпоративных информационных систем Текст научной статьи по специальности «Компьютерные и информационные науки»

1НФОРМАЩИШ I ТЕЛЕКОМУН1КАЦ1ИН1 ТЕХНОЛОГIÏ

УДК 004.9:004.75 Ю.М. ЛИСЕЦКИЙ*

СОВРЕМЕННЫЕ ПОДХОДЫ К ПОСТРОЕНИЮ КОРПОРАТИВНЫХ ИНФОРМАЦИОННЫХ СИСТЕМ

*ДП «ЭС ЭНД ТИ УКРАИНА», г. Киев, Украина

Анотаця. Розглянуто гснуючг тдходи до побудови корпоративних гнформацШних систем. Вико-нано анал1з основних моделей опису 1Т-арх1тектури тдприемства як складног виробничог системи. Показана актуальмсть умверсал1зацИ' тдходу до побудови корпоративних тформацтних систем / розробки модел1, ¡нвар1антног до типу тдприемства.

Ключовi слова: корпоративна тформацтна система, складна виробнича система, тдхгд, модель, 1Т-архтектура, твар1анттсть.

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

Ключевые слова: корпоративная информационная система, сложная производственная система, подход, модель, ИТ-архитектура, инвариантность.

Abstract. The article considers existing approaches to building corporate information systems. The basic models of enterprise IT architecture as a complex production system are analyzed. There is demonstrated the relevance of universalization of approach to building corporate information systems and development of the model which is invariant to enterprise type.

Keywords: corporate information system, complex production systems, approach, model, IT architecture, invariance.

1. Введение

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

Традиционным подходом при формировании описания информационных систем являлось использование модели «жизненного цикла» (ЖЦ). Под моделью ЖЦ информационной системы понимается структура, которая определяет последовательность выполнения и взаимосвязь процессов, действий и задач в течение ЖЦ [3]. Структура ЖЦ информационной системы базируется на трех группах процессов:

• основные процессы (приобретение, поставка, разработка, эксплуатация, сопровождение);

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

• организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).

Создание информационных систем предполагает определенные этапы, которые определяются соответствующими стандартами, где приводится их полный перечень, причем в конкретных условиях построения эти этапы могут объединяться друг с другом или не выполняться. Это зависит от особенностей информационных систем, которые создаются, и от договоренности между разработчиком системы и ее заказчиком [4, 5].

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

Однако при построении информационных систем корпоративного уровня, которые используются для управлении СПС, такой подход уже не является достаточно эффективным, так как при формировании описания системы использование концепции ЖЦ предполагает на каждом этапе рассмотрение вопросов, связанных как с функциями системы, так и с данными. Поэтому в своих работах Джон Захман, вместо традиционного подхода, связанного с рассмотрением отдельных аспектов работы системы как бы в различные моменты времени, предложил использовать рассмотрение системы с различных перспектив [6]. Перспективы в частном случае могут соответствовать различному уровню использования КИС или управления предприятием, если речь идет об ИТ-архитектуре СПС.

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

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

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

В содержание этих столбцов входят:

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

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

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

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

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

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

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

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

• порядок следования столбцов несущественный;

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

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

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

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

Рис. 1. Модель Захмана

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

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

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

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

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

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

Более подробно модель Захмана, ее основные характеристики и применение рассмотрены в работах [8, 9].

3. Модель TOGAF

TOGAF - это аббревиатура от The Open Group Architecture Framework. Модель TOGAF принадлежит консорциуму The Open Group [9]. Представление архитектуры предприятия в модели TOGAF показано на рис. 2.

Как показано на рис. 2, в модели TOGAF архитектура предприятия подразделяется на четыре категории.

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

целей.

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

Архитектура данных - описывает структуру корпоративных хранилищ данных и процедуры доступа к ним.

Рис. 2. Модель TOGAF

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

Модель TOGAF позиционируется как «структура», однако наиболее важным ее компонентом является метод разработки архитектуры - Method of Architecture Development (ADM) .

В модели TOGAF архитектура предприятия рассматривается как континуум архитектур от максимально обобщенных до максимально специализированных. Этот континуум называется континуумом предприятия. Процесс создания конкретной архитектуры предприятия рассматривается как переход от общей архитектуры к специализированной. ADM в модели TOGAF представляет собой процесс осуществления такого перехода.

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

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

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

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

На рис. 3 показано соотношение между континуумом предприятия и ADM.

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

лью - Technical Reference Model (TRM) и базой стандартов информационных систем -Standards Information Base (SIB). TRM является рекомендуемым описанием общей ИТ-архитектуры. SIB представляет собой набор стандартов и псевдостандартов, которые консорциум The Open Group рекомендует использовать при построении ИТ-архитектуры.

Рис. 3. Континуум предприятия в модели TOGAF

В TOGAF техническая эталонная модель и информационная база стандартов рекомендуются к использованию, но не являются обязательными.

Достаточно часто модель TOGAF в значительной степени сводится к методике разработки архитектуры, высокоуровневое представление которой показано на рис. 4.

Этап: подготовительный

Структура и принципы

Этап: А

Архитектурное представление

Этап: Б

Архитектура бизнеса

Этап: В

Архитектуры информационных систем

Этап: Г

Технологическая архитектура

Этап: 3

Управление -архитектурными изменениями

Этап: Ж

Управление внедрением

Этап: Е

Планирование перехода

Этап: Д

Возможности и решения

Рис. 4. ADM в модели TOGAF

Как показано на рис. 4, методика разработки архитектуры в модели TOGAF состоит из восьми этапов.

В самой модели TOGAF определено девять этапов, каждый из которых разбит на несколько подэтапов:

• разработка описания базовой архитектуры данных;

• просмотр и проверка принципов, эталонных моделей, точек зрения и средств;

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

• выбор компонентов архитектуры данных;

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

• анализ качественных критериев (например, производительности, надежности, безопасности и целостности);

• завершение архитектуры данных;

• анализ контрольных точек и последствий;

• анализ различий.

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

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

4. Модель FEA

Большинство авторов описывают Federal Enterprise Architecture (FEA) как набор из пяти эталонных моделей [9]: модель бизнеса, модель обслуживания, модель компонентов, технологическая модель и модель данных (рис. 5).

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

FEA действительно включает эти пять моделей, однако, по мнению некоторых авторов [9], представляет собой нечто намного большее, чем просто набор эталонных моделей.

■о л Pe rfor ma nc e Ref ere nc e Mod el f PRM1 A

-1 О -1 3 ■Inputs, Outputs, and Outcomes L ■ Uniquely Taio-ed Performance Indicators n о 3

а — л го и □ —► Business Reference Modef (BRMl ■ Lines of Business ■ Agencies, Customer Partner В 3 a 3 rt i no

а fc Se rvi c e Co ti i r>o n ei it Referente Mod e 1 (SR M) Щ V*

(Р с (Л, Е ¿enfica Doners., Servirá Types ■B.isiness & Service Components £ > 7

л (Л (Л г О т ■ B.i:iness-foe used Data Standard Zation ■ Cross-Agency Information Exchanges n ST К rf

(Ъ 7 ■Service Component Irteraces, inteíoperabilit^ »Technologies Recommendations 7 t

Рис. 5. Модель FEA

Исчерпывающее описание методологии FEA должно включать следующие пункты.

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

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

• Процесс создания архитектуры предприятия.

• Процесс перехода от старой парадигмы (до создания архитектуры предприятия) к новой (после создания архитектуры предприятия).

• Таксономия для классификации активов, которые попадают в область действия архитектуры предприятия.

• Методика, позволяющая оценить успешность использования архитектуры предприятия для повышения ценности бизнеса.

С точки зрения FEA, архитектура предприятия состоит из отдельных сегментов. Эта идея была впервые изложена в FEAF - «Практическое руководство по FEA совета директоров по информационным технологиям», версия 1.0, февраль 2001 г. Сегмент представляет собой один из основных аспектов бизнеса, например, трудовые ресурсы. Сегменты подразделяются на два типа: базовые и служебные.

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

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

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

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

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

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

• Этап 1. Анализ архитектуры: формирование простого и лаконичного представления сегмента с привязкой к плану организации.

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

• Этап 3. Стратегия инвестиций и финансирование: рассмотрение способов финансирования проекта.

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

Структура FEA для оценки успеха в использовании архитектуры предприятия описана в документе «Структура оценки архитектуры предприятия по программе FEA 2.1», декабрь 2006 г. Эта структура применима и за пределами государственного сектора экономики. Рейтинги по категориям можно эффективно адаптировать ко многим предприятиям для оценки степени готовности их архитектуры.

5. Модель Gartner

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

^ Business Strategy

Environmental Trends

Рис. 6. Модель Gartner

Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней [10] (рис. 7):

• среда бизнес-взаимодействия (Business Relationship Grid);

• бизнес-процессы и стили бизнес-процессов;

• шаблоны;

• технологические строительные блоки (кирпичики - bricks).

В библиотеке компании Gartner можно

найти исследовательские материалы, посвященные архитектуре предприятия. Например, «Процесс создания архитектуры предприятия Gartner: развитие, 2005 г.» и «Структура архитектуры предприятия Gartner: развитие, 2005 г.». Однако эти документы содержат мало описательной информации и датированы концом 2005 г. Компания Gartner утверждает, что эти рекомендации носят вневременной характер, и продолжает их наращивать по мере необходимости [9]. После слияния компаний Gartner и Meta Group текущая методология Gartner не фиксировалась вплоть до апреля 2006 г.

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

Рис. 7. Уровни модели архитектуры Gartner

Компания Gartner уверена, что архитектура предприятия призвана объединить три группы профессионалов: владельцев бизнеса, ИТ-специалистов и специалистов по внедрению технологий. Если удалось объединить эти группы и сформировать у них единое представление о факторах, влияющих на ценность бизнеса, вы победили, если нет - проиграли. Успех оценивается чисто прагматически, например, по доходности бизнеса, а не по количеству отмеченных элементов в матрице процесса.

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

Архитектура предприятия, согласно представлению Gartner, связана со стратегией, а не с технической реализацией. Она направлена на достижение цели. Два самых важных вопроса, которыми задается компания Gartner: куда организация стремится и как она туда попадет.

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

5. Заключение

Таким образом, современные подходы к построению КИС основываются на использовании моделей Захмана, TOGAF, FEA и Gartner. В настоящее время в 90 % случаев используется один из четырех перечисленных выше подходов.

Рассмотренные модели существенно отличаются друг от друга как по целям, так и по подходам: модель Захмана по своей сути является структурой, TOGAF - процессом, FEA - почти методологией, Gartner - набором лучших мировых практик. Поэтому достаточно трудно выбрать одну из моделей, между которыми очень мало общего, для построения ИТ-архитектуры конкретного предприятия.

Так, в [9] приводится сравнение этих моделей по 12 критериям, где каждой модели присваивается оценка по каждому из критериев. Один из основных выводов, который можно сделать из результатов анализа и сравнения, заключается в том, что ни одна из моделей не является универсальной: у каждой есть свои преимущества и недостатки. Для выбора наиболее подходящей модели автор рекомендует применить смешанный подход, при котором в каждом случае создается собственная модель построения ИТ-архитектуры предприятия, состоящая из наиболее полезных для организации компонентов других моделей. Но при этом не указывает, каким образом и на основе каких критериев это можно сделать.

Поэтому проблема разработки универсального подхода к построению КИС, основой которого будет модель, инвариантная к типу СПС, является актуальной.

СПИСОК ЛИТЕРАТУРЫ

1. Автоматизация управления предприятием / В.В. Баронов, Г.Н. Калянов, Ю.И. Попов [и др.]. -М.: ИНФРА-М, 2000. - 239 с.

2. ISO/IEC 2382-1:1993. Information technology. - Vocabulary. - Part 1: Fundamental terms [Электронный ресурс]. - Режим доступа: https://www.iso.org/standard/7229.html.

3. Лисецький Ю.М. 1нформацшт системи i технологи в менеджмента монографiя / Лисецький Ю.М. - Кив: Логос, 2014. - 417 с.

4. ДСТУ 3918-99 (ISO/IEC 12207:1995) 1нформацшш технологи. Процеси життевого циклу програ-много забезпечення. - К.: Держстандарт Украши, 2002. - 49 с.

5. РД 50-34.698-90. Комплекс стандартов и руководящих документов на автоматизированные системы. Требования к содержанию документов. - М.: Изд-во стандартов, 1990. - 38 с.

6. Zachman J.A. A framework for information systems architecture / J.A. Zachman // IBM Syst. J. - 1987. - N 26, Vol. 3. - P. 276 - 292.

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

8. Черняк Л. Архитектура систем по Захману / Л. Черняк // Открытые системы. - 2001. - № 12. -С.28 - 29.

9. Сешнс Р. Сравнение четырех ведущих методологий построения архитектуры предприятия [Электронный ресурс] / Р. Сешнс. - Режим доступа: https://msdn.microsoft.com/ru-ru/library/ee914379.aspx.

10. Структура и модель описания ИТ-архитектуры Gartner [Электронный ресурс]. - Режим доступа: http://www.intuit.ru/studies/courses/995/ 152/lecture/4236?page=4.

Стаття над1йшла до редакцп 23.10.2017