SOA Magazine
по материалам сайта sys-con.com
SOA Project Planning Aspects. New Insights from a New IBM Press Book by: Rawn Shah; Norbert Bieberstein; Sanjay Bose; Marc Fiammante; Keith Jones
Jan. 11, 2006
Данная статья посвящена планированию SOA-проектов. Мы поговорим о наилучших путях создания проектного отдела, о фазах внедрения SOA, механизмах управления SOA и о самих проектах: той роли которую они играют, и о том, каким образом проекты взаимодействуют друг с другом.
Мы не ставим целью снабдить вас готовым шаблоном, с помощью которого вы без труда могли бы составить план своего проекта. Мы также не претендуем на то, что описанные нами организационные структуры являются оптимальными для всех сторон, вовлечённых в SOA-проект. Наш опыт работы с многочисленными клиентами, представителями совершенно разных отраслей, показывает, что не существует универсального, оптимального для всех решения, так же как не существует и универсального подхода к построению SOA. Поиск оптимальных подходов и решений должен быть продиктован индивидуальными особенностями организации. Только учитывая эти индивидуальные особенности можно составить действительно грамотный план и получить оптимальную структуру проекта. Наша задача – просто предложить вам идеи, которые вы могли бы применить к своему SOA-проекту.
Итак, первый шаг – это создание проектного отдела.
1 Создание отдела по работе с SOA-проектами
Исключительно важной составляющей SOA является бизнес-составляющая. Бизнес-модели описаны как модульные процессы. Это оказалось возможным благодаря разложению бизнес-системы и ИТ-системы на составляющие, тем самым обеспечив модульность этих систем и возможность их повторного использования. Подобное компонентное представление удобно применить не только к системам программного обеспечения, но и к структурным бизнес-подразделениям всего предприятия , а также к его организации. Прежде чем приступить непосредственно к реализации SOA-проекта, вам надо продумать, каким образом это можно сделать в условиях ИТ-инфраструктуры вашего предприятия. Однако этого недостаточно. В конечном итоге вам придётся разложить на составляющие и пересмотреть деловую активность всего предприятия. Во-первых, вам необходимо составить «дорожную карту» внедрения SOA, дабы определиться в выборе стратегии. Для этого следует определить, кто именно будет вовлечён в SOA-проект. Участников проекта следует отбирать из разных подразделений организации. Представители каких именно подразделений будут участвовать в проекте, зависит от того уровня внедрения SOA, который вы выберете (см. раздел 1.2). В зависимости от того, что покажет анализ эффективности бизнеса, будет выстроен приоритет бизнес-задач и бизнес-сервисов, и участники проекта смогут понять и сформулировать, “что им надо делать”, “как это делать”, “кто будет этим заниматься” и “по каким критериям можно судить об успехе”. Сотрудники отдела по работе с SOA-проектами занимаются формулированием правил, созданием процессов, системы показателей и организационных структур, необходимых для эффективного планирования, принятия решений, управления и контролирования усилий, направленных на внедрение SOA. Они разрабатывают общую модель бизнес-сервиса, определяют общие ключевые процессы и те бизнес-компоненты, которые будут вовлечены в SOA-проект, а также решают, какие активы будут при этом использоваться.
Создавая отдел по работе с SOA-проектами, следует избегать радикальных перемен в отношении существующих отделов и подразделений, поскольку они могут негативным образом сказаться на корпоративной культуре. Но в то же время нельзя забывать о том, что существует также необходимость объединить усилия в деле SOA, а это неизбежно коснётся структуры подразделений. Возможно, что работа над SOA-проектом потребует внедрения структуры управления, особенно в более-менее крупных ИТ-магазинах, ставящих перед собой большие цели относительно проекта. Это необходимо для управления процессами разработки компонентов или представления уже существующих приложений или унаследованных функций в виде гранулярности сервисов.
Одна из основных задач – создание оптимальной организационной структуры. В организациях, для которых идея SOA нова, часто наблюдается ощутимое сопротивление переменам. В результате упор делается на достижение быстрых результатов, а не на оптимизацию деловой активности, т. е. приведение её в соответствие с бизнес-требованиями.
В тех организациях, где идея SOA прижилась, границы ролей и бизнес-направлений частично стираются, что должно в конечном итоге привести к междисциплинарной координации усилий. Однако все же лучше начинать с малого: такая позиция поможет избежать многих рисков, ведь она позволит вам выбрать тщательно продуманный и спланированный проект интеграции сервисов, чья реализация будет привязана к конкретной небольшой предметной области, но послужит хорошим посылом для дальнейшей эволюции организации предприятия. Организационная структура, подразумевающая междисциплинарную координацию усилий, наиболее приспособлена к решению задач, связанных с SOA. Основываясь на собственном опыте, мы пришли к выводу, что такая структура должна включать в себя:
• Команду, занимающуюся SOA архитектурой, чья деятельность сфокусирована на оптимизации деловой активности: эта команда отвечает за формулирование бизнес-требований, производит анализ предметных областей и технологий процессов, определяет круг необходимых бизнес-компонентов, сервисов и модулей процессов. Наличие этой команды позволит избежать привычного нам следования однобокой инструкции свыше. Преимущество состоит в том, что команда обрабатывает предложения, исходящие и сверху, и с низу, а также существующие методы, применимые для достижения поставленных целей. В результате команда приходит к оптимальному варианту выбора необходимых сервисов. В частности, сопоставляя бизнес-компоненты с ИТ-компонентами, представленными в виде сервисов, команда следит за тем, чтобы гранулярность выбранных сервисов соответствовала бизнес-требованиям и спецификации.
• Команда, отвечающая за техническую сторону внедрения SOA: Основная задача этой команды – обеспечить слияние бизнеса и ИТ, что достигается за счёт следования промышленным и корпоративным стандартам. Команда следит за тем, чтобы сервисы соответствовали требованиям эволюции и повторного использования, как это прописано в общих положениях, касающихся разработки корпоративной ИТ. Члены команды должны быть хорошо подкованными в вопросах новейших индустриальных тенденций, самых современных и передовых технологий, а также стандартизации. Они отвечают за техническую сторону проекта архитектуры. В частности, они определяют базовую конфигурацию и основные принципы архитектуры, такие как принцип повторного использования. Данная команда должна тесно сотрудничать с командой, о которой шла речь выше (командой, занимающейся вопросами оптимизации).
• Отдел дизайна и разработки компонентов: Это обычный ИТ-отдел, занимающийся дизайном и разработкой компонентов и процессов, а также такими новыми технологиями, как разработка моделей бизнес-процессов. Отдел занимается дизайном решений, дизайном абстракций высокого и низкого уровней, сервис-ориентированным анализом и дизайном, а также осуществлением различных этапов тестирования, таких как тестирование устройств и узлов, тестирование систем, испытаниями на соответствие техническим условиям.
• Отдел управления и эксплуатации: Это производственный отдел, занимающийся вопросами управления компонентами сервисов. В круг его деятельности входит контроль и поддержание качества сервисов, обеспечение соблюдения бизнес-соглашений и соглашений об уровне сервисов, обеспечение безопасности, управление запуском сервисов на сервере и обеспечение прибыли. Отдел отвечает за развёртывание сервисов, за обеспечение их непрерывной поддержки, а также за управление всей системой в целом. В зависимости от степени зрелости ИТ-организации, существующие структуры могут быть перегруппированы в целях обеспечения поддержки SOA-проекта. После того, как вы определились с комитетами/отделами/командами, можно приступать к разработке плана внедрения SOA.
2 «Дорожная карта» внедрения SOA
SOA-стратегия не должна полностью заменить собой существующую ИТ-среду. Она должна представлять собой последовательный поэтапный план. Зачастую полная реорганизация существующей ИТ-среды и невозможна, если большая часть сотрудников ИТ-отдела занимаются поддержанием функционирующих систем. Таким образом, «дорожная карта» внедрения SOA – это последовательный итеративный план, подразумевающий постепенное внедрение сервис-ориентированной архитектуры.
Предприятия могут следовать нескольким моделям внедрения сервис-ориентированной архитектуры. Выбор модели зависит от величины предметной области. Мы выделяем следующие модели:
• Первоначальное внедрение: Предприятия, стремящиеся максимально снизить свои риски, как правило, предварительно оценивают свои возможности (степень готовности) и степень валидности технологии. Это позволяет судить о том, каким образом внедрение SOA скажется на технической и бизнес-составляющих определённой предметной области. Полученные данные о рентабельности бизнеса и технических достоинствах позволяют организации делать определённые выводы и, как правило, повышают уровень заинтересованности предприятия во внедрении сервис-ориентированной архитектуры. Для оценки степени своей готовности и степени валидности технологии проводятся предварительные пилотные тесты, заключающиеся в представлении бизнес-операций, содержащихся в новых или уже существующих приложениях, в виде сервисов. Подобные тесты используются для предварительной оценки таких параметров, как:
- Способность преобразовывать унаследованные системы. Она может включать в себя технические решения, как, например, решения, позволяющие осуществлять передачу сообщений, согласующие устройства и блоки соединения или же наличие поставщиков, к которым можно обратиться за средствами обеспечения сервис-ориентированной интеграции.
- Способность удовлетворить нефункциональные требования, такие как эффективность, безопасность, управляемость, доступность инструментария.
- Организационная структура, необходимая для поддержания процесса эволюции предприятия, особенно та, которая имеет дело со структурами, требующими преобразования, и структурами управления.
• Внедрение в рамках определённых бизнес-направлений: При таком подходе предприятие определяет границы внедрения SOA: выбираются те бизнес-направления и процессы, чья эффективность несомненно повысится за счёт той гибкости, которую обеспечит SOA. Для этого необходимо проанализировать и оценить, насколько SOA способна решить поставленные задачи. Это, несомненно, потребует оценки ключевых параметров и факторов успеха.
• Внедрение на уровне предприятия: Данный подход предполагает взгляд на организацию как на полностью сервис-ориентированное предприятие, где все проекты расположены в соответствии с приоритетом по принципу бизнес-эффективности и поэтапно реализуются в заданной архитектурной среде. Необходимо классифицировать деятельность предприятия и соотнести полученные категории деятельности с соответствующими предметными областями и компонентами, которые в совокупности и составляют предприятие. Только после этого учреждается отдел по управлению SOA, уполномоченный вносить изменения в сервисы предприятия. В его обязанности также входит мониторинг и описание этих изменений.
• Внедрение по типу «Предприятие-и-партнер»: Такой подход ещё шире, чем предыдущий. Он предполагает преобразование уже существующих бизнес-моделей или развёртывание абсолютно новой модели, включающей в себя не только предприятие, но и его многочисленных партнёров, поставщиков и клиентов. При этом предприятие выбирает для себя ту роль или комбинацию ролей, которая наилучшим образом способствует достижению успеха. Так, предприятие может стать поставщиком сервисов, потребителем, брокером, агрегатором, компанией-свахой и т.д.
«Дорожная карта» включает в себя типичные этапы разработки ИТ-проекта, такие как начальный этап (анализ, разработка концепции, планирование), разработка, реализация, тестирование, применение (согласно методологии разработки программного обеспечения, предлагаемой компанией Rational). Стоит отдельно отметить, что каждый из этих этапов должен также включать в себя новые виды работ, связанные с идентификацией сервисных компонентов и их реализацией.
3 Необходимость управления SOA
Внедрение SOA позволяет предприятиям повысить свои возможности по взаимодействию с партнёрами, клиентами, поставщиками и т.д., и повысить уровень доходов. С другой стороны, SOA предполагает реструктуризацию приложений для повышения гибкости и снижения издержек, что, в свою очередь, невозможно без сотрудничества бизнеса и ИТ. Таким образом, предприятию необходимо продумать пути обеспечения тандема этих двух сфер и выработать новый способ отображения бизнес-требований в ИТ-приложениях. И организационное управление играет здесь как никогда большую роль. В следующих разделах мы расскажем о том, каким же образом можно установить функции для управления SOA.
3.1 Обоснование необходимости управления SOA. Задачи управления SOA.
Взаимодействие бизнес- и ИТ-составляющих предприятия должно осуществляться очень быстро, чтобы предприятие могло сразу реагировать на изменяющиеся возможности и задачи бизнеса. Задача бизнеса – расставить приоритеты для новых ИТ-сервисов, которые разрабатываются и управляются как часть высокоинтегрированной и сложной архитектуры. Этого невозможно добиться без ключевых функций управления, необходимых для составления успешной «дорожной карты», о которых будет сказано ниже.
Управление позволяет создать всеохватывающую структуру, которая определяет приоритеты и затем поддерживает бизнес-задачи на стратегическом, функциональном и операционном уровнях. Модель управления определяет «что делать», «как это сделать», «кто должен этим заниматься» и «каким образом оценивать достигнутое». Она диктует правила, определяет процессы, системы показателей и организационные структуры, необходимые для эффективного планирования, принятия решений, управления и контроля за работой SOA-инфраструктуры. Без этого невозможно удовлетворить корпоративные бизнес-требования и добиться выполнения поставленных задач. Как уже отмечалось выше, проектный отдел по работе с SOA отвечает за разработку такой модели.
Следующие вопросы помогут вам определиться с выбором подходящей для вас структуры управления:
• Что вы надеетесь изменить в вашем бизнесе с помощью SOA? Является ли внедрение SOA наилучшим способом использования существующей инфраструктуры, способным снизить издержки? Какую именно цель вы преследуете: создать новую модель бизнеса или новую модель взаимодействия? Или и то, и другое?
• Какие роли, обязанности, структуры и процедуры, позволяющие определять приоритеты бизнеса, осуществлять финансирование ИТ, планирование, управление и принятие решений, существуют на вашем предприятии?
• Какими возможностями вы обладаете в деле повышения компетентности лидерства и развития необходимых навыков?
• Использование каких принципов и методов вы считаете оптимальным для обеспечения слияния бизнеса и ИТ?
• Какой способ структуризации взаимодействия бизнеса и ИТ, обеспечивающий целостность и гибкость и позволяющий предприятию чутко реагировать на изменения, вы считаете для себя наиболее приемлемым?
• Какой уровень стандартизации сервисов, их определения и описания является для вас оптимальным?
• Каким образом вы контролируете и измеряете функциональность сервиса и оцениваете поставщиков сервисов? Какие ключевые показатели эффективности бизнеса вы отслеживаете в первую очередь? Кто занимается мониторингом, описанием изменений в сервисах? Кто уполномочен разрешать или не разрешать производить подобные изменения?
• Каким образом вы осуществляете выбор сорсинговой стратегии для сервисов?
Выбор модели управления имеет решающее значение для успешного решения поставленных задач, поэтому далее речь пойдёт о важных функциях управления. Начать следует с обсуждения существующей структуры предприятия и затем подогнать её под ту, что описана в вашей «дорожной карте».
Для того, чтобы осуществлять управление архитектурой, нужно с помощью организационной структуры определить круг ролей и обязанностей, которые для этого необходимы. Опыт показывает, что было бы неплохо основать центр управления SOA (COE), который бы контролировал следование «дорожной карте» и занимался поддержкой крупных и комплексных проектов. Центр COE следит за тем, чтобы реализация SOA была согласована с бизнес-требованиями на стратегическом, тактическом и операционном уровнях. В его полномочия входит одобрение технических артефактов, таких как планы и схемы архитектуры, корпоративные шаблоны и проектные ресурсы.
3.2 Модель управления SOA
В данной статье мы взяли за основу модель, описанную Ивон Бальцер (Yvonne Balzer). Концепция управления SOA, по сути, является ничем иным как более глубоко переосмысленной идеей управления ИТ, с той лишь разницей, что предполагается несколько большая степень вовлечения бизнеса в дело обеспечения поддержки ИТ-компонентов сервисов. Существует множество определений ИТ-управления, но мы отдаём предпочтение тому, которое даёт Институт Управления ИТ (The IT Governance Institute). Предлагаем вам с ним ознакомиться.
Определение понятия «управление ИТ», которое даёт Институт Управления ИТ
ИТ-управление является обязанностью совета директоров и высшего исполнительного руководства. Оно является неотъемлемой частью управления предприятием и состоит из руководящей и организационной структур и процессов, с помощью которых осуществляется контроль за тем, насколько ИТ следует стратегии в решении задач.
Цель ИТ-управления состоит в том, чтобы направить усилия ИТ на обеспечение согласованности деятельности ИТ с бизнес-задачами. Об этом можно судить по следующим критериям:
• Слияние ИТ и бизнеса приносит прибыль.
• ИТ способствует использованию всех имеющихся возможностей и получению максимальной прибыли.
• ИТ-ресурсы используются рационально.
• Риски, связанные с ИТ, тщательно прорабатываются и с ними несложно совладать.
Управление SOA предполагает управление моделью предприятия. При этом модель предприятия рассматривается как набор стандартизированных модульных бизнес-компонентов и процессов, для которых нужно определить приоритет в соответствии с требованиями эффективности. Таким образом, модель управления SOA представляет собой комбинацию организационной структуры, связанных процессов, а также взаимоотношений и взаимодействий, основывающихся на установленных общих правилах, называемых принципами управления, и стратегического руководства.
3.3 Стратегическое руководство и принципы управления SOA
Для того чтобы направить деятельность предприятия на решение бизнес-задач и согласовать её с бизнес-требованиями, необходимо составить стратегическое руководство по разработке SOA. Бизнес-стратегия и задачи должны быть понятны и бизнес-составляющей, и ИТ-составляющей. Причём обе составляющие должны прийти к единому пониманию бизнес-стратегии и бизнес-задач, поскольку на принципах управления и стратегии основывается принятие всех решений. Именно принципы управления и стратегия определяют область принятия решений и то, каким образом будут взаимодействовать бизнес и ИТ. Поэтому все стороны, вовлечённые в проект, начиная с представителей руководства и заканчивая участниками отдельно взятого проекта, должны руководствоваться едиными принципами, которые понятны всем.
Е.Г. Надхан (E.G. Nadhan) выделяет 2 основных подхода к управлению:
• Централизованное управление оптимально подходит для отдельного предприятия. В отдел по управлению входят представители каждого бизнес-подразделения и от экспертов в области технологий. Отделом рассматриваются вопросы по созданию новых и удалению старых сервисов, по внесению изменений в существующие сервисы и принимаются окончательные решения.
• Распределённое управление оптимально для рассредоточенных подразделений. Каждое бизнес-подразделение само осуществляет контроль над работой сервисов в рамках своего отдела. Для того, чтобы это стало возможным, необходимо разработать подходы к функционированию сервисов в рамках всех бизнес-подразделений. А разработкой стандартов и стратегий будет заниматься центральный комитет по управлению.
Каждый из этих подходов соответственно предполагает свои принципы построения архитектуры и по-своему рассматривает сервисы. Существуют и другие подходы, которые ставят во главу угла процессы, бизнес-функции или даже построение моделей компонентов (излюбленный подход IBM). Неважно, какой из них вы выберете для построения архитектуры на вашем предприятии, главное - обеспечить единое понимание и единую интерпретацию выбранного вами структурированного подхода бизнесом и ИТ.
3.4 Распределение полномочий и финансирование
Переход на SOA - это смена парадигмы, предопределённая необходимостью создания более гибких бизнес-моделей, достижения более высокого уровня интеграции и более тесного взаимодействия бизнеса и ИТ. Подобные перемены на предприятии могут быть встречены сопротивлением, и в результате все благие и полномасштабные начинания могут закончиться лишь внедрением Web-сервисов в какой-то небольшой предметной области. Успешная реализация SOA-проекта возможна только при активной поддержке проекта высшим руководством, согласованном финансировании и грамотном распределении полномочий в отделе по управлению SOA.
Одна из проблем, с которыми вы можете столкнуться – это учреждение формального, так сказать, «марионеточного» отдела по управлению SOA, который способен только консультировать, но не в силах претворить собственные рекомендации в жизнь. Ведь в конечном счёте отдел по управлению должен быть в состоянии обеспечить надлежащий контроль финансирования проекта.
Опыт показывает, что комитет/отдел по управлению должен быть способен обеспечить надлежащий контроль финансирования проекта.
3.5 Управление рисками, связанными с «дорожной картой» SOA.
Приступая к следованию «дорожной карте», отдел по управлению прежде всего должен обеспечить необходимый старт и проанализировать риски. Анализ и оценка рисков должны периодически повторно проводиться отделом управления на протяжении всего цикла разработки. Схема 1 поможет вам получить представление о том, каким же образом нужно оценивать готовность предприятия к переходу на сервис-ориентированную архитектуру и факторы риска, которые с этим связаны. (см. схему 1)
На схеме указаны важные аспекты и критерии, которые следует принять во внимание. Хотя, конечно же, не стоит забывать, что вы должны выбирать те критерии, которые важны именно для вас, в зависимости от ситуации и индивидуальных особенностей вашего проекта. Цель проведения подобной оценки – выявить проблемы на техническом, операционном и организационном уровнях, а также понять, какие проблемы и обстоятельства могут помешать переходу предприятия на SOA, т.е. смене текущей бизнес-модели предприятия на сервис-ориентированную. Проведение оценки невозможно в условиях отсутствия понимания между предприятием и клиентами или партнёрами. Оценка покажет, возможно ли с помощью сервис-ориентированной архитектуры отобразить изменения нужд и требований клиента или партера в существующих программных продуктах и приложениях.
На основании полученных данных вы сможете составить адекватный план действий, направленных в основном на то, чтобы повысить готовность вашего предприятия к переходу на сервис-ориентированную архитектуру или, иными словами, поработать над слабыми местами и подтянуть предприятие до необходимого уровня готовности. Опять же отметим, что все усилия по повышению готовности предприятия должны реализовываться в виде тщательно спланированных проектов.
3.6 Процессы управления SOA
К процессам управления относятся процессы, необходимые для стратегического бизнес- и ИТ-планирования, например, разработка стратегии, техническое ИТ-планирование, управление портфолио, сорсинговые процессы, управление нововведениями и управление архитектурой. ИТ любой организации также требует процессов, связанных с осуществлением контроля. Уровень реализации таких процессов зависит от размеров компании: они могут осуществляться как на уровне отдельных отделов, на уровне департаментов, так и на более высоком уровне. Мы предлагаем приступить к обсуждению самых важных процессов управления.
Процесс идентификации и расстановки приоритетов для бизнес-компонентов:
• Определяет структурированный подход к моделированию, идентификации и расстановке приоритетов для бизнес-процессов и сервисных компонентов.
• Помогает формально определить бизнес-цели и ключевые показатели эффективности (они могут быть определены архитектурой и при помощи реализации процесса).
Процесс нейтрализации неисправностей при возникновении исключительных ситуаций
• Модели бизнес-процессов редко бывают исчерпывающими. Никто не может предусмотреть все, что может произойти на предприятии, поэтому жизненно необходимо установить правила поведения в исключительных ситуациях.
• Такой подход к делу гарантирует, что построенная вами архитектура содержит в себе точки входа, позволяющие определенным категориям пользователей или процессов игнорировать обычные, формализованные процессы и исключения процессов. Таким образом, обеспечивается дополнительная гибкость
Процесс обзора архитектуры
• Представляет собой структурированный подход к обзору и одобрению изменений существующей SOA- архитектуры и к принятию решений на основе принципов управления.
• Обзор формального дизайна архитектуры и оценка сервисов имеют решающее значение для центров управления, поскольку именно эти показатели позволяют судить о развитии SOA-архитектуры.
Процесс обработки исключительных ситуаций в архитектуре и обращения к компонентам архитектуры
• Обеспечивает средства, с помощью которых можно обращаться к архитектурным решениям.
• Позволяет решать бизнес-задачи, несмотря на возникшие исключения в архитектуре.
Процесс поддержания жизнеспособности архитектуры
• Следит за тем, чтобы SOA работала и воспринимала новые сервисы.
• Следит за тем, чтобы любые изменения, внесенные в архитектуру, были задокументированы, и чтобы архитектура реагировала на эти изменения.
Коммуникационный процесс архитектуры
• Благодаря ему SOA доступна всем, кому она требуется.
• Полностью обосновывает ту важную роль, которую играет SOA.
Процесс, который мы используем для разработки модели управления, состоит из трёх этапов (см. схему 2). Ключ к успеху состоит в том, чтобы с первого же дня установить функции управления. Для того, чтобы процесс занял у вас меньше времени, рекомендуем реализовывать составленную вами модель на практике в 3 этапа:
Этап 1: Пробное введение в эксплуатацию
• Задействуйте основные принципы и методы управления во время осуществления предприятием своей деятельности.
• Проведите первичный анализ работы SOA.
• Методом проб налаживайте работу SOA. Используйте полученный опыт, экспериментируйте с доступными ресурсами, которые гарантированно обеспечат результат в кратчайшие сроки.
• Этот этап предполагает вовлечение опытных специалистов.
• Продумайте ваши дальнейшие действия.
Этап 2: Наладить работу на профессиональном уровне (автоматизация)
• Создайте необходимые структуры, процессы, методы и инструменты.
• Используйте опыт, приобретённый на первом этапе.
• Задайте первоначальные параметры сервис-ориентированной модели и базовые методы построения архитектуры.
• Соберите команду из опытных архитекторов и специалистов в области методологии.
Этап 3: Стабилизация
• Обучайте ваш персонал работе с SOA и предоставьте ему возможность применить эти знания на практике.
• Не только управляйте, но и снабжайте персонал инструкциями.
• Взращивайте обучающих специалистов.
3.8 Полезные советы
Даже если вы хорошо наладили управление, вам предстоит столкнуться с целым рядом проблем, способных помешать эволюционированию вашей SOA. Таким образом, очень важно начинать строить дом SOA на крепком и надёжном фундаменте. Вот какой практический опыт мы вынесли для себя:
• Установите правила и определите роли для организации усилий в деле SOA.
• Регулярно общайтесь. SOA также подразумевает перемены в корпоративной культуре, поэтому общаться между собой крайне важно для избежания и преодоления барьеров и разногласий. Особенно это касается бизнес-направлений и технологических отделов.
• Документируйте каждое принятое решение, ограничение и полномочия, чтобы обеспечить прозрачность принятия решений и, как следствие, заинтересованность и участие всех отделов в общем деле.
• Определите основную документацию, набор необходимых инструментов и шаблонов. Они должны быть понятными всем сторонам, участвующим в SOA-проекте.
• Установите удобный инструментарий, с помощью которого будет осуществляться управление на протяжении всего жизненного цикла. Особо внимательно отнеситесь к долгосрочным бизнес-процессам, о которых пойдет речь ниже.
• Взвесьте и оцените каждое решение, задокументируйте и укажите ту степень важности, которую вы ему присвоили. Известите сотрудников о своих решениях.
• Продолжайте поддерживать заинтересованность всех отделов и подразделений. Продолжайте политику финансирования, исходящего от всех сторон, участвующих в проекте.
4. Техническое управление SOA
Внедрив SOA, вы должны быть готовы к тому, что циклы ваших бизнес-процессов могут отличаться от циклов тех продуктов, которые вам предлагают поставщики. Вы неизбежно столкнётесь с тем, что, имея дело с долгосрочными процессами, вам придётся поддерживать сценарии, в которых сосуществуют разные версии одного и того же процесса в изменяющейся инфраструктуре. А это будет накладывать определённый отпечаток на цикл развития проекта, осложняя его. Таким образом, увеличится не только длительность цикла, усложнится инструментарий, а также методы, используемые для определения бизнес-процессов, осуществляющихся на вашем предприятии.
Устранить проблемы, возникающие из-за несовпадения циклов, можно следующим образом:
• Снизить уровень того влияния, которое оказывают изменения, за счет модуляризации
• Добиться независимости промежуточного ПО, точно определив состояние процесса
• Мониторинг исключительных ситуаций в бизнесе и работа с ними
4.1 Снижение влияния, оказываемого изменениями, за счет модуляризации
Также как сервисы могут обладать разным уровнем гранулярности и изменчивости, процессы тоже можно характеризовать с позиций гранулярности. Она появляется, когда процессы представляют собой совокупность индивидуальных модулей. Каждый модуль предлагает свой сервисный интерфейс и внутренне регулирует своё состояние. Таким образом, гораздо проще вносить изменения в процессы, разрабатывая новые модули процессов, выбранные из существующих сервисов, использующих политики.
4.2 Добиться независимости промежуточного ПО, точно определив состояние процесса
Механизмы промежуточного ПО, осуществляющие текущие бизнес-процессы, сами внутренне регулируют состояние процессов. Налицо зависимость между ними. Получается, что решение всех вопросов, связанных с процессами, привязано к тому или иному механизму промежуточного ПО, а иногда даже к определённой версии промежуточного ПО. Для того чтобы избежать этой привязки, разработчикам процессов следует поднять уровень возможного определения состояния процесса. Однако это приведёт к возникновению состояний ожидания до момента получения внешнего события.
Таким образом, необходимо определять и регулировать состояние процессов, рассредоточенных в разных частях SOA-инфраструктуры. Один из вариантов решения этой проблемы – набор спецификаций, включенных в WS-Resource Framework. Эти спецификации помогут программистам описать и наладить взаимосвязь между Web-сервисами (модулями процессов) и одним или несколькими компонентами, называемыми WS-Resources.
по материалам сайта sys-con.com
SOA Project Planning Aspects. New Insights from a New IBM Press Book by: Rawn Shah; Norbert Bieberstein; Sanjay Bose; Marc Fiammante; Keith Jones
Jan. 11, 2006
Данная статья посвящена планированию SOA-проектов. Мы поговорим о наилучших путях создания проектного отдела, о фазах внедрения SOA, механизмах управления SOA и о самих проектах: той роли которую они играют, и о том, каким образом проекты взаимодействуют друг с другом.
Мы не ставим целью снабдить вас готовым шаблоном, с помощью которого вы без труда могли бы составить план своего проекта. Мы также не претендуем на то, что описанные нами организационные структуры являются оптимальными для всех сторон, вовлечённых в SOA-проект. Наш опыт работы с многочисленными клиентами, представителями совершенно разных отраслей, показывает, что не существует универсального, оптимального для всех решения, так же как не существует и универсального подхода к построению SOA. Поиск оптимальных подходов и решений должен быть продиктован индивидуальными особенностями организации. Только учитывая эти индивидуальные особенности можно составить действительно грамотный план и получить оптимальную структуру проекта. Наша задача – просто предложить вам идеи, которые вы могли бы применить к своему SOA-проекту.
Итак, первый шаг – это создание проектного отдела.
1 Создание отдела по работе с SOA-проектами
Исключительно важной составляющей SOA является бизнес-составляющая. Бизнес-модели описаны как модульные процессы. Это оказалось возможным благодаря разложению бизнес-системы и ИТ-системы на составляющие, тем самым обеспечив модульность этих систем и возможность их повторного использования. Подобное компонентное представление удобно применить не только к системам программного обеспечения, но и к структурным бизнес-подразделениям всего предприятия , а также к его организации. Прежде чем приступить непосредственно к реализации SOA-проекта, вам надо продумать, каким образом это можно сделать в условиях ИТ-инфраструктуры вашего предприятия. Однако этого недостаточно. В конечном итоге вам придётся разложить на составляющие и пересмотреть деловую активность всего предприятия. Во-первых, вам необходимо составить «дорожную карту» внедрения SOA, дабы определиться в выборе стратегии. Для этого следует определить, кто именно будет вовлечён в SOA-проект. Участников проекта следует отбирать из разных подразделений организации. Представители каких именно подразделений будут участвовать в проекте, зависит от того уровня внедрения SOA, который вы выберете (см. раздел 1.2). В зависимости от того, что покажет анализ эффективности бизнеса, будет выстроен приоритет бизнес-задач и бизнес-сервисов, и участники проекта смогут понять и сформулировать, “что им надо делать”, “как это делать”, “кто будет этим заниматься” и “по каким критериям можно судить об успехе”. Сотрудники отдела по работе с SOA-проектами занимаются формулированием правил, созданием процессов, системы показателей и организационных структур, необходимых для эффективного планирования, принятия решений, управления и контролирования усилий, направленных на внедрение SOA. Они разрабатывают общую модель бизнес-сервиса, определяют общие ключевые процессы и те бизнес-компоненты, которые будут вовлечены в SOA-проект, а также решают, какие активы будут при этом использоваться.
Создавая отдел по работе с SOA-проектами, следует избегать радикальных перемен в отношении существующих отделов и подразделений, поскольку они могут негативным образом сказаться на корпоративной культуре. Но в то же время нельзя забывать о том, что существует также необходимость объединить усилия в деле SOA, а это неизбежно коснётся структуры подразделений. Возможно, что работа над SOA-проектом потребует внедрения структуры управления, особенно в более-менее крупных ИТ-магазинах, ставящих перед собой большие цели относительно проекта. Это необходимо для управления процессами разработки компонентов или представления уже существующих приложений или унаследованных функций в виде гранулярности сервисов.
Одна из основных задач – создание оптимальной организационной структуры. В организациях, для которых идея SOA нова, часто наблюдается ощутимое сопротивление переменам. В результате упор делается на достижение быстрых результатов, а не на оптимизацию деловой активности, т. е. приведение её в соответствие с бизнес-требованиями.
В тех организациях, где идея SOA прижилась, границы ролей и бизнес-направлений частично стираются, что должно в конечном итоге привести к междисциплинарной координации усилий. Однако все же лучше начинать с малого: такая позиция поможет избежать многих рисков, ведь она позволит вам выбрать тщательно продуманный и спланированный проект интеграции сервисов, чья реализация будет привязана к конкретной небольшой предметной области, но послужит хорошим посылом для дальнейшей эволюции организации предприятия. Организационная структура, подразумевающая междисциплинарную координацию усилий, наиболее приспособлена к решению задач, связанных с SOA. Основываясь на собственном опыте, мы пришли к выводу, что такая структура должна включать в себя:
• Команду, занимающуюся SOA архитектурой, чья деятельность сфокусирована на оптимизации деловой активности: эта команда отвечает за формулирование бизнес-требований, производит анализ предметных областей и технологий процессов, определяет круг необходимых бизнес-компонентов, сервисов и модулей процессов. Наличие этой команды позволит избежать привычного нам следования однобокой инструкции свыше. Преимущество состоит в том, что команда обрабатывает предложения, исходящие и сверху, и с низу, а также существующие методы, применимые для достижения поставленных целей. В результате команда приходит к оптимальному варианту выбора необходимых сервисов. В частности, сопоставляя бизнес-компоненты с ИТ-компонентами, представленными в виде сервисов, команда следит за тем, чтобы гранулярность выбранных сервисов соответствовала бизнес-требованиям и спецификации.
• Команда, отвечающая за техническую сторону внедрения SOA: Основная задача этой команды – обеспечить слияние бизнеса и ИТ, что достигается за счёт следования промышленным и корпоративным стандартам. Команда следит за тем, чтобы сервисы соответствовали требованиям эволюции и повторного использования, как это прописано в общих положениях, касающихся разработки корпоративной ИТ. Члены команды должны быть хорошо подкованными в вопросах новейших индустриальных тенденций, самых современных и передовых технологий, а также стандартизации. Они отвечают за техническую сторону проекта архитектуры. В частности, они определяют базовую конфигурацию и основные принципы архитектуры, такие как принцип повторного использования. Данная команда должна тесно сотрудничать с командой, о которой шла речь выше (командой, занимающейся вопросами оптимизации).
• Отдел дизайна и разработки компонентов: Это обычный ИТ-отдел, занимающийся дизайном и разработкой компонентов и процессов, а также такими новыми технологиями, как разработка моделей бизнес-процессов. Отдел занимается дизайном решений, дизайном абстракций высокого и низкого уровней, сервис-ориентированным анализом и дизайном, а также осуществлением различных этапов тестирования, таких как тестирование устройств и узлов, тестирование систем, испытаниями на соответствие техническим условиям.
• Отдел управления и эксплуатации: Это производственный отдел, занимающийся вопросами управления компонентами сервисов. В круг его деятельности входит контроль и поддержание качества сервисов, обеспечение соблюдения бизнес-соглашений и соглашений об уровне сервисов, обеспечение безопасности, управление запуском сервисов на сервере и обеспечение прибыли. Отдел отвечает за развёртывание сервисов, за обеспечение их непрерывной поддержки, а также за управление всей системой в целом. В зависимости от степени зрелости ИТ-организации, существующие структуры могут быть перегруппированы в целях обеспечения поддержки SOA-проекта. После того, как вы определились с комитетами/отделами/командами, можно приступать к разработке плана внедрения SOA.
2 «Дорожная карта» внедрения SOA
SOA-стратегия не должна полностью заменить собой существующую ИТ-среду. Она должна представлять собой последовательный поэтапный план. Зачастую полная реорганизация существующей ИТ-среды и невозможна, если большая часть сотрудников ИТ-отдела занимаются поддержанием функционирующих систем. Таким образом, «дорожная карта» внедрения SOA – это последовательный итеративный план, подразумевающий постепенное внедрение сервис-ориентированной архитектуры.
Предприятия могут следовать нескольким моделям внедрения сервис-ориентированной архитектуры. Выбор модели зависит от величины предметной области. Мы выделяем следующие модели:
• Первоначальное внедрение: Предприятия, стремящиеся максимально снизить свои риски, как правило, предварительно оценивают свои возможности (степень готовности) и степень валидности технологии. Это позволяет судить о том, каким образом внедрение SOA скажется на технической и бизнес-составляющих определённой предметной области. Полученные данные о рентабельности бизнеса и технических достоинствах позволяют организации делать определённые выводы и, как правило, повышают уровень заинтересованности предприятия во внедрении сервис-ориентированной архитектуры. Для оценки степени своей готовности и степени валидности технологии проводятся предварительные пилотные тесты, заключающиеся в представлении бизнес-операций, содержащихся в новых или уже существующих приложениях, в виде сервисов. Подобные тесты используются для предварительной оценки таких параметров, как:
- Способность преобразовывать унаследованные системы. Она может включать в себя технические решения, как, например, решения, позволяющие осуществлять передачу сообщений, согласующие устройства и блоки соединения или же наличие поставщиков, к которым можно обратиться за средствами обеспечения сервис-ориентированной интеграции.
- Способность удовлетворить нефункциональные требования, такие как эффективность, безопасность, управляемость, доступность инструментария.
- Организационная структура, необходимая для поддержания процесса эволюции предприятия, особенно та, которая имеет дело со структурами, требующими преобразования, и структурами управления.
• Внедрение в рамках определённых бизнес-направлений: При таком подходе предприятие определяет границы внедрения SOA: выбираются те бизнес-направления и процессы, чья эффективность несомненно повысится за счёт той гибкости, которую обеспечит SOA. Для этого необходимо проанализировать и оценить, насколько SOA способна решить поставленные задачи. Это, несомненно, потребует оценки ключевых параметров и факторов успеха.
• Внедрение на уровне предприятия: Данный подход предполагает взгляд на организацию как на полностью сервис-ориентированное предприятие, где все проекты расположены в соответствии с приоритетом по принципу бизнес-эффективности и поэтапно реализуются в заданной архитектурной среде. Необходимо классифицировать деятельность предприятия и соотнести полученные категории деятельности с соответствующими предметными областями и компонентами, которые в совокупности и составляют предприятие. Только после этого учреждается отдел по управлению SOA, уполномоченный вносить изменения в сервисы предприятия. В его обязанности также входит мониторинг и описание этих изменений.
• Внедрение по типу «Предприятие-и-партнер»: Такой подход ещё шире, чем предыдущий. Он предполагает преобразование уже существующих бизнес-моделей или развёртывание абсолютно новой модели, включающей в себя не только предприятие, но и его многочисленных партнёров, поставщиков и клиентов. При этом предприятие выбирает для себя ту роль или комбинацию ролей, которая наилучшим образом способствует достижению успеха. Так, предприятие может стать поставщиком сервисов, потребителем, брокером, агрегатором, компанией-свахой и т.д.
«Дорожная карта» включает в себя типичные этапы разработки ИТ-проекта, такие как начальный этап (анализ, разработка концепции, планирование), разработка, реализация, тестирование, применение (согласно методологии разработки программного обеспечения, предлагаемой компанией Rational). Стоит отдельно отметить, что каждый из этих этапов должен также включать в себя новые виды работ, связанные с идентификацией сервисных компонентов и их реализацией.
3 Необходимость управления SOA
Внедрение SOA позволяет предприятиям повысить свои возможности по взаимодействию с партнёрами, клиентами, поставщиками и т.д., и повысить уровень доходов. С другой стороны, SOA предполагает реструктуризацию приложений для повышения гибкости и снижения издержек, что, в свою очередь, невозможно без сотрудничества бизнеса и ИТ. Таким образом, предприятию необходимо продумать пути обеспечения тандема этих двух сфер и выработать новый способ отображения бизнес-требований в ИТ-приложениях. И организационное управление играет здесь как никогда большую роль. В следующих разделах мы расскажем о том, каким же образом можно установить функции для управления SOA.
3.1 Обоснование необходимости управления SOA. Задачи управления SOA.
Взаимодействие бизнес- и ИТ-составляющих предприятия должно осуществляться очень быстро, чтобы предприятие могло сразу реагировать на изменяющиеся возможности и задачи бизнеса. Задача бизнеса – расставить приоритеты для новых ИТ-сервисов, которые разрабатываются и управляются как часть высокоинтегрированной и сложной архитектуры. Этого невозможно добиться без ключевых функций управления, необходимых для составления успешной «дорожной карты», о которых будет сказано ниже.
Управление позволяет создать всеохватывающую структуру, которая определяет приоритеты и затем поддерживает бизнес-задачи на стратегическом, функциональном и операционном уровнях. Модель управления определяет «что делать», «как это сделать», «кто должен этим заниматься» и «каким образом оценивать достигнутое». Она диктует правила, определяет процессы, системы показателей и организационные структуры, необходимые для эффективного планирования, принятия решений, управления и контроля за работой SOA-инфраструктуры. Без этого невозможно удовлетворить корпоративные бизнес-требования и добиться выполнения поставленных задач. Как уже отмечалось выше, проектный отдел по работе с SOA отвечает за разработку такой модели.
Следующие вопросы помогут вам определиться с выбором подходящей для вас структуры управления:
• Что вы надеетесь изменить в вашем бизнесе с помощью SOA? Является ли внедрение SOA наилучшим способом использования существующей инфраструктуры, способным снизить издержки? Какую именно цель вы преследуете: создать новую модель бизнеса или новую модель взаимодействия? Или и то, и другое?
• Какие роли, обязанности, структуры и процедуры, позволяющие определять приоритеты бизнеса, осуществлять финансирование ИТ, планирование, управление и принятие решений, существуют на вашем предприятии?
• Какими возможностями вы обладаете в деле повышения компетентности лидерства и развития необходимых навыков?
• Использование каких принципов и методов вы считаете оптимальным для обеспечения слияния бизнеса и ИТ?
• Какой способ структуризации взаимодействия бизнеса и ИТ, обеспечивающий целостность и гибкость и позволяющий предприятию чутко реагировать на изменения, вы считаете для себя наиболее приемлемым?
• Какой уровень стандартизации сервисов, их определения и описания является для вас оптимальным?
• Каким образом вы контролируете и измеряете функциональность сервиса и оцениваете поставщиков сервисов? Какие ключевые показатели эффективности бизнеса вы отслеживаете в первую очередь? Кто занимается мониторингом, описанием изменений в сервисах? Кто уполномочен разрешать или не разрешать производить подобные изменения?
• Каким образом вы осуществляете выбор сорсинговой стратегии для сервисов?
Выбор модели управления имеет решающее значение для успешного решения поставленных задач, поэтому далее речь пойдёт о важных функциях управления. Начать следует с обсуждения существующей структуры предприятия и затем подогнать её под ту, что описана в вашей «дорожной карте».
Для того, чтобы осуществлять управление архитектурой, нужно с помощью организационной структуры определить круг ролей и обязанностей, которые для этого необходимы. Опыт показывает, что было бы неплохо основать центр управления SOA (COE), который бы контролировал следование «дорожной карте» и занимался поддержкой крупных и комплексных проектов. Центр COE следит за тем, чтобы реализация SOA была согласована с бизнес-требованиями на стратегическом, тактическом и операционном уровнях. В его полномочия входит одобрение технических артефактов, таких как планы и схемы архитектуры, корпоративные шаблоны и проектные ресурсы.
3.2 Модель управления SOA
В данной статье мы взяли за основу модель, описанную Ивон Бальцер (Yvonne Balzer). Концепция управления SOA, по сути, является ничем иным как более глубоко переосмысленной идеей управления ИТ, с той лишь разницей, что предполагается несколько большая степень вовлечения бизнеса в дело обеспечения поддержки ИТ-компонентов сервисов. Существует множество определений ИТ-управления, но мы отдаём предпочтение тому, которое даёт Институт Управления ИТ (The IT Governance Institute). Предлагаем вам с ним ознакомиться.
Определение понятия «управление ИТ», которое даёт Институт Управления ИТ
ИТ-управление является обязанностью совета директоров и высшего исполнительного руководства. Оно является неотъемлемой частью управления предприятием и состоит из руководящей и организационной структур и процессов, с помощью которых осуществляется контроль за тем, насколько ИТ следует стратегии в решении задач.
Цель ИТ-управления состоит в том, чтобы направить усилия ИТ на обеспечение согласованности деятельности ИТ с бизнес-задачами. Об этом можно судить по следующим критериям:
• Слияние ИТ и бизнеса приносит прибыль.
• ИТ способствует использованию всех имеющихся возможностей и получению максимальной прибыли.
• ИТ-ресурсы используются рационально.
• Риски, связанные с ИТ, тщательно прорабатываются и с ними несложно совладать.
Управление SOA предполагает управление моделью предприятия. При этом модель предприятия рассматривается как набор стандартизированных модульных бизнес-компонентов и процессов, для которых нужно определить приоритет в соответствии с требованиями эффективности. Таким образом, модель управления SOA представляет собой комбинацию организационной структуры, связанных процессов, а также взаимоотношений и взаимодействий, основывающихся на установленных общих правилах, называемых принципами управления, и стратегического руководства.
3.3 Стратегическое руководство и принципы управления SOA
Для того чтобы направить деятельность предприятия на решение бизнес-задач и согласовать её с бизнес-требованиями, необходимо составить стратегическое руководство по разработке SOA. Бизнес-стратегия и задачи должны быть понятны и бизнес-составляющей, и ИТ-составляющей. Причём обе составляющие должны прийти к единому пониманию бизнес-стратегии и бизнес-задач, поскольку на принципах управления и стратегии основывается принятие всех решений. Именно принципы управления и стратегия определяют область принятия решений и то, каким образом будут взаимодействовать бизнес и ИТ. Поэтому все стороны, вовлечённые в проект, начиная с представителей руководства и заканчивая участниками отдельно взятого проекта, должны руководствоваться едиными принципами, которые понятны всем.
Е.Г. Надхан (E.G. Nadhan) выделяет 2 основных подхода к управлению:
• Централизованное управление оптимально подходит для отдельного предприятия. В отдел по управлению входят представители каждого бизнес-подразделения и от экспертов в области технологий. Отделом рассматриваются вопросы по созданию новых и удалению старых сервисов, по внесению изменений в существующие сервисы и принимаются окончательные решения.
• Распределённое управление оптимально для рассредоточенных подразделений. Каждое бизнес-подразделение само осуществляет контроль над работой сервисов в рамках своего отдела. Для того, чтобы это стало возможным, необходимо разработать подходы к функционированию сервисов в рамках всех бизнес-подразделений. А разработкой стандартов и стратегий будет заниматься центральный комитет по управлению.
Каждый из этих подходов соответственно предполагает свои принципы построения архитектуры и по-своему рассматривает сервисы. Существуют и другие подходы, которые ставят во главу угла процессы, бизнес-функции или даже построение моделей компонентов (излюбленный подход IBM). Неважно, какой из них вы выберете для построения архитектуры на вашем предприятии, главное - обеспечить единое понимание и единую интерпретацию выбранного вами структурированного подхода бизнесом и ИТ.
3.4 Распределение полномочий и финансирование
Переход на SOA - это смена парадигмы, предопределённая необходимостью создания более гибких бизнес-моделей, достижения более высокого уровня интеграции и более тесного взаимодействия бизнеса и ИТ. Подобные перемены на предприятии могут быть встречены сопротивлением, и в результате все благие и полномасштабные начинания могут закончиться лишь внедрением Web-сервисов в какой-то небольшой предметной области. Успешная реализация SOA-проекта возможна только при активной поддержке проекта высшим руководством, согласованном финансировании и грамотном распределении полномочий в отделе по управлению SOA.
Одна из проблем, с которыми вы можете столкнуться – это учреждение формального, так сказать, «марионеточного» отдела по управлению SOA, который способен только консультировать, но не в силах претворить собственные рекомендации в жизнь. Ведь в конечном счёте отдел по управлению должен быть в состоянии обеспечить надлежащий контроль финансирования проекта.
Опыт показывает, что комитет/отдел по управлению должен быть способен обеспечить надлежащий контроль финансирования проекта.
3.5 Управление рисками, связанными с «дорожной картой» SOA.
Приступая к следованию «дорожной карте», отдел по управлению прежде всего должен обеспечить необходимый старт и проанализировать риски. Анализ и оценка рисков должны периодически повторно проводиться отделом управления на протяжении всего цикла разработки. Схема 1 поможет вам получить представление о том, каким же образом нужно оценивать готовность предприятия к переходу на сервис-ориентированную архитектуру и факторы риска, которые с этим связаны. (см. схему 1)
На схеме указаны важные аспекты и критерии, которые следует принять во внимание. Хотя, конечно же, не стоит забывать, что вы должны выбирать те критерии, которые важны именно для вас, в зависимости от ситуации и индивидуальных особенностей вашего проекта. Цель проведения подобной оценки – выявить проблемы на техническом, операционном и организационном уровнях, а также понять, какие проблемы и обстоятельства могут помешать переходу предприятия на SOA, т.е. смене текущей бизнес-модели предприятия на сервис-ориентированную. Проведение оценки невозможно в условиях отсутствия понимания между предприятием и клиентами или партнёрами. Оценка покажет, возможно ли с помощью сервис-ориентированной архитектуры отобразить изменения нужд и требований клиента или партера в существующих программных продуктах и приложениях.
На основании полученных данных вы сможете составить адекватный план действий, направленных в основном на то, чтобы повысить готовность вашего предприятия к переходу на сервис-ориентированную архитектуру или, иными словами, поработать над слабыми местами и подтянуть предприятие до необходимого уровня готовности. Опять же отметим, что все усилия по повышению готовности предприятия должны реализовываться в виде тщательно спланированных проектов.
3.6 Процессы управления SOA
К процессам управления относятся процессы, необходимые для стратегического бизнес- и ИТ-планирования, например, разработка стратегии, техническое ИТ-планирование, управление портфолио, сорсинговые процессы, управление нововведениями и управление архитектурой. ИТ любой организации также требует процессов, связанных с осуществлением контроля. Уровень реализации таких процессов зависит от размеров компании: они могут осуществляться как на уровне отдельных отделов, на уровне департаментов, так и на более высоком уровне. Мы предлагаем приступить к обсуждению самых важных процессов управления.
Процесс идентификации и расстановки приоритетов для бизнес-компонентов:
• Определяет структурированный подход к моделированию, идентификации и расстановке приоритетов для бизнес-процессов и сервисных компонентов.
• Помогает формально определить бизнес-цели и ключевые показатели эффективности (они могут быть определены архитектурой и при помощи реализации процесса).
Процесс нейтрализации неисправностей при возникновении исключительных ситуаций
• Модели бизнес-процессов редко бывают исчерпывающими. Никто не может предусмотреть все, что может произойти на предприятии, поэтому жизненно необходимо установить правила поведения в исключительных ситуациях.
• Такой подход к делу гарантирует, что построенная вами архитектура содержит в себе точки входа, позволяющие определенным категориям пользователей или процессов игнорировать обычные, формализованные процессы и исключения процессов. Таким образом, обеспечивается дополнительная гибкость
Процесс обзора архитектуры
• Представляет собой структурированный подход к обзору и одобрению изменений существующей SOA- архитектуры и к принятию решений на основе принципов управления.
• Обзор формального дизайна архитектуры и оценка сервисов имеют решающее значение для центров управления, поскольку именно эти показатели позволяют судить о развитии SOA-архитектуры.
Процесс обработки исключительных ситуаций в архитектуре и обращения к компонентам архитектуры
• Обеспечивает средства, с помощью которых можно обращаться к архитектурным решениям.
• Позволяет решать бизнес-задачи, несмотря на возникшие исключения в архитектуре.
Процесс поддержания жизнеспособности архитектуры
• Следит за тем, чтобы SOA работала и воспринимала новые сервисы.
• Следит за тем, чтобы любые изменения, внесенные в архитектуру, были задокументированы, и чтобы архитектура реагировала на эти изменения.
Коммуникационный процесс архитектуры
• Благодаря ему SOA доступна всем, кому она требуется.
• Полностью обосновывает ту важную роль, которую играет SOA.
Теперь, когда мы рассмотрели самые важные процессы, поговорим о том, как реализовать модель управления на практике.3.7 Применение модели управления на практике
Процесс, который мы используем для разработки модели управления, состоит из трёх этапов (см. схему 2). Ключ к успеху состоит в том, чтобы с первого же дня установить функции управления. Для того, чтобы процесс занял у вас меньше времени, рекомендуем реализовывать составленную вами модель на практике в 3 этапа:
Этап 1: Пробное введение в эксплуатацию
• Задействуйте основные принципы и методы управления во время осуществления предприятием своей деятельности.
• Проведите первичный анализ работы SOA.
• Методом проб налаживайте работу SOA. Используйте полученный опыт, экспериментируйте с доступными ресурсами, которые гарантированно обеспечат результат в кратчайшие сроки.
• Этот этап предполагает вовлечение опытных специалистов.
• Продумайте ваши дальнейшие действия.
Этап 2: Наладить работу на профессиональном уровне (автоматизация)
• Создайте необходимые структуры, процессы, методы и инструменты.
• Используйте опыт, приобретённый на первом этапе.
• Задайте первоначальные параметры сервис-ориентированной модели и базовые методы построения архитектуры.
• Соберите команду из опытных архитекторов и специалистов в области методологии.
Этап 3: Стабилизация
• Обучайте ваш персонал работе с SOA и предоставьте ему возможность применить эти знания на практике.
• Не только управляйте, но и снабжайте персонал инструкциями.
• Взращивайте обучающих специалистов.
3.8 Полезные советы
Даже если вы хорошо наладили управление, вам предстоит столкнуться с целым рядом проблем, способных помешать эволюционированию вашей SOA. Таким образом, очень важно начинать строить дом SOA на крепком и надёжном фундаменте. Вот какой практический опыт мы вынесли для себя:
• Установите правила и определите роли для организации усилий в деле SOA.
• Регулярно общайтесь. SOA также подразумевает перемены в корпоративной культуре, поэтому общаться между собой крайне важно для избежания и преодоления барьеров и разногласий. Особенно это касается бизнес-направлений и технологических отделов.
• Документируйте каждое принятое решение, ограничение и полномочия, чтобы обеспечить прозрачность принятия решений и, как следствие, заинтересованность и участие всех отделов в общем деле.
• Определите основную документацию, набор необходимых инструментов и шаблонов. Они должны быть понятными всем сторонам, участвующим в SOA-проекте.
• Установите удобный инструментарий, с помощью которого будет осуществляться управление на протяжении всего жизненного цикла. Особо внимательно отнеситесь к долгосрочным бизнес-процессам, о которых пойдет речь ниже.
• Взвесьте и оцените каждое решение, задокументируйте и укажите ту степень важности, которую вы ему присвоили. Известите сотрудников о своих решениях.
• Продолжайте поддерживать заинтересованность всех отделов и подразделений. Продолжайте политику финансирования, исходящего от всех сторон, участвующих в проекте.
4. Техническое управление SOA
Внедрив SOA, вы должны быть готовы к тому, что циклы ваших бизнес-процессов могут отличаться от циклов тех продуктов, которые вам предлагают поставщики. Вы неизбежно столкнётесь с тем, что, имея дело с долгосрочными процессами, вам придётся поддерживать сценарии, в которых сосуществуют разные версии одного и того же процесса в изменяющейся инфраструктуре. А это будет накладывать определённый отпечаток на цикл развития проекта, осложняя его. Таким образом, увеличится не только длительность цикла, усложнится инструментарий, а также методы, используемые для определения бизнес-процессов, осуществляющихся на вашем предприятии.
Устранить проблемы, возникающие из-за несовпадения циклов, можно следующим образом:
• Снизить уровень того влияния, которое оказывают изменения, за счет модуляризации
• Добиться независимости промежуточного ПО, точно определив состояние процесса
• Мониторинг исключительных ситуаций в бизнесе и работа с ними
4.1 Снижение влияния, оказываемого изменениями, за счет модуляризации
Также как сервисы могут обладать разным уровнем гранулярности и изменчивости, процессы тоже можно характеризовать с позиций гранулярности. Она появляется, когда процессы представляют собой совокупность индивидуальных модулей. Каждый модуль предлагает свой сервисный интерфейс и внутренне регулирует своё состояние. Таким образом, гораздо проще вносить изменения в процессы, разрабатывая новые модули процессов, выбранные из существующих сервисов, использующих политики.
4.2 Добиться независимости промежуточного ПО, точно определив состояние процесса
Механизмы промежуточного ПО, осуществляющие текущие бизнес-процессы, сами внутренне регулируют состояние процессов. Налицо зависимость между ними. Получается, что решение всех вопросов, связанных с процессами, привязано к тому или иному механизму промежуточного ПО, а иногда даже к определённой версии промежуточного ПО. Для того чтобы избежать этой привязки, разработчикам процессов следует поднять уровень возможного определения состояния процесса. Однако это приведёт к возникновению состояний ожидания до момента получения внешнего события.
Таким образом, необходимо определять и регулировать состояние процессов, рассредоточенных в разных частях SOA-инфраструктуры. Один из вариантов решения этой проблемы – набор спецификаций, включенных в WS-Resource Framework. Эти спецификации помогут программистам описать и наладить взаимосвязь между Web-сервисами (модулями процессов) и одним или несколькими компонентами, называемыми WS-Resources.
Комментариев нет:
Отправить комментарий