Конечно же, вы уже об этом слышали, и не раз: «SOA должна диктовать свои условия технологиям, а не технологии диктуют свои условия SOA». Дэвид Линтикум, сотрудник аналитической компании ZapThink, известной как ведущий консультант в области SOA, столкнулся с тем, что это правило соблюдается с точностью до наоборот. Все внимание сфокусировано на ESB и на уровнях управления ею, а не на построении правильной архитектуры как таковой. «Ведь SOA – это архитектура, не так ли?!» - недоумевает Дэвид и размышляет на эту тему, которой и посвящена данная статья. Тем более обидно, что речь идет о крупных финансовых вложениях, которые обречены на то, чтобы стать напрасными.

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

«Поймите меня правильно, - говорит Дэвид Линтикум, - Я не имею ничего против вендоров. Возложить вину за все происходящее на них было бы слишком просто и неправильно. Я всего лишь обращаю ваше внимание на неоспоримый факт: несмотря на то, что технологии являются неотъемлемой частью архитектуры, они должны зависеть от нее, а не наоборот». Иными словами, технологии должны быть следствием использования SOA архитектуры, а не ее движущей силой. Но, тем не менее, как показывает практика, на сегодняшний день преобладают «ESB-ориентированный», «ориентированный на сервисы приложений», «ориентированный на управление» и бог знает какие еще подходы к построению архитектуры».

Конечно, все вышеперечисленные подходы нельзя упрекнуть в полной несостоятельности. SOA-архитектура на предприятии построена, и она работает. Однако она работает не в полную силу и неспособна полностью раскрыть тот потенциал, который на нее возлагается. Так, многим организациям приходится довольствоваться временными, так сказать, «полуоптимальными» решениями, которые служат только несколько лет и требуют дальнейшей корректировки, чтобы предприятие могло идти в ногу с существующими на данный момент бизнес-требованиями, которые постоянно меняются. А ведь грамотно построенная SOA позволяет решить проблему раз и навсегда! Она позволяет сразу найти верное решение, не требующее дальнейшей корректировки! Архитектура сама достигает необходимой степени зрелости, ее не нужно менять через определенные промежутки времени.

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

Руководствуясь всем вышесказанным, Дэвид Линтикум предлагает примерный план действий:

1. Понимание на уровне Процессов

2. Понимание на уровне Сервисов

3. Понимание на уровне Данных

4. Моделирование Данных

5. Моделирование Сервисов

6. Моделирование Процессов

7. Моделирование Управления

8. Планирование системы Безопасности

9. Разработка Стратегии Тестирования

10. Выбор Технологии

Заметьте, что «Выбор Технологии» стоит в этом плане десятым пунктом, а не первым. Это только упрощенный схематичный план. На самом деле он включает в себя больше пунктов.

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

Понимание на уровне сервисов подразумевает, что вы знаете, какие сервисы имеются на вашем предприятии, для чего они нужны. Здесь речь также идет об информации, т.е. о метасервисах – претендентах на выполнение роли сервисов на вашем предприятии.

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

Следует отметить, что все эти пункты согласованы между собой, поэтому необязательно следовать им в заданном порядке, т.е. сверху вниз (от процесса к данным). Можно, наоборот, следовать плану снизу вверх, т.е. начать с последнего пункта и закончить первым (от данных к процессу).

Моделирование имеет в данном случае ключевое значение. Вы выявляете текущую информацию о данных, сервисах и процессах и используете ее для построения своего архитектурного решения. Это момент, когда «наука» уступает место «искусству». Грамотно построенная архитектура – это настоящее произведение искусства. «По правде говоря, мы уже много лет моделируем данные и процессы, однако уровень сервисов – это нечто совершенно новое. И если вы пока не знаете, как проектируются сервисы, вам лучше изучить этот вопрос, прежде чем начинать строить SOA на своем предприятии. Иначе проблем вы не оберетесь», - предупреждает Дэвид Линтикум.

Разумеется, вам необходимо заняться и проблемами безопасности и управления, которые являются неотъемлемой частью SOA, но, «пожалуйста, услышьте меня», не загоняйте SOA в их рамки!

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

Необходимо налаживать безопасность на каждом уровне, и ваш подход к безопасности на разных уровнях будет сильно различаться, в зависимости от того, что именно вам нужно. «В конечном счете, вся безопасность сводится к снижению рисков, просто, когда дело касается SOA, все это делается немного по-другому», утверждает Дэвид.

«Теперь, когда вы выполнили все 9 пунктов намеченного плана, пришло, наконец, время выбрать технологическое решение, подходящее именно для вашей SOA», - продолжает свою мысль Дэвид Линтикум. «Если вы все сделали правильно, то, как правило, вы увидите, что вам необходим не какой-то один программный продукт, а набор из нескольких технологических решений от разных вендоров. А это значит, вам необходимо самим продумать оптимальное для вас решение, а не полагаться на известного вам разрекламированного поставщика – эксперта по SOA-технологиям местного розлива».

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

«Будьте внимательны, подумайте, что именно вы хотите сделать и получите ту помощь, которая нужна именно вам. Успешная SOA с первой попытки – это реально. От вас требуется лишь искреннее желание потрудиться и не торопиться с выбором технологии».

По материалам портала ebizQ

Комментарии