Разработка ПО (архитект. ис)

Принципы данных

Описание архитектурной работы

Видение архитектуры

Черновики определения архитектуры

Черновик спецификации требований к арх:

Результат gap-анализа(из всех арх.)Технические требования,

относящиеся к этой фазе

Шаги:

Выбрать рефересную модель, точки зрения и инструменты

Разработать описание текущей техн. архитектуры

Разработать описание целевой техн. архитектуры

Осуществить gap – анализ

Определить кандидатов в план работ

Разрешить влияние на архитектурный ландшафт

Осуществить формальное ревью стейкхолдеров

Закончить архитектуры данных

Создать документ определения архитектуры данных.

Артефакты:

Уточненная и обновленная версия видения архитектуры

Черновой документ определить архитектуры

Черновой вариант спецификации требований к архитектуре

Компоненты архитектуры данных в плане работ

TOGAF. ADM. Фазы подготовки к реализации архитектуры (Фазы E-F). Используемые в работе артефакты, ключевые шаги и ключевые артефакты результата.

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

Фаза F: Планирование перехода определяет мероприятия для перехода из текущего состояния архитектуры в целевое. Фаза предусматривает разработку «Плана реализации и перехода», детализированного до уровня пакетов работ, которым можно дать стоимостную оценку и, в конечном счёте, оценить проектные параметры (объём, сроки, стоимость) всего перехода в целом.

Фаза Е

Цель:

Создать начальную версию плана архитектурных работ

Определить нужно или нет постепенное внедрение

Определить/согласовать ключевые атрибуты изменений

Определить бизнес-ограничения реализации

Пересмотреть и консолидировать результаты GAP-анализа фаз B-D

Рассмотреть консолидированные требования по связным с бизнес-функциям

Консолидация и сверка требований совместимости

Уточнить и провалидировать зависимости

Подтвердить готовность и риски изменения бизнеса

Сформулировать стратегию реализации и миграции

Определить и сгруппировать главные пакеты работ

Определить архитектуры перехода

Создать план архитектурных работ и план реализации и миграции

Артефакты:

Уточненная и обновленная версия видения архитектуры

Черновой документ определения архитектуры, обновленный при необходимости

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

Оценка возможностей

План архитектурных работ

План реализации и миграции

Фаза F

Цель:

Финализировать план архитектурных работ, план реализации и миграции

Гарантировать, что план внедрения и миграции координируется с подходом предприятия к управлению и внедрению изменения в полном портфеле изменения предприятия

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

Шаги:

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

Назначить бизнес-ценность для каждого пакет работ

Оценить требования к ресурсам, временную оценку проекта и механизм возможности и доставки

Приотиризировать проекты миграции сквозь оценки стоимости/выгоды и валидации рисков

Артефакты:

Организованная модель корпоративной архитектуры:

Задействованные организации

Роли и обязанности архитектурной команды

Ограничение, накладываемые на разработку архитектуры

Бюджетные ограничения

Стратегия управления и поддержки

Адаптированный архитектурный фреймворк

Подготовленный архитектурный репозиторий

Связь с бизнес-принципами, бизнес-целями, бизнес-драйверами

Фреймворк управления архитектурой

TOGAF. ADM. Фазы реализации архитектуры и управления изменениями (Фазы G-H). Используемые в работе артефакты, ключевые шаги и ключевые артефакты результата.

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

Фаза H: Управление изменениями в архитектуре. Для того чтобы обеспечить достижение изначальных целей в меняющихся условиях, необходимо управлять всеми изменениями, которые вносятся в целевую архитектуру.

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

Этап G:

Цель:

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

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

Шаги:

Согласовать контекст и приоритеты для развертывания с менеджерами разработки

Идентифицировать ресурсы и навыки развертывания

Управление разработкой решений по развертыванию

Осуществление проверки корпоративной архитектуры

Реализация бизнес и IT операций

Осуществление ревью по факту завершения и закрытия реализации

Артефакты:

Контракт архитектуры (подписанный)

Оценка соответствия

Запросы на изменение

Развернутые архитектурные решения, включая:

Подготовленный архитектурный репозиторий

Рекомендации соответствия архитектуры и разрешения

Рекомендации на требованиях предоставления услуг

Рекомендации на метриках производительности

Соглашения об уровне обслуживания

Видение архитектуры, обновленная постреализация

Документ определения архитектуры

Бизнес и операционные модели IT для реализованного решения

Этап H:

Цель:

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

Гарантировать, что фреймворк управления архитектурой выполняется

Гарантировать, что возможности архитектуры соответствуют текущим требованиям.

Шаги:

Учредить процесс реализации ценности

Развернуть инструменты мониторинга (архитектурного)

Управление рисками

Предоставление анализа по Управлению изменениям архитектуры

Разработка запросов на изменение с целью достижения целей производительности.

Артефакты:

Обновленная архитектура (для изменений обслуживания)

Изменения в структуре и принципах архитектуры (для изменений обслуживания)

Новый запрос на разработку архитектуры, «по второму кругу» для существенных изменений

Контракт архитектуры, обновляется при необходимости

Оценки соответствия, обновляется при необходимости

TOGAF. Architecture Content Framework. Назначение, основные понятия. Ядро и расширение. Блоки построения архитектуры.

В процессе работы над корпоративной архитектурой возникают различного вида результаты: диаграммы процессов, требования к архитектуре, планы проектов по переходу из одного состояние в другое, результаты проведения авторского надзора и т. п. Благодаря Architecture Content Framework (ACF), который является частью TOGAF, все эти объекты–результаты чётко определены и представляют собой целостную систему для архитектурного описания.

Назначение

•Типизация артефактов

•Описание артефактов

•Связь артефактов с ADM

Категории результата работы

•Доставленный (deliverable) – принят заказчиками, результат проекта.

•Артефакт – описывает аспект архитектуры

•Блок построения (building block) – представляет (переиспользуемый) компонент

•Блок построения архитектуры – спецификация для

•Блок построения решения – компоненты реализации

Связь между категориями

Content metamodel

Концепции метамодели:

•Содержимое ядра и расширений

•Сущности ядра метамодели

•Концепция каталогов, матриц и диаграмм

Модель содержимого и расширения

Ключевые сущности

Architectural Artifacts

•Архитектурные артефакты

•Все по ISO/IEC 42010: 2007

•Привязка к фазам ADM

•Рекомендованные для разработки представления

Артефакт – это что-то, что позволяет нам создать архитектурную поставку (например, матрица стейкхолдеров)

Architecture Deliverables

•Поставляемые результаты работ

•Описаны все входы/выходы ADM

Архитектурная поставка – это подписанный документ, который является значимым и содержим в себе консолидированную информацию из артефактов

Building blocks

Блоки построения архитектуры или решения.

Общие характеристики:

•Блок это пакет функциональности (помним про полезность бизнесу)

•Имеет тип из метамодели содержимого TOGAF (актер, бизнес-функция, бизнес сервис и т.д.)

•Имеет определенные границы и в домене выявлен как «вещь»

•Блок взаимодействует с другими блоками

Характеристики хорошего блока

•Рассматривается к реализации и использованию

•Может быть собран из других блоков

•Может быть часть других блоков

•Идеально – переиспользуемый, заменяемый и имеет хорошую спецификацию

Блок построения архитектуры

•Описывания ограничения:

•Бизнес

•Данных

•Приложений

•Технологий

•Управляет разработкой блоков построения решения Блок построения решения

•Определяет, какие продукты и компоненты реализуют функциональность

•Определяют реализацию

•Выполняет бизнес-требование

•Продукт или выбранный поставщик

----------------------------------------------------------------------------------------------------------------

Всоответствии с ACF все результаты можно разбить на три основные категории:

Конечный результат (Deliverable) — представляет собой результат проекта, зафиксированный в контракте или ином официальном документе. Это скорее проектный термин, чем архитектурный. Категория конечный результат используется на уровне руководства для приёмки работ. Работа считается сделанной, если получены все запланированные конечные результаты. В архитектурных проектах конечными результатами могут быть эталонная модель, стандарт или архитектурная схема, описывающая состояние системы на момент времени.

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

oКаталоги (списки) — например, каталог используемых информационных систем.

oМатрицы — показывают отношения между различными элементами, например, матрица трассировки требований на бизнес-процессы.

o Диаграммы — например, диаграммы вариантов использования (use-case).

Отмечу, что каждый конечный результат может включать несколько артефактов. Например, эталонная модель может состоять из множества схем и описаний.

Строительные блоки (Building blocks) представляют собой реальные компоненты бизнеса или ИТ, которые можно связать друг с другом и получить архитектурное решение. В идеале строительные блоки предполагается делать многоразовыми.

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

Строительные блоки бывают двух видов:

oАрхитектурные блоки (Architecture Building Blocks) — определяют требования и создают каркас, необходимый для их реализации. Например, на уровне предприятия архитектурным блоком может стать необходимость предоставления клиентского сервиса, что, в конечном счёте, приведёт к

разработке различных решений как на уровне бизнеса, так и на уровне ИТ.

oБлоки реализации (Solution Building Blocks) — определяют компоненты готового решения. Например, корпоративная сеть, как готовый продукт, может быть строительным блоком при разработке распределённой информационной системы.

Отношения между конечными результатами, артефактами и строительными блоками показаны на примере

В рассмотренном примере конечным результатом (Deliverable) является документ «Описание архитектуры». Этот документ включает различные артефакты: каталог требований, описание бизнес-процессов, схему серверов и т. д. Каждый артефакт описывает некоторый аспект системы документооборота, которая является строительным блоком. Сами же артефакты включают различные строительные блоки, например, схема серверов включает сервер базы данных, а бизнес-процессы описывают работу подразделения «Канцелярия».