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

За точку отсчета возьмем 2003-2004 годы, когда бизнес и государство стали всерьез рассматривать возможность применения многофункциональных бизнес-приложений (в первую очередь ERP-систем), которые вместе с западными индустриальными моделями пришли на российский ИТ-рынок.

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

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

Топология интеграции

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

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

Однако существовала и другая модель, которая предполагала наличие нескольких равнозначных специализированных бизнес-приложений, возможно, от различных поставщиков. Своим происхождением эта модель обязана популярному в свое время принципу выбора бизнес-приложений best-of-breed (лучшее в своем классе). Каждое из них внедрялось исходя из интересов соответствующих структурных подразделений (финансовый департамент, департамент управления кадрами, и т. д.). В центре внимания таких проектов были проблемы прикладного характера, а ключевым вопросом внедрения было то, как обеспечить разумное соответствие бизнес-процессов («лучших практик»), зафиксированных внутри бизнес-приложений в виде различных программных механизмов, реальным бизнес-процессам организации (или наоборот, как перестроить реальные бизнес-процессы, чтобы они соответствовали лучшим бизнес-практикам).

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

В контексте темы интеграции приложений в упомянутой статье были явно недооценены программные продукты класса Message Oriented Middleware (MOM). Гелиоцентрическая модель была очень удобной и действенной, но в четких пределах, и как только речь заходила о широкомасштабной интеграции бизнес-приложений для крупных компаний по схеме «центральный бэк-офис – региональные филиалы», то приходилось соизмеряться с условиями реальной жизни — низкой пропускной способностью каналов связи. Основу сбалансированной программной инфраструктуры интеграции должны были составлять продукты класса MOM, и производители, располагающие соответствующими программными средствами, имели определенные шансы на успех. Те, кто недооценивал важность MOM и злоупотреблял идеологией централизации, вынуждены были ориентироваться на внедрения у ограниченного круга заказчиков, располагавших адекватной централизованной модели аппаратной и сетевой инфраструктурой.

Далее. Важность выбора интеграционной платформы очень часто отводила на второй план программные адаптеры к бизнес-приложениям. И если для тиражируемых бизнес-приложений крупных западных поставщиков такие адаптеры существуют и лицензируются по стандартным правилам, то для приложений отечественной разработки ситуация иная. Проблема в том, что эти адаптеры должен кто-то разработать, и, что очень важно, сделать их полноценно лицензируемыми, тиражируемыми и поддерживаемыми продуктами. В свое время проводились консультации с российскими компаниями по данной теме, но только в одном случае партнер пришел к выводу о целесообразности собственной разработки своего адаптера к своей системе. В остальных случаях было признано целесообразным каждый раз в рамках проекта интеграции создавать уникальные адаптеры как часть общего решения по программной инфраструктуре. Интересно, что точно такая же проблема существует и в отношении коннекторов к бизнес-приложениям для систем управления идентификацией и доступом пользователей (Identity & Access Management). К сожалению, пока в отношении этой категории программных продуктов российские разработчики не проявляют большого энтузиазма. В то же время, как уже и отмечалось, наличие интеграционной платформы еще не гарантирует успеха интеграционного проекта – критичной точкой является «стык» платформы и самого приложения, где и должен работать адаптер.

Интересно понять, стали ли сегодня бизнес-приложения более открытыми для интеграции?

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

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

Несбывшиеся ожидания

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

Первый объективный фактор, который препятствовал распространению SOA, – масштаб применения этой архитектуры ко всей информационной системе, а не к отдельным ее компонентам. Любой проект в области SOA – это, по сути, проект модернизации всей информационной системы компании, а не ее отдельных элементов (например, кадровой или финансовой систем). Фактически проект SOA – это задача обобществления полезного для бизнеса компании прикладного ПО, представленного в унифицированном виде (программные компоненты, обеспечивающие те или иные бизнес-сервисы).

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

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

Различия приложений определяются их архитектурными компонентами: моделью данных, технологическим стеком (базовое программное обеспечение — среда времени исполнения, то есть СУБД, сервер приложений и т. д.), моделью бизнес-процессов. Различие в моделях бизнес-процессов и в механизмах их реализации является главным препятствием для того, чтобы приложения стали частью глобального бизнес-процесса. Унаследованные приложения не могут стать элементом системы с сервисной архитектурой, и уж никак они не могут стать частью глобальных бизнес-процессов предприятия ввиду того, что в каждом из них использована своя собственная, не предназначенная для интеграции модель бизнес-процессов, да еще и реализованная особым образом. Никогда не удастся создать предсказуемый в поведении процесс, который жестко связывает в рамках предопределенного алгоритма несколько промышленных приложений «старой», «унаследованной» архитектуры. Необходима их модернизация, суть которой состоит в унификации трех компонентов — модели данных, технологического стека, модели бизнес-процессов.

Не удался в целом амбициозный проект одного известного производителя СУБД, предусматривающий унификацию широкого спектра приложений по формуле «единая модель данных – единый технологический стек – единая модель бизнес-процессов». Если идею единой модели данных удалось воплотить в продуктах категории Master Data Management, а единый технологический стек (с определенными ограничениями) можно реализовать за счет применения универсального промышленного сервера приложений, то с единой моделью бизнес-процессов все оказывается неоднозначно — слишком масштабна реализация бизнес-процессов в различных приложениях, слишком она отличается в них, слишком плотно она вплетена в их технологический стек.

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

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

Облака: апофеоз интеграции

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

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

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

 ***

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

Глеб Ладыженский ( GlebL@microsoft.com ) — руководитель направления, Microsoft Russia, в период с 1997-го по май 2010 года работал в компании Oracle СНГ.

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