Вадим Алджанов - ИТ-архитектура. Практическое руководство от А до Я. Первое издание

•Четкое определение задач и целей проекта;

•Формулирование функционально-технических требований к проекту;

•Инфраструктурный аудит ИТ-системы предприятия для проектирования архитектуры решения;

•Формализация существующих на предприятии бизнес-процессов, автоматизируемых в рамках проекта;

•Получение данных для обоснования количества лицензий;

•Оценка ресурсов, которые потребуются для реализации проекта;

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

•Разработка предварительного плана проекта, графика работ и спецификации поставок по каждому этапу и проекту в целом.

Результаты обследования:

•Отчет с фиксацией ситуации в виде «Как есть»;

Предложение по созданию информационной системы в виде «Как необходимо»;

•Предложение по «Функционально-техническим требованиям к проекту»;

•План реализации проекта;

•Оценка рисков проекта и предложения по их минимизации;

•Ориентировочная стоимость пилотного проекта и конечного решения.

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

•Адаптация и настройка базовых, при необходимости разработка новых решений в соответствии с функционально-техническими требованиями, полученными на этапе обследования;

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

•Опытная эксплуатация решения;

•Интеграция с ERP-системой;

•Ввод системы в промышленную эксплуатацию.

Обучение технического персонала и пользователей.

Обеспечение дополнительного функционала – работы, выделенные на этапе обследования в отдельные этапы .

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

Модель Архитектуры Предприятия можно разделить на несколько ключевых уровней (категорий):

•Архитектура бизнеса – содержит стратегию компании, подход к управлению, организационную структуру и ключевые бизнес процессы.

•Архитектура информационных систем – описывает, как устроены или будут устроены информационные системы компании. Архитектура информационных систем может быть разбита на две подгруппы:

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

•Архитектура данных – содержит описание логической и физической структуры данных компании, а также подход и средства управления данными.

•Техническая архитектура – описывает программное обеспечение и оборудование, которое необходимо для развертывания бизнес сервисов, данные и приложения, ИТ инфраструктуру, сервера приложений, сети, телекоммуникации, стандарты и т. д.

Следующим уровнем иерархии может быть по:

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

•Архитектура сегмента . Это архитектура направления деятельности компании, программы проектов или отдельного подразделения. Таких сегментов у компании будет несколько. На этом уровне вы погружаетесь в специфические особенности и требования конкретного подразделения, функции или компании в составе организации. Прорабатываете бизнес кейсы использования ИТ с руководством подразделения. Архитектура сегмента должна иметь ту же структуру и общие сервисы, что и стратегическая архитектура.

•Архитектура решения – архитектура конкретного ИТ решения. Она используется для реализации новых или доработки существующих ИТ решений сервисов или их частей. В ней учтены как общие для всей компании требования, так и специфические потребности, выявленные на уровне архитектуры сегмента. Рамки архитектуры решения ограничены одним проектом, процессов или функцией. Архитектура решения прорабатывается максимально детально. Это позволяет избежать неприятных сюрпризов в будущем при реализации проекта.