рефераты конспекты курсовые дипломные лекции шпоры

Реферат Курсовая Конспект

Уровни схемы методики

Уровни схемы методики - раздел Архитектура, По дисциплине Архитектура предприятия · Области И Домены (Domains) Ит-Архитектуры; · Дисциплины; ...

· области и домены (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).
  • Вычислительный центр уровня предприятия (EDCEnterprise 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)

 

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

Описание шагов в рамках схемы (2)

 

· Параллельно с этими процессами выполняется анализ на "системном уровне": аудит используемых информационных технологий и программно-технических средств, аудит организации процессов управления ИТ, внедрения технологий и приложений.

· Результаты вышеперечисленных этапов являются основой для выполнения "Gap-анализа", т.е. выявления расхождений и различий между существующей ИТ-инфраструктурой и желаемой архитектурой предприятия.

· Результаты Gap-анализа ложатся в основу Плана миграции: определяются цели создания (модернизации) информационных систем и решаемых ими задач, согласовывается стратегия разработки и внедрения информационных технологий (перечень критических процессов, подлежащих автоматизации в первую очередь и т. д.), обсуждается план детального анализа.

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

 

Общая схема разработки АП

 

 

 

Этапы процесса разработки АП

 

  • Этап 1: Описание или уточнение Общего видения (видение общих требований к архитектуре).
  • Этап 2: Описание или уточнение Концептуальной архитектуры, а также разработка и уточнение архитектуры отдельных представлений (или предметных областей, доменов): бизнес-архитектура, архитектура информации, архитектура приложений, технологическая архитектура и пр.
  • Этап 3: Разработка или уточнение Плана реализации.

Разработка концептуальной архитектуры

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

 

Основными элементами Общего видения являются:

 

· описание технологических тенденций, важных для предприятия;

· идентификация бизнес-требований и стратегий;

· идентификация основных требований к информации и технологиям, которые важны с точки зрения реализации бизнес-стратегий;

· идентификация требований к архитектуре предприятия в целом.

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

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

Заметим, что основой разработки архитектур отдельных предметных областей (доменов) служит Концептуальная архитектура.

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

 

Разработка Плана реализации

 

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

 

Сравнение подходов Сверху-вниз и Снизу-верх

 

  Положительные аспекты Отрицательные аспекты
Сверху-вниз · С самого начала создается ясное видение существующей ситуации в целом · С самого начала сформулированы бизнес-потребности и проблемы · С самого начала задаются широкие рамки процесса с необходимой поддержкой высшего руководства · Процесс может носить весьма абстрактный характер (выбор методик, типов моделей и пр.) · Маловероятно, что будут получены явные, видимые результаты в течение первого года работ · Может сложиться впечатление, что результатом проекта являются никому не нужные документы · Процесс сбора информации приводит к задержкам в построении структур управления архитектурным процессом · Использование формальных методологий требует обучения · Использование многих формальных методик требует наличия навыков и опыта в реинжиниринге бизнес-процессов
Снизу-вверх · Программа разработки архитектуры быстро начинает давать видимые результаты · Быстрый успех повышает авторитет и доверие к процессу · Самые "горячие", приоритетные проблемы решаются в первую очередь · Масштаб и сложность проекта растет постепенно · Отсутствует необходимость иметь сразу большую команду, участвующую в процессе разработки архитектуры · Ориентация на решение в первую очередь технологических задач соответствует ключевой области экспертизы ИТ-службы · Результирующая экономия затрат позволяет обосновать необходимость новых организационных структур и процессов, связанных с архитектурой · Первоначальная техническая направленность проекта затрудняет его распространение на более широкие области, связанные с бизнесом · Основанный на внедрении технических стандартов подход создает структуры управления архитектурным процессом, нацеленные на контрольные, "полицейские" функции · Первоначальный технологический фокус воспринимается как игнорирование бизнес-аспектов · Некоторые области, требующие улучшений, должны "ждать" своей очереди (например, архитектура данных)

 

 

Состав проектной команды

 

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

 

Состав управления и контроля архитектурного процесса

 

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

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

 

Руководящие принципы проектной работы

 

· Архитектура новых систем будет проходить формальные процедуры контроля на эффективность.

· Предлагаемые изменения в бизнес-процессах и системах будут контролироваться с точки зрения их влияния на другие обеспечивающие их бизнес-процессы и системы.

· Набор моделей архитектуры будет поддерживаться в актуальном состоянии (в специальном репозитории), целостность моделей и связи между ними также будут контролироваться и обеспечиваться.

· Будут разработаны и поддерживаться стандарты и правила (политики).

· Соответствие стандартам и правилам будет контролироваться.

· Архитектура будет неотъемлемой частью всего процесса управления ИТ на предприятии.

· Технологическая архитектура будет контролироваться на уровне предприятия в целом.

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

 

Элементы контроля и управления архитектурой на различных этапах проектов

 

 

 

 

Оргсттруктуры связанные с контролем и упралением архитектурой

 

 

Уровни проектной работы

 

Таким образом, постоянная работа непосредственно над архитектурой с организационной точки зрения ведется как бы на трех уровнях:

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

Результаты разработки АП

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

· инвестиции в достаточной мере соответствуют архитектуре и могут быть рекомендованы;

· новые инвестиции отклонены из-за плохого соответствия архитектуре;

· инвестиции признаны необходимыми даже в условиях несоответствия архитектуре, и в архитектуру вносятся изменения, чтобы отразить это несоответствие, описать новые функции, объекты данных и необходимые приложения;

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

 

Уровни зрелости АП

 

Уровень 1. Начальный.

Уровень 2. Повторяемый.

Уровень 3. Определенный или регламентируемый.

Уровень 4. Управляемый.

Уровень 5. Оптимизирующий..

 

Уровень Основные характеристики
1. Начальный Спонтанные информационные связи. Хаотичность, непоследовательность
2. Повторяемый Базовые процессы. Повторяемые операции
3. Определенный Стандартизация процессов. Интеграция, наличие процедур
4. Управляемый Контроль качества. Использование обратной связи
5. Оптимизирующий Постоянное развитие. Самоадаптация системы

 

 

Оглавление

 

Тема 1 Архитектура предприятия: Основные понятия и концепции 3

Тема 2 Архитектура предприятия и её моделирование 18

Тема 3 Архитектура бизнеса. Бизнес и информационные технологии 27

Тема 4 Архитектура предприятия: элементы архитектуры предприятия 44

Тема 5 Архитектура и управление IT-портфелем 67

Тема 6 Методики разработки архитектуры предприятия 69

Тема 7 Процесс разработки архитектуры предприятия 86

– Конец работы –

Эта тема принадлежит разделу:

По дисциплине Архитектура предприятия

Министерство образования Российской Федерации... Федеральное государственное бюджетное образовательное... учреждение высшего профессионального образования...

Если Вам нужно дополнительный материал на эту тему, или Вы не нашли то, что искали, рекомендуем воспользоваться поиском по нашей базе работ: Уровни схемы методики

Что будем делать с полученным материалом:

Если этот материал оказался полезным ля Вас, Вы можете сохранить его на свою страничку в социальных сетях:

Все темы данного раздела:

Тема 2 архитектура предприятия и ее моделирование
  Определение АП   В самом общем виде под архитектурой предприятия (EA – Enterprise Architecture) понимается всестороннее и исчерпывающее описание (модел

Виды изменений
•Изменения в рамках обычной операционной деятельности; •Точечные улучшения; •Радикальные изменения(в связи с введением новых компонентов) •Устранение неактуальных процесс

Тема 4 Архитектура предприятия: Элементы архитектуры предприятия
Предметные области архитектуры (1) Бизнес-архитектура. Описывает деятельность организации с точки зрения ее ключевых бизнес-процессов. Архите

Тема 5 Архитектура и управление IT-портфелем
  Управление портфелем ITПод управлением портфелем информационных технологий понимается процесс отбора, управления и оценки инвестиций, связанный как с ИТ-активами, так и с пор

Хотите получать на электронную почту самые свежие новости?
Education Insider Sample
Подпишитесь на Нашу рассылку
Наша политика приватности обеспечивает 100% безопасность и анонимность Ваших E-Mail
Реклама
Соответствующий теме материал
  • Похожее
  • Популярное
  • Облако тегов
  • Здесь
  • Временно
  • Пусто
Теги