Главная страница
Навигация по странице:

  • Общие (framework) инфраструктурные сервисы

  • Общие (framework) бизнес-сервисы

  • Прикладные бизнес-сервисы

  • 6. Методика TOGAF. Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework

  • Архитектура бизнеса

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

  • СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

  • СРО5. Самостоятельная работа реферат по дисциплине it инфраструктура работы 5 Тема Современные методики описания архитектуры предприятия


    Скачать 91.44 Kb.
    НазваниеСамостоятельная работа реферат по дисциплине it инфраструктура работы 5 Тема Современные методики описания архитектуры предприятия
    Дата28.04.2022
    Размер91.44 Kb.
    Формат файлаdocx
    Имя файлаСРО5.docx
    ТипСамостоятельная работа
    #503665
    страница3 из 3
    1   2   3

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

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

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

    Прикладные бизнес-сервисы: специфические для отдельных бизнес-процессов, содержат высокоуровневую бизнес-логику. Например, сервисы CRM-систем или систем управления поставками.

    В результате получается технологическая модель предприятия.

    В полном описании методики META Group приводятся также следующие аспекты:

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

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

    - оценка зрелости архитектуры;

    - анализ технологических тенденций и планирование;

    - управление портфелем ИТ-активов и проектов.

     

    6.  Методика TOGAF.

     

    Методика описания архитектуры TOGAF (сокращение от The Open Group Architecture Framework) была предложена некоммерческим объединением The Open Group, в которое входит ряд ведущих производителей информационных технологий, а также компаний из списка Fortune 1000. TOGAF позиционируется ее авторами не как некоторая эталонная модель, а как «средство для разработки архитектур информационных систем». Основное назначение – ускорить и облегчить процесс разработки архитектуры конкретной организации, обеспечивая при этом возможность будущего развития. В декабре 2003 года была опубликована версия 8.1 этой модели.

    Представление архитектуры предприятия в методологии TOGAF показано на рисунке 3.

    Как показано на рисунке 3, в модели TOGAF архитектура предприятия подразделяется на четыре категории 

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

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

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

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

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

    Как архитектурный процесс модель TOGAF дополняет модель Захмана.

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

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

     

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

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

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

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

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

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

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

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

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

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

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

    Спецификация TOGAF также позволяет гибко работать с этапами. В самой спецификации говорится следующее:

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

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

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

     

     

    Заключение
    Таким образом, на основании проведенного сравнения архитектурных фреймворков можно заключить, что применение методологии TOGAF при проектировании и реализации таких комплексных систем, как ESB, позволяет оперативно реагировать на изменения требований бизнеса и учитывать их при реализации системы. При этом, благодаря инструменту визуализации ArchiMate, полученное архитектурное описание остается простым и понятным как для исполнителей, так и для заказчиков от бизнеса, что делает нашу систему гибкой и прозрачной. 

    СПИСОК РЕКОМЕНДУЕМОЙ ЛИТЕРАТУРЫ.

     

    [1] Данилин А., Слюсаренко А. Архитектура и стратегия. «Инь» и «Янь» информационных технологий предприятия.  –   М. Интернет Ун-т Информ. Технологий, 2005. – 504 с.

     

    [2] Калянов Г. Н. Консалтинг: от бизнес-стратегии к корпоративной информационно-управляющей системе. Учебник для вузов. 2-е изд., доп. – Горячая линия-Телеком М., 2014. –  210 с. 
    [3] Кудрявцев Д.В., Арзуманян М.Ю.,  Григорьев Л.Ю. Технологии бизнес-инжиниринга.  Учебное  пособие / под редакцией Д.В. Кудрявцева. — СПб.:  Изд-во Политехн. ун-та, 2014.

     

    [4] Информационные системы и технологии в экономике и  управлении: Учебник  /под ред. проф. В.В. Трофимова. — М.: Высшее  образование, 2006. –  480 с.

    [5] Репин В.В., Елиферов В.Г. Процессный подход к управлению. Моделирование бизнес-процессов. – М.: РИА «Стандарты и качество», 2004 – 408 с. (Серия «Практический менеджмент»).
    1   2   3


    написать администратору сайта