Разделы

Цифровизация Бизнес-приложения

В чем сложности повторной используемости в СОА

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

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

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

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

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

Попробуем же пройти путем поиска повторной используемости в СОА.

Отвечаем на "наивные" вопросы

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

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

Пока мы говорили только об интересах разработчика ИС – ему объективно выгодно продать как можно больше копий системы. Зададимся вопросом, есть ли интерес в повторном использовании кода у заказчика. Ведь если он использует несколько экземпляров кода, то обычно он всех их и оплачивает.

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

Считается, и не без оснований, что повторное использование сервисов в архитектуре СОА будет автоматически означать отсутствие повторного ввода данных пользователями. А это в современных условиях крайне актуально для заказчика ИС.

Сколько работает оператор?

Вообще вопрос о трудоемкости операторской работы пользователей при эксплуатации ИС – это, как говорится, вопрос из серии неудобных.

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

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

Разработчик ИС обычно видит проблему ввода, подготовка - это уже не его компетенция, а задача заказчика системы. Объяснять последнему, что на самом деле не пользователь виноват, а система управления предприятием в целом, - задача с непредсказуемым результатом и поэтому не менее опасная.