Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/ресурсов, временные модели типа диаграмм Ганта, модели причинно-следственных связей. Факт заключается в том, что нет «одной, самой лучшей» модели для описания бизнес-процессов. Можно провести аналогию с графиками, которые используются для иллюстраций.
Круговая диаграмма с сегментами, пропорциональными по размеру проценту чего-либо целого, отлично подходит для определенных задач, но ее нельзя использовать для иллюстрации и анализа всех типов данных (например, изменений каких-то данных во времени). Точно также при анализе бизнес-процессов выбранный метод моделирования должен отражать цели анализа. Оптимизация процесса по времени и четкий анализ взаимодействия между участниками процесса могут потребовать разных моделей.
Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architeсt, BPWin (новое название – AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. В данном курсе мы не будем останавливаться на сравнительном анализе этих и других средств, и отсылаем читателя к специализированным публикациям.
Основное внимание при разработке Бизнес-архитектуры должно уделяться «картине в целом». Целью Бизнес-архитектуры не является детальное описание деятельности предприятия. Модели, включенные в Бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Дальнейшая детализация выполняется с использованием таких инструментов, как:
1. декомпозиция функций/процессов;
2. анализ бизнес-событий;
3. моделирование местоположений выполнения функций/процессов;
4. модель интеграции функций/процессов.
Декомпозиция бизнес-процессов состоит в идентификации подпроцессов, которые составляют основу выполнения бизнес-функций, определении границ основных организационных единиц и определении вклада каждой функции в цепочку создания добавочной стоимости. Декомпозиция функций/процессов должна:
1. задать границы анализа рассмотрением наиболее критически важных функций бизнеса;
2. идентифицировать основные процессы, обеспечивающие выполнение функций организации;
3. идентифицировать межфункциональные процессы, которые являются первоочередными кандидатами на инновации, связанные с применением информационных технологий;
4. идентифицировать пересечения и излишние функции/процессы.
При этом на уровне описания архитектуры предприятия, во-первых, задача не состоит в документировании каждой функции, а во-вторых, описания должны быть достаточно краткими (не более нескольких страниц).
Таблица 5.2. Компоненты декомпозиции функций/процессов
- Определить границы каждой бизнес-функции
- Понять состав подпроцессов каждой бизнес-функции
- Дать основу для увязывания архитектуры информации, приложений и технологической архитектуры с бизнес-функциями
- Подпроцессы основных бизнес-функций
- Идентификация излишних и малополезных, неэффективных активностей
- Требования к прикладным системам и информации
- Каковы основные функции организации?
- Какие функции не несут в себе ценности?
- Какие функции пересекаются с другими бизнес-функциями?
Анализ бизнес-событий позволяет понять, как инициируются бизнес-события (например, оформление заказа) и какие связанные с ними процессы происходят в цепочке создания добавочной стоимости предприятия, что включает контакты с клиентами и поставщиками. При этом берется конкретное событие, документируется текущий процесс его обработки, и оцениваются возможности по его совершенствованию.
Таблица 5.3. Компоненты анализа бизнес-событий
- Обеспечить понимание ограниченного набора основных бизнес-событий
- Анализ возможностей по оптимизации бизнес-процессов
- Повышение эффективности операции, улучшение взаимодействия с клиентами,…
- Основные инициаторы и участники бизнес-событий
- Партнеры
- Идентификация критически важных артефактов, создающихся и используемых в процессе обработки события
- Проверка возможностей по новациям
- Новые формы ведения бизнеса
- Кто является инициатором бизнес-события?
- Как событие обрабатывается в рамках расширенного предприятия (партнеры и пр.)?
- Кто является основными участниками события?
- Возможны ли инновации, которые связаны с событием и требуются бизнесом?
Модель местоположений идентифицирует в географическом плане то место, где выполняются функции бизнеса, и обеспечивает логистический взгляд на функции, выполняемые организацией. Одним из очевидных преимуществ использования этой модели является идентификация архитектурных требований, которые предъявляются, в частности, к технологической архитектуре с точки зрения обеспечения информационного взаимодействия между различными местами расположения бизнеса. Однако целью моделирования местоположений является визуализация организационных единиц, определение мест, где выполняются функции и связей между ними.
Таблица 5.4. Компоненты модели местоположений
- Обеспечить понимание того, где выполняются функции и процессы
- Понимание требований, накладываемых географическим расположением на решения, касающиеся бизнес- и технологической архитектуры
- Понимание требований со стороны технологической архитектуры к географическому расположению функций
- Распределение функций по местоположениям
- Связи между бизнес-функциями
- Требования к технологической архитектуре и архитектуре прикладных систем
- Возможности по организационным изменениям
- Где выполняются основные функции?
- Какие функции связаны между собой?
- Существуют ли возможности по консолидации и рационализации?
Модель интеграции отражает высокоуровневые требования к интерфейсам между процессами и бизнес-событиями, требования, предъявляемые к информации новыми шаблонами процессов, и временные требования. Эта модель служит основой для построения архитектуры информации и архитектуры прикладных систем, а также содержит общие требования к архитектуре предприятия с точки зрения бизнес-информации и интеграции.
Таблица 5.5. Компоненты модели интеграции
- Обеспечить понимание ключевых внутренних и внешних точек интеграции
- Информационные потоки между участниками бизнес-событий
- Понимание основных интерфейсов прикладных систем
- Понимание требований к технологической архитектуре с точки зрения интеграции
- Потоки информации, которые требуются для реализации различных шаблонов бизнес-процессов
- Связи между функциями бизнеса
- Требования к архитектуре информации, приложениям и технологической архитектуре
- Возможности для организационных изменений
- Какая информация является критической для новых шаблонов реализации бизнес-процессов?
- Какие потоки информации существуют между различными точками соединения моделей бизнес-событий?
- Каковы требования с точки зрения времени?
После того как модели созданы, на их основе можно выполнять различные методы анализа:
1. Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)
2. Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)
3. Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней «пробелы»?)
4. Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)
5. Обучение (Как эти бизнес-процессы соотносятся с другими?)
6. Общая стоимость владения (Сколько стоит этот процесс?)
7. Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)
Безусловно, существует и множество других инструментов и моделей, полезных для более глубокого и более технологичного моделирования бизнес-процессов. В частности, могут использоваться контекстные диаграммы, диаграммы информационных потоков, а также конструкции и возможности языка UML, такие как сценарии использования, диаграммы последовательности, диаграммы деятельности и др. Подробное описание этих средств выходит за рамки данного курса.
Показатели эффективности являются важной составляющей бизнес-архитектуры. Например, в методике FEAF Федеральной Архитектуры США имеется отдельная, явно выделенная модель показателей эффективности.
Практически все модели, связанные с показателями эффективности бизнеса и процессов, используют несколько уровней метрик: метрики оценки «качества» самого процесса, метрики для оценки прямых результатов (output), метрики для оценки конечных результатов.
Метрики уровня процессов оценивают эффективность самого процесса. Типичными метриками являются время цикла выполнения операций, стоимость на транзакцию или единицу выхода процесса. Метрики оценки прямых результатов оценивают возможности процессов производить на выходе продукт или услугу в соответствии со спецификациями.
Типичными метриками оценки прямых результатов являются процент ошибок и количество обслуженных заявок в единицу времени. Метрики оценки конечных результатов оценивают процесс с точки зрения конечного потребителя (клиента) и выполнения функций организации. Примерами таких метрик являются уровень удовлетворенности клиента и эффективность продукта.
В связи с развитием принципов сервис-ориентированной архитектуры и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции.
Подводя итог, можно сказать, что бизнес-архитектура является основным инструментом синхронизации потребностей бизнеса и возможностей информационных технологий. В контексте архитектуры предприятия в целом разработка бизнес-архитектуры состоит в моделировании «картины в целом» и последующем углублении в тщательно отобранные ключевые процессы и информационные потоки, в том числе с использованием таких инструментов, как декомпозиция функций/процессов, анализ бизнес-событий, модели местоположений и модели интеграции.
Дата добавления: 2019-02-12 ; просмотров: 438 ; Мы поможем в написании вашей работы!
Источник: studopedia.net
Основные модели и инструменты описания бизнес-архитектуры
Как правило, руководители и сотрудники бизнес-подразделений находят задачу понимания архитектуры трудной и требующей слишком больших затрат времени. Действительно, за пределами служб ИТ роль и связующий фактор архитектуры предприятия зачастую не осознается, а взаимосвязи между данными являются непонятными.
Поэтому архитекторы нуждаются в простых, высокоуровневых средствах описания активностей и зависимостей в терминах, которые понятны бизнес-руководителям и пользователям и которые показывают соответствия с выполняемыми ими ролями. Графические бизнес-модели являются исключительно полезными в решении этой коммуникационной проблемы. Такие модели являются идеальным способом объяснить на достаточно высоком уровне критические активности и взаимосвязи в терминах бизнеса, и при этом они не требуют знаний в области ИТ. Модели обеспечивают важную связь между бизнес-целями и стратегиями деятельности организации и многими вариантами реализации ИТ (такими как готовые пакеты программ, унаследованные приложения, специально созданные заказные приложения, обслуживание по принципу аутсорсинга и подписки).
Модели бывают различных типов: модели процессов/потоков работ, функциональные модели, организационные модели, модели данных/ресурсов, временные модели типа диаграмм Ганта, модели причинно-следственных связей. Факт заключается в том, что нет «одной, самой лучшей» модели для описания бизнес-процессов. Можно провести аналогию с графиками, которые используются для иллюстраций.
Круговая диаграмма с сегментами, пропорциональными по размеру проценту чего-либо целого, отлично подходит для определенных задач, но ее нельзя использовать для иллюстрации и анализа всех типов данных (например, изменений каких-то данных во времени). Точно также при анализе бизнес-процессов выбранный метод моделирования должен отражать цели анализа. Оптимизация процесса по времени и четкий анализ взаимодействия между участниками процесса могут потребовать разных моделей.
Для автоматизации моделирования процессов сложился специальный класс программных продуктов. Наиболее известными являются такие продукты, как ARIS, Software Architect, BPWin (новое название — AllFusion Process Modeler), хотя в большом количестве случаев стандартных графических пакетов типа Microsoft Visio, текстового редактора и электронной таблицы бывает достаточно. В данном курсе мы не будем останавливаться на сравнительном анализе этих и других средств, и отсылаем читателя к специализированным публикациям.
Основное внимание при разработке Бизнес-архитектуры должно уделяться «картине в целом». Целью Бизнес- архитектуры не является детальное описание деятельности предприятия. Модели, включенные в Бизнес-архитектуру, должны давать необходимый минимум сведений о ключевых функциях, процессах, бизнес-событиях и потоках информации, достаточный для процесса принятия решений, поиска новых возможностей для инноваций. Дальнейшая детализация выполняется с использованием таких инструментов, как:
- • декомпозиция функций/процессов;
- • анализ бизнес-событий;
- • моделирование местоположений выполнения функций/ процессов;
- • модель интеграции функций/процессов.
Декомпозиция бизнес-процессов состоит в идентификации подпроцессов, которые составляют основу выполнения бизнес- функций, определении границ основных организационных единиц и определении вклада каждой функции в цепочку создания добавочной стоимости. Декомпозиция функций/ процессов должна: [1]
- • идентифицировать основные процессы, обеспечивающие выполнение функций организации;
- • идентифицировать межфункциональные процессы, которые являются первоочередными кандидатами на инновации, связанные с применением информационных технологий;
- • идентифицировать пересечения и излишние функции/ процессы.
При этом на уровне описания архитектуры предприятия, во- первых, задача не состоит в документировании каждой функции, а во-вторых, описания должны быть достаточно краткими (не более нескольких страниц).
Таблица 5.2. Компоненты декомпозиции функций/процессов
Основная область анализа
Результаты (артефакты) анализа
Основные вопросы
- • Определить границы каждой бизнес-функции
- • Понять состав подпроцессов каждой бизнес- функции
- • Дать основу для увязывания архитектуры информации, приложений и технологическо й архитектуры с бизнес- функциями
- • Подпроцессы основных бизнес-функций
- • Идентификация излишних и малополезных, неэффективных активностей
- • Требования к прикладным системам и информации
- • Каковы основные функции организации?
- • Какие функции не несут в себе ценности?
- • Какие функции пересекаются с другими бизнес- функциями?
Анализ бизнес-событий позволяет понять, как инициируются бизнес-события (например, оформление заказа) и какие связанные с ними процессы происходят в цепочке создания добавочной стоимости предприятия, что включает контакты с клиентами и поставщиками. При этом берется конкретное событие, документируется текущий процесс его обработки, и оцениваются возможности по его совершенствованию.
Таблица 5.3. Компоненты анализа бизнес-событий
Основная область анализа
Результаты (артефакты) анализа
Основные вопросы
- • Обеспечить понимание ограниченного набора основных бизнес-событий
- • Анализ возможностей по оптимизации бизнес- процессов
- • Повышение эффективности операции, улучшение взаимодействия с клиентами.
- • Основные инициаторы и участники бизнес-событий
- • Партнеры
- • Идентификация критически важных артефактов, создающихся и используемых в процессе обработки события
- • Проверка возможностей по новациям
- • Новые формы ведения бизнеса
- • Кто является инициатором бизнес-события?
- • Как событие обрабатывается в рамках расширенного предприятия (партнеры и пр.)?
- • Кто является основными участниками события?
- • Возможны ли инновации, которые
связаны с событием и требуются бизнесом?
Модель местоположений идентифицирует в географическом плане то место, где выполняются функции бизнеса, и обеспечивает логистический взгляд на функции, выполняемые организацией. Одним из очевидных преимуществ использования этой модели является идентификация архитект урных требований, которые предъявляются, в частности, к технологической архитектуре с точки зрения обеспечения информационного взаимодействия между различными местами расположения бизнеса. Однако целью моделирования местоположений является визуализация организационных единиц, определение мест, где выполняются функции и связей между ними.
Таблица 5.4. Компоненты модели местоположений
Основная область анализа
Результаты (артефакты) анализа
Основные вопросы
• Обеспечить понимание того, где
выполняются функции и процессы
- • Понимание требований, накладываемых географическим расположением на решения, касающиеся бизнес- и технологическо й архитектуры
- • Понимание требований со стороны технологическо й архитектуры к географическом у расположению функций
- • Распределение функций по местоположени ям
- • Связи между бизнес- функциями
- • Требования к технологическо й архитектуре и архитектуре прикладных систем
- • Возможности по организационны м изменениям
- • Какие функции связаны между собой?
- • Существуют ли возможности по консолидации и рационализаци и?
Модель интеграции отражает высокоуровневые требования к интерфейсам между процессами и бизнес-событиями, требования, предъявляемые к информации новыми шаблонами процессов, и временные требования. Эта модель служит основой для построения архитектуры информации и архитектуры прикладных систем, а также содержит общие требования к архитектуре предприятия с точки зрения бизнес- информации и интеграции.
Таблица 5.5. Компоненты модели интеграции
Основная область анализа
Результаты (артефакты) анализа
Основные вопросы
- • Обеспечить понимание ключевых внутренних и внешних точек интеграции
- • Информационн ые потоки между участниками бизнес-событий
- • Понимание основных интерфейсов прикладных систем
- • Понимание требований к технологическо й архитектуре с точки зрения интеграции
• Потоки информации, которые
- • Связи между функциями бизнеса
- • Требования к архитектуре информации, приложениям и технологическо й архитектуре
- • Возможности для
организационны х изменений
- • Какая информация является критической для новых шаблонов реализации бизнес- процессов?
- • Какие потоки информации существуют между различными точками соединения моделей бизнес- событий?
- • Каковы требования с точки зрения времени?
После того как модели созданы, на их основе можно выполнять различные методы анализа: •
Анализ цепочек создания добавочной стоимости (А нужно ли вообще выполнять этот шаг?)
- • Динамическое моделирование (Как эта модель выполнения бизнес-функций будет себя вести при различных значениях на входе и доступных ресурсах, и как со временем будет меняться поведение процесса?)
- • Анализ пересечений и непокрытых областей (Gap-overlap analysis) (Будет ли наша бизнес-архитектура иметь избыточные элементы, и есть ли в ней «пробелы»?)
- • Соотнесение затрат с активностями (Activity-based costing) (На каких процессах, каналах продаж и заказчиках мы реально зарабатываем или теряем деньги?)
- • Обучение (Как эти бизнес-процессы соотносятся с другими?)
- • Общая стоимость владения (Сколько стоит этот процесс?)
- • Возврат инвестиций (ROI) (Будет ли достигнут возврат инвестиций в данный бизнес-процесс и когда?)
Такие модели обычно имеют прямой выход на процесс генерации архитектуры приложений, как это предполагается в подходе разработки архитектуры, управляемой моделями (MDA) (см. лекции 7).
Безусловно, существует и множество других инструментов и моделей, полезных для более глубокого и более технологичного моделирования бизнес-процессов. В частности, могут использоваться контекстные диаграммы, диаграммы информационных потоков, а также конструкции и возможности языка UML, такие как сценарии использования, диаграммы последовательности, диаграммы деятельности и др. Подробное описание этих средств выходит за рамки данного курса.
Мы уже отмечали, что показатели эффективности являются важной составляющей бизнес-архитектуры. Например, в методике FEAF Федеральной Архитектуры США имеется отдельная, явно выделенная модель показателей эффективности.
Практически все модели, связанные с показателями эффективности бизнеса и процессов, используют несколько уровней метрик: метрики оценки «качества» самого процесса, метрики для оценки прямых результатов (output), метрики для оценки конечных результатов.
Метрики уровня процессов оценивают эффективность самого процесса. Типичными метриками являются время цикла выполнения операций, стоимость на транзакцию или единицу выхода процесса. Метрики оценки прямых результатов оценивают возможности процессов производить на выходе продукт или услугу в соответствии со спецификациями.
Типичными метриками оценки прямых результатов являются процент ошибок и количество обслуженных заявок в единицу времени. Метрики оценки конечных результатов оценивают процесс с точки зрения конечного потребителя (клиента) и выполнения функций организации. Примерами таких метрик являются уровень удовлетворенности клиента и эффективность продукта.
В связи с развитием принципов сервис-ориентированной архитектуры (см. лекции 7) и появлением технологически нейтрального, платформенно-независимого языка описания и выполнения бизнес-процессов BPEL (Business Process Execution Language) появилась возможность не только моделировать бизнес-процессы, но и делать их целиком или частично доступными другим системам и организациям в виде сервисов. К этому можно добавить также возможности еще одного стандарта XML Metadata Interchange (XMI) для обмена (экспорта/импорта) данных практически в любые интеграционные продукты. В совокупности это дает возможность создавать модели и репозитории бизнес-процессов для их эффективной интеграции. Более подробную информацию о новых стандартах для моделирования процессов можно найти на сайте ссылка: www.bpmi.org — http://www.bpmi.org.
Подводя итог, можно сказать, что бизнес-архитектура является основным инструментом синхронизации потребностей бизнеса и возможностей информационных технологий. В контексте архитектуры предприятия в целом разработка бизнес- архитектуры состоит в моделировании «картины в целом» и последующем углублении в тщательно отобранные ключевые процессы и информационные потоки, в том числе с использованием таких инструментов, как декомпозиция функций/процессов, анализ бизнес-событий, модели местоположений и модели интеграции.
- [1] задать границы анализа рассмотрением наиболеекритически важных функций бизнеса;
Источник: bstudy.net
Результатом описания бизнес архитектуры является
Рис. 2. Методика разработки архитектуры (ADM) в модели TOGAF
Модель TOGAF позиционируется как «структура», однако наиболее важным ее компонентом является методика разработки архитектуры (ADM). Эта методика представляет собой рецепт по созданию архитектуры. Рецепт можно классифицировать как процесс.
Как показано на рис. 1, методика разработки архитектуры в модели TOGAF состоит из восьми этапов, которые циклически повторяются после первой «накачки». Далее эти этапы будут рассмотрены на примере MedAMore. Однако перед тем как компания MedAMore сможет приступить к использованию методики разработки архитектуры, ей необходимо изучить модель TOGAF. Изучить модель TOGAF можно двумя способами.
Во-первых, компания MedAMore может изучить модель TOGAF самостоятельно. Компания MedAMore может загрузить документацию по TOGAF — в ней достаточно подробно описаны все возможности TOGAF, в том числе методика разработки архитектуры. Также можно приобрести книги по TOGAF. О модели TOGAF доступно больше информации (как бесплатной, так и за умеренную цену), чем обо всех остальных методологиях построения архитектуры вместе взятых.
Во-вторых, компания MedAMore может обратиться к экспертам по TOGAF. На рынке работает множество консультантов по TOGAF, обладающих сертификатами Open Group. Поскольку руководство компании MedAMore хочет свести все риски к минимуму, оно принимает решение обратиться к консультанту по TOGAF. Компания MedAMore обратилась к Тэри, которая является архитектором TOGAF с сертификатом Open Group. Напомним, что другими игроками в компании MedAMore являются Кэт, исполнительный директор MedAMore, Брет, вице-президент по бизнесу, и Ирма, директор по информационным технологиям.
На подготовительном этапе Тэри встречается с основными игроками в компании MedAMore и рассказывает им о процессе TOGAF. Она преследует три основные цели:
· Убедиться в том, что процесс устраивает всех игроков
· Если необходимо, изменить процесс TOGAF в соответствии с корпоративной культурой MedAMore
· Разработать систему управления для надзора за последующей разработкой архитектуры в MedAMore
Тэри будет тесно сотрудничать с Бретом, чтобы понять философию бизнеса, изучить бизнес-модели и стратегические задачи MedAMore. Ей также придется тесно взаимодействовать с Ирмой, чтобы определить архитектурные принципы, лежащие в основе используемых в MedAMore технологий, и задокументировать эти принципы в формате, рекомендуемом моделью TOGAF.
В некоторых организациях осознание необходимости создания архитектуры предприятия дается с большим трудом. Такая ситуация возникает, когда инициатива исходит от ИТ-подразделения, и особенно в случае продолжительного противостояния бизнес и ИТ-подразделений организации. В компании MedAMore сложилась именно такая ситуация. Однако Тэри придется учитывать еще один факт: инициатива исходит не от ИТ-отдела, а от исполнительного директора Кэт. Этот факт придает проекту высокую прозрачность и стимулирует всех участников к сотрудничеству.
По завершении подготовительного этапа Тэри готова перейти к этапу А. Этот этап начинается, по крайней мере, в теории, с Запроса на разработку архитектуры от какого-либо подразделения компании MedAMore. В этом документе излагаются причины запроса с точки зрения бизнеса, приводится бюджет и сведения о персонале, а также указываются ограничения, которые необходимо учитывать. Поскольку в компании MedAMore никогда не создавались Запросы на разработку архитектуры, Тэри придется помочь организации в создании подобного запроса.
После получения «Запроса на разработку архитектуры» (или аналогичного документа) Тэри (консультант по TOGAF) переходит к этапу А. На этом этапе Тэри предстоит убедиться в том, что проект надлежащим образом поддерживается компанией MedAMore, определить область действия проекта, выявить ограничения, задокументировать бизнес-требования и разработать высокоуровневые определения как для базовой (начальной), так и для целевой (желаемой) архитектуры.
Эти базовые и целевые определения включают высокоуровневые определения для всех архитектур, составляющих архитектуру предприятия, а именно для архитектуры бизнеса, технологической архитектуры, архитектуры данных и архитектуры приложений.
Основным документом, создаваемым на этапе А, является «Постановление о разработке архитектуры», которое должно быть утверждено всеми заинтересованными лицами. После этого можно переходить к следующему этапу. В конце этого этапа формируется архитектурное представление для первой итерации цикла разработки архитектуры. Тэри поможет компании MedAMore выбрать проект, проверить проект на соответствие архитектурным принципам, сформулированным на подготовительном этапе, и убедиться в том, что были определены все заинтересованные лица, а обозначенные этими лицами проблемы были устранены.
Архитектурное представление, созданное на этапе А, является основой для этапа Б. Цель Тэри на этапе Б заключается в создании детализированной базовой и целевой архитектур бизнеса и всестороннем анализе различий между этими архитектурами. Для достижения этой цели Тэри в основном будет работать с Бретом (или его подчиненными).
Этап Б довольно сложен: он включает бизнес-моделирование, подробный анализ бизнеса и документирование технических требований. Для успешной реализации этапа Б необходимо участие многих заинтересованных лиц. Основным результатом является подробное описание базовых и желаемых бизнес-целей, а также описание различий между двумя архитектурами бизнеса.
На этапе В выполняются все те же действия, что и на этапе Б, только для архитектуры информационных систем. На этом этапе Тэри работает в основном с Ирмой (или ее подчиненными). В модели TOGAF определено девять этапов, каждый из которых разбит на несколько под этапов:
· Разработка описания базовой архитектуры данных
· Просмотр и проверка принципов, эталонных моделей, точек зрения и средств
· Создание архитектурных моделей, в том числе логических моделей данных, моделей управления данными и моделей отношений, в которых бизнес-функции сопоставляются операциям над данными (создание, чтение, обновление и удаление)
· Выбор компонентов архитектуры данных
· Формальный анализ контрольных точек модели архитектуры и ее компонентов вместе с заинтересованными лицами
· Анализ качественных критериев (например, производительности, надежности, безопасности и целостности)
· Завершение архитектуры данных
· Анализ контрольных точек и последствий
Наиболее важным результатом этого этапа является информация о целях и архитектура приложений.
На этапе Г формируется технологическая архитектура — инфраструктура, необходимая для поддержки новой архитектуры. На этом этапе в основном задействуются технические специалисты Ирмы.
На этапе Д выполняется оценка различных возможностей реализации, определяются основные проекты по внедрению, которые необходимо выполнить, а также связанные с каждым проектом возможности для бизнеса. Стандартом TOGAF на этапе Д рекомендуется «сосредоточиться на проектах, которые дадут результаты в краткосрочной перспективе и позволят реализовать долгосрочные проекты».
Это хороший совет для любой методологии построения архитектуры. Таким образом, Тэри следует выделить проекты, которые можно реализовать с минимальными затратами и максимальной отдачей. Для поиска таких проектов рекомендуется изучить «болевые точки» организации, изначально обозначенные Кэт (исполнительным директором MedAMore). Это позволит принять стратегию развития предприятия на базе архитектуры. Описанные выше «болевые точки» включают трудности в обеспечении поддержки специализации на уровне регионов и складов и ненадежный обмен данными.
Этап Е тесно связан с этапом Д. На этом этапе Тэри работает с руководством компании MedAMore’s, чтобы упорядочить по приоритетам проекты, выбранные на этапе Д, с учетом не только затрат и выхода (определенных на этапе Д), но и факторов риска.
На этапе Ж Тэри на основе упорядоченного по приоритетам списка проектов создает спецификации архитектуры для проектов реализации. Эти спецификации включают критерии приемки и списки рисков и проблем.
Последним этапом является этап З. На этом этапе Тэри корректирует процесс управления архитектурными изменениями с учетом новых артефактов, созданных на последней итерации, и новых данных.
После этого цикл повторяется. Одной из целей первого цикла является передача информация, поэтому с каждой новой итерацией потребность в услугах Тэри снижается.
Многие результаты процесса TOGAF можно получить как с помощью Тэри (консультанта), так и на основе собственно спецификации TOGAF. Методология TOGAF весьма гибкая, а детали реализации архитектурных артефактов могут быть различны. В одной из книг по TOGAF говорится:
Источник: studbooks.net
