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

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

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

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

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

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

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

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

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

Канонические физические форматы для очень слабого связывания, например в контексте B2B. Канонический объект — это сообщение, часто в формате XML, но при этом допускается использование любого стандарта с двухмерными файлами. Главное, чтобы определение сообщения было относительно стабильным и включало определенный контекст для бизнес-процессов.

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

Хотите узнать больше? Присоединяйтесь к обсуждению на LinkedIn.