Togaf что это такое

Togaf что это такое

В этой статье пойдёт речь о международном стандарте TOGAF (The Open Group Architecture Framework) в области системной архитектуры предприятия. TOGAF 9.1 занимает почти 700 страниц, поэтому здесь мы сможем рассмотреть только введение. Без исторического вступления, без объяснений, что такое Open Group, и рассуждений о пользе и трудностях практического применения стандартов — со всем этим разберётесь без меня — перейду сразу к делу.

Краткий обзор

На первых страницах стандарта приводится Executive Overview, в котором, судя по всему, даются ответы на возможные вопросы со стороны топ-менеджмента.

Что такое предприятие (enterprise)?

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

Что такое архитектура предприятия?

Основные термины в стандарте TOGAF взяты из стандарта ISO 42010 «Программная инженерия — Описание архитектуры&raquo. В соответствии с ISO 42010 архитектура представляет собой: «фундаментальную организацию системы, состоящую из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы&raquo. В этом смысле TOGAF рассматривает организацию как систему.

В тоже время TOGAF вводит для архитектуры и более частное определение, которое применяется в своём контексте. В соответствии с ним: « архитектура — это формальное описание системы или детальные план системы на уровне компонент, на основании которого осуществляется реализация системы&raquo.

Зачем нужно заниматься архитектурой предприятия?

Во введении к TOGAF приводится много лозунгов про эффективность бизнеса и ИТ. Но главным образом, всё сводится к тому, что архитектура обеспечивает стратегический контекст развитию ИТ в ответ на требования бизнеса. Другими словами, если есть архитектура, то развитие ИТ происходит не спонтанно, например, по желанию некоторых руководителей или в соответствии с модой, навязываемой вендорами, но вся эта деятельность целиком подчинена бизнесу и его стратегическим интересам. В этом смысле архитектура похожа на ИТ–стратегию, с той лишь разницей, что архитектура является более детальным представлением деятельности, чем стратегия.

Что же заставит меня («капитана бизнеса») заниматься архитектурой предприятия?

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

Какие задачи ставятся архитектору на уровне предприятия?

Почему в качестве основы для разработки архитектуры предприятия мне нужно выбрать именно TOGAF?

Разработка и поддержание архитектуры предприятия представляет собой технически сложный процесс и охватывает различные стороны, имеющие собственные точки зрения и интересы. В этой ситуации TOGAF может создать авторитетную основу для внутрикорпоративной стандартизации и снижения проектных рисков при разработке архитектуры. В создании TOGAF принимали участие более 300 участников форума Open Group из ведущих компаний в сфере ИТ (в большинстве, конечно, американских компаний). В результате TOGAF представляет собой набор «лучших мировых практик», которые позволяют сделать работоспособную и экономически эффективную архитектуру предприятия, ориентированную на потребности бизнеса.

Как относиться к подобной аргументации — решайте сами.

Домены архитектуры

Архитектор уровня предприятия должен успешно работать в каждом из этих доменов.

Метод разработки архитектуры

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

Architecture Development Method

Следующая статья будет посвящена структурным элементам TOGAF

Обзор подготовлен с использованием материалов стандарта TOGAF версии 9.1

Источник

Повышаем степень клиентоориентированности с помощью корпоративной архитектуры на основе TOGAF®

Привет, Хабр. В рамках набора учащихся на курс «Enterprise Architect» подготовили перевод материала.

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

Область бизнес-архитектуры в рамках Enterprise Architecture (Архитектура предприятия) — это не только бизнес-возможности и бизнес-процессы. В первую очередь это касается оптимизации ценности (value) для ваших клиентов и усилий в построении организации, в большей степени ориентированной на них.

Важность ценности в Enterprise Architecture

Традиционно в Enterprise Architecture бизнес-процессы (business processes) являются основным средством взаимодействия с заинтересованными сторонами. Что касается понятия бизнес-возможностей (business capabilities), то это более новая концепция, также часто используемая в Enterprise Architecture. Бизнес-возможности позволяют лучше понять, как программные приложения поддерживают бизнес, что очень хорошо объясняется в этом видео — «Бизнес-архитектура TOGAF®: Руководство по бизнес-возможностям»:

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

Корпоративные архитекторы должны осваивать и использовать концепцию ценности на клиентоориентированном предприятии, как показано на изображении выше. Организация обычно предоставляет несколько ценностных предложений (value propositions) различным сегментам своих клиентов (или персонам) и партнерам, которые доставляются потоками создания ценности (value streams), состоящими из нескольких этапов создания ценности (value stages). На этапах создания ценности участвуют внутренние заинтересованные стороны (stakeholders), внешние заинтересованные стороны и очень часто потребители. Этапы создания ценности создают условия для этапов клиентских путей (customer journey steps), опираются на возможности и вводятся в действие процессами (обычно уровень 2 или 3). Видео Бизнес-архитектура TOGAF® :Значение Guide Поток дает очень четкое и простое объяснение, если вы хотите узнать об этом побольше. Клиентские пути, строго говоря, не является частью бизнес-архитектуры, но, тем не менее, очень полезно для взаимодействия с заинтересованными сторонами.

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

Фактически, ценностные предложения, потоки и этапы создания ценности — это «Почему» инициатива или проект должны быть реализованы. Заинтересованная сторона — это «Кто» должен участвовать для создания ценности. Бизнес-процесс — это «Как» организация может создавать ценность. Наконец, бизнес-возможности — это то, «Что» организация должна контролировать или должна делать для создания ценности.

Важные определения

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

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

Бизнес-возможность (Business Capability). Бизнес-возможности — это особые способности, которыми предприятие может обладать или обменивать для достижения определенной цели. Бизнес-возможности должны поддерживаться приложениями, системами и/или IT-сервисами.

Клиент (Customer). Тот, кто покупает товар или услугу.

Клиентский путь (Customer Journey). Клиентский путь описывает полный опыт, который проходят клиенты при взаимодействии с организацией в виде пути из последовательных шагов до и после покупки продукта или услуги. Вместо того, чтобы рассматривать только часть транзакции или опыта, клиентский путь документирует полный опыт работы с клиентом. Клиентский путь состоит из нескольких этапов.

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

Заинтересованная сторона (Stakeholder). Человек, команда, организация или комбинация вышеперечисленного, заинтересованные в системе.

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

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

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

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

Enterprise Architecture и 5 этапов исполнения гибкой стратегии

Теперь давайте расположим каждый элемент, указанный на рисунке выше, как показано на рисунке ниже, чтобы определить 5 шагов в организации реализации гибкой стратегии. Эти этапы подробно описаны в книге «Практическое руководство по реализации гибкой стратегии: проектирование, архитектура, расстановка приоритетов и успешное достижение корпоративного будущего».

Клиенты (сегменты и/или персоны) и партнеры участвуют на всех пяти этапах реализации гибкой стратегии организации. Заинтересованные стороны бизнеса участвуют во всех этапах, кроме четвертого, который представляет собой этап гибкой доставки и выполнения. Что касается заинтересованных сторон в области IT, они в основном участвуют в планировании инициативы (шаг 3) и гибкой доставке и реализации (шаг 4).

Ценностные предложения, продукты, услуги в основном разрабатываются на этапе бизнес-дизайна и стратегии (шаг 1) для достижения конкретных стратегий и целей. Клиентские пути, потоки и этапы создания ценности обычно изучаются в начале проектировании трансформаций (шаг 2). Бизнес-возможности исследуются как при проектировании трансформаций, так и при планировании инициатив (шаги 2 и 3). Что касается бизнес-процессов, о них в основном заботятся на этапе гибкой доставки и реализации (шаг 4) на оперативном и тактическом уровне, когда экспертам по бизнес-процессам и agile-экспертам необходимо достичь четких целей в оценке тактике.

Чтобы обеспечить дополнительную ценность для своей организации, архитекторам предприятия необходимо понимать, что бизнес-архитектура — это не только бизнес-возможности и бизнес-процессы. Архитекторам предприятий не следует ограничивать свои возможности только проектированием трансформаций и инициативным планированием своей организации. Корпоративные архитекторы также могут внести свой вклад в оптимизацию ценности для клиентов и партнеров своей организации. Включение всех аспектов бизнес-архитектуры в практику вашей enterprise architecture сделает вашу команду гораздо более ценной для заинтересованных сторон на начальном этапе бизнес-дизайна и выработки стратегии и для заинтересованных сторон в IT на этапе гибкой доставки и реализации.

Источник

СОДЕРЖАНИЕ

Обзор

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

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

История

TOGAF 9 является эволюционным развитием TOGAF 8 и включает в себя множество новых функций, таких как:

Дополнительные рекомендации и методы включают:

Open Group бесплатно предоставляет TOGAF организациям для их собственных внутренних некоммерческих целей.

Столбы TOGAF

Домены архитектуры предприятия

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

Метод разработки архитектуры

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

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

Континуум предприятия

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

TOGAF 9.2 распознает следующие роли;

TOGAF культура

TOGAF предоставляет сертификаты для инструментов и людей.

Инструменты, сертифицированные TOGAF

Сертифицированные инструменты TOGAF 9 перечислены в следующей таблице.

Самый последний реестр сертифицированных инструментов можно найти в реестре Open Group.

Квалификация

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

(Уровень I) Гарантирует, что человек понимает архитектуру предприятия, а также основные концепции и терминологию TOGAF.

Проверенный

(Уровень II) В дополнение к квалификации Foundation, это означает, что кандидат может анализировать и применять свои знания для решения бизнес-задач.

Получение статуса TOGAF Certified автоматически означает бесплатное членство в Ассоциации архитекторов предприятий.

Критика

Источник

TOGAF

Пространства имён

Действия на странице

По состоянию на 2016, TOGAF используют 40 из 50 крупнейших транснациональных компаний и 300 из 500 самых крупных компаний США.

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

Содержание

Основные принципы

Задачи системного архитектора

Терминология

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

Основные термины в стандарте TOGAF взяты из стандарта ISO 42010.

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

Состав

В состав модели TOGAF входят две основные компоненты:

Метод разработки архитектуры

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

Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес-архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!

Базовая архитектура

Базовая Архитектура включает в себя:

Использование TOGAF с другими фреймворками

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

Во всех случаях предполагается, что архитектор будет адаптировать и развивать TOGAF для того, чтобы определить индивидуальный метод, который интегрирован в процессы и организационные структуры предприятия. Эта адаптация может включать в себя принятие элементов из других архитектурных фреймворков или интеграцию методов TOGAF с другими стандартными фрейворками (ITIL, CMMI, COBIT, PRINCE2, PMBOK).

Источник

Методология управления изменениями на основе методологии TOGAF и языка моделирования Archimate

Древнее китайское проклятие гласит – чтоб тебе жить в эпоху перемен. Любые перемены, изменения всегда болезненны и приносят множество проблем. Однако именно они и порождают новые возможности. Ицхак Адизес, в своей методологии подчёркивает, что именно рост компании обеспечивает повышение коммерческого дохода. Но рост — это всегда изменение. Будь то переход с этапа младенчества или юности, как и обратное изменение с этапов застоя к расцвету.

Вторая проблема – это как будут осуществляться данные изменения,по каким принципам. Очень часто они происходят бессистемно. В работу компании врываются «бизнес-консультанты» различных направления и начинают либо менять что-то в одном направлении – например срочно внедрять какую-то ERP систему, либо объявляют проблемную функцию, например, логистику и начинают её «модернизировать изо всех сил.

Поэтому хаотическое внесение изменений не только не решит текущие проблемы, но и создаст массу новых, за счёт нарушения текущих связей. Кроме этого понятие «проблемы» весьма размыто. Очень часто, их некорректно определяют соответственно и решения, которые призваны их победить порождают новые и новые проблемы. Именно поэтому, существуют инструменты и своды инструкций по осуществлению изменений в компании как в системе. Свод подобных инструкций, разработанных западными экспертами называется TOGAF. Он представляет собой полноценную методологию, описывающую как изменить все элементы компании, с учётом их связей. Методология представляет компанию связью нескольких уровней.

Схема компании с точки зрения TOGAF

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

На стадии предварительной фазы, оценивается необходимость архитектурного проекта и проводиться адаптация методологии. Дело в том, что в небольшой компании, примерно человек до 50, применение методологии является излишеством, либо придётся при практическом приенении из неё слишком многое не использовать, и она потеряет смысл. В рамках адаптации принимаются организационные решения, насколько глубоко архитектура будет прорабатываться и какие части методологии будут использоваться в работе.

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

Пример архитектурного видения.

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

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

Пример схемы этого уровня.

Пример схемы физического уровня.

Данная логика появилась не слишком давно, однако доказала свою пользу. Очень часто на проектах блок инфраструктуры оставался неохваченным.

Пример схемы в рамках системной архитектуры

Технологическая архитектура обеспечивает работу системной архитектуры и бизнес-архитектуры.

Пример схемы в рамках технологической архитектуры

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

Схема примера взаимодействия сервисов

Пример пакетов работ.

В процессе работы корпоративному архитектору, как и архитектору в строительстве требуется проектировать модель компании в различных разрезах. Инструментом корпоративного архитектора является язык Arсhimate. Он гармонично дополняет TOGAF, позволяя моделировать действия, описываемые методологией.Однако необходимо понимать важный момент, данный язык моделирования является высокоуровневым и совершенно не подходит как для детального описания бизнес-процессов, так и моделирования работы внутренней логики ИТ систем. В этом случае следует применять BPMN и UML.

Схема применения инструментов моделирования.

В завершении статьи подчеркну, что несмотря на мою попытку максимально охватить данный вопрос, очень многое осталось за «бортом». Поэтому рекомендую ознакомиться на сайте разработчиков с полной версией методологии и описанием языка моделирования.

Источник