Актуальность темы интеграции корпоративных приложений не ослабевает: на современном предприятии, как правило, работает множество разнородных систем, при этом еще может понадобиться наладить эффективное взаимодействие с приложениями партнера, не упустив из виду ту пользу, которую продолжают приносить унаследованные решения. А с распространением сервис-ориентированного подхода к интеграции и появлением технологий автоматизации бизнес-процессов на базе SOA (service-oriented architecture) интеграционные проекты могут стать одним из факторов успеха бизнеса в целом. Вопросы интеграции постоянно поднимаются на страницах «Открытых систем», поэтому не случайно, что журнал выступил в качестве организатора круглого стола «Интеграция приложений — теория и практика».
Ведущий круглого стола, научный редактор журнала «Открытые системы» Сергей Кузнецов проиллюстрировал проблемы интеграции картиной Брейгеля «Вавилонская башня». Именно так может выглядеть корпоративная информационная система спустя годы после ее создания, когда под воздействием различных изменений на предприятии она приобретает неустойчивую многоуровневую форму, которой очень трудно управлять. Как достроить Вавилонскую башню? Как привести корпоративную систему в то состояние, когда она действительно будет приносить пользу бизнесу, не создавая организационных проблем?
Для обсуждения участникам круглого стола были предложены несколько тем, связанных с задачей интеграции приложений. Свою точку зрения по каждой из них высказали выступившие в роли экспертов советник директора главного центра информатизации Банка России Валерий Артемьев, начальник Центра компетенции общекорпоративных систем ФК «УралСиб» Илья Батай, директор по разработке программного обеспечения компании «Крок» Алексей Добровольский и директор по технологиям Oracle СНГ Глеб Ладыженский. В работе круглого стола принимали также участие представители компаний «Евразия», «Связь ВСД», «Альфа-Банк» и др.
Цели и особенности
Любой проект начинается с определения целей и задач. От кого обычно исходит инициатива интеграционных проектов — от тех, кто отвечает за бизнес, или от ИТ-специалистов? Направлена ли интеграция на повышение эффективности бизнес-процессов или на улучшение внутренней организации на предприятии? Чем может обернуться неэффективная интеграция приложений для предприятия, всегда ли следствием неудачного интеграционного проекта являются серьезные проблемы эксплуатации ИТ-инфраструктуры? И, наконец, насколько масштабной должны быть интеграция, возможно ли обойтись без проекта корпоративного уровня, реализуя вместо этого точечные соединения отдельных приложений?
ВА: Главная цель, которую преследуют интеграционные проекты в Банке России, состоит в том, чтобы построить гибкую систему, способную реагировать на изменения в бизнесе. Инициатором таких проектов у нас чаще всего является ИТ-служба. Это существенный недостаток, поскольку в условиях отрыва сотрудников ИТ-отдела от бизнеса специалисты бизнес-подразделений не понимают, в чем цель очередной перестройки инфраструктуры. Но есть и примеры, когда интеграцию инициировал бизнес — среди них объединение старой бухгалтерской системы с новыми модулями автоматизации внутрихозяйственной деятельности, интеграция между собой депозитарных систем на базе технологий потоков работ. В проекте автоматизации деятельности Банка России на открытых финансовых рынках мы начинаем использовать технологии Web-сервисов. Во главе таких проектов стоят, прежде всего, определенные организационные нужды банка.
Справедливо ли утверждение, что неэффективная интеграция неизбежно порождает проблемы эксплуатации? У нас очень много эксплуатационных регламентов, мы должны к определенному времени готовить конкретный отчет, и в этом смысле неэффективное интеграционное решение будет влиять на скорость подготовки и приводить к проблемам. Неправильные порции обмена данными при недостаточной пропускной способности каналов и, как следствие, неудовлетворительная скорость обмена данными могут привести к неэффективной эксплуатации интегрированной композитной системы в условиях заданных регламентов. Кроме того, чем больше средств применяется при интеграции, что происходит при реализации точечных решений, тем сложнее становится эксплуатация.
ИА: Первая проблема, которая возникает при внедрении любого ИТ-решения, состоит в том, откуда исходит инициатива внедрения — «сверху» или «снизу». В интеграционных проектах такой вопрос почти не стоит, поскольку их стоимость высока, и без поддержки сверху реализация невозможна, так как не будет финансирования, а без поддержки снизу их просто некому будет делать. Зато возникает вторая вечная проблема — от кого исходит инициатива интеграции, от бизнеса или от ИТ? Близка к идеальной ситуация, когда в интеграции заинтересован бизнес: в этом случае убедить «айтишников» в том, что интеграция нужна, будет не сложно. Бизнес, который хочет интеграции, как правило, имеет опыт визуального моделирования бизнес-процессов и желает оживить эти картинки. Насколько это удастся, зависит от возможностей ИТ-специалистов автоматизировать каждый из квадратиков построенной диаграммы бизнес-процесса.
Второй, наиболее распространенный вариант — интеграция от ИТ. Если ИТ-отдел сумеет убедить бизнес в важности интеграционного проекта, то сможет построить полностью здание интеграции. Если нет, то строительство начинается снизу, с фундамента, который представляет собой транспортный уровень и интеграцию на уровне передачи сообщений. Известно, что интеграцию лучше начинать с небольшого, быстрого и успешного проекта. Как правило, это интеграция приложения А с приложением В. На следующем этапе часто делаются попытки реализовать такой же проект. Если пойти «на поводу» у бизнеса и начать лепить проекты интеграции систем попарно, не задумываясь о дальнейшем, то получится интеграционный хаос. Поэтому стоит сразу продумывать перспективы развития, чтобы построить корпоративную систему интеграции. Парадокс в том, что все равно сначала нужна интеграция по типу «точка-точка». Но ее надо организовывать по принципам общей шины, не просто выделяя технические интерфейсы, но пытаясь «обернуть» их в бизнес-сущность. Это позволит в дальнейшем легко перейти на уровень бизнес-логики, представив компоненты в виде сервисов и предоставив к ним интерфейсы.
АД: Я бы разбил интеграционные проекты на несколько классов. Одна из наиболее распространенных задач сегодня — это выдача корпоративной отчетности, для формирования которой требуется объединение данных из разных информационных систем. Второй вариант — обмен данными между системами с целью устранения повторного ввода. Третий класс решений — объединение информационных систем для реализации общего бизнес-процесса. И четвертый — внедрение в организации средств управления ИТ-инфраструктурой. Инициатором всех этих проектов является бизнес. В получении сводной корпоративной отчетности обычно заинтересован топ-менеджмент предприятия. С целью снижения нагрузки на пользователей в бизнес-подразделениях внедряются средства синхронизации данных. Объединение информационных систем в единые бизнес-процессы применяется для уменьшения транзакционных затрат организации. И даже четвертый класс решений, внедрение систем управления, тоже является бизнес-проектом, так как призван снизить затраты ИТ-подразделений на эксплуатацию инфраструктуры.
Интеграционный проект можно определить как внедрение системы, требующей взаимодействия более чем с одной системой. Сложность «системы систем» всегда выше, а надежность всегда ниже, соответственно, любое интеграционное решение так или иначе порождает увеличение трудозатрат на эксплуатацию инфраструктуры. Именно поэтому обычно в интеграционных решениях заинтересованы бизнес-пользователи, которые хотят уменьшить собственные трудозатраты.
Есть два варианта неэффективной интеграции. Первый вариант — это интеграция, которая увеличит совокупные затраты на содержание бизнеса или ИТ-инфраструктуры в текущем состоянии, второй — когда затраты на модификацию интегрированной системы становятся неразумными. К сожалению, встречаются оба варианта, причем на разных уровнях. Например, неправильно выбранная архитектура интеграционного решения затронет оба варианта, так как ее будет сложно поддерживать и тяжело развивать.
Судя по нашей практике, интеграционные проекты как таковые весьма редки. Наиболее частый вариант проникновения интеграционных решений в инфрастуктуру предприятий — когда при внедрении очередной информационной системы необходимо наладить ее совместную работу с уже существующими приложениями. При этом в 90% случаях разработчик или внедренец новой информационной системы применит точечное решение с наименьшей трудоемкостью реализации. Вопрос эффективности или неэффективности таких решений связан с тем, насколько они правильно спроектированы, легко модифицируемы, эффективно поддерживаются ИТ-службой заказчика. И я бы не сказал, что классическая схема с применением корпоративной сервисной шины (Enterprise Service Bus, ESB) однозначно эффективнее точечных решений.
ГЛ: Кто инициирует интеграционный проект? Конечно, бизнес-руководители, поскольку это проект, который сулит ИТ-службе достаточно большие неприятности. При этом далеко не везде бизнес-процессы сформулированы и соответствующим образом описаны, поэтому проекты интеграции инициируются для решения конкретных интеграционных задач.
Неэффективная интеграция, безусловно, порождает проблемы эксплуатации. Однако нужно иметь в виду, что, даже если существующее интеграционное решение не вполне удачно, попытка внедрения некоего «правильного» решения может привести к еще более неэффективному результату с точки зрения эксплуатации.
Очень часто задача интеграции встает при внедрении масштабной системы, например, ERP, которую необходимо объединить с приложениями типа «1С», «Парус» и т.д. Такая интеграция обычно реализуется в виде небольших программ, организующих связи по принципу «точка-точка». Я считаю, что в ряде случаев достаточно этим обойтись, не придумывая себе проблемы в виде комплексных интеграционных решений.
Реализация
В качестве второй темы организаторы предложили обсудить принципиальные особенности проектов интеграции в сравнении с другими ИТ-инициативами. Более частный, но не менее серьезный вопрос — как часто проекты по интеграции приложений начинаются с внедрения систем управления нормативно-справочной информацией (НСИ), которая играет сегодня важную организующую роль в среде корпоративных данных. И несомненно, полезно обменяться опытом по поводу возможных ошибок интеграционных проектов.
ИБ: Основная особенность интеграционных проектов состоит в том, что в них вовлекаются множество инфраструктур и подразделений корпорации. Залог успешного решения интеграционных проблем — построение эффективной команды. Во-первых, во главе команды должен стоять архитектор всего решения, опытный профессионал. В команду должны входить технологи, которые знают бизнес-процессы и интерфейсы и сумеют написать ТЗ, понятное и разным бизнес-подразделениям, и ИТ-специалистам, и входящим в команду интеграторам-программистам. В качестве последних можно взять даже выпускников вузов с небольшим опытом программирования, если результаты их работы будут тестировать и принимать технологи, а общее руководство осуществлять архитектор, контролирующий выполнение основных принципов построения интеграционных решений.
Еще один член команды — администратор, который принимает систему в эксплуатацию. Главная его задача — мониторинг, поэтому от него требуются надежность и внимательность. Он должен узнать о сбое в системе раньше, чем все остальные. Во многом здесь помогут средства автоматизации мониторинга.
Следующая часть команды — внешняя по отношению к интеграторам. Во-первых, это представители бизнеса. Найти заказчика, который согласится на эксперименты над его бизнесом и готов терпеливо дожидаться результата — большое дело! Кроме того, необходимо взаимодействие с разработчиками интегрируемых систем. Зачастую встречается активное сопротивление, ведь они всю жизнь писали интерфейсы, выгрузки файлов, зачем им что-то еще делать? Надо добиваться понимания, что интеграционная платформа сможет продлить их команде жизнь на предприятии, иначе их просто заменят неким монолитным решением.
Второй аспект, который нужно учитывать в проекте интеграции, это процессы. Во-первых, процессы создания интеграционного решения. В начале работы необходимо выработать единую концепцию построения операционной шины, платформы, определить регламенты по созданию интеграционных решений, регламенты по контролю их качества, особенно при условии, что команда будет состоять из малоопытных студентов. Наличие жестких регламентов помогает в реализации и облегчает эксплуатацию в дальнейшем. Контроль выполнения этих регламентов должен быть возложен на руководителя-архитектора.
Кроме того, часто забывают о процессах эксплуатации интеграционных систем. Поскольку интеграция находится на стыке, любой сбой бизнес-процесса, как и любой сбой в инфраструктуре ложится на плечи интеграторов. Вопрос вашей же безопасности — это наличие регламентов, описывающих, кто за что отвечает. Создавать регламенты необходимо параллельно с созданием документации на интеграционное решение.
Если решается именно задача интеграции, а не сбор отчетности, то вопрос внедрения системы управления основными данными (Master Data Management, MDM) в корпорации встает не сразу. Если первые процессы невелики, то эту задачу надо решать какими-то локальными методами. У нас руки до MDM дошли только сейчас, через три-четыре года эксплуатации интеграционного решения. Это большая и неблагодарная задача в том плане, что экономический эффект невозможно посчитать. При подключении большого числа разнородных систем очень много как технологических, так и организационных рисков: кто-то не захочет отдать информацию, возникнут VIP-клиенты, информацию о которых нельзя вносить в единую базу, кто-нибудь скажет, что не возьмет данные из базы MDM и т.д.
АД: Полностью согласен со своим коллегой. Единственное, я хотел бы возразить по поводу студентов. Студент с двухмесячным опытом может поддерживать систему, пока она работает. Как только система падает, а любая сложная система рано или поздно падает, необходима помощь «основных сил». И если у вас в команде только один опытный главный архитектор, но он в этот момент где-то на Багамах, а в офисе одни студенты, то все — бизнес стал!
Действительно, беда интеграционных проектов — это то, что они затрагивают большое количество информационных систем и подразделений предприятий. Наиболее острые проблемы возникают при интеграции бизнес-процессов, когда необходима слаженная работа персонала, эксплуатирующего эти системы. Согласовать требования между разными подразделениями часто оказывается нерешаемой задачей. Возникают проблемы разных показателей эффективности подразделений, разных персональных предпочтений, разного видения одного и того же бизнес-процесса. Как показывает опыт, если спонсором и движущей силой интеграционного проекта не выступает топ-менеджер, который может отдавать прямые указания всем вовлеченным в проект подразделениям, проект этот, скорее всего, обречен на неудачу.
У интеграционных проектов есть еще ряд неприятных черт, например, быстрая изменчивость требований. Когда вы интегрируете пять информационных систем, то каждая из них развивается самостоятельно согласно запросам эксплуатирующего бизнес-подразделения, причем в качестве особого подарка интегратору внедрение новых версий этих систем будет происходить без дополнительного объявления, что может разрушить весь проект.
Что касается систем управления справочниками и нормативными документами, то мы начали уже немного уставать от создания частных решений. Любая задача, которая подразумевает перенос данных между двумя информационными системами, ставит проблему перекодировки справочников, классификаторов и т.д. Обычно организации обращаются к внедрению MDM-платформы через достаточно долгое время после начала процесса интеграции, и стимулом к этому становятся непомерно высокие затраты на поддержание различных справочников, таблиц и т.д.
Типичных ошибок интеграционных проектов множество. Одну я уже назвал — это отсутствие спонсора, который будет стимулировать весь проект в целом. Это относится к организации планирования. От исполнителей такого проекта требуется знание технологий бизнес-процессов всех интегрируемых систем, что в одном человеке или в одной команде сочетается очень редко. Ошибки выбора целевой архитектуры тоже происходят достаточно часто, например, в последнее время стало очень популярно пытаться применять интеграционное решение на основе Web-сервисов. По нашему опыту, эти технологии работают только в идеальных условиях. Но самая типичная ошибка состоит в следующем. К определенному моменту во всех неудачных интеграционных проектах становится понятно, что на предыдущих этапах что-то сделали совсем неправильно. Но к этому моменту груз ответственности и материальных потерь уже не позволяет все остановить, честно признаться в своих ошибках акционерам компании и снова начать с учетом предыдущего опыта.
ГЛ: Не надо ставить знак равенства между системами управления НСИ и MDM. MDM — это отдельное направление, представленное сейчас широким классом продуктов, которые, как правило, реализуют интеграцию через консолидацию данных. Такие решения есть у IBM, Oracle и др. Система управления НСИ может быть одной из реализаций MDM.
Как мне кажется, исключительная сложность интеграционного проекта проявляется в том, что, чем масштабней проект, тем больше в него вовлечено организаций. Как правило, такие проекты организуются консорциумами, где исключительно сложно договориться о разграничении полномочий, финансовых ограничениях и т.д. Из числа ошибок, которые происходят при реализации проекта, я бы обратил внимание на целевую архитектуру, которую нужно очень тщательно анализировать, прорабатывать все аспекты технологии, избегать необоснованных ожиданий по возможностям платформы. К сожалению, в большинстве случаев системный анализ на этапе выбора целевой архитектуры крайне слаб, а то и не делается вообще.
ВА: Если мы говорим про проекты, которые имеют стратегическую направленность, то перспектива для них — это интеграционные платформы. В наших условиях они дороги, но они и на Западе дороги. Многие неудачи таких проектов связаны с тем, что первоначальные затраты в инфраструктуру очень велики. На Западе в качестве особенностей интеграционных проектов отмечают изменение инфраструктуры и методологий, используемых разработчиками, с учетом особенностей SOA. В Банке России пока не было таких серьезных проектов, но я считаю, что жизненный цикл разработки должен быть короче по сравнению с тем, что есть сейчас. Одна из проблем выражается в том, что в интеграционных проектах мы вынуждены использовать устаревшие ГОСТы, созданные двадцать, а то и тридцать лет назад, поскольку необходимо как-то описать взаимодействие систем. Идеологи SOA утверждают, что сервисный подход способен упростить ситуацию.
Если рассматривать интеграцию как разработку инфраструктурного решения, то успех этих проектов зависит от способности разработчиков строить модульные структуры. Считается также, что необходим корпоративный архитектор.
Что касается НСИ, то в Банке России этой работе придается большое значение. Исторически так сложилось, что у нас используются разные инструменты, но методологически вся эта деятельность выделена. Мы сопровождаем более 150 различных справочников, получаем классификаторы из Росстата, ведем свои ведомственные и т.д. Сейчас создается новая система на основе метаданных.
Технологии
Для успеха проекта принципиально важными могут оказаться критерии выбора технологических платформ интеграции. Сегодня маркетинговая активность основных игроков рынка инфраструктурного программного обеспечения сосредоточена вокруг нескольких терминов и технологий, но есть ли что-то действительно принципиально новое в новейших средствах интеграции? И насколько архитектура SOA и технология ESB реально способны выступить в качестве панацеи от всех «болезней» интеграции?
АД: Общий критерий выбора технологических средств интеграции приложений — достижение поставленных целей с минимальными издержками и в минимальные сроки. Но на этот выбор будут влиять сотни других факторов, в том числе наличие подготовленных специалистов, цена программных лицензий, стоимость дополнительного оборудования, степень «зоопарка» систем в организации и т.д.
По существу, технологические проблемы интеграции информационных систем были решены в середине 90-х годов, когда появились средства межмашинного взаимодействия на уровне вызова удаленных процедур или CORBA и первые мониторы распределенных транзакций. Чуть позже были реализованы средства гарантированной доставки. Дальнейшее развитие этих технологий происходило эволюционно. Последнее поколение систем интеграции от «большой тройки» поставщиков — IBM, Oracle и Microsoft — поддерживает Web-сервисы как одно из средств межмашинного взаимодействия и новые стандарты описания бизнес-процессов, но принципиально ничего нового в них не появилось. Более того, значение Web-сервисов сильно преувеличено. Web-сервис очень просто запрограммировать и отладить, но надо понимать, что Web-сервисы проектировались не как средство интеграции, а как средство доступа клиентского приложения к удаленному приложению в Internet. Поэтому изначально спецификации Web-сервисов лишены средств обеспечения безопасности, до сих пор нет стандарта на скоординированную работу Web-сервисов, нет средств гарантированной доставки сообщений.
Что касается SOA, то она на данный момент никак не помогает справиться с проблемой интеграции информационных систем. Дело в том, что SOA — это не технология и даже не архитектура, это некий концептуальный подход к построению информационных систем. Он сводится к тому, что каждая информационная система должна обеспечивать доступ к своим функциям через набор сервисов и посредством интерфейса может участвовать в некоторых скоординированных действиях, допустим, в бизнес-процессе, затрагивающем несколько информационных систем. Для воплощения концепции SOA в жизнь необходимо, чтобы каждая информационная система на предприятии была реализована в соответствии с этим подходом. На деле же ни один из поставщиков крупных корпоративных приложений не заинтересован в том, чтобы делить их на компоненты, и к каждому компоненту, реализующему набор бизнес-функций, предоставлять внешний интерфейс. Вы выбираете крупную информационную систему по набору возможностей и эксплуатационных параметров, и вас не интересует, осуществим ли к ней доступ из других приложений. Подход SOA не просто не нужен поставщикам крупных систем класса ERP, CRM и т.д., он для них вреден! Эти поставщики предоставляют целую линейку систем разного функционального назначения. Программные продукты одного производителя обычно интегрированы посредством общей базы данных. Подход SOA означает, что заказчик может купить компоненты по принципу «лучший в своем классе» и организовать их взаимодействие, а это поставщику невыгодно. Отсюда я делаю вывод, что SOA так и останется красивой концепцией.
А корпоративная сервисная шина решает вполне конкретную задачу — обеспечение транспорта между интегрированными приложениями. Концептуально ESB выросла из шины передачи сообщений и отличается от нее тем, что к шине передачи сообщений вы можете подключить приложения, только используя протокол этого конкретного продукта, а к ESB можно подключить приложения с помощью одного из поддерживаемых протоколов, и система сама обеспечит необходимое преобразование форматов.
ГЛ: То, что говорит Алексей, возможно, справедливо в отношении некоторых поставщиков крупных приложений. Для того чтобы интегрировать приложения в функционирующие бизнес-процессы, к сожалению, эти приложения надо переписывать. Каждый разработчик стремится выпустить на рынок полноценную рабочую систему, но никто не задумывается о реализации правильного интерфейса для включения приложения в бизнес-процесс. Результатом такого подхода получаются работающие, но слабо интегрируемые приложения.
Что делать в такой ситуации? Oracle приобрела ряд компаний, которые умеют делать лучшие в своем классе системы управления логистикой, управления отношениями с клиентами и т.д. Объединенная команда сейчас работает над проектом Fusion Applications, в результате которого должны появиться приложения, способные стать частью глобальных бизнес-процессов. А индустриальным стандартом для этого является SOA. Алексей прав в своих высказываниях о Web-сервисах, однако существуют подходы к их реализации, которые позволяют снять многие проблемы. Отметать эту идеологию нельзя, она правильная.
Определяя критерии выбора технологических средств интеграции приложений, надо осознавать, что они не безграничны по своим возможностям. Очень часто мне приходилось сталкиваться с тем, что заказчик не сам выявляет критерии, а поручает это консультанту, и консультанты придумывают огромный набор требований, мотивируя это тем, что заказчик выбирает технологическую платформу на долгосрочную перспективу. Лучше исходить из здравого смысла и решать конкретную бизнес-задачу.
ВА: Недооценка SOA связана с тем, что в России плохо относятся к стандартам, поскольку просто их не понимают. Рамочные стандарты — это определенная идея, которой нужно следовать. Я согласен с тем, что говорилось о Web-сервисах, но то, что SOA напрямую связывается с Web-сервисами, скорее проблема маркетологов. SOA надо воспринимать как стратегическую архитектурную идею, которой вы будете следовать в течение длительного периода времени. Другой вопрос, какую инструментальную базу вы возьмете, можно ли использовать несколько средств от разных фирм? Сомневаюсь, потому что они поставляют их как платформы, а платформы интегрируются очень тяжело.
Важной технологией является мониторинг сервисов. Необходимо реализовывать его в полном объеме, без этого не будет будущего ни у сервисного подхода, ни у соответствующего инструментария, поскольку надежности и безопасности сейчас уделяется очень большое внимание.
Еще одна тенденция — слияние средств интеграции приложений со средствами интеграции информации и инструментами репликации баз данных. Неявно при интеграции приложений подразумевается, что в этом взаимодействии передаются параметры не сложнее массива. Если же нужен обмен более сложными данными, то приходится применять другие решения, например, строить общую базу данных или делать репликацию.
ИБ: Решение о внедрении интеграционной платформы — стратегическое, потому что никто его экономическую эффективность доказать не может. Действовать локально в рамках конкретной задачи, как предлагает коллега из Oracle, не совсем корректно, потому что проекты идут в предприятиях много и часто, и планировать эту деятельность необходимо на предельно возможный период времени. Поддерживать большое количество стандартов, действительно, не следует; необходимо выделить основные.
Казалось бы, можно было бы воспользоваться решениями собственной разработки. Но нам же не приходит в голову писать свою операционную систему, а интеграционная платформа — продукт такого же уровня, поэтому его необходимо покупать у поставщиков. На рынке существуют два класса игроков — небольшие компании, решающие локальные задачи (к ним относятся и многие российские разработчики, поставляющие небольшие интеграционные решения), и глобальные игроки. Я бы рекомендовал выбирать из пятерки лидеров, которые поставляют платформы, включающие решения для каждого типа интеграции — транспорт, управление бизнес-процессами, MDM и т.д. Конечно, маленькие предприятия не в состоянии купить весь стек — это очень дорого. Поэтому начинайте с малого, например, с транспортных средств, но закладывая основы для того, чтобы при росте потребностей бизнеса иметь возможность переходить на следующие уровни. Критерий выбора конкретного поставщика — бюджет, наличие поддержки, наличие собственных специалистов.
Что касается SOA, мне не понятно, почему вокруг нее такая большая шумиха. Насколько мне известно, эта концепция была заявлена уже в 90-х годах, просто раскручивалась не так широко. Для бизнеса SOA — это, в лучшем случае, инструмент, позволяющий гибко и быстро перенастраивать бизнес-процессы, в худшем — инициатива ИТ, за которую придется платить. С точки зрения ИТ-руководства — это хорошо «раскрученная» архитектурная идея, под флагом которой можно выдвинуться на рынке и поднять свой авторитет в глазах бизнеса. Однако, по сути, это старый, хорошо известный подход, в соответствии с которым для интеграции каждое приложение должно иметь интерфейсы на уровне решаемых бизнес-задач.
Здесь было правильно замечено, что производители не заинтересованы в том, чтобы разбивать свое монолитное приложение и выставлять его лучшие части во внешний мир. Нет никакой гарантии, что заказчик захочет потом купить другую часть, не самую лучшую. Что появилось в SOA действительного нового, так это использование Web-сервисов в качестве технического стандарта. То, что поднялась шумиха, даже хорошо, потому что теперь про SOA знают все. Как это реализовать в России? Надо монолитные приложения разбить на бизнес-задачи и унифицировать к ним доступ, «обернув» их технические интерфейсы в некоторое подобие сервисов. Это основная задача интеграционной платформы. Решив ее, мы сможем строить корпоративные композитные приложения. Пока я не знаю конкретных примеров, но начинаю задумываться об этом, поскольку надеюсь, что через год-два мы доберемся и до управления бизнес-процессами, и до создания композитных приложений.
