Лекция 6 Роль человека в СОА. Лекция Роль человека в соа. Интеграция bpm, soa, Web 0
 Скачать 0.99 Mb.
|
|
Лекция 6. Роль человека в СОА. Интеграция BPM, SOA, Web 2.0. Роль человека в СОА Задания для пользователей IBM – Краткие основы СОА. Существуют следующие типы заданий для пользователей: Задания с участием (participating tasks). Активизируются системой (процессом), требующей реакции пользователя для продолжения работы. Система инициирует задание, а субъект из списка кандидатов-исполнителей принимает и выполняет его. Затем он предоставляет ответ в систему, уведомляя о его завершении. Примером такого задания является процесс возмещения командировочных расходов, ожидающий утверждения менеджером.  Рисунок 2. Участники и взаимодействия задания с участием Порождаемые задания (originating tasks). Активизируются субъектом через пользовательский интерфейс. Они предназначены для системы: субъект создает порождаемое задание и запускает его; запрос передается системе для запуска требуемых сервисов. После завершения инициатору отправляется уведомление.  Рисунок 3. Участники и взаимодействия порождаемого задания Задания исключительно для пользователей (purely human tasks). Создаются и запускаются субъектом, предназначены для другого субъекта, который принимает и завершает их. Такие задания не взаимодействуют с бизнес-процессом или другими Web-сервисами. Они не являются автоматизированными и проходят тот же цикл назначения и уведомлений. Рисунок 4. Участники и взаимодействия заданий исключительно для пользователей  Логично, что задания для пользователей длятся намного дольше, чем автоматизированные задания, что поднимает еще один вопрос: могут ли процессы позволить себе прерывание и время ожидания, вызываемые заданиями для пользователей? Ответ - да. Для получения более подробного ответа давайте рассмотрим типы бизнес-процессов. Типы бизнес-процессов Бизнес-процессы могут быть либо долго выполняющимися процессами, либо микропотоками: Долго выполняющиеся (long running) процессы прерываемы и могут работать в нескольких транзакциях. Они могут ожидать внешних сигналов, аналогичных тем, которые являются результатом работы заданий для пользователей. Практическое правило заключается в том, что если процесс содержит задание для пользователя, он должен быть долго выполняющимся. Такие процессы могут содержать синхронные и асинхронные сервисы. Долго выполняющиеся процессы запоминают каждое промежуточное состояние процесса, для того чтобы иметь возможность отката. Микропотоки (micro-flows) выполняются без прерывания за одну транзакцию, имеют малую длительность и состоят только из синхронных сервисов. Роли в создании СОА. SOA Adoption for Dummies, 53 В процесс жизненного цикла вовлечены: 1. Владелец бизнеса: определяет требования, необходимые для создания новых деловых возможностей. Наилучший способ их выражения – в нотации моделирования бизнес-процессов (Business Process Modeling Notation, BPMN). Формальное описание процессов облегчает реализацию ИТ. Владелец бизнеса должен описать, помимо функциональности, нефункциональные характеристики, такие как качество предоставление услуг (QoS –Quality of Service). 2. Архитектор: анализирует бизнес-требования и воплощает их в конструкции сервисов и бизнес-процессов. Он принимает решение: использовать имеющийся компонент, или создать новый. При создании нового или изменении существующего компонента, архитектор формирует проектные спецификации в форме диаграмм состояний, моделей процессов и интерфейсов. Архитектор формализует нефункциональные требования (доступность, безопасность, производительность и прочее). 3. Разработчик: Внедряет компоненты, основанные на проектных спецификациях архитектора. Он создает план тестирования. Для реализации технологии разработчик использует заготовки, автоматически создаваемые на основе спецификаций: forward-engineering, reverse-engineering. 4. Управляющий качеством: использует данные остальных участников, проверяет корректность реализации. Он использует план тестирования, оценивает качество, побочные эффекты, нефункциональные характеристики. 5. Оператор: получает проверенное решение и применяет его в работе ИС. Он использует формализованные нефункциональные требования для обеспечения требуемого качества услуг. Цикл жизни SOA и различные его этапы Архитектура SOA характеризуется динамическим циклом жизни. Для нее свойственна возможность постоянного улучшения процессов, что, наряду с применяемой в SOA концепцией слабого связывания, позволяет совершенствовать процессы через разборку и повторную сборку строительных блоков (сервисов в данном случае). Диаграмма цикла жизни SOA содержит четыре смежных шестиугольника, представляющих четыре этапа SOA. Как видно на диаграмме, изображенной на рисунке (Рисунок 1), эти четыре этапа образуют непрерывный замкнутый цикл мониторинга и улучшения.  Рисунок 1. Четыре этапа цикла жизни SOA Рассмотрим эти этапы более подробно. Этап моделирования Этап моделирования включает в себя анализ деятельности и сбор требований, за которыми следует моделирование и оптимизация бизнес-процесса. Модель помогает сформировать общее понимание процесса, его целей и результатов. Она также гарантирует соответствие проекта бизнес-требованиям и обеспечивает исходные критерии для последующего измерения производительности. Этап сборки На этом этапе существующие активы (например, ERP-сист, финансовые системы и т.д.), которые будут использоваться в моделируемых процессах, инкапсулируются в сервисы, тогда как отсутствующие нужные функциональности реализуются и тестируются. Когда все сервисы становятся доступными, можно скоординировать их для реализации бизнес-процесса. Этап развертывания На этапе развертывания среда времени исполнения настраивается на необходимый уровень качества сервиса и на удовлетворение требований безопасности. Среда может масштабироваться и оптимизироваться для повышения надежности работы критичных процессов и для обеспечения гибкости, позволяющей динамически обновлять ее в случае каких-либо изменений. Этап управления На этом этапе выполняется мониторинг ряда аспектов, таких как доступность сервисов, время реакции, контроль версий сервисов. Важную роль на этом этапе играет мониторинг ключевых показателей производительности (key performance indicators - KPI) процесса. Он помогает предотвратить или изолировать и диагностировать возникающие проблемы в реальном времени, а также обеспечить обратную связь с целью улучшения производительности бизнес-процесса и устранения узких мест. Эта обратная связь передается на этап моделирования (первый этап) с целью усовершенствования процесса. Управление архитектурой SOA Как отмечалось в первом разделе, SOA нуждается в интегрированной среде управления (management), в противном случае она выходит из-под контроля. Управление SOA реализуется в рамках концепции руководства (governance), контролирующей различные аспекты архитектуры SOA. Еще один аспект, который должен обязательно реализовываться в SOA-среде по причине ее открытой природы – система безопасности. Подробности механизма управления SOA рассматриваются в данном разделе. Руководство SOA IBM – Effective SOA governance Организации должны определить, какие операции могут быть реализованы сервисами и быть способными оценить функционирование сервисов. Руководство СОА это расширение ИТ-руководства направленное на жизненный цикл сервисов и смешанных приложений. Внедрение руководства СОА часто начинает процесс совершенствования корпоративного и ИТ-руководства. SOA Governance – Play of the Game, BY PHILLIP WINDLEY Основная цель правил проектирования систем в усилении модульности и создании абстракций. Когда эти правила согласованы и утверждены, они называются политиками. Политики СОА в разработке и обеспечении функционирования называются руководством СОА. Политики могут отражать любой аспект жизни сервиса, включая разработку, внедрение и выполнение. Например, политика разработки может утверждать корпоративное пространство имен, политика внедрения может требовать соблюдение сервисом ряда стандартов. Политика выполнения может требовать управления всех сервисов корпоративной системой безопасности. IBM – Краткие основы СОА. Руководство SOA (governance) - это интегрированная среда принятия решения и идентификации ролей для поддержки действий, согласующихся со стратегией предприятия, и предотвращения действий, не являющихся таковыми. Эта интегрированная среда управляется группой или комитетом, ответственным за создание стратегии руководства и идентификацию ролей, полномочий и ответственности индивидуумов, которым дается право принятия решений и проведения стратегии. Коротко говоря, комитет должен решить три основных вопроса: Какие решения необходимо выполнить, чтобы гарантировать эффективное управление информационными активами? Кто ответственен за принятие этих решений? Как можно привести эти решения в исполнение и проконтролировать это? В рамках реализации механизма руководства идентифицируются и контролируются соглашения по уровню сервиса (service level agreements - SLA). Также собираются показатели производительности с целью определения эффективности руководства. Какую роль играет руководство в среде SOA? Руководство в SOA играет решающую роль; оно должно фигурировать во всех этапах цикла жизни SOA, как показано на рисунке 2.  Рисунок 2 Место руководства по отношению к этапам цикла жизни SOA Необходимость руководства для SOA очевидна по следующим причинам: Руководство подразумевает применение принципов корпоративной стратегии для направления деятельности и управления информационными активами. Руководство гарантирует поддержание заданного уровня целостности, производительности, надежности и актуальности сервисов. Руководство гарантирует корректную оценку требований бизнес-приложения и расстановку приоритетов при создании и потреблении сервисов, способствуя, таким образом, наилучшему использованию в соответствии с бизнес-целями. Руководство гарантирует рентабельность инвестиций в информационные технологии. Руководство гарантирует, что корпоративная архитектура SOA является основным ориентиром при проектировании любого сервиса. Руководство, как контролирующий орган, опирается на передовые методики применения информационных технологий. Защищая бизнес-активы, руководство способствует также защите корпоративных данных и конфиденциальности информации, используемой в различных регионах. Руководство, управляя информационными технологиями предприятия, способствует целостности и надежности данных и процессов с целью получения преимуществ от повторного использования и максимизации прибыли. Руководство гарантирует требуемый уровень производительности и качества сервисов всех компонентов в цепочке потребитель-провайдер. Стандарты являются основой SOA, поэтому руководство гарантирует высокий уровень совместимости, открывающий предприятию все преимущества открытых стандартов. Руководство использует показатели для аудита и мониторинга продвижения разработки информационной инфраструктуры и ее соответствия утвержденной стратегии. Соответствие качества сервиса установленным требованиям в руководстве SOA В интегрированной среде с руководством SOA стратегии QoS определяются и реализуются на уровне предприятия. Это жизненно важно в открытой среде, где интеграция и обмен информацией между сервисами не ограничен внутренними функциями предприятия, а выходит за его пределы на предприятия различного размера, различных областей и с различными информационными технологиями, причем должен поддерживаться и гарантироваться устойчивый уровень общих процессов. Например, один не отвечающий требованиям сервис может поставить под угрозу всю систему. В некоторых системах инфраструктура способна определять уровни QoS и отклонять не отвечающие требованиям сервисы. Почему системы безопасности в средах SOA являются сложными и распределенными? Такие сложные системы безопасности необходимы по следующим причинам: Распределенные системы требуют распределенной системы безопасности. Существует необходимость управления реестрами пользователей и управления доступом для нескольких приложений, платформ, бизнес-партнеров и сущностей, чего нельзя сделать из единой точки. Необходимо последовательно осуществлять политики безопасности во всей среде. Система безопасности должна быть способна развиваться по мере развития предприятия и его приложений. Влияние изменения в сервисах на цикл жизни SOA Учитывая принцип слабой связи, изменения сервисов в среде SOA выполняются просто, поскольку потребители сервисов отделены от провайдеров сервисов посредством шины ESB, расположенной между ними и способной быть посредником при обмене сообщениями. Изменения на стороне провайдера могут учитываться в ESB, так чтобы потребитель оставался таким же. С другой стороны, необходимо подчеркнуть важность неуправляемых изменений в среде SOA. Согласно принципу повторного использования, каждый сервис может быть сервисом корпоративного уровня, а не только локальным и используемым в одном отделе или подразделении. Любые неуправляемые изменения в таком сервисе могут привести к непредсказуемым сбоям на всем предприятии и к остановке процессов. Это демонстрирует важность руководства в реализации стратегии управления изменениями. Эта стратегия должна оценивать последствия, разрешать изменения и гарантировать реализацию системы уведомлений для затронутых изменением участников взаимодействий (ESB или непосредственных пользователей). Управление изменениями в распределенных системах должно осуществляться на основании строгих правил. Роль ESB в руководстве SOA ESB играет важную роль в осуществлении руководства. К ESB могут быть применены стратегии системы безопасности и QoS с целью управления их уровнями и разрешения только допустимых запросов. В целом ESB играет роль унифицированной платформы, на которой реализуются необходимые стратегии. По своей природе ESB является центром, где происходят все взаимодействия, что делает ее идеальным местом для применения правил. Это, гарантирует, что каждый участник процесса либо соответствует этим правилам, либо изолируется. Подготовка к реализации SOA Процесс внедрения SOA в организации требует наличия определенной квалификации, включая: Способность определить готовность организации к такому внедрению. Информирование людей о преимуществах и недостатках СОА. Оценку проблем и стимулов для внедрения SOA как c коммерческой, так и с технической стороны. Факторы внедрения SOA с точки зрения бизнеса Для бизнеса важно знать форму и влияние, которые эта новая парадигма окажет на организацию, поэтому необходимо идентифицировать возможные проблемы. Проблемы с точки зрения бизнеса К таким проблемам относятся: Сомнения менеджмента из-за того, что SOA больше управляется ИТ, чем бизнесом. Отображение процессов на сервисы. Отсутствие знаний о SOA и о ее возможностях. Неправильное представление о том, что SOA является только архитектурным подходом к информационным технологиям, что может привести к пренебрежению критически важной ролью руководства. В своем большинстве указанные проблемы могут быть решены, или, по крайней мере, идентифицированы, путем проведения учебных занятий с целью демонстрации преимуществ и реального значения SOA. Побуждающие факторы Основным побуждающим фактором является потенциал SOA для: Повышения окупаемости (return on investment - ROI) благодаря уменьшенной стоимости реализации за счет внедрения стандартов, повторного использования, отображения сервисов и интеграции с партнерами. Уменьшения времени выхода на рынок за счет повторного использования активов и внедрения сервисов, предоставляемых партнерами. Улучшения видимости информационных активов и их согласования с бизнес-целями. Повышения гибкости как внутренней (при взаимодействиях), так и внешней (при работе с партнерами). Реализации более эффективных процессов за счет повторного использования информационных активов и стандартов. Обеспечения гибкости бизнес-деятельности и способности легко и быстро адаптироваться к рыночным изменениям. Уменьшения затрат по организации. Факторы внедрения SOA в организациях с точки зрения ИТ. Некоторые сдерживающие и побуждающие факторы, важные для ИТ-службы, перечислены ниже. Проблемы с точки зрения информационных технологий К таким проблемам можно отнести: Преобразование существующих специализированных систем в основанные на стандартах сервисы. Управление, руководство и контроль сервисов. Проблемы защиты распределенных систем. Надежность новых систем по сравнению с существующими проверенными системами. Оптимизация и унификация существующих активов для устранения избыточности. Побуждающие факторы с точки зрения информационных технологий Такими факторами могут быть: Внедрение стандартов. Это также считается проблемой, но, несмотря на усилия, необходимые для их внедрения, преимущества очевидны для каждого ИТ-специалиста. Гарантирование высокого качества сервиса. Повторное использование существующих информационных активов. Слабое связывание сервисов. Независимость от конкретного провайдера или партнера. Идентификация преград для внедрения SOA Организации необходимо идентифицировать и попытаться преодолеть все преграды, блокирующие внедрение SOA. Вот примеры возможных преград: Консервативные ИТ-специалисты настаивают на старой модели разработки по принципу "водопада". Мнение о том, что сложные системы лучше, боязнь неизвестного. Игнорирование важности архитекторов и стремление считать их теоретиками, стоящими дороже, чем того требует решение. Следует отметить, что архитекторы играют важнейшую роль в SOA, и их отсутствие непременно приведет к нежелательным результатам. Организационное сопротивление внедрению модели SOA. SOA требует кооперации всех групп в организации, а не только простой реализации интегрированной информационной среды. Интеграция BPM, SOA и WEB 2.0 BPM, SOA, Web 2.0 - Oracle Whitepaper Управление бизнес-процессами(BPM) представляет собой стратегию руководства и улучшения деятельности предприятия через постоянный процесс оптимизации в замкнутом цикле моделирования, выполнения и измерения. В дополнение, использование средств управления ресурсами, управления связей с клиентами (CRM), решений business intelligence позволяет BPM развиваться как технологически, так и методологически.  На первой конференции по Web 2.0 (first O'Reilly Media Web 2.0 conference in 2004) Тим О’Рейли сказал: Веб 2.0 это бизнес-революция в компьютерной индустрии, вызванная развитием сети Интернет как вычислительной платформы и попытка понять правила достижения успеха на этой платформе. Основное правило таково: Строить приложения, усиливающие сетевые эффекты, позволяющие функционировать тем лучше, чем больше людей их используют.   Схематичное представление пересечения BPM, SOA и Web2.0 требует решения множества проблем. Основная из них заключается в большом числе участников подобных проектов, их противоречивых интересов.  Управление бизнес-процессами. Ключ к успешной трансформации бизнеса в понимании ролей всех участников. Изменения обычно требуются вследствии корректировки целей на верхнем уровне управления, но причиной может быть, например, изменение рыночных тенденций, желание владельца или стандартная схема роста. Одной из основных задач является создание новых решений без разрушения работающих компонент, от которых зависит прибыль и выполнение работ. Сложность в сохранении ежедневной работоспособности системы без отказа от инноваций. Обычно, в организации есть три отдельные группы: конечные пользователи, группа ИТ(enterprise information technology (EIT) group) и исполнительное руководство (chief executive officers (CXOs) group) Пользователи: используют ИС для выполнения каждодневных задач. Они не заинтересованы в модернизации технологий, с которыми работают. Они знают свои обязанности и заинтересованы тогда, когда не работает необходимое для выполнения работ, или продемонстрированы ясные преимущества новой технологии. В ряде случаев пользователи требуют сохранения старой функциональности наряду с новой. ИТ-специалисты, включают в себя проектировщиков, инженеров, дизайнеров. Эта группа преодолевает расхождения между руководством и конечным пользователем системы, реализуя цели бизнеса в своих решениях. Исполнительное руководство: эта группа занимается организацией как деятельности, так и деловой культуры предприятия, обеспечивает стратегическое планирование, достижение краткосрочных и долгосрочных целей. Эта группа может направлять культурные изменения при адаптации новой структуры предприятия. Важнейшим фактором является наличие развитых коммуникация между участниками, с целью донести до каждого его роль в процессе. Пользователи системы обычно видят свою роль в увеличении эффективности работы, или даже в увеличении рабочего времени, для большей отдачи. Руководство видит своей задачей адаптацию новых стратегий, правил и планов для трансформации. ИТ-специалисты занимаются обслуживанием и модернизацией информационных систем. BPM представляет все изменения подчиненными иерархии целей, позволяя выставлять приоритеты и обеспечивая представление о создаваемой информационной системе. Созданные модели улучшаются и обрабатываются с помощью автоматических средств визуализации. Это позволяет увидеть результат до реализации, а также определить необходимый инвентарь сервисов, который необходимо дополнительно разработать.  Большинство BPM-инструментов позволяют руководству и ИТ-специалистам работать совместно через общий инструмент и общие модели. Такие интегрированные средства разработки позволяют, например, создавать шаблоны кода, интерфейсы и примеры. Средства моделирования позволяют измерять ключевые показатели выполнения, иногда без затрат труда разработчиков, применяя некоторые средства моделирования (например, имитационное моделирование). Такие возможности позволяют менеджменту моделировать работу и отвечать на вопрос «что если..» при помощи симуляции процессов. Этим достигается совместная работа, итеративные циклы разработки, стандартизация и общий взгляд на разработку. Тенденции: совмещение BPM, SOA и WEB 2.0 Сегодня организации осознают необходимость внедрения BPMS в областях, которые ранее считались слишком сложными для автоматизации, включая сугубо человеческие задачи с неструктурированной или плохо структурированной информацией. Не все виды деятельности могут быть формализованы, смоделированы и повторены, большая часть работ трудно автоматизировать. Люди интеллектуальных профессий часто полагаются на опыт, а не на инструкции с ограниченным числом решений и исключительных ситуаций. Организации пытаются помочь людям интеллектуального труда применением множества разнородных систем управления знаниями и совместной работы, но такие системы, как правило, узкоспециализированы и сложно адаптируются к конкретной задаче. BPM позволяет обеспечивать исполнителя нужной ему информацией в требуемый момент времени, но не во всех случаях. Иногда, требуемые знания не доступны в информационной системе и их необходимо найти во внешних системах, документах и источниках данных. Хотя основной задачей внедрения BPM являются процессы с обработкой структурированных данных и четкими, формализованными процессами, эти системы развиваются в направлении поддержки работы пользователей со знаниями, что сейчас выполняется вручную, обработкой документов, e-mail-писем и электронных таблиц. Подобные ситуации требуют от BPM роли посредника, обеспечивающего пользователю возможность создания собственного окружения и связей с помощниками в рамках процесса.  Рассмотрим процесс обработки некоторой заявки. В модели процесса все выглядит простым: пользователь получает заявку, обрабатывает ее и возвращает системе результат, замыкая круг обработки. В реальности, для решения задачи, пользователю может понадобится консультация с коллегами и совместной работы. Иногда нам заранее известно, кто эти люди, иногда их необходимо найти. Поиск людей в контексте решаемой задачи экономит время и делает труд интеллектуальных работников более эффективным. Эффективное взаимодействие часто определяется информацией, создаваемой нами в пределах бизнеса, или во внешних источниках. Для завершения задачи необходимо иметь доступ к этим данным на этапе принятия решения.  Кроме поиска информации, люди при формировании решений используют средства и ресурсы за пределами ИС компании. Эти средства часто не совместимы с корпоративной ИС, а в худшем случае к ним нет доступа. Для облегчения подобных взаимодействий, система моделирования бизнес-процессов должна позволять сотруднику получать доступ к корпоративным и внешним системам коллективной работы, средствам Web 2.0 и веб-сервисам для создания собственного окружения выполнения сложных задач. |