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

Предпосылки использования информационной архитектуры

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

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

Методология десяти шагов

Методология десяти шагов является мощной и достаточно гибкой для поддержания широкого спектра корпоративных стратегий, включая:

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

Некоторые из ключевых особенностей и преимуществ данной методологии в сравнении с другими промышленными методологиями: 

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

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

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

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

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

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

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

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

Ниже приведено высокоуровневое описание каждого из 10 шагов:

1. Организация управляющего комитета: определение бизнес и ИТ-руководителей, которые будут служить в качестве группы принятия решения на предприятии; определить устав комитета и бизнес-мотивацию для его существования, и установить свою операционную модель.
2. Определение структуры управления: определите, что, кто, как и когда делает в процессе управления; политику в области данных, документов, интеграционных принципов и технологических стандартов, при этом все программы должны быть согласованы и соответствовать этим стандартам.
3. Разработка корпоративной модели: создание сверху вниз концептуальных базовых моделей, в том числе: целевой операционной модели; мартицы бизнес-функций; и концептуальной бизнес модели.
4. Назначение организационных ролей: определить владельцев и распорядителей данных для информационных областей; функциональных владельцев для общих бизнес-функций в сервис-ориентированной архитектуры или координаторов для управления данными.
5. Определить области охвата программы: модель должна четко определить сферу действия данной программы и разработать план действий.
6. Оценить основное направление использования архитектуры предприятия и качество данных предприятия: использование модели предприятия и описания содержания работ для получения архитектурной оценки состояния в текущий момент и определения ответственных со стороны бизнеса и с технической стороны.
7. Разработать целевую архитектуру: разработка архитектуры данных/систем/сервисов будущего состояния итеративным способом в сочетании с шагом 6.
8. Разработка плана миграции: разработка общей стратегии реализации программы и плана действий.
9. Разработка модели программы: создание модели бизнес-данных и модели обмена информацией для определенной программы (логические и физические модели, как правило, создаются в отдельных проектах в рамках программы).
10. Реализация проектов: это стандартная дисциплина управления проектами и программами с тем исключением, что некоторые программы управления данными не имеют определенного окончания. Некоторые процессы (шаги 2, 3, 4, 5) могут повторяться итеративно для обеспечения их актуальности и поддержания изменений требований.  

Ключевые особенности структуры включают: 

• Отдельные модели представления данных в состоянии покоя (данные сохраненные в репозитории и поддерживаются компонентами приложения) и данных в движении (обмен данными между компонентами приложений). 
• Четырехуровневая архитектура с абстракцией каждого уровня для определенной категории заинтересованных сторон и информации, которая им необходима:   
  1. Уровень 4 – видение предприятия: общепрограммный       контекст для руководителей и менеджеров данных.
  2. Уровень 3 – бизнес видение: модели       сегмента для владельцев бизнеса и спонсоров проекта.
  3. Уровень 2 – видение решения: архитектурные       модели для конкретных систем и решений.
  4. Уровень 1 – технологическое видение:       технические модели для разработчиков, инженеров и обслуживающего персонала.
• Уровни 3 и 4 разрабатываются сверху вниз.
• Уровни 1 и 2 создаются сверху вниз при выполнении определенной конкретной разработки (то есть когда есть возможность контролировать и влиять на модели данных). Если же речь идет о наследовании или интеграции, то движение идет снизу вверх (то есть, возможности контролировать модели почти отсутствуют, а в целом необходимо производить перепроектирование моделей при помощи аналитических инструментов).    

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

Эталонные модели 

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

2. Бизнес Функция/Информационная Матрица: используется для определения основных операционных возможностей, соответствующих сервисов и информационных потоков, генерирующих создание и использование матрицы. Основные функции сервисов используются как навигационные точки при обработке модели (отражение процесса и целевые модели систем). 

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

Информационные модели 

1. Информационная объектная модель: Используется для обеспечения связи между функциями предприятия, моделями систем и бизнес глоссарием (т.е., информационный объект включает в себя список элементов данных из бизнес-глоссария). Допускается использование для оценки текущих возможностей по управлению информацией (отражение в процессе и целевых моделях системы) или в качестве концептуальной модели для компонентов приложений, разработанных пользователями. 

2. Бизнес глоссарий: список элементов бизнес данных с соответствующими бизнес описаниями.

Процессные модели 

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

2. Диаграмма последовательности: Альтернативное представление операционных сценариев с использованием методов UML. 

3. Модель бизнес событий: общее (каноническое) описание бизнес событий, включая триггеры бизнес процессов, целевых участников и описание полезной работы (от элементов в бизнес-глоссарии)

Мои статьи:

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

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

2. Курс ITIL