Управление портфелем IT под управлением портфелем информационных технологий понимается процесс отбора, управления и оценки инвестиций, связанный как с ИТ-активами, так и с портфелем ИТ-проектов. Управление портфелем ИТ-активов позволяет организациям категоризировать, оценивать, расставлять приоритеты, покупать и управлять ИТ-активами и проектами в соответствии с текущими и будущими потребностями бизнеса с учетом приемлемой степени риска. Таким образом, управление портфелем ИТ по своей сути является дисциплиной в области планирования инвестиций. Управление портфелем ИТ должно преследовать три цели: максимизация ценности (стоимости) портфеля, синхронизация портфеля ИТ с целями бизнеса и поиск оптимального баланса между риском и потенциальной отдачей от портфеля ИТ.
В связи с этим описание желаемого состояния архитектуры ИТ обеспечивает представление о необходимых инвестициях в технологии и навыки ИТ-персонала.
Эффективное управление портфелем информационных технологий на уровне предприятия в целом должно обеспечиваться за счет совместного использования ряда дисциплин и процессов, среди которых главными являются следующие:
- стратегия и планирование на уровне предприятия.
- архитектура предприятия.
- управление ИТ-программами и проектами.
IT-программы и проекты
ИТ-программы и проекты – это основной механизм реализации архитектуры в рамках выбранной стратегии. Дисциплина управления ИТ-программами и проектами связана с навыками управления портфелем взаимосвязанных программ и проектов на корпоративном уровне, с управлением процессами, финансовыми и человеческими ресурсами, которые требуются для реализации проектов, с управлением графиками реализации проектов и т.д. Управление ИТ-программами и проектами и архитектура предприятия взаимно дополняют друг друга, обеспечивая, в конечном итоге, интеграцию различных процессов, связанных с использованием ИТ на предприятии. При этом сутью управления программами/проектами является реализация, в то время как архитектура обеспечивает основу для выработки стратегии.
|
|
Процессы выработки стратегии и планирование обеспечивают основу для отбора, управления и оценки ИТ-ресурсов и проектов.
Соотношение между АП «как есть» и «как должно быть»
Особенности АП
- архитектура определяет основные компоненты (бизнес-архитектура, архитектура приложений и т.д.);
- архитектура определяет взаимосвязи между компонентами и взаимодействия между ними;
- уровень детализации архитектуры выбирается таким, что "опускается" вся информация о компонентах, которая не имеет значения вне вопросов взаимодействия с остальными компонентами архитектуры;
- поведение компонент является частью архитектуры настолько, насколько это важно с точки зрения взаимодействия с другими компонентами;
- каждая система имеет архитектуру – даже система, которая состоит из одной компоненты;
- архитектура содержит объяснения и обоснования по поводу своих компонент и структуры;
- определения архитектуры не содержат описания самих компонент.
Контекст разработки АП
Определение разработки АП
С учетом полученных выше знаний и детализации представления об архитектуре предприятия мы можем сказать, что ее разработка является процессом, основанным на бизнес-стратегии, который координирует идущие параллельно процессы создания бизнес-архитектуры, архитектуры информации, архитектуры прикладных систем и технологической архитектуры [5.1]. Таким образом, архитектура предприятия является целостным описанием ключевых стратегий организации, связанных с бизнесом, информацией, прикладными системами и технологиями, а также их влиянием на функции и бизнес-процессы организации. Разработка архитектуры предприятия ведется в соответствующем контексте существующих в организации структур управления и взаимодействия.
|
|
Методики разработки АП
Существуют различные подходы или рамочные модели, методики (то, что по -английски называется frameworks) к описанию архитектуры предприятия. Эти методики задают классификацию основных областей архитектуры и единые принципы для их описания во взаимной увязке друг с другом, описание используемых правил (политик), стандартов, процессов, моделей, которые используются для определения различных элементов архитектуры на разных уровнях абстракции. В качестве примеров можно указать следующие методики:
- методики, опубликованные аналитическими компаниями, такими как Gartner, Giga Group, META Group и другими;
- модель Захмана;
- методика TOGAF;
- методика POSIX 1003.23, которая основывается на разработках компании Cap Gemini, переданных для публичного использования в 1996 году.
Для государственных организаций существуют специальные методики, такие как разрабатываемая при поддержке правительства США Федеральная Архитектура Госорганизаций (FEAF – Federal Enterprise Architecture Framework) или используемая в Министерстве Обороны США DoDAF (Department of Defence Architecture Framework).
|
|
Описание IT-архитектуры
Описание ИТ-архитектуры служит детальным руководством, которое определяет основные, стандартные или типовые элементы ИТ-систем, их взаимосвязи, а также процессы управления информационными системами. Что хотелось бы получить от такого документа? Можно сформулировать следующие, частично противоречивые, требования:
- достаточно высокий уровень детализации для практического использования специалистами в области информационных технологий при разработке новых систем;
- простоту для понимания бизнес-аудиторией;
- динамику рассмотрения (т.е. "Архитектура как есть" – "Краткосрочные и среднесрочные задачи" – "Стратегические планы");
- возможность адаптации по новым требованиям бизнеса и учет возможностей реализации незапланированных (ad-hoc) проектов.
Пример модели архитектуры предприятия
| Содержание (предмет) Архитектуры предприятия | Определения архитектуры | ||||
| Описания систем | Руководства, Правила и Стандарты | ||||
| Как есть | Как должно быть | ||||
| Бизнес-архитектура | Связи между бизнес-процессами | Принципы (система ценностей и постулатов) Новые требования | |||
| Бизнес-функции | |||||
| Подфункции | |||||
| Новые функции | |||||
| Архитектура информации | Информация | Шаблоны, Правила (политики), Сервисы | Модели технологической архитектуры (список стандартных технологий и продуктов) | ||
| Архитектура приложений | Приложения | ||||
| Точки доступа | |||||
| Интеграция | |||||
| Технологическая архитектура | Инфраструктура | ||||
| Платформы | |||||
| Системы хранения | |||||
| Сети | |||||
| Безопасность | |||||
| Системное управление | |||||
| Описание текущей среды ИТ | Область управления и контроля архитектуры | ||||
| Движущие силы с точки зрения бизнеса и стратегии |
Модель Захмана
Правила заполнения таблицы Захмана
- каждая клетка таблицы независима от других, вместе они образуют функционально полное пространство для описания системы ("базис");
- порядок следования колонок несущественен;
- каждая клетка содержит соответствующее описание аспекта реализации системы в виде определенной модели или, возможно, простого описания (текстового документа);
- базовые модели для каждой из колонок являются уникальными;
- соответствующие модели в клетках каждого ряда в совокупности образуют полное описание системы с выбранной перспективы;
- заполнение клеток должно проводиться последовательно "сверху вниз", попытка пропуска одного из рядов является, скорее, "шаманством" (в том плане, что нельзя создать хорошо работающую систему, "перепрыгнув" определенные уровни ее описания на этапе проектирования).
Основные характеристики модели Захмана
· простота для понимания как техническими, так и нетехническими специалистами;
· целостность в отношении предприятия, то есть каждая проблема может быть соотнесена с предприятием в целом;
· поддержка обсуждений сложных вопросов с использованием относительно небольшого количества нетехнических понятия;
· возможность применения для планирования, позволяющего лучше принимать решение за счет того, что решения никогда не будет выноситься «в пустоте» (в отрыве от остальных аспектов деятельности предприятия);
· Применимость для решения задач, то есть возможность работать с абстракциями и сущностями, выделяя и изолируя отдельные параметры системы без потери восприятия Предприятия как целого;
· Нейтральность, то есть независимость от каких-либо инструментов; благодаря этому каждый инструмент и методология могут быть отображены на данную модель и могут явно показать, что они делают и чего они не делают.
Модель описания IT-архитектуры Gartner
Модель Gartner 2002 года сформирована в виде четырех связанных, взаимозависимых и усложняющихся уровней:
· Среда бизнес-взаимодействия (Business Relationship Grid);
· Бизнес-процессы и стили бизнес-процессов;
· Шаблоны;
· Технологические строительные блоки (кирпичики – bricks).
Описание уровней модели Gartner (1)
В этой схеме верхние два уровня ориентированы на совместное обсуждение с бизнес-руководителями и IT-специалистами и в какой-то степени соответствует тому, что мы называли бизнес-архитектурой, а ниже два уровня входят во внутреннюю компетенцию ИТ-службы:
· Верхний уровень Среды бизнес-взаимодействия описывает, новую модель «виртуального» бизнеса, а также все что связано с кооперацией предприятий и бизнесом В2В. Этот уровень соответствует понятию «отраслевой нервной системы» взаимодействующих предприятий. Он получил развитие в связи с распространением Интернет как среды взаимодействия, и связан с понятием доступа, межорганизационного взаимодействия.
Описание уровней модели Gartner (2)
· Второй уровень Стили бизнес-процессов описывает, как организация выполняет свои ключевые функции, т.е. включает в себя бизнес-процессы предприятия, такие обработка заказа, мониторинг производственных процессов, анализ использования критически важных ресурсов, совместная работа с информацией;
· Следующий уровень Шаблоны описывает модели и алгоритмы, которые могут широко использоваться для решения различных задач на предприятии. Отметим, что шаблоны охватывают не только область программного обеспечения, но и соответствующие сетевые и вычислительные ресурсы, как мы рассматривали ранее в разделе 4.7. примерами шаблонов является трехуровневая архитектура прикладных систем (интерфейс – логика – данные), использование «толстого» клиента в архитектуре клиент/сервер, хранилища данных. Что касается приложений, то упор сделан на использовании шаблонов сервис-ориентированной архитектуры, т.е. реализации приложений в виде модульного набора различных типов сервисов. Это, в том числе, позволяет в перспективе интегрировать приложения как web-сервисы.
· Нижний уровень Строительные блоки (Bricks) соответствует технологической архитектуре и включает в себя операционные системы, серверы, базы данных, сами данные и пр.
IT-архитектура в модели Gartner
Методика META Group
Исторически архитектурная методика META Group оперировала таким понятием, так Технологическая архитектура масштаба предприятия ( EWTA –Enterprise Wide Technical Architecture ). Однако по мере того, как в индустрии происходило понимание более тесной связи между бизнесом и информационными технологиями, в представления (домены или предметные области) Архитектуры предприятия META Group были добавлены такие домены, как Бизнес-архитектура (EBA - Enterprise Business Architecture), Архитектура информации (EAI – Enterprise Information Architecture) и портфель прикладных систем предприятия (EAP – Enterprise Application Portfolio). Это соответствует эволюции понятия «Архитектура предприятия», которая происходила на рынке в целом (см. раздел 3.2.1), и принятой сегодня практике выделения доменов архитектуры.
Кроме того, расширяя многие другие представления, архитектурная методика META Group рассматривает Архитектуру предприятия в интеграции с другими ключевыми процессами, в частности, с процессом управления корпоративными ИТ-программами и проектами (EPM – Enterprise Program Management) и процессом выработки стратегии и планирования. В частности, отмечается, что архитектура, собственно говоря, и реализуется на практике через процесс управления ИТ-программами и проектами.
Объединяющим для всех доменов архитектуры META Group является процесс формулировки бизнес-требований к ИТ-архитектуре, что оформляется в виде двух документов: Видения общих требований (CRV – Common requirements Vision) и Принципах концептуальной архитектуры (CA – Conceptual Architecture).
Аналитическая работа и компоненты АП
Этапы разработки АП по методике META Group
На этапе 1 разрабатывается Видение общих требований. Разработка видения общих требований включает в себя:
· Анализ тенденций развития внешней для предприятия среды, включая технологические тенденции;
· Бизнес-стратегии и основные движущие силы с точки зрения бизнеса;
· Требования к информационным системам со стороны бизнеса;
· Требования к технологической архитектуре, которая обеспечивает адекватные возможности для информационных систем с точки зрения потребностей бизнеса.
Этап 2 состоит в разработке Концептуальной архитектуры, которая определяет логически связанный набор принципов, обеспечивающий общее руководство для развития информационных систем предприятия и технологической инфраструктуры. На этом же этапе параллельно ведется разработка наиболее приоритетных доменов архитектуры. Здесь же выполняется анализ на несоответствие (gap-анализ) между текущим и желаемым состояние архитектуры.
Этап 3 состоит в разработке плана реализации, обеспечивающего миграцию в сторону желаемого состояния архитектуры.
Структура описания элементов (доменов) АП
Состав описания домена (элемента) АП (1)
· Формулировка миссии домена: стратегические цели домена.
· Описание компонентов домена: это обеспечивает общее понимание включенных в домен технологий.
· Принципы проектирования, принятые в домене. Они определяют правила, применяемые в процессе принятия решений в отношении технологий домена, а также обоснования и последствия принятия этих принципов. здесь могут быть построены матрицы соответствия между требованиями к технологической архитектуре (RTA), сформулированные в процессе создания Видения общих требований, и принципов проектирования, принятых для конкретного домена.
Состав описания домена (элемента) АП (2)
· Стандарты: продукты и технические стандарты, которые обеспечивают требования к технологической архитектуре. Выделяют стратегические (предпочтительные) стандарты, переходные (которые используются, но от которых организация отказывается) и исследовательские или новые (которые находятся только на этапе рассмотрении и апробации).
· Лучшие практики.
· Конфигурации. Они формулируются в тех случаях, когда нужно уменьшить сложность принятия решений или когда можно уменьшить общую стоимость владения за счет стандартных конфигураций.
· Несоответствия между существующим состоянием домена технологической архитектуры и желаемым состоянием. Это служит основой для последующих работ группы, которая отвечает за данный домен архитектуры.
Методика TOGAF
Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а такжекомпаний из спискаFortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития.
Основным полем для применения TOGAF является, прежде всего, программная инфраструктура информационной системы (в противоположность таким типам архитектур, как бизнес-архитектура, архитектура данных и приложений). Таким образом, она в наилучшей мере подходит для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса (mission-critical). Поскольку эта интеграционная архитектура сильно зависит от принимаемых решений в остальных областях, то в рамках TOGAF в необходимой степени рассматриваются и эти смежные области.
В состав модели TOGAF входят две основные компоненты – методика ADM (Architecture Development Method), определяющая процесс разработки архитектуры, и Базовая Архитектура (Foundation Architecture). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятием TOGAF и моделью
Захмана.
Структура TOGAF
Фазы разработки архитектуры
В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:
· Подготовка: уточнение модели под особенности организации, определение принципов реализации проекта.
· Фаза А: определение границ проекта, разработка общего представления (Vision) архитектуры; утверждение плана работ и подхода руководством.
· Фаза B: разработка бизнес-архитектуры предприятия.
· Фаза С: разработка архитектуры данных и архитектуры приложений.
· Фаза D: разработка технологической архитектуры.
· Фаза Е: поверка возможности реализации предложенных решений.
· Фаза F: планирование перехода к новой системе.
· Фаза G: формирование системы управления преобразованиями.
· Фаза H: управление изменением архитектуры.
Каждая фаза. В свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные процессы:
· Описание существующей технологической архитектуры.
§ Обзор бизнес-архитектуры, архитектуры данных и приложений для определения начальных данных и необходимой степени детализации.
§ Описание существующей системы с необходимой степенью детализации, которая выбирается для того, чтобы можно было выявить необходимые изменения при формировании целевой архитектуры. Формирование реестра используемых платформ программного и аппаратного обеспечения.
§ Выявление и описание элементарных архитектурных блоков – кандидатов на использование в новой архитектуре. Фактически, речь идет о возможных архитектурных шаблонах.
§ Разработка черновика технического отчета, резюмирующего основные результаты изучения существующего состояния и возможности использования типовых блоков.
§ Направление черновика отчета на рецензирование, анализ комментариев и внесение, при необходимости, поправок.
· Формирование целевой технологической архитектуры.
§ Описание существующей системы в терминах TOGAF.
§ Определение перспектив (представлений) архитектуры.
§ Формирование модели целевой архитектуры.
§ Определение ИТ-служб (сервисов).
§ Подтверждение учета бизнеса-требований.
§ Определение архитектуры и используемых блоков (шаблонов).
§ Проведение анализа расхождений (gap analysis).
NASCIO Architecture Toolkit
Уровни схемы методики
· области и домены (Domains) ИТ-архитектуры;
· дисциплины;
· технологические дисциплины;
· продуктовые компоненты;
· документы соответствия.
Области (домены) являются логическими блоками технологической архитектуры. Каждая Область может включать одну и более дисциплин. Вся ИТ-архитектура подразделялась на набор областей верхнего уровня (доменов), описывающих отдельные аспекты ИТ-систем.
Дисциплины обеспечивают логическое деление доменов на разделы, которыми уже проще управлять, т.е. домены включает в себя несколько функциональных дисциплин. Дисциплины представляют собой достаточно связанные единицы в рамках соответствующей предметной области. Каждая дисциплина содержит одну и более Технологических дисциплин.
Продуктовые компоненты включают протоколы, продукты (семейства продуктов) и конфигурации, которые специфичны для каждой технологической рованы.
Пример описания АП в соответствии с NASCIO
| Область (домен) | Дисциплина | Технологическая дисциплина | Продуктовые компоненты | Документы соответствия |
| Информация | Управление данными | реляционные СУБД | · MS SQL · Oracle · DB2 | · Стандарты предприятия наименование хранимых процедур |
| плоские файловые системы | · Квоты на использование общего дискового пространства | |||
| настольные БД | · MS Access | · Стандарты предприятия по защите БД Access | ||
| модели Данных | · ERWin · MS Visio · Designer 2000 | · Нормализация данных · Стандарты предприятия наименования таблиц и атрибутов |
Области и дисциплины NASCIO
| Область | Дисциплины |
| Информация | · Управление данными (Data Management) · Управление знаниями · Геоинформационные системы (GIS) · Хранение данных |
| Приложения | · Управление Средствами Разработки Приложений · Электронные средства совместной работы |
| Интеграция | · Функциональная интеграция · Программное обеспечение промежуточного слоя (связующее ПО) |
| Доступ | · Доступ · Branding: например, рекомендации по внешнему виду web-сайта гос организации · Доступность |
| Сеть | · Физическая сеть · Управление сетью |
| Платформа | · Платформа: аппаратное обеспечение (серверы, настольные системы хранения · Управление конфигурациями: стандарты на операционные системы, утилиты, конфигурации аппаратного обеспечения) |
| Системное управление | · Управление активами · Управление изменениями · Управление событиями · Управление инцидентами и проблемами · Непрерывность бизнеса (Business Continuity) |
| Частная информация | · Профилирование · Персонифицирование · Обеспечение защиты частной информации |
| Безопасность | · Корпоративная безопасность · Безопасность · Безопасность серверов |
Модель «4+1»
Достаточно важную роль в развитии подходов к описанию Архитектуры предприятия сыграла модель «4+1» (точнее «The 4+1 View Model of Architecture»), которая была предложена Филиппом Кручтеном (Philippe Kruchten) из компании Rational ещё в 1995 году.
| Системные интеграторы Производительность Масштабируемость |
| Функциональность с точки зрения конечного пользователя |
| Разработчики Управление разработкой ПО |
| Системные инженеры Топология Коммуникация |
| Логическое представление |
| Представление уровня разработки |
| Процессное представление |
| Физическое представление |
| Сценарии |
Содержание модели «4+1»
Модель предлагает простой и понятный способ описания архитектуры ложных систем, который состоит в использовании пяти различных категорий и представлений (views). Четырьмя основными представлениями в этой методике являются следующие:
· Логическое представление. Является объективной моделью проектирования (в том случае, если используется объективно-ориентированная модель проектирования).
· Процессное представление. Описывает вопросы параллельного исполнения и синхронизации процессов.
· Физическое представление. Описывает размещение программных компонент системы на аппаратных платформах и аспекты, связанные с физическим расположением системы.
· Представление уровня разработки. Описывает статистическую организацию программной системы в среде разработки.
Архитектурные методики и концепции Microsoft (1)
Крупные компании-поставщики инфраструктурных информационных технологий, такие как Microsoft, IBM, SAP и другие могут "позволить себе роскошь" создания собственных методик разработки архитектуры информационных систем предприятия – конечно, с учетом своей области специализации. В то же время – это в какой-то степени и обязанность таких компаний, поскольку спектр предлагаемых ими технологий покрывает существенную часть архитектуры предприятия в целом, и специалистам нужны соответствующие практические рекомендации непосредственно от поставщиков.
При этом компания Microsoft выработала достаточно подробные методики, покрывающие различные аспекты архитектуры и, прежде всего, процессы разработки систем и создания инфраструктуры и процессы эксплуатации систем и инфраструктуры. В частности, это такие методики, как Microsoft Solutions Framework (MSF), Microsoft Operations Framework (MOF), Microsoft Systems Architecture (MSA) и Microsoft Solutions for Management (MSM), которые мы рассмотрим ниже.
Архитектурные методики и концепции Microsoft
Эти четыре взаимодополняющие методики Microsoft дают специалистам рекомендации, касающиеся следующих четырех основных вопросов:
· MSF – "Как правильно создавать ИТ-системы?"
· MSA – "Как правильно создавать технологическую инфраструктуру?"
· MOF – "Как правильно эксплуатировать технологическую инфраструктуру?"
· MSM – "Как правильно строить процессы управления технологической инфраструктурой?"
Шаблоны методички Microsoft
Содержание MSF
В таком контексте MSF как методика разработки архитектуры предприятия – это инструмент, который гарантирует, что деятельность подразделений информационных технологий будет ориентирована именно на бизнес-потребности.
Компоненты, составляющие основу методики MSF, могут применяться по отдельности или в совокупности для увеличения вероятности успеха в следующих областях:
· разработка прикладных программных систем, включая web-приложения, системы электронной коммерции, мобильные приложения, n-уровневые системы;
· проекты создания ИТ-инфраструктуры, включая развертывание настольных систем, обновления операционных систем, развертывание корпоративных систем обмена сообщениями и электронной почты, системы управления инфраструктурой и конфигурациями;
· проекты интеграции готовых решений, таких как системы управления ресурсами предприятия (ERP), системы офисной автоматизации, системы управления проектами;
· любая сложная комбинация перечисленных выше типов проектов.
Если кратко, то MSF содержит руководства по планированию, разработке, тестированию и внедрению решений. Модель архитектуры предприятия в рамках MSF характеризуется четырьмя задачами:
· интеграция: сбалансированность внутрикорпоративных интересов, тесное взаимодействие бизнес-подразделений и ИТ-службы;
· итерационность: архитектура создается посредством последовательного выпуска версий решений;
· макетируемость: одна из целей разработки архитектуры – быстро создать промежуточный, но вполне работоспособный макет;
· учет приоритетов: разработка архитектуры всегда учитывает необходимость обеспечения поддержки основных бизнес-процессов.
Содержание MSA
MSA описывает следующие конфигурации инфраструктуры:
- Вычислительный центр уровня подразделения (DDC – Departmental Data Center).
- Вычислительный центр уровня предприятия (EDC – Enterprise Data Center).
- Вычислительный центр Интернет-систем (IDC – Internet Data Center).
- Вычислительный центр для высокомасштабируемых сервисов (HSSDS – Highly Scalable Services Data Center).
MSA детально описывает логическую и физическую технологические архитектуры, включает все необходимые технологии: сети, серверы, системы хранения и программное обеспечение. Использование этих протестированных методик существенно снижает трудозатраты по проектированию, построению, тестированию и эксплуатации технологической инфраструктуры.
MSA предоставляет следующие документы для специалистов, решивших воспользоваться этой методикой:
· Справочные (эталонные или референсные) описания архитектуры.
· Предписывающие руководства: руководство по архитектуре, руководство по тестированию, руководство по созданию, руководство по эксплуатации. Все они содержат протестированные в лабораторных условиях фрагменты технологической архитектуры.
· Руководство по службам.
· Руководство по поддержке.
Сравнительный анализ описанных методик
| Модель | IEEE POSIX 1003.23 | Модель Захмана | TOGAF | FEAF | Методики Gartner | Методики META Group | NASCIO Toolkit | Методики Microsoft |
| Характеристика | ||||||||
| Иерархический подход, возможность связи с бизнес-стратегией | 
|
|
|
|
|
| ||
| Поддержка различных уровней абстракции |
|
|
|
|
|
|
|
|
| Формальный язык и система обозначений |
| |||||||
| Описание процесса разработки архитектуры |
|
|
|
|
|
| ||
| Рекомендации по управлению архитектурой |
|
|
|
|
|
|
Подготовка к процессу составления АП
Мы уже отмечали, что с учетом существующего реального состояния дел большинство организаций либо не имеют формализованной определенной архитектуры, либо эти определения неполны и недостаточно четко связаны с требованиями бизнеса. В таких случаях имеет смысл организовать работу в рамках специального проекта с определенными сроками и результатами, основной целью которого будет являться создание первоначального описания архитектуры организации и создание механизмов для ее последующего поддержания и развития.
Первоочередными задачами такого проекта являются:
· организация необходимых структур с привлечением руководства предприятия, бизнес-подразделений и планирование работ;
· понимание стратегии развития бизнеса организации;
· формирование общих для бизнеса и ИТ требований к целевой архитектуре;
· разработка концептуальной архитектуры в виде согласованного и полного набора принципов, в соответствии с которыми будет проводиться разработка архитектуры отдельных доменов (предметных областей или частных архитектур).
Задачи, решаемые в рамках подготовки к АП
1. Определение и обоснование цели – ответы на вопросы Почему? и Что?
2. Выполнение ряда шагов, связанных с инициацией процесса разработки архитектуры (см. ниже).
3. Определение существующего состояния архитектуры ("as is") для каждой выбранной области (домена) – отправная точка ответа на вопрос Где?
4. Определение целевой архитектуры – конечная точка ответа на вопрос Где?
5. Анализ расхождений между текущим и желаемым состоянием.
6. Разработка плана перехода – ответы на вопросы Когда? и Как?
7. Подтверждение (проверка) достижимости – можно ли на самом деле достичь конечного состояния из данного начального состояния с учетом существующих ограничений?
8. Выполнение намеченного плана.
Элементы архитектурного процесса
Методика EAP
Один из признанных авторитетов в области корпоративной архитектуры Стивен Спивак (Steven Spewak) предложил удачную модель планирования архитектуры предприятия, которая называется EAP (Entrerprise Architecture Planning – Планирование архитектуры предприятия).
Схема разработки архитектуры и стратегии IT
Описание шагов в рамках схемы (1)