Архитектура взаимодействующих информационных систем

Архитектура совместимых информационных систем (AIOS) — это эталонная архитектура для разработки совместимых корпоративных информационных систем . Если предприятия или государственные органы хотят заниматься автоматизированными бизнес-процессами с другими организациями, их ИТ-системы должны иметь возможность работать вместе, т. е. они должны быть совместимыми . AIOS представляет собой общий план построения для этих организаций для разработки совместимых информационных систем путем систематической корректировки и расширения своих внутренних информационных систем. AIOS была описана в докторской диссертации и основана на результатах различных исследовательских проектов по совместимости. ^[1] Она не зависит от конкретных продуктов или поставщиков, но в общем описывает различные уровни, представления, отношения и технические средства, необходимые для эффективного создания совместимых информационных систем. Для этой цели она объединяет концепции сервисно-ориентированной архитектуры , совместного бизнеса и моделирования бизнес-процессов . Ее можно рассматривать как дополнение к ARIS , хорошо известной архитектуре для внутренних информационных систем и бизнес-процессов.

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

Информационные системы — это системы, которые обрабатывают информацию, то есть они собирают, транспортируют, преобразуют, хранят и предлагают информацию. Согласно концепции, преобладающей в исследованиях информационных систем, информационная система включает в себя не только аппаратное и программное обеспечение предприятия, но и связанных с ним людей, бизнес-функции и процессы, а также организационные структуры. ^[2] Это широкое понимание, например, также воплощено в структуре Захмана .

Архитектура определяется как «фундаментальная организация системы, воплощенная в ее компонентах, их отношениях друг с другом и с окружающей средой, а также принципах, управляющих ее проектированием и развитием». ^[3] Синц определяет архитектуру информационной системы как план построения информационной системы в смысле спецификации и документации ее компонентов и их взаимосвязей, охватывающих все соответствующие точки зрения, а также правила построения для создания плана здания. ^[4]

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

После работы над совместимыми информационными системами, проведенной в рамках Европейских исследовательских проектов ^[5], в 2010 году была опубликована Архитектура совместимых информационных систем (AIOS) в качестве справочника по построению слабосвязанных, взаимодействующих информационных систем и по систематическому, основанному на моделях внедрению совместных бизнес-процессов.

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

1. Описание различных типов данных, входящих в состав интероперабельной информационной системы, а также их взаимосвязей. Это также называется статической частью или структурой архитектуры. Оно сообщает организациям, какие элементы информации (например, описания сообщений, последовательности обмена, роли и услуги) они должны предоставлять партнерам по сотрудничеству и как они могут оптимально соотнести их с внутренними элементами.
2. Описание различных путей построения для внедрения или настройки интероперабельных информационных систем. Это также называется динамической частью архитектуры. Она сообщает организации, как итеративно разрабатывать элементы, упомянутые выше.
3. Концепция технических компонентов, необходимых для реализации архитектуры, например, инструментов проектирования, внутренних и внешних репозиториев.

Одним из элементов, входящих в третью категорию, является «репозиторий BII» , в котором каждая организация публикует содержимое своего интерфейса взаимодействия бизнеса (BII) для партнеров по сотрудничеству. Поскольку он включает внешние представления элементов информационной системы, он предоставляет функции публикации и обнаружения, необходимые в архитектуре, ориентированной на услуги : в BII внешне релевантные процессы, услуги, организационные структуры и т. д. описываются на различных уровнях технической детализации, что позволяет другим организациям искать также элементы бизнес-уровня, а не только технические артефакты. Здесь, в отличие от традиционного подхода SOA, вместо одного центрального каталога услуг реализуются различные репозитории, специфичные для партнеров.

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

Подобно частным, публичным и глобальным представлениям, известным из моделирования бизнес-процессов и рабочих процессов, в AIOS предоставляются соответствующие частные, публичные и глобальные представления элементов информационной системы.

1. Частное представление включает в себя единственные видимые изнутри элементы информационной системы.
2. Публичный вид действует как интерфейс к внутренним, частным элементам системы; он защищает внутренние системы и обеспечивает взаимодействие без необходимости внесения существенных изменений во внутренние системы. Этот публичный вид описывает границы информационной системы организации для ее партнеров по сотрудничеству и соединяет внутренние и внешние информационные системы, тем самым также предоставляя содержимое интерфейса взаимодействия бизнеса организации.
3. Глобальное представление можно использовать для корреляции и объединения публичных представлений различных систем.

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

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

Таким образом, в сочетании с осью «совместные представления» предоставляются частные, публичные и глобальные представления о процессах, функциях, данных и организационных ролях .

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

1. Уровень бизнеса : Здесь процессы, которые необходимо автоматизировать, описываются с уровня, независимого от техники. В MDA этот уровень называется уровнем CIM.
2. Технический уровень : Здесь описывается концепция ИТ. Поэтому модели первого уровня технически обогащены, например, вместо бизнес-функций теперь описываются компоненты, но все еще на грубом, концептуальном уровне. Поскольку модели на втором уровне представляют собой основу для автоматизированной генерации исполняемого кода, их, возможно, придется дополнительно адаптировать, чтобы соответствовать ограничениям уровня реализации.
3. Уровень выполнения : здесь модели интерпретируются машиной и могут использоваться во время выполнения процессов.