|
|
Обозрение подготовлено
На успешность реализации СОА-проектов может повлиять множество факторов. Если компания готова к длительным инвестициям и к переменам в устоявшихся бизнес-процессах, если движение к сервис-ориентированной архитектуре происходит под руководством квалифицированного и наделенного соответствующими полномочиями CIO, то у такого СОА-проекта, по мнению экспертов, есть значительные шансы принести компании ожидаемый экономический эффект.
По наблюдениям аналитиков, построение сервис-ориентированной архитектуры оказалось для бизнеса удачной возможностью уйти от проблем с имеющимися приложениями и неудачно реализованными ранее ИТ-проектами. Однако на практике построение СОА само по себе сложное и рискованное предприятие.
Эксперты отмечают, что количество неудачных СОА-проектов примерно равно числу успехов в этой области. Иными словами, в 50% случаев компания имеет шанс потерпеть неудачу. Причем вероятность провала СОА-проекта резко возрастает в том случае, если его заказчиком выступает одна из 2 тыс. крупнейших мировых компаний или правительственная структура. Наиболее успешные СОА появляются в результате следования методологическим рекомендациям по построению. Есть ряд факторов, влияющих на успех проекта, и взгляд заказчика на текущий СОА-проект с учетом этих факторов позволит ему определить, потерпит его СОА-проект неудачу, или же окажется успешным.
Самым главным достоинством «лучших практик» в области СОА является то, что выстроенная архитектура сочетает в себе старые проверенные ИТ-решения с новыми методиками, что позволяет систематически вносить важные преобразования в привычные области деятельности персонала и внедрять новые технологии.
Основной причиной провала СОА-проектов является кадровая проблема. Причем она может проявиться как со стороны руководства компании, так и со стороны рядовых сотрудников. Особенно критичной является нехватка квалифицированных специалистов, разрабатывающих архитектуру. При этом речь идет не столько о недоукомплектованности ИТ-департамента, сколько о недостаточной компетенции имеющихся ИТ-специалистов в области СОА, а также о недостатке умений и полномочий для того, чтобы произвести необходимые изменения.
Но все-таки провал СОА по вине человеческого фактора обычно начинается сверху. Правда, по данным исследования Barton Group, смена ИТ-директора в ходе провального проекта может привести и к позитивному результату. Ключевым фактором успеха в этом случае становится инициатива руководства, его способность изменить сложившийся образ работы компании, а затем и ее архитектуру.
Не менее значимым для успешного развития СОА условием является наличие инновационно настроенных лидеров. Такие руководители осознают значимость инвестиций в инфраструктуру и понимают, насколько это важно для успешного развития компании.
Топ-менеджменту компании важно понимать, что СОА не обойдется дешево. Потребуется внесение множества изменений во все составляющие существующей системы: в процесс проектирования, тестирования и применения на практике информационных систем. Стоимость этих инвестиций может составить миллионы долларов, которые потребуются, в том числе, и на обучение специалистов, готовых разработать технологию, с помощью которой будут произведены необходимые компании преобразования.
Инвестиции в СОА нельзя рассматривать как одноразовый «преобразовательный» проект. Напротив, компания должна считать СОА путем развития. Планируя его, следует предусмотреть серию проектов, определяющих основные направления дальнейшего развития компании. Необходимо предварительно оценить ориентировочную стоимость данных усилий, чтобы инвестиции послужили достижению поставленных ранее целей. Предприятия должны остановить свой выбор на долгосрочной стратегии управления, которая подразумевает многолетнюю (и обычно многомиллионную) нацеленность на проведение систематических изменений в имеющейся инфраструктуре.
К сожалению, большинство СОА-проектов в определенный момент замораживаются - чаще всего из-за нехватки бюджетных средств или перераспределения финансовых ресурсов в пользу краткосрочных проектов. В этом случае СОА не имеет шансов быть завершенной, и задача руководителя – не допустить подобного поворота событий.
Для построения СОА требуется провести два ключевых изменения в управлении бизнесом, в которых прежде не было необходимости. Первое – это разделение управления архитектурой между различными отделами компании, сопряженное с риском потери контроля над разработками. Другая необходимая перемена состоит в необходимости пересмотра устоявшегося мнения по поводу основных бизнес-процессов, по поводу таких понятий, как сложившаяся бизнес-практика, распределение ресурсов, «политическое влияние» и др.
Большинство сотрудников, находящихся на нижних ступенях служебной лестницы, может, и готовы перейти на СОА. Но хотели бы, чтобы к СОА их привела управленческая команда. Реалии таковы, что сами управленцы зачастую не обладают необходимыми для этого навыками и способностями. Поэтому руководству необходимо четко определиться, кто именно поведет компанию вперед, к СОА. Возможно, это приведет к необходимости замены сотрудников ИТ-департамента или увеличения его штата. Оба варианта дорогостоящие. Многие компании, осваивающие пути перехода на СОА, приглашают для этих целей консультантов или внешних управляющих СОА-проектом. Ряд предприятий инвестируют в соответствующее обучение сотрудников или даже принимают в штат целые команды консультантов для помощи в проведении преобразований. Однако вне зависимости от специфики деятельности компании ей не стоит даже пробовать переходить к СОА с «неправильными» людьми – такие попытки ни к чему не приведут.
Приближение к СОА подразумевает изменения в дальнейшем развитии архитектуры и систем компании. Раньше многие компании, готовые принять СОА, использовали средства, казавшиеся на тот момент современными, для решения краткосрочных задач. Но то, что они не уделяли должного внимания долговременному развитию, оборачивалось лишь новыми тактическими проблемами.
При стремлении к СОА потребуются продуманные практические шаги, которые позволят компании разделить архитектуру на простые функциональные процессы, а затем выстроить ее снова, но уже в виде СОА. Даже если речь идет о небольшой компании – ей также необходимо разбить архитектуру на составляющие, а потом работать с каждой частью: вначале последовательно, а затем и параллельно.
Дальнейшая работа связана с изучением информации с помощью семантики и метаданных. Это потребует больших усилий, поскольку большинство предприятий обычно не имеют ясного представления об имеющихся семантических уровнях. Усилия компаний обычно направлены не на рассмотрение существующих процессов, а на создание новых. Многие специалисты, занимающиеся СОА, пропускают этот важный этап, что, безусловно, наносит вред проекту.
По окончании данного этапа компания должна перейти к сервисам - дать определение существующим и новым, из которых будет состоять СОА. Этот этап нужен для выяснения того, какие сервисы в компании уже имеются, какие еще потребуются, а также для структурирования сервисов с целью их последующего использования. Необходимо убедиться в том, что удалось в полной мере определить и задокументировать сервисы, а затем объединить их в уже продуманную модель.
При этом следует иметь в виду, что большинство сервисов составят уже существующие. Многие думают, что СОА – это в первую очередь построение новых сервисов, но чаще всего это оказывается не так. Большинство неудачных СОА-проектов становятся таковыми вследствие того, что руководители проектов пытаются «изобрести велосипед» вместо того, чтобы заниматься решением неотложных проблем компании.
При объединении сервисов можно выбрать один из трех возможных вариантов. Во-первых, можно объединить сервисы в необходимые процессы на программном уровне. Во-вторых, можно использовать BPEL для объединения сервисов в готовое бизнес-решение. И, наконец, третий способ такого объединения – это использование традиционных инструментов интеграции. Какой бы вариант ни был выбран, необходимо убедиться в том, что он соответствует требованиям, предъявляемым компанией к проекту. Помимо этого, компании необходимо создать стратегию управления СОА, определить способ управления, основанный на избранной стратегии и инструментах, которые позволят поддержать создание и реализацию политики управления.
Многие забывают, что главное слово в аббревиатуре СОА – архитектура. Пытаются «перепрыгнуть» через эту часть и заняться технологией. Происходит это потому, что архитектура требует больших усилий и достаточно скучна, в то время как разработка технологии проста и интересна. Однако уделить время архитектурному планированию все-таки необходимо - чтобы вести СОА-проект компании в правильном направлении. Надо создать стратегию, бизнес-процессы, архитектуру, трезво оценить свой бюджет, - и только тогда можно приступать к самой важной части – направлять технологии на правильный путь.
Еще одна причина, по которой архитектурой пренебрегают, кроется в том, что в большинстве крупных компаний реализующие СОА-проект специалисты не имеют должных полномочий, что заставляет их подчиниться технологии. Обычно они могут лишь попытаться повлиять на руководство, но чаще всего при этом сталкиваются с непониманием и непоколебимостью решения. Из-за недостаточного авторитета специалистов по СОА долгосрочная стратегия будет обречена, если конечно, руководство не согласится их поддержать.
Вследствие этого решению краткосрочных потребностей уделяется значительно большее внимание, нежели долгосрочной стратегии. Руководство, пытающееся управлять организацией, пробует различные технологии одну за другой, пытаясь их применить без ясного плана относительно того, как все эти технологии будут сосуществовать в дальнейшем. В результате то, что называют архитектурой предприятия, часто оказывается не более чем наслоением этих бессвязных тактических усилий. Такие виды «архитектур» слишком сложны, чтобы изменяться в соответствии с новыми потребностями бизнеса.
Но если компания все-таки сумеет сосредоточиться на архитектуре, то у нее появится намного больше шансов на успех. Концентрация на архитектуре требует значительных изменений в работе сотрудников ИТ-отдела. Архитектура никогда не должна подвергаться влиянию технологии. Поскольку это существенное изменение в привычном образе работы, немногие сотрудники с готовностью и сразу на это пойдут. Поэтому руководству компании и приходится волевым усилием совершать такие изменения с целью поддержки долгосрочной стратегии. Но топ-менеджмент предприятия и должен поддерживать подобные преобразования, в противном случае это приведет к неоправданным тратам. Проблема заключается в том, что ненужные траты стали нормой работы крупных компаний и прячутся за таким понятиями как «постоянные издержки» и «издержки, обусловленные упущенными возможностями».
Не существует универсальной технологии СОА, которая подходила бы каждому предприятию. Компания должна осознавать необходимость соотнесения своих требований с «правильными» технологиями. Иными словами, технологические запросы должны соответствовать потребностям конкретной компании. Но большинство компаний при выборе архитектуры ошибочно руководствуются технологией. Они приобретают коробочное СОА-решение с надеждой, что оно решит все их проблемы. В итоге решение, не соответствующее их реальным потребностям, не может дать положительных результатов, и СОА-проект терпит неудачу.
Найти подходящую технологию для решения существующих проблем достаточно просто, однако требует серьезных временных затрат. Необходимо на одной стороне листа написать потребности компании, а на другой – технологии, которые могли бы помочь их удовлетворить. Затем следует выделить несколько наиболее подходящих технологий для последующего тестирования. Далее необходимо связаться с вендорами и проверить предположение о том, что данная технология действительно будет корректно работать в конкретной компании в условиях СОА.
Другой, не менее привлекательный для заказчика подход - взять решение, созданное для одной из крупнейших компаний и перенести этот опыт построения СОА на свое предприятие. Нельзя не согласиться, что определенная польза от скопированной технологии будет, но она не сможет полностью соответствовать индивидуальным потребностям компании. Принимая неподходящую технологию только лишь из удобства и выгоды от работы с единственным поставщиком, компания может привести СОА-проект к провалу. И наоборот: в большинстве случаев правильное технологическое решение для создания СОА будет состоять из совокупности технологий различных вендоров.
При построении СОА следует убедиться, что создаваемая архитектура независима от технологии. Может казаться, что легче строить архитектуру, опираясь на конкретную технологию, тем более что большинство вендоров предлагают так поступать. Но нельзя забывать, что технологии меняются постоянно, в то время как ядро архитектуры компании должно оставаться неизменным. Поэтому предприятию следует сначала разработать архитектуру и только потом позаботиться о технологии, которая будет ее поддерживать, учитывая дальнейшие технологические трансформации.
Успех СОА не является чем-то космически недостижимым. Это вопрос создания хорошо проверенных ИТ, которые дисциплинируют, которые способны поддерживать изменения потребностей заказчика, включая человеческий фактор, процессы, технологии и бизнес. Многие организации, потерпевшие в подобном проекте неудачу, поддались соблазну в погоне за «быстрыми и простыми» технологически-ориентированными решениями, забыв об основополагающих принципах СОА.
Причина большинства провалов СОА-проектов также состоит в отсутствии ясного понимания системных изменений, которых требовало построение СОА. Эта проблема касается различных уровней управления компанией и лежит в области разделения полномочий и сфер влияния. Задача сильного руководства - противостоять подобным проблемам, но большинство предприятий, кажется, не имеют влиятельного ИТ-лидера, а без него проект будет обречен на неудачу.
Основной принцип успешной СОА – наличие инновационного мышления у топ-менеджмента компании, наличие лидера, который способен и уполномочен преобразовывать свою компанию, опираясь на инновационные принципы. Многие предприятия могут приблизиться к выполнению требований СОА, но чаще всего для этого им требуется смена руководства, а иногда и некоторых рядовых сотрудников. ROI СОА-проекта является реальным и существенным, однако он требует от компании определенных «жертв» на старте проекта.
По материалам Barton Group
Сообщить факт о Windows XP
Почему устарела Windows XP?
Сообщить цифры о Windows XP