Облачная архитектура и разрушение монолитности приложений — это хорошо, но если вы это сделаете, вам также понадобится способ управлять беспорядком, который возникает в результате дробления, — утверждает EnterpriseWeb.
Графы знаний, вероятно, лучшая технология, которая у нас есть для интеграции данных. А как насчет интеграции приложений? Графы знаний также могут помочь в этом, утверждает EnterpriseWeb.
Как решить извечную проблему интеграции данных? Мы рассмотрели этот вопрос в одной из первых статей, написанных для этой колонки еще в 2016 году. Это было время, когда ключевые термины и тенденции, которые доминируют в сегодняшнем ландшафте, такие как графики знаний и фабрика данных, в лучшем случае были незаметны.
Интеграция данных может показаться не такой восхитительно интригующей, как вкрапления искусственного интеллекта или машинного обучения в ванильные приложения (приложения с настройками по умолчанию). Тем не менее, мы утверждали, что это хлеб с маслом для многих, средство реализации всех интересных вещей с использованием данных и превосходный вариант использования концепций, лежащих в основе ИИ.
Ключевые концепции, за которые мы тогда выступали, получили широкое признание и приняты сегодня в своих странах. граф знаний и облик фабрики данных: федерация и семантика. В то время концепции не были столь широко распространены, а отдельные части технологий были менее зрелыми и признанными. Сегодня особенно важны графы знаний и фабрики данных; просто проверьте последние отчеты Gartner.
Причина, по которой мы возвращаемся к этой старой истории, заключается не в том, чтобы погреться в некотором самодовольстве, о котором вы говорите, а в том, чтобы добавить к этому. Графы знаний и фабрики данных могут и, надеюсь, со временем решат проблемы интеграции данных. А как насчет интеграции приложений? Могут ли в этом помочь графы и онтологии?
Интеграция данных и интеграция приложений
Повествование о «99 хранилищах данных» было основано на реальной истории о том, как быстрое увеличение источников данных создает проблемы для предприятия. Но как насчет приложений и API? Та же история разыгрывается, так почему бы не использовать то же лекарство и от этой болезни? Это то, что Дэйв Дуггал и EnterpriseWeb стремятся достичь.
Дуггал, основатель и генеральный директор EnterpriseWeb, большую часть своей карьеры посвятил созданию, развитию, строительству и развитию компаний. На создание EnterpriseWeb его вдохновил опыт создания и интеграции приложений, а также то, насколько статичными остаются операции в компаниях, которыми он руководил. Он сказал:
Традиционная разработка программного обеспечения продолжается и по сей день — это ручной код и, в первую очередь, ручная интеграция. Вы кодируете и перекодируете, интегрируете и повторно интегрируете. И, конечно же, это не соответствует требованиям сегодняшнего дня.
В какой-то момент все было на мэйнфрейме — большой и цельной централизации, но при этом очень мощной. Одна из причин, по которой мэйнфреймы являются очень мощными, заключается в том, что на мэйнфреймах данные и код живут вместе. Не было такого ложного разделения между командой данных и командой разработчиков.
Теперь мы разошлись. У нас есть целый ряд новых возможностей. Но у нас также есть целый ряд проблем. Потому что, когда мы отошли от мэйнфреймов, а затем от цельных приложений, которые были тесно связанными кодом, с большим количеством сервисных приложений, с микросервисами, а теперь и с бессерверными функциями, мы поняли, что не имеем программных моделей структуры и управления.
Другими словами, мы все разобрали. Шалтай-Болтай сломался. Все детали лежали на полу. Мы не смогли на самом деле представить механизм, средство или метод для воссоздания этих вещей и взглянуть на то, где мы находимся сегодня.
Суть тезиса Дуггала и предложения EnterpriseWeb заключается в том, что те же инструменты, которые могут решать интеграцию данных, также должны быть способны решать интеграцию приложений: графы и онтологии.
Случай с SAP
Дуггал описал EnterpriseWeb как платформу без кода, которая использует графы для моделирования декларативных отношений между элементами решения, позволяет декларативно объединять объекты в службы и связывать службы в процессы, управляемые событиями. Если это звучит сложно, то, откровенно говоря, это потому, что это так. Цель EnterpriseWeb — скрыть эту сложность.
Запатентованная технология EnterpriseWeb позволяет ему делать что-то вроде автоматического обнаружения и интеграции сервисов. Чтобы продемонстрировать эту способность, Дуггал недавно был приглашен для решения поставленной в SAP онтологии задачи выполнения заказов клиентов.
Целью SAP было выяснить, смогут ли они упростить для клиентов подключение и использование их портфеля продуктов. Задача сделала доступными модели и файлы, определяющие процесс, и предоставила доступ к конечным точкам. По словам Дуггала, процесс, которому следует EnterpriseWeb, подходит для любого сценария.
Вначале идет домен — в данном случае домен SAP, который довольно велик. EnterpriseWeb поставляется со встроенной верхней онтологией общих концепций предприятия — понятий людей, мест, вещей, заказов, местоположений и т. Д.
В этом сценарии также использовалась модель предметной области SAP, используя возможности EnterpriseWeb для импорта информации о модели предметной области из различных источников, от файлов JSON, XML, RDF и UML, до схем баз данных и приложений, текстовых документов и электронных таблиц. В случае SAP это OData (Open Data Protocol). Получение этих источников позволяет EnterpriseWeb установить верхнюю онтологию.
Далее происходит то, что EnterpriseWeb подключается к конечным точкам службы, которые необходимо интегрировать, и заполняет онтологию объектами домена и их свойствами, поведением, зависимостями и ограничениями.
Это создает граф знаний рабочего домена предприятия и индексированный каталог всех его объектов домена, основной целью которого является выполнение служб для бизнес-процессов.
В случае SAP движущей силой процесса было описание BPMN (Business Process Model and Notation) сценария выполнения заказа клиента. BPMN — это стандартный формат, используемый в управлении бизнес-процессами. BPMN была импортирована вместе с моделью SAP One Domain, а затем были извлечены задачи, роли и точки интеграции. Затем процесс был преобразован в управляемый событиями поток данных, естественно смоделированный в виде графа.
Традиционно, отметил Дуггал, графы использовались для аналитики и рекомендаций, а не для обработки транзакций и бизнес-процессов. Причина в сложности этих объектов. Он добавил:
«У объектов есть множество свойств, поведения, зависимостей, ограничений, сходств. Все эти вещи смоделированы в наших графах, все они агрегированы и адресуемы. Они сделаны так, чтобы быть сверхэффективными для обработки».
Фабрика приложений
Заключительная часть процесса — это организация сервисов, то есть их выполнение, координация и развертывание в правильном порядке и с правильными параметрами, где бы они ни находились — локально, в облаке или в контейнерах.
Это создает то, что Дуггал назвал «фабрикой приложений», как расширение понятия фабрики данных. Идея фабрики данных состоит в том, чтобы предоставить единую плоскость доступа для корпоративных данных, где бы они ни находились. Идея фабрики приложений состоит в том, чтобы предоставить единую плоскость доступа для корпоративных сервисов, где бы они ни находились.
Конечно, этот процесс не требует 100% кода и усилий, и Даггал признает это. По его оценкам, автоматизированный процесс приема данных может обеспечить правильность около 95% модели предметной области, процессов и услуг, и требуется некоторая тонкая настройка для обеспечения правильного сопоставления. Однако, утверждает он, это серьезный отход от ручного подхода и огромный рост производительности.
Дуггал упомянул о работе с операторами связи в случаях использования 5G, которые влекут за собой сложные сети и инфраструктуру, которые EnterpriseWeb смогла внедрить менее чем за час. Сопоставления или минимальные жизнеспособные сопоставления общих свойств, как их называл Дуггал, являются ключевой частью этого. Опять же, основной продукт интеграции данных и интегрированных подходов, используется в контексте интеграции приложений.
Причина такого сходства заключается в том, что эти подходы были тщательно изучены и учтены при разработке и внедрении EnterpriseWeb, сказал Дуггал. Цель состояла в том, чтобы создать платформу без кода для сегодняшнего технологического ландшафта, которая устранит то, что он считает зияющей дырой в эпоху нативных облаков:
«Если вы посмотрите на ландшафт поставщиков Cloud Native Computing Foundation, вы увидите сотни инструментов для облачных вычислений. Что они представляют?
Проблема в том, кто все это снова связывает. Каждый компонент промежуточного программного обеспечения прекрасно выглядит изолированно. Эй, посмотрите на этот новый компонент. Это нужно для аналитики. Посмотрите на этот новый компонент, он вам нужен для мероприятий. Посмотрите на одну вещь в этом компоненте.
Люди забывают о проблеме N + 1: каждый раз, когда вы добавляете новый компонент, вы добавляете накладные расходы и усложняете архитектуру своей системы, и вы этого не замечаете. Когда вы складываете все это вместе, кого на самом деле волнуют такие вопросы как согласованность, неизменяемость, идемпотентность, асинхронность и параллелизм? «
