Разработка IT Архитектуры: Принципы построения сервиса интеграции данных

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

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

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

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

Уровни:

• Проект: Интеграционные процессы носят разовый характер, а успех зависит от усилий компетентных и опытных людей. Интеграция, как правило, рассматривается в качестве проектной деятельности (или ее части) и происходит в течение всего жизненного цикла проекта. Разовый характер проявляется в однократном выполнении интеграции в производстве. Некоторые интеграционные процессы определяются формально. Ограниченное управление изменениями используется в качестве контрольной функции на производстве.    
• Программа: Интеграционные процессы определяются для идентификации межфункциональных и межсистемных взаимодействий при планировании изменений в начале жизненного цикла проекта. Основные показатели интеграции анализируются по стоимости, расписанию и требованиям для отслеживания и повторения успешных интеграционных инициатив с аналогичными характеристиками. Контроль изменений превратился в управление изменениями. Формальный процесс выпуска определяет, что интеграция производится с управлением изменениями и конфигурациями и используется для контроля изменений в приложениях. 
• Поддержка:   Процессы управления интеграцией для полного жизненного цикла стандартизированы, документированы и повсеместно применяются на предприятии. Методологией построения интеграции установлена ответственность за управление и оптимизацию систем интеграции на производстве. При разработке приложения обязательно должен закладываться функционал для взаимодействия с интеграционным слоем. Требования по интеграции имеют больший вес, чем функциональные требования при выборе продукта. 
• Интеграция:   Постоянное совершенствование осуществляется через обратную связь от процессов и от пилотных инновационных технологий. Внутренние и внешние определения данных и процессов унифицированы, и общие бизнес-функции поддерживают все направления. Сотрудники, не являющиеся разработчиками, имеют возможность определять и реализовывать новые интеграционные взаимодействия в рамках определенных предметных областей путем работы с интеграционными порталами самообслуживания. 

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

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

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

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

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

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

5. Поддержка метаданных: Поддержка метаданных об интеграционных взаимосвязях и потоках данных является обязанностью ответственных за интеграцию и ее сопровождение лиц, а так же в их компетенцию входит поддержка приложений и изменение зависимостей. 

6. Контроль изменения конфигураций: Установить постоянный процесс управления изменениями в приложениях и их последствиями или воздействием на другие приложения. 

7. Адаптация LEAN системы управления: Выберите из более чем 30ти инструментов, методов и концепций, позволяющих и поощряющих внедрение LEAN интеграционных принципов. 

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

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

При внедрении единой системы интеграции в организации есть ряд шагов по определению области системы интеграции, созданию подразделения, ответсвенного за интеграцию (если применимо) и определению операционных и рационализаторских процедур.                      

Шаг 1: Определить область интеграционной системы. 

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

Шаг 2: Создание каталога. 

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

Шаг 3: Инвентаризация бизнес систем и интеграционных систем. 

Инвентаризуются бизнес-системы, задействованные в проекте. Каждой системе устанавливается класс из систематики, определенной на шаге 1. Далее метаданные каждой системы собираются и загружаются в репозиторий. 

Шаг 4: Инвентаризуются интеграционные системы организации. 

Не обязательным (но рекомендуемым) шагом является определение технологий, используемых бизнес системами и интеграционными системами. Это помогает выявить пробелы и совпадения в технологиях или функциях в организации. 

Шаг 5: Определить подразделение, ответственное за интеграцию. 

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

Шаг 6: Разработать стандарты использования. 

После завершения инвентаризации следует определить в каких случаях каждая система и каждая технология (если технологии определялись на шагах 3 и 4) используются. Рекомендуется установить стандарты использования и согласовать их со всеми ответственными за ресурсы, задействованными в проекте.  Также рекомендуется предпринять шаги по выявлению избыточных технологий, такие как метод классификации, методы gap анализа и стратегии рационализации. 

Шаг 7: Установить соглашения об уровне сервиса (SLA) 

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

Шаг 8: Подготовить описание порядка работы с системами 

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

Шаг 9: Разработать план миграции. 

Целью подразделения, ответственного за интеграцию является консолидация, централизация и стандартизация (что позволяет повторно использовать объекты и упрощает разработку и операции). Для достижения этой цели необходимо принять решение относительно того, какие бизнес инструменты и процессы из имеющегося набора будут использоваться, а какие будут объединены либо изъяты из обращения. Шаг 9 опирается на результаты, определенные для целевой архитектуры в шаге 6 путем использования выявленных расхождений и перекрытий в технологиях и разработки плана принятия решений по поводу существующих в организации систем интеграции, которые не укладываются в рамки новой парадигмы. На данном шаге также можно воспользоваться лучшей практикой – «Оптимизацией портфелей». 

Мои статьи:

1. Принципы построения модели данных 

Семантика данных
Поддержание производительности

2.  Методология десяти шагов для Разработки IT-Архитектуры

3. Курс ITIL