- Системная интеграция как инструмент повышения эффективности бизнеса
- Цели и задачи системной интеграции
- Кому нужна системная интеграция?
- Кто может быть системным интегратором?
- Системная интеграция свой бизнес
- Определение системной интеграции
- Виды работ при системной интеграции
- Общие подходы к интеграции систем
- Ситуация 1. Нет интеграции между системами
- Ситуация 2. Вертикальная интеграция
- Ситуация 3. Интеграция «многие ко многим» (звезда, спагетти)
- Ситуация 4. Горизонтальная интеграция
- Ситуация 5. Отсутствие необходимости в интеграции
- Объекты и методы интеграции систем
- Интеграция платформ
- Интеграция приложений
- Интеграция бизнес-процессов
- Программные продукты для интеграции систем
- Microsoft BizTalk Server
- Microsoft SQL Server
- Oracle SOA Suite
Системная интеграция как инструмент повышения эффективности бизнеса
Понятие «системная интеграция» давно уже существует на рынке услуг и используется в разных отраслях народного хозяйства. Однако различные предприятия, да и сами системные интеграторы, вкладывают в этот термин зачастую совершенно разный смысл и понимают задачи и цели системной интеграции по-разному — от самой простой поставки оборудования до реализации «под ключ» какого-либо проекта. Необходимость интеграции особенно сильно чувствуется в отраслях, использующих последние научно-технические разработки и достижения.
Цели и задачи системной интеграции
Сначала понятие системной интеграции было просто модным словом. Но потом оно получило реальное наполнение и смысл. И актуальность этого понятия возрастает с каждым годом, по мере появления все новых и новых технологий. К тем отраслям, в которых системная интеграция играет большую роль, относятся, бесспорно, спутниковая связь и цифровое телерадиовещание. На самом деле сущность понятия «системная интеграция» можно определить, как совокупность знаний и комплекс мероприятий по созданию эффективного механизма реализации проектов с целью минимизации материально-временных затрат и максимизации получаемой прибыли. Другими словами, важно создать продукт, который будет приносить прибыль, а не убытки. В глобальном смысле можно сказать, что системная интеграция — это деятельность по решению бизнес-задач компании, работающей в области предоставления услуг связи или телевидения.
Кому нужна системная интеграция?
Иногда считают, что системная интеграция нужна только компаниям и корпорациям, имеющим крупные бизнес-процессы. Однако это не так. Как было сказано выше, системная интеграция — это совокупность знаний и навыков, а знаний много не бывает, и никому еще хорошие знания и навыки не навредили.
Хорошая теоретическая подготовка и практические навыки в любой области человеческой деятельности всегда были только на пользу. Поэтому системная интеграция ценна и полезна как маленьким предприятиям, так и большим корпорациям. И, как ни странно, для маленькой компании значение интеграции может быть важнее, чем для большой, потому что в случае чего у большой компании найдутся средства на исправление ошибки, а маленькая компания не имеет права на нее. Как правило, исправить ошибку стоит дороже, чем ее не допустить. Кроме того, системная интеграция нужна не только в начале какого-то проекта, как считают некоторые, она нужна на всех этапах деятельности компании. На каждом этапе системная интеграция решает свои задачи.
Рассмотрим задачи системной интеграции на двух наиболее характерных примерах: новая компания, созданная для реализации какого-либо проекта, и «старая» компания, уже работающая на рынке, имеющая свой бизнес, но также задумавшая реализовать новый проект или модернизировать и развить существующую инфраструктуру. Эти две задачи являются наиболее характерными случаями в работе любого системного интегратора.
В первом случае системному интегратору приходится решать ряд задач, которые на первый взгляд не имеют отношения к системной интеграции. Дело в том, что зачастую вновь создаваемые компании — потенциальные «операторы услуги» — до конца не представляют конечной цели разрабатываемого проекта и всех нюансов, связанных с реализацией своей услуги. В этом случае системному интегратору предстоит вместе со своим клиентом определить и понять, что же хочет заказчик, какую цель преследует, какие технологии собирается использовать и правильно ли он понимает свои возможности и возможности технологии. На этом этапе очень важно избавиться от ложных иллюзий, часто сопровождающих новые технологии. Как правило, это происходит из-за того, что заказчику удается найти очень мало достоверной информации о новой технологии и ее возможностях. Поэтому люди оперируют недостоверными данными, в основном, рекламного характера, которые распространены в средствах массовой информации и Интернете.
И дело даже не в том, что новая технология не обладает нужным функционалом, а в том, что на начальном этапе своего выхода на рынок не все заложенные функции сразу удается реализовать разработчикам оборудования. Опора на недостоверную информацию может привести к тому, что люди неверно поставят цель, которая не будет достигнута в ближайшие несколько лет, а может и вовсе остаться нереализованной. Вторым важным вопросом является нормативно-правовая ситуация в стране и отрасли, связанная с внедрением услуг, основанных на новых технологиях. Прежде всего — это вопросы сертификации оборудования и разрешительно-лицензионного характера,связанные с лицензированием деятельности, услуги или разрешением на использование частот. Системному интегратору приходится разъяснять и рассказывать заказчику о том, какая на данный момент существует процедура ввода в эксплуатацию объекта связи, какие документы предстоит собрать, каков порядок получения этих документов и т.д. А если компания планирует работать со старой, уже отработанной технологией? Это, конечно, упрощает ситуацию, но не намного, поскольку вопросы, связанные с правовой стороной, остаются и их приходится разъяснять клиенту и помогать их решить. После того как все эти и другие вопросы организационного плана будут улажены и выяснится, что нет существенных препятствий к внедрению новой услуги, наступает этап разработки схемного решения и подбор оборудования.
Вопросы, связанные с технической стороной проекта, такие как разработка функциональной схемы, выбор типа оборудования, его спецификация по опциям, выбор места установки оборудования и т.д. и т.п., безусловно, очень важны и сложны не менее, чем вопросы правового плана, но все-таки для новой компании они второстепенны. И для заказчика важно получить ответы на все эти вопросы из одного источника, и никто, кроме системного интегратора, не сможет дать на них комплексного ответа.
Если говорить о компании сложившейся, с налаженным бизнесом, то в этом случае задачи системной интеграции сводятся к другому кругу вопросов — в основном технического плана. При расширении своего бизнеса компании потребуется дооснастить свой технический парк новым оборудованием. И здесь на первый план выходит задача состыковать (проинтегрировать) существующее оборудование, которое может быть различным по срокам эксплуатации и маркам производителей с вновь поставляемым оборудованием. И сделать это надо так, чтобы не нарушить существующий ритм работы компании и не ухудшить налаженные сервисы. Для того чтобы это выполнить, необходимо обладать хорошими знаниями по функциональным особенностям различного оборудования и иметь практический опыт по его инсталляции.
Кто может быть системным интегратором?
Для того чтобы ответить на вопрос «Кто может быть системным интегратором?», сначала давайте посмотрим на те задачи, которые он должен решать. Не вдаваясь в подробности и кратко суммируя все вышесказанное, можно определить такой перечень работ:
- разработка концептуальных положений новых услуг связи или создаваемых в определенных условиях (разработка системного проекта);
- разработка технического задания на комплекс или систему;
- выбор технологии и разработка схемотехнических решений;
- выбор оборудования и определение необходимого набора опций;
- оказание помощи в решении организационно-правовых вопросов легализации услуг связи;
- разработка технического задания, написание рабочего проекта, прохождение экспертизы;
- поставка оборудования;
- выполнение подготовительных строительных работ для размещения оборудования;
- монтаж оборудования, пусконаладка и проведение испытаний;
- обучение персонала заказчика;
- участие в сдаче объекта связи в эксплуатацию;
- гарантийное и послегарантийное сопровождение.
Для того чтобы быть в состоянии выполнить все вышеперечисленное, естественно, надо обладать определенным набором знаний и навыков, материальными и человеческими ресурсами. Для того чтобы наработать все это, требуются время и постоянная работа в определенной области. Сегодня мало быть просто поставщиком оборудования, надо еще хорошо знать его возможности и уметь обучить других людей работать на нем. Лишь обладая глубокими знаниями в области технологий и оборудования, можно создавать системы и предлагать решения, которые потребуют не очень больших капитальных затрат и минимальных эксплуатационных расходов.
Лишь те компании, которые постоянно общаются с разработчиками оборудования и технологий, со специалистами профильных министерств и ведомств, сами разрабатывают решения и сами проводят инсталляцию оборудования, постоянно повышают уровень знаний своих специалистов благодаря посещению заводов и выставок, семинаров и тренингов, могут в полной мере обеспечить своих заказчиков всей необходимой информацией и предоставить весь комплекс услуг по реализации самого сложного проекта.
Компания ООО «НПО СвязьПроект» в полной мере отвечает всем вышеперечисленным требованиям. Сферой деятельности компании является строительство сетей спутниковой связи и сетей цифрового телерадиовещания, создание передвижных станций спутниковой связи (ПССС) различного назначения Drive Away и Fly Away. Компанией была создана технология производства ПССС под торговой маркой «Экспресс-Р» и на данный момент эти станции производятся в Москве в сжатые сроки, обеспечивая при этом профессиональный уровень качества и надежности.
Обладая штатом высококвалифицированных специалистов, имеющих опыт эксплуатации и создания систем различного назначения и сложности, компания «НПО СвязьПроект» всегда готова предложить своим клиентам оптимальное сочетание комплекта оборудования для решения их задач, какими бы сложными они не были.
Источник
Системная интеграция свой бизнес
в LinkedIn
на free-lance.ru
в ЖЖ
in english
В этой статье будет рассмотрена деятельность под названием «системная интеграция», которой занимаются ИТ-компании, именующие себя «системными интеграторами». Автор несколько лет работал менеджером проектов в одном из российских системных интеграторов, поэтому попытается описать это понятие «изнутри», четко определить его, рассмотреть виды системной интеграции, подходы к ее осуществлению.
Для начала мы опишем термин «системная интеграция», приведем различные определения. Затем рассмотрим его структуру с точки зрения видов работ, выполняемых в рамках системной интеграции: технический аспект, управленческий аспект и др. И, наконец, подробно остановимся на техническом аспекте – опишем виды, технологии системной интеграции, специализированные программные продукты.
Определение системной интеграции
Понятия «системная интеграция» и «системный интегратор» весьма емкие, под которые часто попадают виды деятельности и компании, которые не являются таковыми в классическом определении этих терминов.
При этом суть понятия «системная интеграция», в принципе, очевидна из самого термина – интеграция систем, т.е. выстраивание единого решения (системы) из отдельных компонентов (подсистем), увязывание между собой этих компонентов с целью придачи этой единой системе эмерджентных свойств – дополнительных преимуществ, получаемых за счет совместного использования подсистем, отсутствующих у каждой из подсистем в отдельности.
Простейший пример эмерджентности – уменьшение трудозатрат бухгалтеров в компании за счет информационного обмена между оперативной и бухгалтерской информационными системами по сравнению с использованием этих же подсистем без стыковки друг с другом, т.е. не в виде единой информационной системы.
Общим случаем системы, в рамках которой происходит интеграция подсистем, является единая информационная система компании (КИС, корпоративная информационная система). Подсистемами при этом являются:
Таким образом, системная интеграция заключается во внедрении компонентов информационной системы предприятия и увязывание их между собой (интеграция) в рамках единой КИС.
Полноценная системная интеграция является существенно более сложной деятельностью, чем внедрение отдельных систем и решений, т.к. отдельное решение направлено на решение ограниченного числа конкретных бизнес-задач. Например, внедрение CRM-системы обычно направлено на повышение лояльности клиентов компании. В то время как в рамках системной интеграции создается единая КИС, направленная на решение всего спектра бизнес-задач компании.
По этой причине принципиальным фактором, отличающим «многопрофильную ИТ-компанию» от «системного интегратора» является наличие в последней высококвалифицированных бизнес-консультантов, способных предложить заказчику комплексное ИТ-решение (КИС), направленное на достижение его бизнес-целей, и включающее в себя различные классы взаимосвязанных (интегрированных) систем и решений различных вендоров.
Не менее сложной задачей является технико-экономическое обоснование предлагаемых вариантов создания единой КИС.
Общее определение термина «системная интеграция».
Системная интеграция – объединение отдельных компонентов (подсистем) в одну систему и гарантия того, что подсистемы функционируют совместно как единая система. В информационных технологиях системная интеграция – процесс связывание между собой различных компьютерных систем и программных приложений физически или функционально при помощи специальных техник, таких как компьютерные сети, интеграция корпоративных приложений, управление бизнес-процессами, программирование и др. [http://en.wikipedia.org/wiki/System_integration]
Интересными являются определения этого термина самими компаниями системными интеграторами [http://www.miks.ru/search/25838.html]:
Виды работ при системной интеграции
Ранее было показано, что системная интеграция представляет из себя процесс создания единой информационной системы предприятия из отдельных компонентов.
«Правильная» КИС, реально решающая бизнес-задачи заказчика, может быть построена только в том случае, если системный интегратор, реализующий данный проект:
Достаточно крупный интеграционный проект, как правило, включает в себя следующие аспекты (уровни работ) и требует наличия следующих компетенций:
Из приведенного выше видно, что системная интеграция – существенно более сложная деятельность, чем то, что следует из ее определения. Однако, в настоящей работе мы остановимся подробнее лишь на техническом аспекте этого понятия. А именно на технологиях интеграции систем.
Общие подходы к интеграции систем
Интеграция систем в большинстве случаев – мера вынужденная, направленная на повышение эффективности бизнес-процессов компании, в которых используются информационные систем [http://citcity.ru/16663/]. Для того, чтобы продемонстрировать ценность интеграции информационных систем и наиболее распространенные подходы к интеграции рассмотрим последовательно несколько ситуаций.
Ситуация 1. Нет интеграции между системами
На схеме выше в компании используются три независимые информационные системы: «Складская система» (учет и анализ товародвижений на складе), «CRM-система» (учет и анализ продаж и других взаимоотношений с клиентами) и «Бухгалтерская система» (бухгалтерский учет и финансовый анализ). Между ними нет информационного обмена. Это приводит к тому, что менеджеры по продажам после выставления счетов клиентам вынуждены печатать их копии и нести в бухгалтерию. В бухгалтерии они регистрируются в бухгалтерской системе. Бухгалтерия регистрирует поступление денег на счет. Менеджеры по продажам, не имея возможность получить оплаты автоматически в CRM-систему вынуждены ежедневно осведомляться в бухгалтерии о поступлении денег от клиентов. Не лучше ситуация в работе склада. Здесь есть обширный документооборот с бухгалтерией, двойная регистрация действий (один раз в складской системе, второй раз в бухгалтерской) и менеджерами по продажам (получение от них распоряжений на отгрузку товара клиентам и информирование их о фактах отгрузки).
Если посчитать затраты оплачиваемого компанией времени сотрудников на выполнение дублирующихся процедур в разных системах (выделены красным на схеме), то может получиться ощутимая доля в общих издержках фирмы.
Ситуация 2. Вертикальная интеграция
На следующей схеме изображен подход, называемый «вертикальной интеграцией». В соответствии с этим подходом системы интегрируются по принципу функциональных экспертиз [2]. Например, в данном случае выделены две экспертизы: оперативный учет и бухгалтерской учет. При этом бухгалтерский учет находится по вертикали выше оперативного учета. В нашем примере подсистемы оперативного учета поставляют данные подсистеме бухгалтерского учета. Это позволяет существенно сократить трудозатраты на дублирующиеся и бумажные операции, однако, есть два отягчающих момента.
Во-первых, такую систему крайне трудно расширять функционально. Например, компания может захотеть создать подсистему-экспертизу «Аналитика», которая по вертикали будет расположена над экспертизой «Бухгалтерский учет». Эта экспертиза в значительной степени основана на данных «Оперативного учета». Поэтому, помимо собственно разработки подсистемы «Аналитика» придется дорабатывать подсистему «Бухгалтерский учет» для того, чтобы она получала и хранила для нее из «Оперативного учета» дополнительную информацию.
Во-вторых, остаются значительные возможности по интеграции в рамках одной функциональной экспертизы.
Ситуация 3. Интеграция «многие ко многим» (звезда, спагетти)
Интеграция «многие ко многим» не предполагает выделение слоев функциональных экспертиз. При этом подходе каждая из используемых в компании подсистем может при необходимости обращаться к функционалу любой другой подсистемы. С другой стороны каждая из подсистем может использоваться любой другой подсистемой. Такой тип отношений между элементами называется «многие ко многим». Также если подсистем немного, то схема отражающая связи между ними похожа на «звезду». А если систем много, то бесконечные их переплетения образуют «спагетти» [2].
В этом случаем имеем место с практически неограниченными возможностями интеграции подсистем между собой (естественно, если подсистемы технологически позволяют делать это, об этом ниже).
Но, с другой стороны, затраты на поддержку такой интеграционной схемы экспоненциально растут при увеличении числа интегрированных подсистем. Например, если в нашем случае потребуется изменить что-то в бухгалтерской подсистеме (допустим, изменить ее объектную модель), то это может привести к необходимости переработки все остальных подсистем использующих ее, т.к. вызовы старой объектной модели перестанут работать. Для трех взаимодействующих систем это может быт не так критично, а вот для тридцати весьма и весьма.
Ситуация 4. Горизонтальная интеграция
Данный подход заключается в использования специализированного «промежуточного» (middleware) ПО. Основная задача этого ПО заключается в хранении репозитория функционала корпоративных приложений, подключенных к ней и обеспечение возможности использования этих функций другими приложениями, также подключенными к этой шине. Взаимодействие между приложениями могут, например, происходить в форме обмена сообщениями или вызова опубликованных функций в виде вэб-сервисов. Подключение системы к шине состоит в создании специального адаптера для каждой системы. После этого «опубликованные» функции системы становятся доступными другим подключенным системам.
Например, CRM-система при подключении к шине публикует свои функции по работе с клиентской базой данных. Шина обеспечивает возможность их использования бухгалтерской и складской системами. В свою очередь CRM-система получает возможность с бухгалтерскими и складскими данными.
Преимуществом данного подхода является то, что сами системы могут произвольно меняться в рамках существующей спецификации опубликованных функций. При этом никаких изменений в других системах не требуется. Кроме того, подключение новой системы в достаточной степени стандартизировано и упрощено. Например, имеется возможность подключить новую систему «Аналитика», которая сразу получит доступ ко всем остальным подсистемам.
Ситуация 5. Отсутствие необходимости в интеграции
Безусловно, самая лучшая интеграция – это отсутствие необходимости в ней. Например, все представленные выше подсистемы могут быть реализованы в виде функциональных модулей одной ERP-системы какого-либо вендора. В этом случае необходимость в интеграции отпадает, т.к. система уже изначально единая, обеспечивающая гораздо большую связность между функциональными модулями чем любой из приведенных выше вариантов интеграции между различными системами.
Объекты и методы интеграции систем
Ранее при описании подходов к интеграции систем мы рассматривали каждую информационную систему как «неделимый» объект. Однако, информационная система представляет из себя совокупность нескольких компонентов, поэтому, говоря об интеграции информационных систем, правильнее говорить об интеграции составляющих их компонентов.
Обычно, информационная система содержит в себе следующие компоненты:
Поэтому, интеграция информационных систем заключается в интеграции одного или нескольких компонентов интегрируемых информационных систем (объектов интеграции):
Рассмотрим подробнее процесс и технологии интеграции на каждом из этих уровней.
Интеграция платформ
Целями интеграции платформ являются:
Существует несколько подходов, направленных на достижение этих целей. В рамках каждого из подходов существуют различные технологии [http://citcity.ru/10881/]:
Технологии удаленного вызова процедур (в широком смысле под процедурой понимается некоторая функциональность приложения) позволяют опубликовать процедуру и обеспечить возможность ее вызова (передачи входящих параметров и получения выходных результатов) для приложений, работающих на других платформах. Элементами таких технологий обычно являются: общий для всех платформ язык описания интерфейсов процедур (IDL, WSDL), «адаптер» (переходник) процедуры, который транслирует внешние вызовы во внутренние и передает результаты обратно (стабы) и менеджеры, отвечающие за доставку запросов и результатов между платформами в сети (брокеры). Примерами технологий удаленного вызова процедур являются: RPC, CORBA, DCOM, Web-сервисы.
Концепция программного обеспечения промежуточного слоя (framework, среда исполнения, виртуальная машина) состоит в разработке прикладного ПО не с использованием сервисов конкретной операционной системы (например, Windows API), а с использованием сервисов ПО промежуточного слоя. Разработчиками ПО промежуточного слоя создаются ее реализации под различные операционные системы, которые транслируют вызовы соответствующих функций фрэйворка в вызовы соответствующей операционной системы. Типичным примером является технология Java Runtime Environment. Приложения, разработанные для этой технологии работают на любых программно-аппаратных платформах (Windows, Linux и др.) без каких-либо доработок самих приложений. Аналогичные возможности предоставляет среда Microsoft .Net Framework.
Интересной и современной концепцией является «виртуализация». К интеграции платформ она имеет отношение постольку, поскольку позволяет существенно упростить использования различных платформ и, соответственно, использование систем, требующих для своего функционирования наличия конкретных платформ. Если без виртуализации возможно одновременное функционирование N операционных сред на N серверов, то применение технологий виртуализации позволяет обеспечить функционирование N операционных сред на M серверов. Если N > M – это позволяет сократить расходы на аппаратное обеспечение путем его более эффективного использования. Если N Универсальный доступ к данным
Технологии универсального доступа к данным позволяют обеспечить единообразный доступ к данным различных СУБД. Посредником для работы с конкретной СУБД в данном случае является драйвер для соответствующей СУБД. Например, один и тот же SQL-запрос на выборку данных «SELECT * FROM TTABLE» может быть использован на выборку данных из таблицы TTABLE, хранящейся в СУБД MS SQL Server, Oracle, IBM DB2 и др. Это позволяет абстрагироваться от специфики конкретных СУБД и легко осуществлять интеграцию данных, хранящихся в различных СУБД. Наиболее распространенные технологии этого класса: ODBC, JDBC.
Концепция хранилищ данных состоит в создании корпоративного хранилища данных. Хранилище данных – база данных, хранящая в себе данные, собираемые из баз данных различных информационных систем, для целей их дальнейшего анализа. Например, может быть создано единое хранилище данных компании, в которое собрана информация из бухгалтерской, оперативной системы, внешних систем партнеров компаний. Для создания хранилищ данных используются технологии (OLAP), отличные от технологий создания оперативных БД (OLTP). В основном это делается для повышения производительности выполнения сложных аналитических запросов по многим параметрам (многомерные запросы). Подходы к созданию и наполнению хранилищ данных отражены в парадигме ETL (extraction, transformation, loading = извлечение, преобразование и загрузка). Технологии и инструментальные средства анализа больших массивов данных с целью выявления закономерностей предметной области объединяются понятием «Data Mining». Термин для совокупности технологий хранилищ данных и инструментальных средств и – «Business Intelligence».
Интеграция приложений
Интеграция на уровне приложений подразумевает использование готовых функций приложений другими приложениями. Например, разрабатывая систему электронного документооборота, существует возможность использовать в рамках этой системы в качестве текстового редактора MS Word вместо того, чтобы разрабатывать свой собственный текстовый редактор. Или, например, ПО Call-центра, получив входящий звонок от клиента, имеет возможность обратиться к функции биллинговой системы по проверке баланса (на входе – номер телефона абонента, на выходе – его текущий баланс) и, в зависимости от состояния баланса соединить его с оператором или автоматически проинформировать о необходимости пополнить свой счет. При этом структура база данных биллинговой системы является ее внутренней информацией, публикуются конкретные функции, позволяющие другим системам работать с конкретными данными.
Стоит упомянуть следующие подходы к интеграции приложений:
Интерфейс прикладного программирования конкретной системы представляет из себя «опубликованный» функционал этой системы, который может быть использован извне. Функционал может публиковаться в виде набора функций (пример – Windows API) или в виде объектной модели (объекты со свойствами и методами, пример – объектные модели приложений Microsoft Office) [4].
В большинстве случае интеграция нескольких систем заключается в передаче информации между ними, например, в форме запрос-ответ. Если системы функционируют в гетерогенных распределенных средах, то принципиальное значение имеет обеспечение гарантированности, безопасности, управляемости доставки информации между приложениями. Эти и другие принципы реализуются в корпоративных системах обмена сообщениями. В данном случае речь идет об обмене сообщениями между приложениями, а не людьми, как, например, в случае E-mail или ICQ. Функциональность этих систем достаточно прозрачна – прием сообщения от одного приложения, транспортировка по заданным правилам и передача этого сообщения другому приложению. При этом может производиться шифрование сообщений (для невозможности прочтения данных в процессе транспортировки), цифровая подпись (для защиты от умышленного изменения данных во время пути сообщения), настройка подписки (для отправки одного сообщения сразу нескольким приложениям), определение метаданных для сообщений (для облегчения использования сообщений со сложной структурой содержимого) и др [http://en.wikipedia.org/wiki/Enterprise_service_bus].
Сервис-ориентированная архитектура (SOA) является современной и модной парадигмой. Она является логическим продолжением концепции Web-сервисов, которая состоит в публикации функциональных блоков какого-либо приложения в виде, позволяющем получить к ним доступ другим приложением через Web. Web (протокол HTTP) в данном случае привлекателен ввиду возможности его использования и, соответственно, использования опубликованных в Web приложений на любых программно-аппаратных платформах. Web-сервис – небольшая программная надстройка над функционалом приложения, преобразующая вызовы, получаемы через Web во внутренние вызовы функций приложения и возвращающая результаты обратно. Основными идеями SOA являются [http://en.wikipedia.org/wiki/Service-oriented_architecture]:
Понятно, что в данном случае создания новых приложений на основе существующих Web-сервисов будет существенно ниже, чем разработка приложений «с нуля» или обширная интеграция с другими системами.
Например, в компании (оператор связи) существует система Service Desk (техническая поддержка абонентов) и биллинговая система (тарификация услуг). Перед компанией стоит задача сделать новую систему «Личный кабинет абонента», в которой абонент мог бы через Интернет просмотреть состояние своего счета и сообщить о неисправности. Для этого компания вместо того, чтобы создавать «Личный кабинет» с собственной базой данных, синхронизируемой с БД биллинговой системы и системы Service Desk, использует готовые Web-сервисы «Карточка абонента» (опубликованный функционал биллинговой системы) и «Создать заявку в техподдержку» (опубликованный функционал системы Service Desk). Очевидно, что вся работа по новому приложению «Личный кабинет» состоит лишь в создании Web-интерфейса пользователя на сайте компании.
Также часто используется следующий подход – интеграция пользовательских интерфейсов. Например, для создания приложений «одного окна». Простейший пример – фреймы в вэб-странице. Внутри каждого фрэйма при этом содержится отдельное вэб-приложение. Благодаря фрэймам, все эти приложения отображаются на экране одновременно. Пользовательские интерфейсы вэб-приложений очень легко интегрируются, однако, существуют возможности интегрировать и «классические» пользовательские интерфейсы и их фрагменты (ActiveX).
Интеграция бизнес-процессов
Наиболее целостным подходом к интеграции систем является интеграции на уровне бизнес-процессов. В рамках интеграции бизнес-процессов происходит и интеграция приложений, и интеграция данных и, что не менее важно, людей, вовлеченных в этот бизнес-процесс. Интеграция на уровне бизнес-процессов является наиболее «естественной» для организаций, т.к. их деятельность состоит, прежде всего, именно из бизнес-процессов, а не приложений, баз данных и платформ.
Идеи, лежащие в основе интеграции бизнес-процессов, достаточно просты:
Некоторые примеры интегрирующего ПО рассмотрены ниже.
Программные продукты для интеграции систем
Существует большое количество программных продуктов для интеграции систем: коммерческий и бесплатных, с закрытыми исходниками и Open Source, дорогих и дешевых, с различной функциональностью, рассчитанных на различный масштаб бизнеса пользователей.
Можно выделить следующие классы продуктов для интеграции систем:
Серьезные продукты для интеграции корпоративных приложений от солидных вендоров включают в себя компоненты сразу нескольких классов из перечисленных выше. В настоящей работе мы ограничимся продуктами от трех вендоров: Microsoft, Oracle и IBM.
Microsoft BizTalk Server
BizTalk Server представляет собой программный продукт для интеграции приложений и бизнес-процессов. На схеме ниже показана архитектура BizTalk Server, основанная на идеологии обмена сообщениями между приложениями.
Центральной частью системы является механизм обмена сообщениями (Engine), который состоит из двух частей:
«Надстройки» над BizTalk Server Engine (Business Activity Monitoring и Services) предоставляют возможности управления бизнес-процессами в организации на основании информации, собираемой в процессе «общения» интегрированных приложений.
Реализованная в продукте идея заключается в регистрации некоторой необходимой информации (Tracking, задается при настройке правил обработки сообщений в Engine) для целей дальнейшего мониторинга бизнес-процессов. Например, можно описать бизнес-процесс продажи, включающий несколько стадий (заказ, оплата, отгрузка и т.п.). Далее при получении сообщения от соответствующей системы (POS, бухгалтерия, склад и т.п.), отражающего факт изменения стадии конкретной продажи, это регистрируется и становится доступным для просмотра текущего состояния и анализа исторических данных.
Также следует отметить, что Microsoft BizTalk Server позиционируется вендором как продукт для B2B-интеграции. Это означает, что интегрируемые бизнес-процессы и приложения не обязательно должны находиться в рамках одной компании, а могут затрагивать несколько взаимодействующих компании, например, в цепочке поставок. В этом случае каждая такая компания использует Microsoft BizTalk Server для интеграции внутренних процессов и приложений и взаимодействует с BizTalk-серверами других компаний для внешнего обмена [http://www.microsoft.com/rus/biztalk/].
Microsoft SQL Server
Общеизвестная СУБД Microsoft SQL Server является также примером платформы для интеграции данных. Функции интеграции реализуются в MS SQL Server следующими компонентами: Integration Services и Analysis Services.
Analysis Services поддерживает процесс интеграции данных на следующих этапах, а именно [8]:
Oracle SOA Suite
Данный продукт от Oracle похож по своей функциональности на BizTalk сервер от Microsoft. Он разработан на технологиях Java, поэтому может работать на различных платформах (Windows, Solaris, HP-UX, Linux).
Также, в отличие от BizTalk Server Oracle SOA Suite представляет из себя не один программный продукт, а набор относительно программных компонентов, некоторые из которых могут использоваться по отдельности [http://www.oracle.com/global/ru/ip/10g/as/bpel.html]:
Oracle SOA Suite входит в состав продуктов middleware, для которых вендор использует обобщающее название Oracle Fusion.
Источник