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

Перечислим только некоторые проблемы такого подхода:

>  тратятся ресурсы на бесцельное тестирование;

>  на основе недостоверных данных может быть остановлен успешный проект;

>  если проект не остановлен, то он существенно задерживается;

>  формируются некорректные ожидания относительно характеристик промышленного SOA-решения.

Как организовать разработку SOA-решений?

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

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

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

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

И только когда проанализированы результаты пилота, и он признан удачным, можно с открытыми глазами начинать промышленный проект.

Распределение времени и средств по этапам складывается примерно следующее (см. таблицу 1).