Несмотря на то что протоколы, связанные с эталонной моделью OSI, используются сейчас очень редко, сама модель до сих пор весьма актуальна, а свойства ее уровней, которые будут обсуждаться в этом разделе, очень важны. В эталонной модели TCP/IP все наоборот - сама модель сейчас почти не используется, а ее протоколы являются самыми распространенными. Исходя из этого, мы обсудим подробности, касающиеся обеих моделей.
Эталонная модель OSI
Эталонная модель OSI (за исключением физической среды) показана на рис. 1.16. Эта модель основана на разработке Международной организации по стандартизации (International Organization for Standardization, ISO) и является первым шагом к международной стандартизации протоколов, используемых на различных уровнях (Day и Zimmerman, 1983). Затем она была пересмотрена в 1995 году (Day, 1995). Называется эта структура эталонной моделью взаимодействия открытых систем ISO (ISO OSI (Open System Interconnection) Reference Model), поскольку она связывает открытые системы, то есть системы, открытые для связи с другими системами. Для краткости мы будем называть эту модель просто «модель OSI».
Модель OSI имеет семь уровней. Появление именно такой структуры было обусловлено следующими соображениями.
1. Уровень должен создаваться по мере необходимости отдельного уровня абстракции.
2. Каждый уровень должен выполнять строго определенную функцию.
3. Выбор функций для каждого уровня должен осуществляться с учетом создания стандартизированных международных протоколов.
4. Границы между уровнями должны выбираться так, чтобы поток данных между интерфейсами был минимальным.
5. Количество уровней должно быть достаточно большим, чтобы различные функции не объединялись в одном уровне без необходимости, но не слишком высоким, чтобы архитектура не становилась громоздкой.
Далее мы обсудим каждый уровень модели, начиная с самого нижнего. Обратите внимание: модель OSI не является сетевой архитектурой, поскольку она не описывает службы и протоколы, используемые на каждом уровне. Она просто определяет, что должен делать каждый уровень. Тем не менее ISO также разработала стандарты для каждого уровня, хотя эти стандарты не входят в саму эталонную модель. Каждый из них был опубликован как отдельный международный стандарт.
Физический уровень
Физический уровень занимается реальной передачей необработанных битов по каналу связи. При разработке сети необходимо убедиться, что когда одна сторона передает единицу, то принимающая сторона получает также единицу, а не ноль. Принципиальными вопросами здесь являются следующие: какое напряжение должно использоваться для отображения единицы, а какое - для нуля; сколько микросекунд длится бит; может ли передача производиться одновременно в двух направлениях; как устанавливается начальная связь и как она прекращается, когда обе стороны закончили свои задачи; из какого количества проводов должен состоять кабель и какова функция каждого провода. Вопросы разработки в основном связаны с механическими, электрическими и процедурными интерфейсами, а также с физическим носителем, лежащим ниже физического уровня.
Уровень передачи данных
Основная задача уровня передачи данных - быть способным передавать «сырые» данные физического уровня по надежной линии связи, свободной от необнаруженных ошибок с точки зрения вышестоящего сетевого уровня. Уровень выполняет эту задачу при помощи разбиения входных данных на кадры, обычный размер которых колеблется от нескольких сотен до нескольких тысяч байт. Кадры данных передаются последовательно с обработкой кадров подтверждения, отсылаемых обратно получателем.
Еще одна проблема, возникающая на уровне передачи данных (а также и на большей части более высоких уровней), - как не допустить ситуации, когда быстрый передатчик заваливает приемник данными. Должен быть предусмотрен некий механизм регуляции, который информировал бы передатчик о наличии свободного места в буфере приемника на текущий момент. Часто подобное управление объединяется с механизмом обработки ошибок.
В широковещательных сетях существует еще одна проблема уровня передачи данных: как управлять доступом к совместно используемому каналу. Эта проблема разрешается введением специального дополнительного подуровня уровня передачи данных - подуровня доступа к носителю.
Сетевой уровень
Сетевой уровень занимается управлением операциями подсети. Важнейшим моментом здесь является определение маршрутов пересылки пакетов от источника к пункту назначения. Маршруты могут быть жестко заданы в виде таблиц и редко меняться. Кроме того, они могут задаваться в начале каждого соединения, например терминальной сессии. Наконец, они могут быть в высокой степени динамическими, то есть вычисляемыми заново для каждого пакета с учетом текущей загруженности сети.
Если в подсети одновременно присутствует слишком большое количество пакетов, то они могут закрыть дорогу друг другу, образуя заторы в узких местах. Недопущение подобной закупорки также является задачей сетевого уровня. В более общем смысле сетевой уровень занимается предоставлением определенного уровня сервиса (это касается задержек, времени передачи, вопросов синхронизации).
При путешествии пакета из одной сети в другую также может возникнуть ряд проблем. Так, способ адресации, применяемый в одной сети, может отличаться от принятого в другой. Сеть может вообще отказаться принимать пакеты из-за того, что они слишком большого размера. Также могут различаться протоколы, и т. д. Именно сетевой уровень должен разрешать все эти проблемы, позволяя объединять разнородные сети.
В широковещательных сетях проблема маршрутизации очень проста, поэтому в них сетевой уровень очень примитивный или вообще отсутствует.
Транспортный уровень
Основная функция транспортного уровня - принять данные от сеансового уровня, разбить их при необходимости на небольшие части, передать их сетевому уровню и гарантировать, что эти части в правильном виде прибудут по назначению. Кроме того, все это должно быть сделано эффективно и таким образом, чтобы изолировать более высокие уровни от каких-либо изменений в аппаратной технологии.
Транспортный уровень также определяет тип сервиса, предоставляемого сеансовому уровню и, в конечном счете, пользователям сети. Наиболее популярной разновидностью транспортного соединения является защищенный от ошибок канал между двумя узлами, поставляющий сообщения или байты в том порядке, в каком они были отправлены. Однако транспортный уровень может предоставлять и другие типы сервисов, например пересылку отдельных сообщений без гарантии соблюдения порядка их доставки или одновременную отправку сообщения различным адресатам по принципу широковещания. Тип сервиса определяется при установке соединения. (Строго говоря, полностью защищенный от ошибок канал создать невозможно. Говорят лишь о таком канале, уровень ошибок в котором достаточно мал, чтобы ими можно было пренебречь на практике.)
Транспортный уровень является настоящим сквозным уровнем, то есть доставляющим сообщения от источника адресату. Другими словами, программа на машине-источнике поддерживает связь с подобной программой на другой машине при помощи заголовков сообщений и управляющих сообщений. На более низких уровнях для поддержки этого соединения устанавливаются соединения между всеми соседними машинами, через которые проходит маршрут сообщений.
Сеансовый уровень
Сеансовый уровень позволяет пользователям различных компьютеров устанавливать сеансы связи друг с другом. При этом предоставляются различные типы сервисов, среди которых управление диалогом (отслеживание очередности передачи данных), управление маркерами (предотвращение одновременного выполнения критичной операции несколькими системами) и синхронизация (установка служебных меток внутри длинных сообщений, позволяющих после устранения ошибки продолжить передачу с того места, на котором она оборвалась).
Уровень представления
В отличие от более низких уровней, задача которых - достоверная передача битов и байтов, уровень представления занимается по большей части синтаксисом и семантикой передаваемой информации. Чтобы было возможно общение компьютеров с различными представлениями данных, необходимо преобразовывать форматы данных друг в друга, передавая их по сети в неком стандартизированном виде. Уровень представления занимается этими преобразованиями, предоставляя возможность определения и изменения структур данных более высокого уровня (например, записей баз данных).
Прикладной уровень
Прикладной уровень содержит набор популярных протоколов, необходимых пользователям. Одним из наиболее распространенных является протокол передачи гипертекста HTTP (HyperText Transfer Protocol), который составляет основу технологии Всемирной Паутины. Когда браузер запрашивает веб-страницу, он передает ее имя (адрес) и рассчитывает на то, что сервер будет использовать HTTP. Сервер в ответ отсылает страницу. Другие прикладные протоколы используются для передачи файлов, электронной почты, сетевых рассылок.
Критика модели и протоколов OSI
Некоторое время назад, многим экспертам в данной области казалось, что модель OSI и ее протоколы завоюют весь мир и вытеснят все остальное. Этого не случилось. Почему? Может быть, полезно оглянуться и учесть некоторые из уроков этой истории. Основных причин неудачи модели OSI было четыре:
Несвоевременность;
Неудачная технология;
Неудачная реализация;
Неудачная политика.
Несвоевременность
Прежде всего рассмотрим причину номер один: несвоевременность. Для успеха стандарта чрезвычайно важно, в какое время он устанавливается. У Дэвида Кларка (David Clark) из M.I.T. есть теория стандартов, которую он называет апокалипсисом двух слонов.
На этом рисунке изображена активность, сопровождающая любую новую разработку. Открытие новой темы вначале вызывает всплеск исследовательской активности в виде дискуссий, статей и собраний. Через некоторое время наступает спад активности, эту тему открывают для себя корпорации, и в результате в нее инвестируются миллиарды долларов.
Существенным является то, что стандарты пишутся именно в период между двумя «слонами». Если их создавать слишком рано, прежде чем закончатся исследования, предмет может оказаться еще слишком мало изучен и понят, что повлечет принятие плохих стандартов. Если создавать их слишком поздно, компании могут успеть вложить деньги в несколько отличные от стандартов технологии, так что принятые стандарты могут оказаться проигнорированными. Если интервал между двумя пиками активности будет слишком коротким (а все стремятся делать деньги как можно быстрее), разработчики стандартов могут просто не успеть их выработать.
Теперь становится ясно, почему стандартные протоколы OSI потерпели неудачу. К моменту их появления среди исследовательских университетов уже получили широкое распространение конкурирующие с ними протоколы TCP/IP. И хотя волна инвестиций еще не обрушилась на данную область, рынок университетов был достаточно широк для того, чтобы многие разработчики стали осторожно предлагать продукты, поддерживающие протоколы TCP/IP. Когда же появился OSI, разработчики не захотели поддерживать второй стек протоколов; таким образом, начальных предложений не было. Каждая компания выжидала, пока первым начнет кто-нибудь другой, поэтому OSI так никто и не стал поддерживать.
Плохая технология
Второй причиной, по которой модель OSI не была реализована, оказалось несовершенство как самой модели, так и ее протоколов. Выбор семиуровневой структуры стал больше политическим решением, чем техническим. В результате два уровня (сеансовый и уровень представления) почти пусты, тогда как два других (сетевой и передачи данных) перегружены.
Эталонная модель OSI вместе с соответствующими определениями служб и протоколами оказалась невероятно сложной. Если сложить в стопку распечатку официального описания стандартов, получится кипа бумаги высотой в один метр. Модель тяжело реализуема и неэффективна в работе.
Еще одна проблема, помимо невозможности понять стандарты OSI, заключалась в том, что некоторые функции, такие как адресация, управление потоком и обработка ошибок, повторялись снова и снова в каждом уровне. Так, например, в книге Saltzer и др. (1984) указывается, что для того, чтобы контроль за ошибками был эффективным, он должен осуществляться на самом верхнем уровне, поэтому повторение его снова и снова на каждом уровне часто оказывается излишним и неэффективным.
Неудачная реализация
Учитывая огромную сложность модели и протоколов, громоздкость и медлительность первых реализаций не стали неожиданностью. Неудачу потерпели все, кто попытался реализовать эту модель. Поэтому вскоре понятие «OSI» стало ассоциироваться с плохим качеством. И хотя со временем продукты улучшились, ассоциации остались.
Первые реализации TCP/IP, основанные на Berkley UNIX, напротив, были достаточно хороши (не говоря уже о том, что они были открытыми). Они довольно быстро вошли в употребление, что привело к появлению большого сообщества пользователей. Это вызвало исправления и улучшения реализации, в результате чего сообщество пользователей еще выросло. В данном случае обратная связь явно была положительной.
Неудачная политика
Из-за особенностей первоначальной реализации многие, особенно в университетских кругах, считали TCP/IP частью системы UNIX. А к системе UNIX в университетских кругах в 80-е годы испытывали чувства, средние между родительскими (в те времена некорректно по отношению к правам мужского населения называемые материнскими) и чувствами к яблочному пирогу.
С другой стороны, OSI считался детищем европейских телекоммуникационных министерств, Европейского сообщества и (позднее) правительства США. Все это было лишь отчасти верным, однако сама мысль о группе правительственных чиновников, пытающихся протолкнуть неудачный в техническом отношении стандарт в глотки бедных исследователей и программистов, прокладывавших компьютерные сети в траншеях, не способствовала продвижению этой модели. Кое-кто рассматривал это развитие в том же свете, что и заявления корпорации IBM, сделанные в 1960 году, о том, что PL/I будет языком будущего, или Министерства обороны, поправлявшего позднее это утверждение своим заявлением, что в действительности таким языком будет Ada.
Несмотря на все недостатки, модель OSI (кроме сеансового уровня и уровня представления) показала себя исключительно полезной для теоретических дискуссий о компьютерных сетях. Протоколы OSI, напротив, не получили широкого распространения. Для TCP/IP верно обратное: модель практически не существует, тогда как протоколы чрезвычайно популярны.
Предлагаемая эталонная модель BPM (Business Process Management) основывается на цепочке следующих предпосылок:
Повышение производительности предприятия как сложной системы требует ее рационального построения, а процессное управление является наиболее современной концепцией для такого построения;
BPM (как дисциплина) предлагает системный подход к реализации процессного управления;
На каждом процессно-управляемом предприятии есть своя BPM-система - портфолио всех бизнес-процессов, а также методов и инструментов для руководства разработкой, исполнения и развития этого портфолио;
Гибкость BPM-системы предприятия является основным фактором ее успеха;
Специализированная программная платформа (BPM suite) для реализации BPM-системы предприятия необходима, но недостаточна, так как BPM занимает особое место в архитектуре предприятия.
Для управления своей производительностью большинство предприятий используют принцип обратной связи (рис. 1), позволяющий адаптироваться к внешней бизнес-экосистеме путем выполнения определенной последовательности действий:
Измерение хода исполнения производственно-хозяйственной деятельности (обычно такие измерения представлены в форме различных метрик или индикаторов, например, процент возвращающихся клиентов);
Вычленение из внешней бизнес-экосистемы важных для предприятия событий (например, законов или новых потребностей рынка);
Определение стратегии развития бизнеса предприятия;
Реализация принятых решений (путем внесения изменений в бизнес-систему предприятия).
В соответствии с классической рекомендацией Эдварда Деминга, автора многочисленных работ в области управления качеством, в том числе известной книги «Выход из кризиса», все усовершенствования должны проводиться циклично, непрерывно и с проверкой на каждом цикле. Степень и частота этих усовершенствований зависят от конкретной ситуации, но рекомендуется делать такие циклы достаточно компактными. Различные усовершенствования могут затрагивать различные аспекты работы предприятия. Вопрос в том, как предприятие может достигнуть наилучших результатов в каждом конкретном случае? Существуют две объективные предпосылки для оптимизации деятельности предприятия как единого целого:
Обеспечение руководства надлежащей информацией и инструментами для принятия решения;
Гарантия того, что бизнес-система предприятия способна к осуществлению необходимых изменений в необходимом темпе.
Наиболее современная концепция организации работы предприятия - процессное управление, при котором процессы и службы становятся явными.
Мир бизнеса давно понял (см. такие методики, как TQM, BPR, Six Sigma, Lean, ISO 9000, и др.), что службы и процессы - это основа функционирования большинства предприятий. Множество предприятий используют процессное управление для организации своей производственно-хозяйственной деятельности, как портфолио бизнес-процессов и методов управления ими.
Процессное управление, как управленческая концепция, постулирует целесообразность координации деятельности отдельных служб предприятия с целью получения определенного результата при помощи явно и формально определенных бизнес-процессов. При этом службы - это операционно независимые функциональные единицы; у предприятия может быть много элементарных нанослужб, которые организованы в мегаслужбу (собственно предприятие).
Использование явного определения координации позволяет формализовать взаимозависимости между службами. Наличие такой формализации дает возможность использовать различные методы (моделирование, автоматизированная проверка, контроль за версиями, автоматизированное выполнение и т.д.) для улучшения понимания бизнеса (для принятия более правильных решений) и повышения скорости развития бизнес-систем (для более быстрой реализации изменений).
Кроме процессов и служб, бизнес-системы предприятий работают с событиями, правилами, данными, индикаторами работы, ролями, документами и т.д.
Для реализации процессного управления предприятия используют три популярные дисциплины постоянного усовершенствования бизнес-процессов: ISO 9000, Six Sigma и «бережливое», или «экономное», производство (Lean production). Они воздействуют на различные области бизнес-системы предприятия, однако всегда предусматривается сбор данных о фактически проделанной работе и использование некой модели бизнес-процессов для принятия решений (хотя иногда эта модель находится только в чьей-то голове). В то же самое время они предлагают различные и взаимодополняющие методы для того, чтобы определить, какие именно изменения необходимы для улучшения функционирования бизнес-системы предприятия.
На рис. 2 приведена обобщенная модель процессно-управляемого предприятия.
В чем основная трудность оптимизации деятельности такого предприятия? Различные части бизнес-системы используют разные описания одного и того же бизнес-процесса. Обычно эти описания существуют отдельно и разработаны разными людьми, обновляются различными темпами, не обмениваются информацией, а некоторых из них просто нет в явном виде. Наличие единого описания бизнес-процессов предприятия позволяет устранить этот недостаток. Это описание должно быть явно и формально определено, чтобы одновременно служить моделью для моделирования, исполняемой программой и документацией, легко понимаемой всеми вовлеченными в бизнес-процесс сотрудниками.
Такое описание - основа дисциплины BPM, позволяющей моделировать, автоматизировать, выполнять, контролировать, измерять и оптимизировать потоки работ, охватывающие программные системы, сотрудников, клиентов и партнеров в пределах и вне границ предприятия. Дисциплина BPM рассматривает все операции с бизнес-процессами (моделирование, исполнение и т.п.) как единое целое (рис. 3).
На данный момент в индустрии BPM еще не сложилась надлежащая система стандартов на форматы формального описания бизнес-процессов. Три наиболее популярных формата: BPMN (Business Process Modelling Notation , графическое представление моделей бизнес-процессов), BPEL (Business Process Execution Language , формализация исполнения взаимодействия между Web-сервисами) и XPDL (XML Process Description Language, www.wfmc.org, спецификация по обмену моделями бизнес-процессов между различными приложениями) были разработаны различными группами и для различных целей и, к сожалению, адекватно не взаимодополняют друг друга.
Ситуация усугубляется тем, что за различными форматами стоят различные производители и каждый старается «протолкнуть» на рынок свое решение. Как это неоднократно повторялось, в подобной борьбе интересы конечного потребителя мало принимаются во внимание - сегодня нет достаточно мощной организации, представляющей интересы конечного потребителя BPM (по аналогии с группой стандартов для HTML , успех которой объясняется принятием всеми разработчиками Web-браузеров единого теста ACID3 для сравнения своих продуктов). Идеальной ситуацией в BPM было бы стандартное определение семантики исполнения для BPMN-подобного описания бизнес-процессов. Именно стандартная семантика исполнения гарантировала бы одинаковую интерпретацию бизнес-процессов любым ПО. Дополнительно такое описание должно позволять адаптацию степени описания бизнес-процессов для нужд конкретного потребителя (например, пользователь видит грубую диаграмму, аналитик - более подробную и т.п.).
Все это не означает, что BPEL или XPDL станут ненужными - их использование будет скрыто, как это происходит в сфере подготовки электронных документов. Один и тот же электронный документ может одновременно существовать в XML, PDF, PostScript и т.п., но только один основной формат (XML) используется для модификации документа.
Кроме процессов и служб, бизнес-системы предприятия работают с такими дополнительными артефактами, как:
события (events) - явления, происшедшие в пределах и вне границ предприятия, на которые возможна некая реакция бизнес-системы, например, при получении заказа от клиента необходимо начать бизнес-процесс обслуживания;
объекты (data and documents objects) - формальные информационные описания реальных вещей и людей, образующих бизнес; это информация на входе и выходе бизнес-процесса, например, бизнес-процесс обслуживания заказа получает на входе собственно формуляр заказа и информацию о клиенте, а на выходе формирует отчет о выполнении заказа;
деятельности (activities) - мелкие работы, преобразующие объекты, например автоматические деятельности типа проверки кредитной карты клиента или деятельности, осуществляемые человеком, такие как визирование документа руководством;
правила (rules) - ограничения и условия, при которых функционирует предприятие, например, выдача кредита на определенную сумму должна утверждаться генеральным директором банка;
роли (roles) - понятия, представляющие соответствующие навыки или обязанности, требуемые для выполнения определенных действий, например, только менеджер высшего звена может подписать конкретный документ;
аудиторские следы (audit trails) - информация о выполнении конкретного бизнес-процесса, например, кто сделал, что и с каким результатом;
основные индикаторы производительности (Key Performance Indicator, KPI) - ограниченное число показателей, измеряющих степень достижения поставленных целей.
Рис. 4 иллюстрирует распределение артефактов между различными частями бизнес-системы предприятия. Выражение «процессы (как шаблоны)» означает абстрактные описания (модели или планы) процессов;
выражение «процессы (как экземпляры)» означает фактические результаты выполнения этих шаблонов. Обычно шаблон используется для создания многих экземпляров (подобно незаполненному бланку, который многократно копируется для заполнения разными людьми). Выражение «службы (как интерфейсы)» означает формальные описания служб, которые доступны для их потребителей; выражение «службы (как программы)» означает средства выполнения служб - такие средства обеспечиваются поставщиками служб.
Для успешной работы со всей сложной совокупностью взаимозависимых артефактов у любого процессно-управляемого предприятия есть своя собственная BPM-система - это портфолио всех бизнес-процессов предприятия, а также методов и инструментов для руководства разработкой, исполнения и развития этого портфолио. Другими словами, BPM-система предприятия ответственна за синергетическое функционирование различных частей бизнес-системы предприятия.
BPM-система, как правило, не идеальна (например, некоторые процессы могут существовать лишь на бумаге, а некоторые детали «живут» только в умах определенных людей), но она существует. Например, любую реализацию ISO 9000 можно рассматривать как пример BPM-системы.
Улучшение BPM-системы предприятия, помимо чисто технических аспектов, должно учитывать социо-технические вопросы. У BPM-системы предприятия есть много заинтересованных лиц, каждое из которых решает свои задачи, воспринимает BPM-дисциплину своим образом и работает со своими артефактами. Для успешного развития BPM-системы предприятия необходимо обратить особое внимание на проблемы всех заинтересованных лиц и заранее объяснить им, как улучшение BPM-системы предприятия изменит их работу к лучшему. Крайне важно достигнуть единого понимания всех артефактов среди всех заинтересованных лиц.
Растущая популярность и большой потенциал BPM вызвали появление нового класса корпоративного ПО - BPM suite, или BPMS, содержащего следующие типичные компоненты (рис. 5):
Инструмент моделирования (Process modelling tool) - графическая программа для манипулирования такими артефактами, как события, правила, процессы, активности, службы и т.д.;
Инструмент тестирования (Process testing tool) - среда функционального тестирования, которое позволяет «исполнять» процесс по различным сценариям;
Хранилище шаблонов (Process template repository) - база данных шаблонов бизнес-процессов с поддержкой различных версий одного и того же шаблона;
Исполнитель процессов (Process execution engine);
Хранилище экземпляров (Process instance repository) - база данных для выполняемых и уже выполненных экземпляров бизнес-процессов;
Список работ (Work list) - интерфейс между BPM suite и пользователем, выполняющим некоторые активности в рамках одного или нескольких бизнес-процессов;
Приборная панель (Dashboard) - интерфейс оперативного контроля за исполнением бизнес-процессов;
Инструмент анализа (Process analysis tool) - среда для изучения тенденции исполнения бизнес-процессов;
Инструмент имитационного моделирования (Process simulation tool) - среда для тестирования производительности бизнес-процессов.
Необходимость взаимодействия между BPM suite и корпоративным ПО, которое поддерживает другие артефакты, вызвала появление нового класса корпоративного ПО - Business Process Platform (BPP). Типичные технологии BPP (рис. 6):
Business Event Management (BEM) - анализ бизнес-событий в режиме реального времени и запуск соответствующих бизнес-процессов (BEM связан с Complex Event Processing (CEP) и Event Driven Architecture (EDA));
Business Rules Management (BRM) - явное и формальное кодирование бизнес-правил, которые могут модифицироваться пользователями;
Master Data Management (MDM) - упрощение работы со структурированными данными за счет устранения хаоса при использовании одних и тех же данных;
Enterprise Content Management (ECM) - управление корпоративной информацией, предназначенной для человека (обобщение понятия документ);
Configuration Management Data Base (CMDB) - централизованное описание всей информационно-вычислительной среды предприятия, используемое для привязки BPM к информационно-вычислительным ресурсам предприятия;
Role-Based Access Control (RBAC) - управления доступом к информации с целью эффективного разделения контрольных и исполнительских полномочий (separation of duty);
Business Activity Monitoring (BAM) - оперативный контроль функционирования предприятия;
Business Intelligence (BI) - анализ характеристик и тенденций работы предприятия;
Service-Oriented Architecture (SOA) - архитектурный стиль для построения сложных программных систем в виде набора универсально доступных и взаимозависимых служб, который используется для реализации, выполнения и управления службами;
Enterprise Service Bus (ESB) - среда коммуникаций между службами в рамках SOA.
Таким образом, дисциплина BPM способна обеспечить единое, формальное и выполнимое описание бизнес-процессов, которое может использоваться в различных инструментах BPM suite, причем реальные данные собираются во время выполнения бизнес-процессов. Вместе с тем высокая гибкость BPM-системы предприятия не гарантируется автоматически после покупки BPM suite или BPP - способность конкретной BPM-системы развиться в необходимом темпе должна проектироваться, реализовываться и постоянно контролироваться. Как и здоровье человека, все это нельзя купить.
Необходимость вовлечения практически всего корпоративного ПО в единую логику улучшения BPM-системы предприятия поднимает вопрос о роли и месте BPM в архитектуре предприятия (Enterprise Architecture, EA). EA является на сегодня устоявшейся практикой ИТ-департаментов по упорядочению информационно-вычислительной среды предприятия. В основе EA лежат следующие правила:
Текущая ситуация с информационно-вычислительной средой предприятия тщательно документируется как исходная точка as-is;
Желаемая ситуация документируется как конечная точка to-be;
Строится и исполняется долгосрочный план по переводу информационно-вычислительной среды предприятия из одной точки в другую.
Все это, казалась бы, вполне разумно, но сразу видна разница с подходом, предусматривающим небольшие улучшения, который лежит в основе процессного управления. Как совместить эти два противоположных подхода?
Дисциплина BPM может решить основную проблему EA - дать объективную оценку производственно-хозяйственных возможностей (а не только информационно-вычислительных) того, что будет в точке to-be. Несмотря на то что EA описывает полную номенклатуру артефактов предприятия (его генотип), она не может достоверно сказать, какие изменения в этом генотипе влияют на конкретные производственно-хозяйственные характеристики предприятия, то есть на фенотип предприятия (cовокупность характеристик, присущих индивиду на определенной стадии развития).
Со своей стороны, дисциплина BPM структурирует взаимозависимости между артефактами в виде явных и исполняемых моделей (бизнес-процесс - это пример взаимозависимости между такими артефактами, как события, роли, правила и т.п.). Наличие таких исполняемых моделей позволяет с некоторой степенью достоверности оценить производственно-хозяйственные характеристики предприятия при изменении генотипа предприятия.
Естественно, чем больше взаимозависимостей между артефактами смоделировано и чем достовернее эти модели, тем точнее такие оценки. Потенциально симбиоз номенклатуры артефактов предприятия и формально определенных взаимозависимостей между ними дает исполняемую модель предприятия на конкретный момент времени. Если строить такие исполняемые модели на единых принципах (например, krislawrence.com), то появляется возможность для сравнения эффекта от применения различных стратегий развития предприятия и появления более систематических и предсказуемых технологий по преобразованию одних исполняемых моделей в другие.
В некотором смысле комбинация EA+BPM может стать своего рода навигатором, который обеспечивает руководство и практическую помощь в развитии бизнеса и ИТ при реализации генеральной линии предприятия.
Не секрет, что сегодня производители ПО определяют и развивают BPM по-разному. Однако, более перспективный путь развития BPM - это BPM, ориентированный на нужды конечных потребителей, и эталонная модель BPM - первый шаг по созданию единого понимания BPM среди всех заинтересованных лиц.
Предлагаемая в статье эталонная модель основана на практическом опыте автора по проектированию, разработке и сопровождению различных корпоративных решений. В частности, эта модель использовалась для автоматизации ежегодного производства более 3 тыс. сложных электронных продуктов со средним временем подготовки продукта в несколько лет. В результате обслуживание и развитие этой производственной системы потребовали в несколько раз меньше ресурсов, чем при традиционном подходе. n
Александр Самарин ([email protected]) - корпоративный архитектор ИТ-департамента правительства кантона Женева (Швейцария).
Process Frameworks для BPM
Подход к реализации технологий управления бизнес-процессами, упрощающий внедрение BPM-систем, подразумевает четкое определение бизнес-задачи и соответствующих ей бизнес-процессов; реализацию этих процессов за срок не более трех месяцев с целью демонстрации ценности данного подхода; дальнейшее расширение реализации на основные бизнес-задачи. Однако главная трудность на этом пути - недопонимание и отсутствие согласованности между бизнес- и ИТ-подразделениями. Значительно упростить проект внедрения и сократить затраты позволяют специализированные референсные модели (Process Frameworks).
Референсная модель - пакет аналитических и программных ресурсов, состоящий из описания и рекомендаций по организации высокоуровневой структуры бизнес-процесса, набора атрибутов и метрик оценки эффективности выполнения, а также программных модулей, созданных для быстрого построения прототипа бизнес-процесса для последующей его адаптации под специфику конкретной компании.
Референсные модели помогают в определении и установке требований и позволяют наладить бизнес-процессы, они основаны на отраслевых стандартах и включают в себя отраслевой опыт. Для типовых процессов референсные модели способны помочь при выборе и моделировании основных последовательностей работы, определении ключевых показателей эффективности (КPI) и параметров, позволяющих оценить результативность в ключевых областях, а также при управлении деятельностью и решением задач, анализе исходных причин и обработке исключительных случаев.
В структуру типичной референсной модели входят: рекомендации и описание предметной области; элементы композитных пользовательский интерфейсов (экранные формы и логически связные в цепочки портлеты); оболочки сервисов для быстрой реализации доступа к бизнес данным; примеры типовых бизнес-правил; ключевые показатели эффективности и элементы для их анализа; исполняемые модели процессов; модели данных и атрибуты процесса; адаптации к законодательной базе и специфике бизнеса в конкретной стране; рекомендации по этапам развертывания и реализации процессов. Такой набор ресурсов позволят быстрее адаптироваться к реализации процессного подхода в рамках конкретной системы управления бизнес-процессами, сократить время итераций цикла разработки, тестового исполнения и анализа процессов. При этом достигается максимальное соответствие технической реализации и существующей бизнес-задачи.
Однако, как отмечают аналитики AMR Research, «технологии и методы сами по себе не способны обеспечить каких-либо преимуществ - «больше» не всегда значит «лучше». Некоторые компании применяют множество различных решений, однако эффективность от этого только падает. Важна грамотность применения таких технологий». В референсных моделях в качестве основы используются принятые в отрасли стандарты и опыт компании Software AG по созданию эталонной модели для определения требований клиентов. На практике эта модель становится отправной точкой, с помощью которой клиенты могут создать нужную модель.
Process Framework, например, для бизнес-процесса обработки заказов, включает в себя базовую модель процесса со схемами действий для различных пользователей и ролей, избранные KPI из модели SCOR (The Supply-Chain Operations Reference-model) для процесса в целом и отдельных этапов, правила поддержки разных последовательностей обработки, например с учетом сегмента клиентов, целевые показатели для различных сегментов клиентов, типов продукции и регионов, а также панели индикации, помогающие контролировать особые ситуации.
Process Framework позволяет акцентировать внимание на необходимости и возможности коррекции KPI для конкретных групп клиентов и их конфигурирования с учетом появления новых товаров, выхода на новые регионы или сегменты рынка. Подобная информация позволит руководителям, отвечающим за цепочки поставок, торговые операции, логистику и производство, улучшить контроль над конкретной деятельностью, а руководителям ИТ-отделов быстро оценить реальную работоспособность ИТ-систем, поддерживающих обработку заказов.
Владимир Аленцев ([email protected]) - консультант по BPM и SOA , представительство Software AG в России и СНГ (Москва).
Эталонная модель
Эталонная модель (англ. reference model , master model ) - это абстрактное представление понятий и отношений между ними в некоторой проблемной области. На основе эталонной строятся более конкретные и детально описанные модели, в итоге воплощённые в реально существующие объекты и механизмы. Понятие эталонной модели используется в информатике .
Wikimedia Foundation . 2010 .
эталонная модель - иерархическая модель — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом Синонимы иерархическая модель EN reference model …
эталонная модель - etaloninis modelis statusas T sritis automatika atitikmenys: angl. master model; reference model vok. Referenzmodell, n rus. эталонная модель, f pranc. modèle de référence, m; modèle standard, m … Automatikos terminų žodynas
эталонная модель - 3.1.41 эталонная модель (reference model): Структурированный комплект взаимосвязанных представлений об объекте (например информационной системе), охватывающий данный объект в целом, упрощающий разбиение связей по тематике, который может быть… … Словарь-справочник терминов нормативно-технической документации
эталонная модель ВОС - Модель взаимодействия открытых систем, разработанная ISO в 1984 г. Позволяет универсальным образом описать логику информационного обмена между взаимосвязанными системами и абонентами. Полная модель содержит семь уровней. На самом нижнем… … Справочник технического переводчика
эталонная модель ISO/OSI - Семиуровневая эталонная модель протоколов передачи данных. Определяет уровни: физический, канальный, сетевой, транспортный, сеансовый, представительский и прикладной. В CAN сетях обычно реализуются только физический, канальный и прикладной уровни … Справочник технического переводчика
эталонная модель протоколов широкополосной ISDN-сети - Модель включает четыре горизонтальных уровня (физический, ATM, адаптации ATM и верхние уровни) и три вертикальных плоскости (пользователя, управления и администрирования). Соответствие между моделями В ISDN и OSI обеспечивается на физическом… … Справочник технического переводчика
эталонная модель BOC - ЭМВОС Модель, разработанная МОС, содержащая семь уровней (слоев) протоколов и предназначенная для коммуникации между устройствами в сети. [Е.С.Алексеев, А.А.Мячев. Англо русский толковый словарь по системотехнике ЭВМ. Москва 1993] Тематики… … Справочник технического переводчика
эталонная модель взаимодействия открытых систем - — Тематики электросвязь, основные понятия EN ISO/OSI reference model … Справочник технического переводчика
эталонная модель протокола - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN protocol reference modulePRM … Справочник технического переводчика
эталонная модель соединения открытых систем - — [Л.Г.Суменко. Англо русский словарь по информационным технологиям. М.: ГП ЦНИИС, 2003.] Тематики информационные технологии в целом EN reference model of open systems … Справочник технического переводчика
Сетевая модель OSI — это эталонная модель взаимодействия открытых систем, на английском звучит как Open Systems Interconnection Basic Reference Model. Ее назначение в обобщенном представлении средств сетевого взаимодействия.
То есть модель OSI — то обобщенные стандарты для разработчиков программ, благодаря которым любой компьютер одинаково может расшифровать данные, переданные с другого компьютера. Чтобы было понятно, приведу жизненный пример. Известно, что пчелы видят все окружающее их в утрафиалетовом свете. То есть одну и ту же картинку наш глаз и пчелиный воспринимает абсолютно по-разному и то, что видят насекомые, может быть незаметно для зрения человека.
То же самое и с компьютерами — если один разработчик пишет приложение на каком-либо программном языке, который понимает его собственный компьютер, но не доступен ни для одного другого, то на любом другом устройстве вы прочитать созданный этим приложением документ не сможете. Поэтому пришли к такой идее, чтобы при написании приложений следовать единому своду правил, понятному для всех.
Для наглядности процесс работы сети принято разделять на 7 уровней , на каждом из которых работает своя группа протоколов.
Сетевой протокол
— это правила и технические процедуры, позволяющие компьютерам, объединенным в сеть, осуществлять соединение и обмен данными.
Группа протоколов, объединенных единой конечной целью, называется стек протоколов.
Для выполнения разных задач имеется несколько протоколов, которые занимаются обслуживанием систем, например, стек TCP/IP. Давайте здесь внимательно посмотрим на то, каким образом информация с одного компьютера отправляется по локальной сети на другой комп.
Для того, чтобы верно произвести все эти операции и нужен единый свод правил, то есть эталонная модель OSI.
Вернемся у к уровням OSI. Их принято отсчитывать в обратном порядке и в верхней части таблицы располагаются сетевые приложения, а в нижней — физическая среда передачи информации. По мере того, как данные от компьютера спускаются вниз непосредственно к сетевому кабелю, протоколы, работающие на разных уровнях, постепенно их преобразовывают, подготавливая к физической передаче.
Разберем их подробнее.
Его задача забрать у сетевого приложения данные и отправить на 6 уровень.
Переводит эти данные на единый универсальный язык. Дело в том, что каждый компьютерный процессор имеет собственный формат обработки данных, но в сеть они должны попасть в 1 универсальном формате — именно этим и занимается уровень представления.
У него много задач.
Обеспечивает приложениям необходимую степень защиты при доставке сообщений. Имеется две группы протоколов:
Обеспечивает сквозную передачу пакета, рассчитывая его маршрут. На этом уровне в пакетах ко всей предыдущей динформации, сформированной другими уровнями, добавляются IP адреса отправителя и получателя. Именно с этого момент пакет данных называется собственно ПАКЕТОМ, у которого есть >>IP адреса (IP протокол — это протокол межсетевого взаимодействия).
Здесь происходит передача пакета в пределах одного кабеля, то есть одной локальной сети. Он работает только до пограничного маршрутизатора одной локальной сети. К полученному пакету канальный уровень добавляет свой заголовок — MAC адреса отправителя и получателя и в таком виде блок данных уже называется КАДРОМ.
При передачи за пределы одной локальной сети пакету присваивается MAC не хоста (компьютера), а маршрутизатора другой сети. Отсюда как раз появляется вопрос серых и белых IP, о которых шла речб в статье, на которую была выше дана ссылка. Серый — это адрес внутри одной локальной сети, который не используетс яза ее пределами. Белый — уникальный адрес во всем глобальном интернете.
При поступлении пакета на пограничный роутер IP пакета подменяется на IP этого роутера и вся локальная сеть выходит в глобальную, то есть интернет, под одним единственным IP адресом. Если адрес белый, то часть данных с IP адресом не изменяется.
Отвечает за преобразование двоичной информации в физический сигнал, который отправляется в физический канал передачи данных. Если это кабель, то сигнал электрический, если оптоволоконная сеть, то в оптический сигнал. Осуществляется это преобразование при помощи сетевого адаптера.
TCP/IP — это стек протоколов, который управляет передачей данных как в локальной сети, так и в глобальной сети Интернет. Данный стек содержит 4 уровня, то есть по эталонной модели OSI каждый из них объединяет в себе несколько уровней.
В 1978 г. ISO (International Standards Organization) выпустила набор спецификаций, описывающих модель взаимодействия открытых систем, т.е. систем, доступных для связи с другими системами. Это был первый шаг к международной стандартизации протоколов. Все системы могли теперь использовать одинаковые протоколы и стандарты для обмена информацией.
В 1984 г. ISO выпустила новую версию своей модели, названную эталонной моделью взаимодействия открытых систем ISO. Эта версия стала международным стандартом. Ее спецификации используют производители при разработке сетевых продуктов, ее придерживаются при построении сетей. Полностью модель носит название ISO OSI (Open System Interconnection Reference Model). Для краткости будем ее называть модель OSI . Модель OSI не является сетевой архитектурой, так как не описывает службы и протоколы, используемые на каждом уровне. Она просто определяет, что должен делать каждый уровень. Важно также понимать, что эталонная модель не является чем-то реальным, таким, что обеспечивает связь. Сама по себе она не заставляет коммуникации функционировать и служит лишь для классификации. Она классифицирует то, что непосредственно работает, а именно - протоколы . Протоколом считается набор спецификаций, определяющих реализацию одного или нескольких уровней OSI. ISO разработала также стандарты для каждого уровня, хотя эти стандарты не входят в саму эталонную модель. Каждый из них был опубликован как отдельный международный стандарт.
Модель OSI имеет семь уровней . Каждому уровню соответствуют различные сетевые операции, оборудование и протоколы. Появление именно семи уровней было обусловлено функциональными особенностями модели.
Модель OSI без физического носителя показана на рис.
Определенные сетевые функции, выполняемые на каждом уровне, взаимодействуют только с функциями соседних уровней - вышестоящего и нижележащего. Например, Сеансовый уровень должен взаимодействовать только с Представительским и Транспортным уровнями . Все эти функции подробно описаны.
Каждый уровень выполняет несколько операций при подготовке данных для доставки по сети на другой компьютер. Уровни отделяются друг от друга границами - интерфейсами . Все запросы от одного уровня к другому передаются через интерфейс. Каждый уровень, выполняя свои функции, пользуется услугами нижележащего уровня. Самые нижние уровни - 1-й и 2-й - определяют физическую среду при передаче битов данных через плату СА и кабель. Самые верхние уровни определяют, каким способом реализуется доступ приложений к услугам связи.
Задача каждого уровня − предоставление услуг вышележащему уровню, маскируя при этом детали реализации этих услуг. Каждый уровень на компьютере-отправителе работает так, как будто он напрямую связан с соответствующим уровнем на компьютере-получателе. Эта виртуальная связь показана на рис. пунктирными линиями. В действительности же связь осуществляется между соседними уровнями одного компьютера. ПО каждого уровня реализует определенные сетевые функции в соответствии с набором протоколов.
Перед отправкой в сеть данные разбиваются на пакеты , передаваемые между устройствами сети как единое целое. Пакет проходит последовательно все уровни ПО от прикладного до физического, при этом на каждом уровне к пакету добавляется форматирующая или адресная информация, необходимая для безошибочной передачи данных по сети.
На принимающей стороне пакет также проходит через все уровни, но в обратном порядке. ПО каждого уровня анализирует информацию пакета, удаляет ту информацию, которая добавлена к пакету на таком же уровне отправителем, и передает пакет следующему уровню. По достижении пакетом Прикладного уровня вся служебная информация будет удалена, и данные примут свой первоначальный вид.
Таким образом, только Физический уровень модели может непосредственно послать информацию соответствующему уровню другого компьютера. Информация на компьютере-отправителе и компьютере-получателе должна пройти все уровни, начиная с того, с которого она посылается, и заканчивая соответствующим уровнем того компьютера, которым она принимается. Например, если Сетевой уровень передает информацию с компьютера А, она спускается через Канальный и Физический уровни в сетевой кабель, затем попадает в компьютер В, где поднимается через Физический и Канальный уровни и достигает Сетевого уровня. В среде клиент-сервер примером такой информации служит адрес и результат контроля ошибок, добавленные к пакету.
Взаимодействие смежных уровней осуществляется через интерфейс. Интерфейс определяет услуги, которые нижний уровень предоставляет верхнему, и способ доступа к ним.
Рассмотрим каждый из семи уровней модели OSI и услуги, которые они предоставляют смежным уровням.
Прикладной (Application) уровень . Уровень 7. Он представляет собой окно для доступа прикладных процессов к сетевым услугам. Услуги, которые он обеспечивает, напрямую поддерживают приложения пользователя. Прикладной уровень управляет общим доступом к сети, потоком данных и восстановлением данных после сбоев связи.
Уровень представления (Presentation) . Уровень 6. Представительский уровень определяет формат, используемый для обмена данными между сетевыми компьютерами. Типичный пример работы служб Представительского уровня − кодирование передаваемых данных определенным стандартным образом. Уровень представления отвечает за преобразование протоколов, трансляцию и шифрование данных, смену кодовой таблицы и расширение графических команд. Кроме того, он управляет сжатием данных для уменьшения объема передаваемых бит.
Сеансовый уровень (Session) . Уровень 5. Сеансовый уровень позволяет двум приложениям разных компьютеров устанавливать, использовать и завершать соединение, называемое сеансом. Сеанс может предоставлять еще и расширенный набор услуг, полезный для некоторых приложений. Сеансовый уровень управляет диалогом между взаимодействующими процессами, устанавливая, какая из сторон, когда, как долго и т.д. должна осуществлять передачу.
Транспортный уровень (Transport) . Уровень 4. Основная функция Транспортного уровня − принять данные от Сеансового уровня, разбить их при необходимости на небольшие части и передать Сетевому уровню, гарантируя, что эти части в правильном порядке прибудут по назначению. Все это должно быть сделано эффективно и так, чтобы изолировать более высокие уровни от каких-либо изменений в аппаратной технологии. Транспортный уровень также следит за созданием и удалением сетевых соединений, управляет потоком сообщений, проверяет ошибки и участвует в решении задач, связанных с отправкой и получением пакетов. Примеры протоколов транспортного уровня - ТСР и SРХ.
Сетевой уровень (Network) . Уровень 3. Сетевой уровень управляет операциями подсети. Он отвечает за адресацию сообщений и перевод логических адресов и имен в физические. Сетевой уровень разрешает также проблемы, связанные с разными способами адресации и разными протоколами при переходе пакетов из одной сети в другую, позволяя объединять разнородные сети. Примеры протоколов сетевого уровня - IP и IPX.
Уровень передачи данных
или канальный (Data Link)
. Уровень 2. Основная задача Канального уровня - преобразовать способность Физического уровня передавать данные в надежную линию связи, свободную от необнаруженных ошибок с точки зрения вышестоящего Сетевого уровня. Эту задачу Канальный уровень выполняет при помощи разбиения входных данных на кадры размером от нескольких сот до нескольких тысяч байтов. Каждый следующий кадр данных передается только после получения и обработки кадра подтверждения, посылаемого обратно получателем. Кадр - это логически организованная структура, в которую можно помещать данные. На рис. представлен простой кадр данных, где идентификатор отправителя − адрес компьютера-отправителя, а идентификатор получателя − адрес компьютера-получателя. Управляющая информация используется для маршрутизации, указания типа пакета и сегментации. CRC (циклический код) позволяет выявить ошибки и гарантирует правильный прием информации.
Физический уровень (Physical) . Уровень 1. Физический уровень осуществляет передачу неструктурированного, сырого, потока бит по физической среде (например, по сетевому кабелю). На этом уровне реализуются электрический, оптический, механический и функциональный интерфейсы с кабелем. Физический уровень также формирует сигналы, которые переносят данные, поступившие ото всех вышележащих уровней. На этом уровне определяется способ соединения сетевого кабеля с платой СА и способ передачи сигналов по сетевому кабелю. Физический уровень отвечает за кодирование данных и синхронизацию бит, гарантируя, что переданная единица будет воспринята именно как единица, а не как ноль. Уровень устанавливает длительность каждого бита и способ перевода в электрические или оптические импульсы, передаваемые по сетевому кабелю
