togaf что это такое
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 что это такое
В этой статье пойдёт речь о международном стандарте TOGAF (The Open Group Architecture Framework) в области системной архитектуры предприятия. TOGAF 9.1 занимает почти 700 страниц, поэтому здесь мы сможем рассмотреть только введение. Без исторического вступления, без объяснений, что такое Open Group, и рассуждений о пользе и трудностях практического применения стандартов — со всем этим разберётесь без меня — перейду сразу к делу.
Краткий обзор
На первых страницах стандарта приводится Executive Overview, в котором, судя по всему, даются ответы на возможные вопросы со стороны топ-менеджмента.
Что такое предприятие (enterprise)?
В соответствии с TOGAF термин «предприятие» имеет широкую трактовку. Предприятием называется одна или несколько организаций с общими целями. В этом смысле предприятием может считаться как целая корпорация, так и её подразделение; как государственное учреждение, так и коммерческая фирма или, например, несколько фирм с общими владельцами.
Что такое архитектура предприятия?
Основные термины в стандарте TOGAF взяты из стандарта ISO 42010 «Программная инженерия — Описание архитектуры». В соответствии с ISO 42010 архитектура представляет собой: «фундаментальную организацию системы, состоящую из компонент, их отношениях друг к другу и окружающей среде, а также принципов, определяющих проектирование и развитие системы». В этом смысле TOGAF рассматривает организацию как систему.
В тоже время TOGAF вводит для архитектуры и более частное определение, которое применяется в своём контексте. В соответствии с ним: « архитектура — это формальное описание системы или детальные план системы на уровне компонент, на основании которого осуществляется реализация системы».
Зачем нужно заниматься архитектурой предприятия?
Во введении к 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 на этапе гибкой доставки и реализации.
Методики описания архитектур. Модели Захмана и Gartner, методики META Group и TOGAF
Методика TOGAF
В состав модели TOGAF входят две основные компоненты – методика ADM ( Architecture Development Method ), определяющая процесс разработки архитектуры, и Базовая Архитектура ( Foundation Architecture ). Она дополняется соответствующей базой данных ресурсов, включающей описания архитектурных принципов, примеров реализации, а также специализированный язык ADML. Заметим, что в описании TOGAF добавлен специальный документ, поясняющий соответствие между понятиями TOGAF и моделью Захмана.
Общая структура TOGAF [5.17] показана на рис. 8.9.
Важно отметить, что TOGAF распространяется свободно и может быть использована бесплатно любой организацией для разработки внутренних проектов. Лицензируется только коммерческое использование.
В соответствии с методикой ADM, процесс разработки архитектуры включает следующие фазы:
Каждая фаза, в свою очередь разбивается на подпроцессы (этапы), отдельные работы и так далее. Например, фаза D включает следующие основные подпроцессы:
Описание существующей технологической архитектуры.
Формирование целевой технологической архитектуры.
Для каждого такого подпроцесса определяются решаемые в его ходе задачи, входные и выходные документы. Важно отметить, что процесс предусматривает не обязательную, но возможную адаптацию самого метода к условиям конкретного предприятия, которая осуществляется на предварительной фазе. Это может быть вызвано как необходимостью учета других существующих стандартов предприятия, так и привлечением аутсорсинговых компаний к разработке архитектуры. Интересным примером может являться проект внедрения корпоративной ERP-системы. В этом случае необходимо определенное изменение порядка разработки – так, бизнес- архитектура в этом случае может определяться возможностями, поддерживаемыми в выбранном продукте, поэтому фазы B и С в данном случае будут выполняться не до, а после фазы D!
Процесс разработки не заканчивается после выбора оптимальной архитектуры и разработки плана миграции. Необходимыми элементами являются задачи, выполняемые на фазах G и H. В частности, для обеспечения практического принятия архитектуры в организации и успеха проекта обязательным является формирование Системы управления реализацией архитектуры ( Implementation Governance ). Так, фаза G предусматривает следующие задачи:
m_i_kuznetsov
m_i_kuznetsovРазмышления о разработке программного обеспечения и информационных систем
То, что действительно важно, но чему нигде не учат
На русском языке официальной спецификации TOGAF нет. Неофициальный перевод можно посмотреть здесь.
И ещё нашёл цикл видеолекций Александра Кварцхавы «Курс лекций по TOGAF». Александр дал неплохое определение TOGAF как инструмента трансформации лучших мировых архитектурных практик в модель архитектуры конкретного предприятия. Видеолекции по TOGAF являются частью видеокурса «Archimate, TOGAF, UML и BPMN».
Recent Posts from This Journal
Ох, как давно не писал в блог. Ну да ладно, всему своё время. Я ж тут не периодическое издание изображаю ) Сегодня хочу поговорить о культуре…
Показатели качества по ISO 9126
На тему показателей качества я писал полтора года назад в статье «Анализ действующей системы: характеристики качества». Статья была основана как раз…
Характеристики качества. FURPS+
Новая презентация на моём Инстаграмм-канале рассказывает о классификации FURPS+. Часто эту классификацию рассматривают как классификацию требований…
Классификация бизнес-целей: отчёт CMU/SEI-2005-TR-021, часть 5
Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей. Первая часть была посвящена применяемой методике классификации и общей…
Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей. Первая часть была посвящена применяемой методике классификации и общей…
Классификация бизнес-целей: отчёт CMU/SEI-2005-TR-021, часть 3
Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей. Первая часть была посвящена применяемой методике классификации и общей…
Продолжаю публикацию перевода отчёта SEI о классификации бизнес-целей. Первая часть была посвящена применяемой методике классификации и общей…
Постановка целей с использованием модели SMART
Как-то выпал из моего блога перевод отчёта о классификации бизнес-целей, сделанный мной ещё год назад. Пожалуй, надо восполнить этот пробел. Ввиду…