Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Автор: Mike Kavis

Оригинал статьи: «Opinion: Top 10 reasons why people make SOA fail»

Недавно в нескольких статьях обсуждалось почему проваливаются многие инициативы SOA. В начале июля, делая презентацию на ежегодной конференции Burton Group, вице-президент и директор по исследованиям компании Anne Thomas Manes сказала, что провалы SOA чаще всего связаны с человеческими и культурными, а не технологическими проблемами. Я полностью поддерживаю это утверждение, так как я в течение длительного времени говорю то же самое в своем блоге.

Итак, теперь мы знаем кого винить в провалившихся инициативах SOA. Это люди, тупица! Но как именно люди проваливают SOA? Дайте-ка я посчитаю.

1. Им не удается объяснить экономический эффект SOA.

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

Рекомендация: начните с реальных проблем бизнеса. Именно из-за этого BPM является приложением номер один («killer app») для SOA. Улучшая и автоматизируя бизнес-процессы, BPM решает несколько проблем бизнеса. Он обеспечивает прозрачность операционной эффективности, повышает гибкость, давая возможность бизнесу динамически менять процессы без вовлечения ИТ, устраняет потери – таким образом сокращая издержки – и многое другое. Для начала покажите бизнесу как SOA решит реальные проблемы бизнеса. Потом переходите к технологическим аспектам.

2. Они недооценивают роль организационных изменений.

Как и для любой инициативы, предполагающей трансформацию, сопротивление изменениям – это убийца проекта. SOA приносит в организацию значительные перемены, особенно если в организации отсутствует продуманная корпоративная архитектура. Основной вклад в сопротивление переменам приходится на страх перед неизвестным. Людям необходимо понимать «что я буду с этого иметь» и почему изменение порядка вещей – благо для них и для компании. Сложность в том, что люди на разных уровнях организации затрагиваются по-разному. На каждом уровне свои заботы, которые надо принимать во внимание, причем подход должен быть индивидуальным.

Рекомендация: разработайте план организационных изменений. Я бы пошел на шаг дальше и нанял внешнего эксперта по организационным изменениям, чтобы помочь инициативной команде SOA управлять этими изменениями. Я большой фанат восьми-шаговой методологии John Kotter.

3. Им не удается обеспечить серьезную поддержку со стороны руководства.

У вашей инициативы SOA мало шансов достичь поставленных целей без серьезной поддержки со стороны руководства. SOA покрывает различные подразделения и различные системы, и в этом основная сложность. Сильный руководитель вам нужен, чтобы инициатива развивалась, и чтобы преодолевать возникающие на пути барьеры. Но только пинков недостаточно. Этот человек также должен обладать достаточным временем, чтобы концентрироваться на инициативе SOA, поддерживая на верхнем уровне ощущение актуальности.

Рекомендация: Если SOA у вас привязана к бизнес-потребностям, спонсором из числа руководства должен быть высокопоставленный человек, который получит от реализации существенную выгоду. Позвольте бизнесу владеть и продвигать портфолио проектов, приводящих в движение календарный план SOA. В технологических компаниях спонсор из числа руководства – это, вероятно, генеральный директор, ИТ директор, директор по технологиям или главный архитектор. Кого бы вы не выбрали, этот человек должен уметь сдвигать горы и должен обладать послужным списком успешного руководства.

4. Они пытаются сделать SOA «задешево».

SOA – это то, что вы должны делать, а не то, что вы можете купить. Некоторые компании пробуют SOA с ограниченным бюджетом. В дополнение ко всему требуемому промежуточному ПО, есть еще огромные инвестиции в инструментарий для управления, в обучение, консалтинг, инфраструктуру и безопасность.

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

Рекомендация: Создайте план-график SOA с портфолио проектов и видение долгосрочного выигрыша, который даст компании SOA. Создайте финансовое обоснование для всей инициативы SOA и покажите ROI, NPV, IRR или другой финансовый показатель, самый важный для компании. Если вы создадите достаточно хорошее бизнес-обоснование, то для финансирования инициативы будет достаточно денег. Есть также несколько замечательных Open Source продуктов, которые могут значительно снизить общую стоимость вашей реализации SOA.

5. Им не хватает навыков, необходимых для реализации SOA.

Есть много специализированных ролей и наборов умений, которых вероятно нет в вашей организации. Вам нужны архитекторы SOA, специалисты по моделированию бизнес-процессов, администраторы входящих в стек программных средств, архитекторы данных и многие другие. Это не дешевые позиции. Пытаться реализовать SOA без опыта SOA – это главная ошибка. SOA затрагивает все подразделения ИТ, включая тестирование, инфраструктуру и безопасность. Это намного сложнее, чем просто отправить небольшое число разработчиков на небольшое число учебных курсов. И не забывайте также про бизнес. Бизнесу нужно обучение по усовершенствованию процессов и, возможно также, даже по инструментарию BPM.

Рекомендация: разработайте обширный план обучения и использования ресурсов, и сделайте его частью начального запроса финансирования, когда будете разрабатывать финансовое обоснование SOA. Постарайтесь уменьшить число обращений за деньгами и получить как можно больше заранее. Иначе менеджмент будет смотреть на инициативу SOA как на бесконечную утечку капитала.

6. У них слабое управление проектами.

В конце концов, все сводится к способности компании управлять проектами. Менеджеры проектов должны очерчивать границы, снижать риски, держать всех в графике и обеспечивать надлежащие коммуникации с людьми на всех уровнях. Сбор требований критичен, тут надо избежать аналитического паралича. Если в вашей компании приходится бороться за обычный проект, то ваши шансы на успех с SOA будут вдвойне сомнительны.

Рекомендация: назначьте в проект ваши лучшие управленческие ресурсы. Или выйдите наружу и привлеките в помощь рок-звезду или двух, чтобы возглавить эту инициативу. Кого бы вы не выбрали, у него должен быть послужной список реализации обширных инициатив, связанных с трансформацией. Что еще более усложняет поиск – этот человек должен достаточно разбираться в технике, чтобы понимать SOA на концептуальном уровне.

7. Они думают о SOA как о проекте вместо архитектуры.

Многие компании наивны и думают, что реализация SOA – это просто еще один проект. SOA – это программная архитектура, и она дает желаемую выгоду только когда компания следует основным принципам сервис-ориентированности и добивается того, что результаты следуют видению архитектуры и календарному плану. SOA требует специализации. Бизнес-сервис может быть построен усилиями архитектора SOA, разработчика, архитектора данных, сетевого архитектора и специалиста по безопасности. Прошли времена, когда один человек носил все шляпы. Есть также специализация по уровням стека. Есть дизайнеры пользовательского интерфейса, специалисты по моделированию бизнес-процессов, эксперты по сервисам данных, специалисты по бизнес-правилам, специалисты по ESB и т.д. Все эти специалисты могут одновременно работать над одним сервисом, что требует высокого уровня сотрудничества.

Рекомендация: стандартная структура команды ИТ неэффективна для SOA. Не замыкайтесь в рамках. Я предпочитаю матричную организацию и среду ситуационной комнаты. Уберите офисные кубики и организуйте открытое пространство, чтобы все эти специалисты могли работать вместе в тесном контакте. Полезно, чтобы в комнате были также тестировщики и люди бизнеса. Расставьте повсюду доски для совещаний. Ликвидируйте, насколько это возможно, плановые совещания и используйте практики, более ориентированные на совместную работу.

8. Они недооценивают сложность SOA.

Чего вы не знаете, того не знаете. Концептуально, SOA – это просто новый этап эволюции того, что ИТ делает в течение лет. Эту концепцию несложно понять, но трудно корректно реализовать. Прелесть SOA и BPM в простоте, которую они дают конечным пользователям, интегрируя различные бэк-системы таким образом, что они выглядят для пользователя как одно композитное приложение. Оборотная сторона SOA – то, что это в значительной степени увеличивает сложность создания и поддержки программного обеспечения. Реализация SOA – это упражнение в программной инженерии. Это не усилие в стиле drag-and-drop, и многим разработчикам придется бороться, чтобы совершить переход. SOA требует следования стандартам и передовому опыту (управление) и нуждается в талантливых личностях, понимающих сложные концепции в такой степени, что могут их реализовывать.

При внедрении SOA надо сделать так много, что безопасность зачастую оставляют на потом. Критически важно собирать требования по безопасности на ранней стадии, чтобы нижележащая архитектура с самого начала обеспечивала безопасность. В противном случае, если с безопасностью разбираться потом, то с большой вероятностью в архитектуру понадобится вносить большие изменения.

Рекомендация: сколь бы вы не были консервативны, будьте готовы к различным техническим заторам на пути. Делайте вовремя, потому что вы встретитесь с различными интеграционными проблемами, некоторые из которых будут связаны с вашим кодом и некоторые – с самим инструментарием. Все продукты вендоров далеки от зрелости, и с ними будут проблемы. Будьте реалистичны в ожиданиях, и не пытайтесь сделать слишком много за слишком короткий срок. Начните с малого, выдавайте результаты чаще, и пользуйтесь ими. Встраивайте безопасность с начала, не оставляйте на потом.

9. Им не удается реализовать управление SOA Governance и следовать ему.

Governance – для многих людей слово ругательное. Все что отдаленно звучит похоже на «правительство» (government) не может быть хорошим, не так ли? Неправда! Назовите это “SOA management”, и может быть люди не будут дрожать так сильно.

В любом случае, чтобы получить выгоды SOA (повторное использование, гибкость, быстрые изменения), команда должна следовать принятым в компании архитектурным рекомендациям. Это то, что называется управлением во время разработки. Без управления во время разработки, вы вероятно придете к ПКВС – просто куче веб сервисов. Если это произойдет, вы можете выкинуть расчеты ROI из окна, потому что, вы придете к тому, что каждый раз все будет разрабатываться с нуля. При правильном подходе SOA со временем становится все более экономичной. В конце концов, усилия в разработки сместятся от создания сервисов к использованию сервисов. Jason Bloobmerg, аналитик из ZapThing LLC, называет это моментом получения чаевых – когда SOA начинает получать выгоду от быстрых изменений и гибкости.

Еще есть управление во время исполнения. Здесь вы заблаговременно управляете состоянием вашей промышленной среды SOA. Управление во время исполнения позволяет вам видеть какие сервисы используются, накладывать политики и SLA, искать неисправности, анализировать производительность и управлять всеми активами. Не думайте что с инсталляцией все заканчивается. Управление распределенной средой – не та задача, к которой можно относиться поверхностно.

Рекомендация: относитесь к управлению, как к полноценно финансируемой инициативе, развивающейся вместе с вашей реализацией SOA. Должна быть выделенная команда (обычно в составе подразделения корпоративной архитектуры) с собственным календарным планом и долгосрочной перспективой. Не пытайтесь реализовать управление за ночь. Это путешествие, достижение высокой степени зрелости займет несколько лет. Ваша SOA будет достигать зрелости вместе с управлением. Инвестируйте в каталог (registry), репозиторий (repository) и инструментарий управления. Для тестирования управления вам также понадобятся новые тестовые инструменты.

10. Они позволяют вендорам продвигать архитектуру.

Ron Schmelzer из ZapThink сфабриковал термин «vendor-driven architecture» (VDA). Если слишком сильно полагаться на вендора, то это может привести к беде. Цель вендора – продать вам как можно больше барахла. Ваша цель – успешно реализовать SOA и обеспечить вашей компании максимум пользы за минимальную цену. Видите конфликт интересов?

Далее, вендоры обещают гладкую интеграцию, если вы приобретете все инструменты из их стека. Реальность такова, что они накупили так много продуктов других компаний, что их стек обеспечивает интеграцию не лучшую, чем если вы покупаете инструменты у множества вендоров.

Рекомендация: решите, что вам нужно, до разговоров с вендорами. Тщательно проведите процесс оценки вендоров. Когда вы сузите его до нескольких вендоров, пусть они придут к вам и выполнят пилотный проект «proof of concept», требования к которому дадите вы. Понаблюдайте собственными глазами, как они его будут выполнять. Тут вендоры уже больше не смогут прятаться за симпатичными слайдами PowerPoint; это может уберечь вас от совершения колоссальной ошибки. Делайте свое домашнее задание. Читайте блоги практиков, разговаривайте с консультантами, использующими инструменты, разговаривайте с другими компаниями, реализовавшими SOA, и разговаривайте с референсами вендоров. Не ищите коротких путей - вам придется жить с теми решениями, которые вы примите.

Комментарии