Статья

10 главных ошибок в СОА-проектах

Аутсорсинг

Все большее количество компаний в мире (и в России постепенно тоже) начинают СОА-проекты с целью сократить свои затраты на интеграцию приложений, с одной стороны, и повысить гибкость ИТ-инфраструктуры, с другой. Однако многие из этих инициатив начинают "буксовать" чуть ли не в самой начальной стадии. В итоге часть компаний так и не реанимируют данные проекты, вообще отказываясь от СОА в своих стратегиях информатизации. ZDNet приводит 10 самых распространенных ошибок, которые мешают реализации СОА-проектов.

СОА-проект - очень продолжительная ИТ-инициатива, в процессе реализации которой компании неизбежно сталкиваются с целым рядом сложностей. Негативный опыт, как и накопленные лучшие практики, позволяют выявить наиболее часто встречаемые "узкие места", которые следует сразу иметь в виду, ступая на "путь СОА". ZDNet приводит список из 10 самых распространенных ошибок, которые могут совершить компании, ведущие СОА-проекты.

1. Беспорядочный подход к сервисам. Часто, начиная переходить на СОА, компании выделяют веб-сервисы бездумно и беспорядочно. Это приводит к тому, что впоследствии многие сервисы оказываются избыточными или ненужными, а сама процедура становится неоправданно дорогой.

2. Игнорирование бизнес-аналитиков. Участие бизнес-аналитиков в СОА-проекте с самого начала критически важно для его успешного завершения. Однако проектные команды часто забывают об этом, фокусируясь исключительно на технических задачах внедрения, выделения веб-сервисов, а не на потребностях бизнеса.

3. Фокус внимания на продуктах в ущерб идеологии. Компании часто обращают больше внимания на собственно СОА-продукты - инструменты, интеграционные платформы и софт - а не на идеологическое планирование проекта по переходу на СОА. На самом деле, рассматривать продукты имеет смысл только после составления детального плана миграции на новую архитектуру.

4. Приоритет большим проектам. Самый практичный вариант начала перехода на СОА - реализация в первую очередь небольших проектов с минимальными рисками. У них, правда, наименее очевиден результат, но зато они формируют хорошую площадку для обучения, накопления опыта и необходимой базы знаний. Однако вместо этого компании часто начинают со сложных и крупных инициатив, риски у которых очень высоки. Такие проекты чаще бывают неудачными.

5. Отношение к СОА как к ИТ-задаче. В первую очередь, СОА должна быть бизнес-задачей, хотя она и маскируется под техническую. Только при таком подходе технические акценты не будут перевешивать более приоритетные бизнес-потребности.

6. Откладывание идентификации. Многие компании, только дойдя до середины проекта, вспоминают об идентификации пользователей и определении бизнес-ролей. Однако это должно быть жестко заложено в инфраструктуру еще на стадии планирования.

7. Закупка новых ИТ-продуктов. Надеясь в полной мере ощутить преимущества перехода на СОА, компании часто стремятся закупить много специализированных ИТ-решений. При этом особой необходимости в них может и не быть. Как правило, СОА-проекты можно начинать на уже существующем аппаратном и программном обеспечении, ограничиваясь минимальными дополнительными инвестициями.

8. Непонимание ключевых ролей. Часто у проектной команды и даже ее руководителя нет четкого понимания бизнес-ролей - и в частности, того, кто является ключевым "владельцем" данных в компании. Проект, в котором нет изначального понимания, какие подразделения владеют какими сервисами - практически обречен.

9. Надежда на быстрое распространение. Многие ожидают, что СОА-проекты будут быстро распространяться от одного бизнес-подразделения к другому - и всерьез расстраиваются, если этого не происходит. Однако именно постепенный медленный переход на сервисы всего предприятия является залогом более эффективной в итоге инфраструктуры.

10. Отсутствие ресурсов. Многие небольшие компании не располагают достаточными внутренними ресурсами и экспертизой для реализации СОА-проекта. Это приводит к накоплению ошибок и в конечном итоге к провалу. Однако средний и малый бизнес может прости идти своим путем, избегая негибких подходов и методик - и выделяя как веб-сервисы лишь самые необходимые элементы архитектуры.

Пол Каллахан