Методология описания архитектуры предприятия (TOGAF)

МИНИСТЕРСТВО СЕЛЬСКОГО ХОЗЯЙСТВА РОССИЙСКОЙ ФЕДЕРАЦИИ Федеральное государственное бюджетное образовательное учреждение высшего образования

" Российский Государственный Аграрный Университет — МСХА имени К.А. Тимирязева"

Кафедра: «Информационных технологий в строительстве»

Реферат по дисциплине «Архитектура предприятия»

на тему: «Методология описания архитектуры предприятия (TOGAF)»

Выполнил:

Антофьева О.А.

Москва 2015

Содержание Введение

1. Общее понятие предмета

2. Определение методики TOGAF

2.1 TOGAF. Архитектурные составляющие

2.2 TOGAF. Метод разработки архитектуры (ADM)

2.3 TOGAF. Архитектурная функциональность предприятия Заключение

Список используемой литературы

TOGAF — это стандарт в области архитектуры предприятия, более 60% компаний из cписка Fortune 500 используют TOGAF. Рассмотрим данную методологию подробнее в данной работе.

Методика (стандарт) TOGAF:

· Современная и активно развивающаяся

· Широко используемая

· Системная

· Гибкая и совместимая с другими методиками и стандартами

· Имеет детально разработанный метод архитектурной разработки

· Открытая

1. Общее понятие предмета Архитектура предприятия — это совокупность технологических и человеческих факторов, главной задачей которых стоит развитие предприятия в краткосрочной и долгосрочной перспективе. Успех современных предприятий зависит от того, насколько быстро и эффективно они могут отвечать современным меняющимся требованиям рынка. Таким образом, «архитектура предприятия» показывает способы и методы достижения бизнес-стратегии компании. Разработка архитектуры предприятия должна вестись в контексте структур управления и взаимодействия в организации. Существуют различные методики построения и оценки архитектуры предприятия, они задают классификацию основных областей архитектуры, описание используемых правил (политик), стандартов, процессов и моделей. В качестве примеров можно указать следующие методики:

— методика Захмана;

— методика TOGAF;

— методика FEAF;

— методика Garther.

2. Определение методики TOGAF

архитектура togaf моделирование

TOGAF — это аббревиатура от The Open Group Architecture Framework (структура архитектуры The Open Group). Методология TOGAF принадлежит консорциуму The Open Group.

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

2.1 TOGAF. Архитектурные составляющие

TOGAF архитектура предприятия подразделяется на четыре категории:

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

Архитектура приложений — описывает структуру конкретных приложений и их взаимодействие друг с другом.

Архитектура данных — описывает структуру корпоративных хранилищ данных и процедуры доступа к ним.

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

2.2 TOGAF. Архитектурная функциональность предприятия Как архитектурный процесс модель TOGAF дополняет модель Захмана. Захман показывает, как следует классифицировать артефакты. Модель TOGAF описывает процесс создания артефактов.

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

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

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

Следующий уровень специализации в модели TOGAF называется отраслевыми архитектурами. Эти принципы характерны для предприятий, занятых в одной сфере деятельности, например в случае с MedAMore — для всех фармацевтических компаний.

Самый высокий уровень специализации в модели TOGAF называется архитектурами организаций. Это архитектуры конкретных предприятий, например MedAMore.

Рис. 1. Континуум предприятия в модели TOGAF

В модели TOGAF на уровне фундаментальных архитектур определяется ряд баз знаний. Вы можете столкнуться с двумя из них: технической эталонной моделью (TRM) и информационной базой стандартов (SIB). Техническая эталонная модель является рекомендуемым описанием общей ИТ-архитектуры. Информационная база стандартов представляет собой набор стандартов и псевдостандартов, которые консорциум The Open Group рекомендует использовать при построении ИТ-архитектуры.

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

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

2.3 TOGAF. Метод разработки архитектуры (ADM)

Рис. 2. Методика разработки архитектуры (ADM) в модели TOGAF

Модель TOGAF позиционируется как «структура», однако наиболее важным ее компонентом является методика разработки архитектуры (ADM). Эта методика представляет собой рецепт по созданию архитектуры. Рецепт можно классифицировать как процесс.

Как показано на рис. 1, методика разработки архитектуры в модели TOGAF состоит из восьми этапов, которые циклически повторяются после первой «накачки». Далее эти этапы будут рассмотрены на примере MedAMore. Однако перед тем как компания MedAMore сможет приступить к использованию методики разработки архитектуры, ей необходимо изучить модель TOGAF. Изучить модель TOGAF можно двумя способами.

Во-первых, компания MedAMore может изучить модель TOGAF самостоятельно. Компания MedAMore может загрузить документацию по TOGAF — в ней достаточно подробно описаны все возможности TOGAF, в том числе методика разработки архитектуры. Также можно приобрести книги по TOGAF. О модели TOGAF доступно больше информации (как бесплатной, так и за умеренную цену), чем обо всех остальных методологиях построения архитектуры вместе взятых.

Во-вторых, компания MedAMore может обратиться к экспертам по TOGAF. На рынке работает множество консультантов по TOGAF, обладающих сертификатами Open Group. Поскольку руководство компании MedAMore хочет свести все риски к минимуму, оно принимает решение обратиться к консультанту по TOGAF. Компания MedAMore обратилась к Тэри, которая является архитектором TOGAF с сертификатом Open Group. Напомним, что другими игроками в компании MedAMore являются Кэт, исполнительный директор MedAMore, Брет, вице-президент по бизнесу, и Ирма, директор по информационным технологиям.

На подготовительном этапе Тэри встречается с основными игроками в компании MedAMore и рассказывает им о процессе TOGAF. Она преследует три основные цели:

· Убедиться в том, что процесс устраивает всех игроков

· Если необходимо, изменить процесс TOGAF в соответствии с корпоративной культурой MedAMore

· Разработать систему управления для надзора за последующей разработкой архитектуры в MedAMore

Тэри будет тесно сотрудничать с Бретом, чтобы понять философию бизнеса, изучить бизнес-модели и стратегические задачи MedAMore. Ей также придется тесно взаимодействовать с Ирмой, чтобы определить архитектурные принципы, лежащие в основе используемых в MedAMore технологий, и задокументировать эти принципы в формате, рекомендуемом моделью TOGAF.

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

По завершении подготовительного этапа Тэри готова перейти к этапу А. Этот этап начинается, по крайней мере, в теории, с Запроса на разработку архитектуры от какого-либо подразделения компании MedAMore. В этом документе излагаются причины запроса с точки зрения бизнеса, приводится бюджет и сведения о персонале, а также указываются ограничения, которые необходимо учитывать. Поскольку в компании MedAMore никогда не создавались Запросы на разработку архитектуры, Тэри придется помочь организации в создании подобного запроса.

После получения «Запроса на разработку архитектуры» (или аналогичного документа) Тэри (консультант по TOGAF) переходит к этапу А. На этом этапе Тэри предстоит убедиться в том, что проект надлежащим образом поддерживается компанией MedAMore, определить область действия проекта, выявить ограничения, задокументировать бизнес-требования и разработать высокоуровневые определения как для базовой (начальной), так и для целевой (желаемой) архитектуры.

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

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

Архитектурное представление, созданное на этапе А, является основой для этапа Б. Цель Тэри на этапе Б заключается в создании детализированной базовой и целевой архитектур бизнеса и всестороннем анализе различий между этими архитектурами. Для достижения этой цели Тэри в основном будет работать с Бретом (или его подчиненными).

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

На этапе В выполняются все те же действия, что и на этапе Б, только для архитектуры информационных систем. На этом этапе Тэри работает в основном с Ирмой (или ее подчиненными). В модели TOGAF определено девять этапов, каждый из которых разбит на несколько под этапов:

· Разработка описания базовой архитектуры данных

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

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

· Выбор компонентов архитектуры данных

· Формальный анализ контрольных точек модели архитектуры и ее компонентов вместе с заинтересованными лицами

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

· Завершение архитектуры данных

· Анализ контрольных точек и последствий

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

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

На этапе Д выполняется оценка различных возможностей реализации, определяются основные проекты по внедрению, которые необходимо выполнить, а также связанные с каждым проектом возможности для бизнеса. Стандартом TOGAF на этапе Д рекомендуется «сосредоточиться на проектах, которые дадут результаты в краткосрочной перспективе и позволят реализовать долгосрочные проекты».

Это хороший совет для любой методологии построения архитектуры. Таким образом, Тэри следует выделить проекты, которые можно реализовать с минимальными затратами и максимальной отдачей. Для поиска таких проектов рекомендуется изучить «болевые точки» организации, изначально обозначенные Кэт (исполнительным директором MedAMore). Это позволит принять стратегию развития предприятия на базе архитектуры. Описанные выше «болевые точки» включают трудности в обеспечении поддержки специализации на уровне регионов и складов и ненадежный обмен данными.

Этап Е тесно связан с этапом Д. На этом этапе Тэри работает с руководством компании MedAMore’s, чтобы упорядочить по приоритетам проекты, выбранные на этапе Д, с учетом не только затрат и выхода (определенных на этапе Д), но и факторов риска.

На этапе Ж Тэри на основе упорядоченного по приоритетам списка проектов создает спецификации архитектуры для проектов реализации. Эти спецификации включают критерии приемки и списки рисков и проблем.

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

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

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

Заключение

«Методология TOGAF — это не только и не столько создаваемые документы; фактически она в меньшей степени ориентирована на шаблоны документов, а в большей — на то, что мы получаем на входе и на выходе».

Спецификация TOGAF также позволяет гибко работать с этапами.

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

Список используемой литературы

1. Роджер Сешнс Сравнение четырех ведущих методологий построения архитектуры предприятия.

2. К. С. Дрогобыцкая, И. Н. Дрогобыцкий. Архитектурные модели экономических систем: Монография. — М.: Вузовский учебник: ИНФРА-М, 2014.

3. Межгосударственный стандарт ГОСТ 7.32−2001 «Система стандартов по информации, библиотечному и издательскому делу. Отчет о научноисследовательской работе. Структура и правила оформления» (утв. постановлением Госстандарта РФ от 4 сентября 2001 г. N 367-ст) (с изменениями от 7 сентября 2005 г.).

4. Калянов Г. Н. Архитектура предприятия и инструменты ее моделирования.