Поделиться
В чем сложности повторной используемости в СОА
Концепция СОА, приобретающая все большую популярной, на самом деле оказывается не такой прозрачной, как представляется в начале. Для многих компаний большое значение имеет создание "набора" повторно используемых программ или сервисов, что даст возможность наглядно оценить преимущества СОА. Однако кажущаяся на первый взгляд простой задача в реальности далеко не тривиальна.Вопросы появляются в процессе эксплуатации и именно в виде повторного ввода. Но это уже становится проблемой заказчика, с которой он вынужден справляться самостоятельно.
Здесь возникает законный вопрос о том, почему заказчик не может сразу поставить перед разработчиком новой системы интеграционные задачи. Оказывается, что это совсем не просто, технические решения при этом неоднозначны, а цена разработки резко возрастает. Запросить повышенный бюджет с риском не справиться с интеграционными вопросами - это рискованная стратегия для представителя заказчика. Получается, что обеим сторонаи проще не касаться этих проблем, а впоследствии совместно объяснить руководству, что все возникшие позднее сложности появились объективно.
Попробуем, тем не менее, проанализировать вопросы потенциальной интеграции для нашей гипотетической ИС.
Пробуем убрать "повторы"
В рассматриваемой ИС стоит задача учета лиц, ответственных за хранение, ремонт, установку и демонтаж оборудования. Понятно, что это работники предприятия, которые получают зарплату, а значит - уже есть в системе расчетов с персоналом и кадрового учета. Таким образом, эта часть учетной задачи уже реализована.
Но вряд ли нас удовлетворит ситуация, когда при необходимости заполнения поля "ответственный" в нашей ИС нам будет предложено выбрать из полного списка работников предприятия в несколько тысяч человек.
Можно "притащить" вместе с пользователями систему поиска и систему структурирования пользователей по различным признакам, например, по подразделениям, в которых они работают. Но заказчик это вряд ли оценит. Ему надо на практике просто "выпадающий список" из десятка человек, которые практически занимаются конкретной задачей.
Если подумать, то можно предложить сервис, который управляет подобными подмножествами работников. Он позволит сделать выборку из общей базы сотрудников, именовать ее, возможно, еще дополнить какими-то атрибутами и представлять, при необходимости, нашей учетной ИС.
В этом случае мы получим ряд преимуществ. Сохранится связность данных: записи о сотрудниках вводятся только один раз (мы избавились от повторного ввода). Пользователям целевой ИС удается избежать непродуктивного поиска: предварительная выборка работников уже произведена (Мы повысили эффективность операторов). Наконец, такой сервис, наверняка, понадобится в будущем для еще какой-нибудь ИС (Вот она - повторная используемость).
На фоне этих плюсов выделяется один, но очень неприятный минус. Соотношение трудоемкости проектирования и разворачивания нового сервиса, а затем еще и процедур доступа к нему, и простого добавления в монолитное приложение еще одной таблицы может составлять 100 к 1.
И ведь такой выбор надо будет произвести не один раз, а по каждому из направлений интеграции. В такой ситуации любой здравомыслящий менеджер команды разработчиков, находящейся под постоянным прессом сроков и бюджета, скорее всего отдаст предпочтение повторному вводу - и будет в чем-то прав.
Все затраты надо произвести "здесь и сейчас". Все преимущества ожидаются "в светлом будущем" на этапе интеграции, которая всегда достаточно сложна, и есть, что какие-либо другие архитектурные ошибки вообще заслонят собой весь ожидаемый эффект. Надо быть большим фанатом СОА, чтобы решиться на такую архитектуру.
Мы понимаем, что в каждой конкретной ситуации разработчику гораздо выгоднее не связываться с интеграцией. А заказчик, в свою очередь, также стоит перед тяжелым выбором: Увеличить бюджет с негарантированным результатом или оставить интеграцию "на потом"? В нашем случае, перед глазами есть поучительный пример. Те же работники, которые учитываются в системе (как объекты), являются одновременно и ее операторами (субъектами). А вот современную систему управления доступом уже строят на принципах технологии единого входа single sign-on, понимая, что это, хоть и сложнее для разработчика, и дороже, но в масштабе предприятия даст положительный эффект.
Дело за малым - подождать, пока принцип single sign-on пробьет себе дорогу сам и в других предметных областях. Учитывая, что и сегодня он не является повсеместным, ждать придется долго.Для более полной картины рассмотрим другое, не столь очевидное направление интеграции.
Учитываем условия эксплуатации
В рассматриваемой ИС также стоит задача учета условий эксплуатации оборудования. Это важно для сравнительной оценки эффективности. Предположим, что если оборудование уже привязано к площадке, то условия его эксплуатации фактически определены, т.к. в другой ИС эта площадка описана большим набором параметров смежной предметной области (пусть, например, это будет геология).Кажется, что такая привязка уже решает все вопросы. Но это только кажется. Излишняя информация создает не меньше проблем, чем недостаточная. С точки зрения геологии параметров получается так много, что каждая площадка становится уникальной. А нам необходимо будет производить статистическое обобщение результатов эксплуатации.
Где разместить данные, позволяющие произвести это обобщение? И где их вообще взять, если специалисты предметных областей при запросе таких данных поначалу только пожимают плечами? Эти данные придется добывать на практике, методом проб и ошибок.
Сюда тоже просится выделенный сервис. И повторность его использования будет во "времени" - прежде чем он даст какие-то разумные результаты, его придется раз пять переделать. В этом случае обособленность пойдет. Однако и тут затраты на выделение сервиса выглядят как неприемлемо большие по сравнению с монолитным приложением.
Короткая ссылка
