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

С точки зрения ИТ: Соблюдение ИТ ценностей и требований (технологичность, безопасность и управляемость ИТ).

Перенос часть работ на сторону ИТ департамента, или отказ от автоматизации ряда элементов, может снизить стоимость решения, повысить простоту эксплуатации и удобство для клиентов.

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

Управлять изменениями.

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

Навести порядок и управлять развитием ИТ.

Современные реалии ведения бизнеса и развития технологий приводит к тому, что бизнес требует внедрение все новых и новых технологические решения. Различные методы и модели их внедрения (самостоятельная разработка, покупка «коробочного» решения, внедрение и сопровождение со стороны третьей стороны и т п) приводит к тому, что в ИТ инфраструктуре появляется большое количество различного аппаратного и программного обеспечения, частично дублирующего друг друга, устаревших решений, и т п. Кроме этого, постоянная зависимость от специалистов, обладающих «уникальными» знаниями и опытом. Задача ИТ директора – организация управления ИТ, непрерывное обучение сотрудников новым технологиям, выбор перспективных направлений, которые могут принести выгоду бизнесу.

Базовые принципы построения Архитектуры Предприятия

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

•Какая информация/данные критичны для бизнеса компании и как они организованы;

•Какие приложения будут поддерживать бизнес;

•Смогут ли эти приложения эффективно взаимодействовать между собой и с внешними системами партнеров и поставщиков;

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

•Достаточно ли обеспечена информационная безопасность систем;

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

•Какие стандарты должны использоваться при разработке и закупке компонент системы;

Формирование архитектуры производится с использованием распространенных методологий, рамочных моделей (frameworks) описания архитектуры и инструментальных средств моделирования (например, ARIS IT Architect) – с учетом имеющихся у Заказчика опыта и предпочтений. В ходе проекта формируется набор архитектурных принципов, определяются используемые и перспективные стандарты и разрабатываются модели архитектуры в целом и ее отдельных областей (приложения, данные, интеграция, техническая инфраструктура, безопасность и др.)

Примерный порядок построения единого информационного пространства предприятия следующий:

Обследование предприятия

•Цели и основные задачи:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Уровни зрелости ИТ

В процессе роста и развития организации, департамент ИТ также проходит несколько этапов своего развития. При построении Архитектуры Предприятия следует принимать во внимание уровень зрелости организации в целом, так и ИТ в частности. Можно выделить следующие этапы и симптомы состояния ИТ департамента:

Начальный или «локализация»

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

Основные симптомы данного этапа развития:

•Роль ИТ департамента – второстепенная

•Стратегия ИТ департамента – отсутствует

•Бюджет ИТ департамента – отсутствует

•Тип деятельности ИТ департамента – пассивный, только по запросу.

•Задачи менеджмента – максимальная экономия

•Место в организационной структуре компании – служба в составе бизнес департамента (администрация, финансы)

Развития или «стандартизация»

Компания переходит от закрытия потребностей отдельных бизнес подразделений или функций и повышает эффективность ИТ за счет стандартизации технологий и инфраструктуры. Основные симптомы данного этапа развития:

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

•Стратегия ИТ департамента – отсутствует или на начальном уровне

•Бюджет ИТ департамента – отсутствует или управляемый со стороны

•Тип деятельности ИТ департамента – слабо активный по ИТ инфраструктуре и пассивный, только по запросу для бизнеса

•Задачи менеджмента – минимальные инвестиции

Место в организационной структуре компании – служба или отдел в составе бизнес департамента (администрация, финансы) или под курацией.

Становления или «оптимизация»

Компания строит сквозные бизнес процессы, используя общие данные и информационные системы. Централизует по возможности бизнес процессы и функции подразделений в централизованных информационных системах по предварительно описанных операционных моделях. Основные симптомы данного этапа развития:

•Роль ИТ департамента – важная

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

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

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

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

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

Зрелый

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Руководство по эталонным моделям, определяет полезность методологии в создании адекватного набора эталонных моделей. На этом практически полностью сосредоточена методология 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»

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

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

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

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

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

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

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

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

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

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

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

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

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

Архитектура Предприятия – матрица «Zahman Framework»

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

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

В основе FEAF лежат пять эталонных моделей:

•Исполнительная модель.

•Бизнес-модель.

•Сервисная модель Компонента.

•Техническая эталонная модель.

•Эталонная модель данных.

Одно из полезных свойств фреймворка FEA – принцип сегментного подхода, дает возможность ускорить внедрение «Архитектуры предприятия». Процесс разработки архитектуры предприятия по методологии FEA включает в себя следующие этапы:

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

•Архитектурное определение

•Стратегия инвестиций и финансирования

•План управления программой и реализация проекта

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

Методология Gartner – эту модель можно описать как набор рекомендаций по созданию архитектуры предприятия.

Модель Gartner 2002 года сформулирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:

•Среда бизнес-взаимодействия (Business Relationship Grid);

•Бизнес-процессы и стили бизнес-процессов;

•Шаблоны;

•Технологические строительные блоки (кирпичики – bricks).

Методология Gartner – по сути своей не является методологией, как например структурированная модель Захмана, ни процессом как TOGAF, ни как FEA. Gartner – является набором практических рекомендаций. Данная методология является сборником советов по построению архитектуры предприятия от одной из наиболее известных в мире консалтинговых ИТ-компаний – Gartner.

Данный фреймворк представляет собой трехмерный куб, состоящий из слоев:

•Горизонтальные слои.

•Вертикальные домены.

•Вертикальные элементы технической архитектуры.

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

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

•Обзор бизнес – архитектуры

•Описание существующей системы с необходимой степенью детализации

•Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре

•Разработка черновика технического отчета

•Направление черновика отчета на рецензирование

TOGAF позиционируется не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. Рассмотрим построение Архитектуры Предприятия на основе методологии «TOGAF» более детально, который на мой взгляд имеет ряд преимуществ:

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

•TOGAF – это де-факто является стандартом. Имеется программа сертификации по TOGAF.

•TOGAF – абсолютно бесплатен. Множество открытых ресурсов, скачивайте и используйте.

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

•TOGAF совместим с другими Фреймворками, например, с «Zahman Framework». Как архитектурный процесс модель TOGAF дополняет модель Захмана – которая, классифицируется как архитектурная таксономия. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.

Рисунок: Структура Архитектуры Предприятия «TOGAF»

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

Базовые принципы

Процесс создания конкретной архитектуры предприятия рассматривается как переход от общей архитектуры к специализированной. Методика разработки архитектуры в модели TOGAF представляет собой процесс осуществления такого перехода. В модели TOGAF наиболее обобщенные архитектуры называются фундаментальными архитектурами. Эти принципы построения архитектуры теоретически могут использоваться практически любой ИТ-организацией в мире.

Следующий уровень специализации в модели TOGAF называется общесистемными архитектурами. Эти принципы прослеживаются во многих – возможно, не во всех – типах предприятий. Далее идет отраслевой уровень архитектурой. Эти принципы характерны для предприятий, занятых в одной сфере деятельности. И наконец финальный уровень – это уровень архитектуры организации. Это самый высокий уровень специализации в модели TOGAF. Это архитектуры конкретных предприятий.

В состав модели TOGAF входят две основные компоненты:

•методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры.

•Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML.