Поделиться
В чем сложности повторной используемости в СОА
Концепция СОА, приобретающая все большую популярной, на самом деле оказывается не такой прозрачной, как представляется в начале. Для многих компаний большое значение имеет создание "набора" повторно используемых программ или сервисов, что даст возможность наглядно оценить преимущества СОА. Однако кажущаяся на первый взгляд простой задача в реальности далеко не тривиальна.Одна только угроза полной бесполезности системы учета, которую сделали "с чистого листа и с одного раза" на основании неясных предположений специалистов предметной области, которых просто "взяли за горло", заставляет сомневаться как заказчика, так и разработчика ИС.
Это не все. Есть и совсем специфические случаи интеграции.
Переходим к тех-и бухучету
Наше оборудование, учет которого мы намереваемся вести, уже учитывается как объект основных средств предприятия. Это обязательно, так как связано с налогообложением. На его основании определяется налогооблагаемая база. За этим следит налоговая инспекция.
Соблазн объединить бухгалтерский и технический учет весьма велик. Но мы бы не советовали заниматься этим.
Практики отражения движения одних и тех же объектов в бухгалтерском и техническом учете в России отличаются кардинально. Хорошо это или нет – вопрос отдельный, но попытка устройства маленькой бухгалтерской революции способна скомпрометировать любую ИС. Что хорошо для техники, для бухгалтера-налоговика смерть. И наоборот. Не стоит усложнять себе жизнь еще и постановкой принципиально не решаемых задач.
Даже если идея подобной интеграции будет предложена заказчиком, имеет смысл проявить твердость и уклониться от ее решения. Предмет автоматизации должен "созреть".
Опытный ИТ-специалист может возразить, что в интегрированных системах, которые приходят к нам с западных рынков, такое объединение де-факто уже проведено. Ответить на это можно следующим образом. В реальных российских условиях такой интегрированный учет превращается в учет в интересах бухгалтерии. С налоговой инспекцией много не поспоришь. Для технических специалистов эта система, в лучшем случае, остается бесполезной.
И сейчас мы уже договоримся до полной "крамолы". Необходимо не просто вести два отдельных учета, а еще и принять меры, чтобы сопоставить их было достаточно затруднительно. В противном случае всегда найдется "умный товарищ", который обнаружит расхождения и воспользуется ими как оружием в борьбе с ИТ-службой и ее руководителем. Хотя ИТ-служба тут совершенно не при чем. Управленческая практика такая. Предупреждаем сразу. Предъявлять настоящую статью в качестве оправдания будет бесполезно.
Возникает резонный вопрос: А как же быть с повторным вводом? Ведь двойной учет, кажется, породит его неизбежно?
Не стоит сильно опасаться. В описанном случае будет необходимо производить в разных системах учет разных операций (или, по крайней мере, разных аспектов одной операции) и их реальное пересечение не составит более 10-20%. Это вполне приемлемая плата за отсутствие перманентной головной боли в попытках совместить несовместимое.
И вот теперь мы подошли еще к одному важному аспекту создания ИС. Речь пойдет о важности слабосвязности сервисов, составляющих ИС.
Оставляем люфты, зазоры и заглушки
Те, кто изучал теорию машин и механизмов, знают, что если спроектировать некий достаточно сложный кинематический механизм, не предусмотрев в нем некоторые зазоры и люфты, то после изготовления и сборки его просто заклинит. Детали, изготовленные из реальных материалов с реальными допусками, не смогут двигаться совместно.
Реальные, а не выдуманные, бизнес-процессы нашей экономики подобны таким механизмам. Они функционируют только благодаря наличию люфтов между своими частями. Беда не в самих люфтах, а в том, что временами они должны быть просто гигантскими. Другими словами, одна шестеренка стремится вращать привод вправо, а другая в это же самое время – влево. Привод при этом не должен рассыпаться на части, а временами проворачиваться то в одном, то в другом направлении по велению какого-то скрытого от глаз "чудесного" устройства.
Попытки создать супер-интегрированную информационную систему, все части которой совершенно синхронно "проворачиваются" вместе друг с другом, на определенном этапе развития системы демонстрируют несостоятельность такого подхода. Изменить такую систему можно, в большинстве случаев, тоже только всю целиком. И чем больше становится система, тем меньше шансов что-либо в ней исправить.
Дать выход в этой ситуации как раз призвана концепция СОА, которая предполагает использование слабосвязанных сервисов. При взаимодействии друг с другом сервисы должны допускать временную несогласованность данных. Это облегчит поэтапную модернизацию системы.
Другое дело, что временная рассинхронизация не должна превращаться в постоянную. Система должна постоянно мотивировать пользователей устранять такую рассинхронизацию в разумное время. Но вопрос о том, как это сделать, требует отдельного рассмотрения.
Для того, чтобы иметь возможность поэтапной модернизации комплексной ИС, нам важно использовать легковесные слабосвязанные сервисы еще по одной причине.
Только для таких сервисов экономически реально и обосновано формирование временных заглушек (stubs). Наличие таких заглушек должно обеспечить поэтапное наращивание функциональности комплексной ИС.
Подводим итоги
Результат, полученный нами по итогам рассуждений, достаточно прозрачен. Только легковесные и слабосвязанные сервисы имеют шансы на повторное использование. А это, в свою очередь, предопределяет и требует, чтобы сами приложения, из которых состоит комплексная корпоративная ИС, были созданы как совокупность взаимодействующих сервисов.
Кроме этого, хотелось бы подчеркнуть еще несколько положений. Во-первых, основная причина, по которой мы стремимся к повторному использованию кода, - это необходимость иметь интегрированную комплексную систему, в которой в большинстве случаев исключена ситуация "повторного ввода" данных. Во-вторых, классические способы интеграции систем дают не слишком хорошие результаты, и концепция применения слабосвязанных сервисов СОА должна обеспечить потенциально лучшее решение. В-третьих, при поиске потенциальных кандидатов на выделение сервисов мы понимаем, что зачастую нам необходимо выделять в сервис не кусок функциональной задачи, а некоторую системную инфраструктуру. В-четвертых, размер имеет значение - только достаточно легковесные и слабосвязанные сервисы имеют шанс на развитие в виде переделки или замены, а значит, - позволяют развиваться комплексной ИС. В-пятых, задача замены монолитного приложения на совокупность слабосвязанных сервисов способна пока в разы увеличить трудоемкость разработки системы и, вследствие этого, имеет плохие экономические предпосылки к внедрению.
Напоследок можно сказать и о позитивном аспекте - проблемы высокой трудоемкости не являются фатальными, и в случае достаточно ясного понимания, какие именно инструменты необходимы, эти инструменты будут рано или поздно разработаны.
В целом без последовательного использования концепции СОА задача формирования пула повторно используемых программных компонентов вряд ли разрешима. Во всяком случае, простой интеграции монолитных приложений, хотя бы и с использованием технологий СОА, для этого явно недостаточно.
Короткая ссылка
