Файл: Вадим Алджанов итархитектура от а до Я Теоретические основы. Первое.pdf
ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.01.2024
Просмотров: 867
Скачиваний: 4
ВНИМАНИЕ! Если данный файл нарушает Ваши авторские права, то обязательно сообщите нам.
департамента (администрация, финансы)
Развития или «стандартизация»
Компания переходит от закрытия потребностей отдельных бизнес подразделений или функций и повышает эффективность
ИТ за счет стандартизации технологий и инфраструктуры. Основные симптомы данного этапа развития:
•Роль ИТ департамента – не стратегический ресурс
•Стратегия ИТ департамента – отсутствует или на начальном уровне
•Бюджет ИТ департамента – отсутствует или управляемый со стороны
•Тип деятельности ИТ департамента – слабо активный по ИТ инфраструктуре и пассивный, только по запросу для бизнеса
•Задачи менеджмента – минимальные инвестиции
•Место в организационной структуре компании – служба или отдел в составе бизнес департамента (администрация, финансы) или под курацией.
Становления или «оптимизация»
Компания строит сквозные бизнес процессы, используя общие данные и информационные системы. Централизует по возможности бизнес процессы и функции подразделений в централизованных информационных системах по предварительно описанных операционных моделях. Основные симптомы данного этапа развития:
•Роль ИТ департамента – важная
•Стратегия ИТ департамента – частично отвечает бизнес требованиям
•Бюджет ИТ департамента – существует и управляем
•Тип деятельности ИТ департамента – реактивная реакция на бизнес требования,
•Задачи менеджмента – получение бизнес выгоды в краткосрочной перспективе
•Место в организационной структуре компании – выделенный департамент, но ИТ менеджер не входит в состав совета директоров.
Зрелый
Повторное использование имеющихся бизнес процессов и компонентов для создания новых сервисов и возможностей. ИТ работает на опережение и является не отъемлющей частью бизнеса. Основные симптомы данного этапа развития:
•Роль ИТ департамента – стратегический ресурс организации
•Стратегия ИТ департамента – интегрированная в бизнес стратегию компании
•Бюджет ИТ департамента – существует и рассматривается как инвестиции в бизнес
•Тип деятельности ИТ департамента – активная реакция (превентивная) на бизнес требования
•Задачи менеджмента – долгосрочные инвестиции в бизнес
•Место в организационной структуре компании – департамент, ИТ директор в составе совета директоров
Каждый из этих этапов имеет плюсы и минусы. Этап развития ИТ должен соответствовать этапу развития компании. Опыт показывает, что перескочить хотя бы через один из этапов сложно и требуются колоссальные затраты ресурсов (времени, денег, энергии сотрудников и т. д.), при этом эффект будет обратный. Большинство компаний проходят их один за другим. Переход на следующую стадию переходит при осознании руководством компании или остроты возникших вопросов:
•Проблемы поддержки роста и изменений бизнеса
•Дублирование бизнес процессов
•Многообразие платформ и систем
•Неудовлетворенность текущем состоянием ИТ
Развития или «стандартизация»
Компания переходит от закрытия потребностей отдельных бизнес подразделений или функций и повышает эффективность
ИТ за счет стандартизации технологий и инфраструктуры. Основные симптомы данного этапа развития:
•Роль ИТ департамента – не стратегический ресурс
•Стратегия ИТ департамента – отсутствует или на начальном уровне
•Бюджет ИТ департамента – отсутствует или управляемый со стороны
•Тип деятельности ИТ департамента – слабо активный по ИТ инфраструктуре и пассивный, только по запросу для бизнеса
•Задачи менеджмента – минимальные инвестиции
•Место в организационной структуре компании – служба или отдел в составе бизнес департамента (администрация, финансы) или под курацией.
Становления или «оптимизация»
Компания строит сквозные бизнес процессы, используя общие данные и информационные системы. Централизует по возможности бизнес процессы и функции подразделений в централизованных информационных системах по предварительно описанных операционных моделях. Основные симптомы данного этапа развития:
•Роль ИТ департамента – важная
•Стратегия ИТ департамента – частично отвечает бизнес требованиям
•Бюджет ИТ департамента – существует и управляем
•Тип деятельности ИТ департамента – реактивная реакция на бизнес требования,
•Задачи менеджмента – получение бизнес выгоды в краткосрочной перспективе
•Место в организационной структуре компании – выделенный департамент, но ИТ менеджер не входит в состав совета директоров.
Зрелый
Повторное использование имеющихся бизнес процессов и компонентов для создания новых сервисов и возможностей. ИТ работает на опережение и является не отъемлющей частью бизнеса. Основные симптомы данного этапа развития:
•Роль ИТ департамента – стратегический ресурс организации
•Стратегия ИТ департамента – интегрированная в бизнес стратегию компании
•Бюджет ИТ департамента – существует и рассматривается как инвестиции в бизнес
•Тип деятельности ИТ департамента – активная реакция (превентивная) на бизнес требования
•Задачи менеджмента – долгосрочные инвестиции в бизнес
•Место в организационной структуре компании – департамент, ИТ директор в составе совета директоров
Каждый из этих этапов имеет плюсы и минусы. Этап развития ИТ должен соответствовать этапу развития компании. Опыт показывает, что перескочить хотя бы через один из этапов сложно и требуются колоссальные затраты ресурсов (времени, денег, энергии сотрудников и т. д.), при этом эффект будет обратный. Большинство компаний проходят их один за другим. Переход на следующую стадию переходит при осознании руководством компании или остроты возникших вопросов:
•Проблемы поддержки роста и изменений бизнеса
•Дублирование бизнес процессов
•Многообразие платформ и систем
•Неудовлетворенность текущем состоянием ИТ
1 2 3 4 5 6 7 8 9 ... 44
Критерии выбора методологии
Так как методологии сильно отличаются друг от друга, то следует задать критерии для их сравнения.
Полнота таксономии, определяет, насколько методология пригодна для классификации различных архитектурных артефактов. Полностью сосредоточена на фреймворке Захмана.
Полнота процесса, определяет, насколько детально представлен процесс создания архитектуры предприятия.
Руководство по эталонным моделям, определяет полезность методологии в создании адекватного набора эталонных моделей. На этом практически полностью сосредоточена методология 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 – абсолютно бесплатен. Множество открытых ресурсов, скачивайте и используйте.
•TOGAF содержит полный набор инструментов для создания и развития архитектурной практики в организации. Есть пошаговый процесс для разработки описания Архитектуры
Предприятия и полный набор инструментов, шаблонов и т. д.
•TOGAF совместим с другими Фреймворками, например, с «Zahman Framework». Как архитектурный процесс модель TOGAF дополняет модель Захмана – которая, классифицируется как архитектурная таксономия. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.