Поделиться
В чем сложности повторной используемости в СОА
Концепция СОА, приобретающая все большую популярной, на самом деле оказывается не такой прозрачной, как представляется в начале. Для многих компаний большое значение имеет создание "набора" повторно используемых программ или сервисов, что даст возможность наглядно оценить преимущества СОА. Однако кажущаяся на первый взгляд простой задача в реальности далеко не тривиальна.Заказчику поставить столь тонкие и принципиальные системные вопросы перед разработчиком ИС не менее тяжело – большинство их будет переадресовано назад. Это требует высокой культуры совместной работы и взаимного доверия. Проще отправиться по извечному кругу российского менеджмента и до поры до времени не поднимать шум. Ну а уж если "котел переполнится", можно будет провести быструю операцию поиска виновного в ситуации неопределенной ответственности и при любом результате затем начать новый цикл разработки.
Решать такие вопросы "всерьез" очень сложно. Можно быть уверенным в том, что если на этом фоне в системе существует еще и "повторный ввод", то он будет предъявлен разработчику ИС во всей полноте. Наличие "повторного ввода" является достаточно очевидным фактом, а реальные затраты времени, связанные с ним, все участники процесса ощущают "на интуитивном уровне".
Откуда берется повторный ввод?
В ходе эволюционного формирования больших комплексных ИС ситуация повторного ввода данных воспроизводится постоянно.
Например, у нас развивалась автоматизация двух областей деятельности. До поры до времени они не пересекались друг с другом и развивались независимо. Постепенно начала выявляться общая область интересов. Системы автоматизации первой и второй областей деятельности решали проблемы третьей каждая по своему, в соответствии со своей логикой и сложившимся порядком. Пока объем параллельной обработки был невелик, это мало кого беспокоило. Если же возникла необходимость интеграции данных "общей" области в единую картину, то можно смело утверждать, что объем повторного ввода к этому моменту уже достиг критической величины.
Другой пример. В ситуации ограниченного бюджета сначала автоматизировалась одна область деятельности. Затем появилась возможность автоматизировать еще одну. В процессе выяснилось, что некоторая часть ее функционала уже автоматизирована в первой. При этом специфические особенности области не учтены. Бюджета для переделки первой системы уже нет. Возможно, и ее разработчик сейчас недоступен. Единственным доступным решением остается дублирование функционала в новой.
Сам факт, что ИС создаются во времени, в пространстве и при ограниченных бюджетах, неизбежно порождает повторный ввод. Каждая новая создает свою не синхронизированную с другими копию реального мира.
Легко ли интегрировать системы?
Этот вопрос явно риторический. Системы интегрировать трудно. И наличие технических средств интеграции лишь немного облегчает этот процесс.
Предположим, необходимо интегрировать две системы , чтобы избежать повторного ввода данныхM. Понятно, что образы данных не совпадают полностью - их типичное пересечение составляет 70-90%.
Для начала необходимо определиться, какая из систем будет обеспечивать ввод, а какая - синхронизироваться. Это решение будет, скорее всего, компромиссным. Вряд ли одна система обладает решающим преимуществом перед другой. Еще сложнее определиться – где вводить оставшуюся "непересекающуюся" часть. Этот процесс можно оставить за исходной системой – но такое решение непривлекательно ввиду увеличения фрагментарности ввода. Перенести ввод в новую систему вряд ли окажется возможным, как по техническим, так и по организационным причинам. Получится пристроить ввод где-то в средствах интеграции – это возможно технически, однако скорее всего не имеет преимуществ по сравнению с тем, чтобы оставить ввод в исходной системе.
Окончательным решением может оказаться то, при котором изменения, вносимые в существующие системы, будут минимальными. Всем остальным придется пожертвовать.
Ситуация не будет проще и в том случае, если в одной из систем данные не вводятся, а рассчитываются.
Например, первая система вводит данные, а во второй они уже рассчитаны. Направление синхронизации при этом определяется однозначно. Зато возможность каким-то образом изменить данные во второй системе практически исчезает. При этом ее переделка получится слишком серьезной. Кажется, что транспортная система интеграции способна сделать все необходимые преобразования данных, однако она лишена контекста, который присутствует во второй системе. И это может оказаться принципиальной проблемой.
Описанные сложности не являются чем-то из ряда вон выходящим. Это стандартные проблемы, которые приходится решать при интеграции систем. И случай, когда интеграция, вместо того, чтобы из двух подсистем сделать одну, порождает три, - типичны, а не редки.
СОА призвана избавить нас от этой безысходности при условии, что будет обеспечено повторное использование кода. Повторное использование сервисов должно предотвращать ситуации, когда возникает повторный ввод.
Однако неплохо было бы выяснить, действительно ли, используя СОА, возможно достичь такой высокой степени повторного использования кода, а также подтвердить, что вследствие этого ситуации двойного ввода действительно удается избежать.
Анализируем типовую задачу
Предположим, нам необходимо наладить учет некоторых технических устройств, которые закупаются разной конструкции, у разных поставщиков и по разным ценам. Затем они попадают в производство, где эксплуатируются на разных площадках и в разных условиях. Потом они проходят ремонт, где могут быть разукомплектованы и собраны заново в другом составе. За их сохранность отвечают на разных этапах разные люди. В конце концов, устройства списываются. Необходимо иметь возможность анализа жизненного цикла этих устройств и просто элементарного учета их сохранности.
Это совершенно типовая задача, и ее реализация не представляет никакой технической проблемы. Но только при одном условии. Необходимо, чтобы вновь создаваемая система была единственной в своем роде, и никакие части описанной учетной задачи не были решены уже ранее в других ИС.
Оговорка очень серьезная. Она означает заведомое исключение из рассмотрения интеграционных вопросов. А на деле такая ситуация встречается крайне редко.
Для разработчика очень велик соблазн просто закрыть глаза на все проблемы интеграции и представить, что их нет. Новая система создается "с чистого листа". Все требования по реализации учетной задачи выполняются.
Короткая ссылка
