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

•Роль ИТ департамента – стратегический ресурс организации

•Стратегия ИТ департамента – интегрированная в бизнес стратегию компании

•Бюджет ИТ департамента – существует и рассматривается как инвестиции в бизнес

•Тип деятельности ИТ департамента – активная реакция (превентивная) на бизнес требования

•Задачи менеджмента – долгосрочные инвестиции в бизнес

•Место в организационной структуре компании – департамент, ИТ директор в составе совета директоров

Каждый из этих этапов имеет плюсы и минусы. Этап развития ИТ должен соответствовать этапу развития компании. Опыт показывает, что перескочить хотя бы через один из этапов сложно и требуются колоссальные затраты ресурсов (времени, денег, энергии сотрудников и т. д.), при этом эффект будет обратный. Большинство компаний проходят их один за другим. Переход на следующую стадию переходит при осознании руководством компании или остроты возникших вопросов:

•Проблемы поддержки роста и изменений бизнеса

•Дублирование бизнес процессов

•Многообразие платформ и систем

•Неудовлетворенность текущем состоянием ИТ

Критерии выбора методологии

Так как методологии сильно отличаются друг от друга, то следует задать критерии для их сравнения.

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

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

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

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

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

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

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

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

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

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

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

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

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

•«Zahman Framework» – наиболее ранняя и известная методология. Идеально подходит для «классификации» элементов архитектуры.

•«TOGAF (The Open Group Architecture Framework)». Методология получила широкую известность и распространение, во многом за счет открытости. Представляет из себя каркас «построения процессов».

•«Gartner» – методология экспертного анализа с использованием «лучших» практик.

•«FEAF» – методология построения архитектуры, использующая «сервис ориентированный» подход.

При построении ИТ Архитектуры Предприятия необходимо выделить следующие состояния архитектуры организации:

•Текущее состояние «As-is» или «Baseline Architecture».

•Переходное состояние «Transition Architecture».

•Будущее состояние «To-be» или «Target Architecture».

•План перехода «Enterprise Architecture Management Plan & Roadmap»

В общем случае Архитектура Предприятия представляет из себя план перехода от «Текущего» к «Будущему» состоянию организации. Архитектурный проект длится несколько лет и инициирует множество ИТ проектов. Эти проекты будут разной продолжительности, у них разные даты начала и окончания. Их нужно сгруппировать таким образом, чтобы изменения в бизнесе и ИТ происходили в нужное время, с минимальными рисками и без проблем с совместимостью. То есть архитектура может переходить из одного работоспособного состояния в другое несколько раз за время архитектурного проекта. Промежуточное состояния называют «переходной архитектурой» (Transition Architecture).

Архитектура Предприятия на основе методологии «ZAHMAN FRAMEWORKS»

Наиболее ранняя методология и на мой взгляд наиболее полная и структурированная. Изначально разрабатывалась как архитектура Информационных Систем. Основная идея заключается в том, чтобы обеспечить возможность последовательного описания каждого отдельного аспекта системы в координации со всеми остальными. Модель «Захмана» используется для описания предприятия в целом, так что предложенная модель, вообще говоря, может использоваться как средство для описания архитектур сложных производственных систем любого типа. Основные характеристики данной модели:

•целостность в отношении предприятия;

•обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятий;

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

•простота описания

Модель Захмана имеет такие преимущества перед другими моделями:

•Отличается своей простотой понимания как техническими, так и нетехническими специалистами.

•Более детальными описаниями компонентов архитектуры

•Возможность применения для планирования, позволяющего лучше принимать решения.

•Наиболее наглядным представлением компонентов компании.

•Описанием сложной архитектуры небольшим количеством нетехнических понятий.

•Независимостью конкретных инструментов описания.

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