TOGAF 10 и архитектура предприятия
Идея создать модель идеальной архитектуры предприятия существует уже довольно давно. Есть различные методологии, стандарты, шаблоны, описывающие разные варианты создания архитектуры. Платформа TOGAF (The Open Group Architecture Framework) является широко распространенным решением для построения корпоративной архитектуры, которая предоставляет общий язык, методологию и инструменты для проектирования, планирования и внедрения ИТ‑инфраструктуры организации. Одним из ключевых компонентов TOGAF является метод разработки архитектуры (ADM), который описывает пошаговый процесс создания архитектуры предприятия и управления ею. В рамках ADM существуют различные методы, которые могут быть использованы для разработки архитектуры организации. В рамках данной статьи мы рассмотрим некоторые из них.
Стандарт TOGAF является основой для корпоративной архитектуры. Он может свободно использоваться любой организацией, желающей разработать корпоративную архитектуру для внутреннего использования.
Свобода изменений
Хотя вся документация TOGAF представляет собой единое целое, допускается, что организации будут изменять ее в процессе внедрения и намеренно выбирать некоторые элементы, настраивать, исключать ненужные и создавать свои. Например, организация может захотеть внедрить метамодель TOGAF, но отказаться от использования какого‑либо руководства по разработке внутренней технологической архитектуры, поскольку она является активным потребителем облачных сервисов.
Прежде, чем начинать работу с TOGAF стоит ответить на некоторые фундаментальные вопросы, например, зачем нужна архитектура предприятия или зачем использовать стандарт TOGAF в качестве основы для архитектуры.
Термин «Предприятие» в контексте «Архитектуры предприятия» может применяться либо ко всему предприятию в целом, охватывая всю его деятельность, информацию и технологии, которые составляют всю инфраструктуру и управление предприятием, либо к одному или нескольким конкретным направлениям деятельности внутри предприятия. Предприятие может включать партнеров, поставщиков и клиентов, а также внутренние бизнес‑подразделения. Во всех случаях архитектура охватывает множество систем и функциональных групп внутри предприятия.
Многие организации могут включать в себя несколько предприятий и могут разрабатывать и поддерживать ряд независимых корпоративных архитектур для решения каждой из них. Эти предприятия часто имеют много общего друг с другом, включая процессы, функции и свои информационные системы, и часто существует большой потенциал для более широкого использования общей архитектуры. Например, общая структура может обеспечить основу для разработки общих элементов и решений, а также совместно используемое хранилище архитектуры для интеграции и повторного использования бизнес‑моделей, проектов, информации и данных.
Основные цели
Цель корпоративной архитектуры — оптимизировать в масштабах всего предприятия часто фрагментированные унаследованные процессы (как ручные, так и автоматизированные) в интегрированную среду, которая реагирует на изменения и поддерживает реализацию бизнес‑стратегии.
Эффективное управление и использование информации, а также цифровая трансформация являются ключевыми факторами успеха в бизнесе и необходимыми средствами достижения конкурентных преимуществ. Корпоративная архитектура удовлетворяет эту потребность, обеспечивая стратегический контекст для развития и расширения возможностей использования цифровых технологий в ответ на постоянно меняющиеся потребности бизнес‑среды.
Кроме того, хорошая корпоративная архитектура позволяет достичь правильного баланса между трансформацией бизнеса и постоянной операционной эффективностью. Она позволяет отдельным бизнес‑подразделениям безопасно внедрять инновации в стремлении к достижению меняющихся бизнес‑целей и конкурентных преимуществ. В то же время корпоративная архитектура позволяет удовлетворять потребности организации с помощью интегрированной стратегии, которая обеспечивает максимально возможную синергию как внутри предприятия, так и за его пределами.
И, наконец, закон о защите персональных данных требует, чтобы процессы, связанные с персональными данными, были полностью задокументированы таким образом, чтобы их могли легко понять неподготовленные читатели, такие как субъекты данных, судьи и юристы. Очевидно, что создание этой базовой документации вытекает из изменившихся фундаментальных соображений, и теперь это имеет решающее значение.
Применение архитектуры TOGAF
Рассмотрим основные области архитектуры, которые обычно рассматриваются как подмножества общей архитектуры предприятия, и все они поддерживаются стандартом TOGAF.
Прежде всего это бизнес‑архитектура (Business Architecture), которая определяет бизнес‑стратегию, управление, организацию и ключевые бизнес‑процессы используемые в организации.
Для описания структуры логических и физических ресурсов организации, а также ресурсов управления данными используется архитектура данных (Data Architecture).
Архитектура приложения (Application Architecture) обеспечивает схему развертывания отдельных приложений, их взаимодействия и взаимосвязи с основными бизнес‑процессами организации.
И наконец, технологическая архитектура (Technology Architecture) описывает цифровую архитектуру и логические возможности программной и аппаратной инфраструктуры, а также стандарты, необходимые для поддержки развертывания бизнес‑служб, служб передачи данных и приложений. Данный раздел включает в себя цифровые сервисы, Интернет вещей (IoT), инфраструктуру социальных сетей, облачные сервисы, ИТ‑инфраструктуру, промежуточное программное обеспечение, сети, коммуникации, обработку данных, стандарты и т. д.
Также существует множество других областей, которые можно было бы определить, объединив соответствующие представления о бизнесе, данных, приложениях и технологиях.
Метод ADM
Метод разработки архитектуры ADM, который уже упоминался в начале статьи, обеспечивает проверенный и воспроизводимый процесс разработки архитектур. Данный метод включает в себя создание архитектурной основы, разработку архитектурного контента, переход и управление реализацией различных архитектур предприятия.
Процесс разработки и реализации архитектуры представляет собой непрерывный цикл, в рамках которого предприятия преобразовывают текущую архитектуру в соответствии с актуальными бизнес‑целями и задачами.
Далее мы рассмотрим этапы ADM, представленные на рисунке. На предварительном этапе (Preliminary) описываются мероприятия, необходимые для работы платформы TOGAF и определение принципов архитектуры.
На начальном шаге А мы должны определить текущие проблемы, составить эскиз решения и определение общей стратегии перехода к изменениям.
На этапе B мы описываем разработку бизнес‑архитектуры для поддержки согласованного архитектурного видения, представленного на шаге А. Этап C описывает разработку архитектуры информационных систем для поддержки согласованного архитектурного видения. Технологическая архитектура на шаге D описывает разработку технологической архитектуры для поддержки согласованного архитектурного видения.
Этапы А‑Е представляют собой некоторое понимание проблемы и разработку необходимого архитектурного видения.
Далее на этапе E проводится первоначальное планирование взаимодействия для тех архитектурных решений, которые мы определили на предыдущих этапах. Этап F определяет, как перейти от базовой архитектуры к целевой путем завершения разработки подробного плана внедрения и миграции.
На этапе G мы осуществляем архитектурный надзор за реализацией плана, разработанного на шаге F. И завершающий этап H устанавливает процедуры для управления изменениями в новой архитектуре, такими как обеспечение правильного планирования, структурирования и получения ожидаемых бизнес ценностей.
Управление всеми этими этапами осуществляет Requirement Management, который управляет требованиями к архитектуре в рамках ADM.
В целом, описание этапов ADM в TOGAF сосредоточено на рекомендациях о том, что можно сделать для определения и развертывания архитектуры предприятия.
Артефакты и строительные блоки
Результатами использования ADM являются технологические процессы, архитектурные требования, проектные планы, оценка соответствия проекта требованиям и т. д. Фреймворк архитектурного контента TOGAF предоставляет структурную модель архитектурного контента, которая позволяет последовательно определять, структурировать и представлять основные рабочие продукты.
Фреймворк архитектурного контента использует следующие три категории для описания типа рабочего продукта в контексте использования:
Конечный результат — это рабочий продукт, который оговорен в контракте и, в свою очередь, официально рассмотрен, одобрен и подписан заинтересованными сторонами
Конечные результаты представляют собой выходные данные проектов, и то, что представлено в виде документации, обычно архивируются по завершении проекта или передается в архитектурное хранилище в качестве эталонной модели, стандарта или моментального снимка архитектурного ландшафта на определенный момент времени.
Следующим типом является артефакт. Это рабочий продукт, который описывает один из аспектов архитектуры. Артефакты обычно классифицируются как каталоги (списки элементов), матрицы (показывающие взаимосвязи между элементами) и диаграммы (изображения элементов). Примеры включают каталог требований, матрицу взаимодействия приложений и диаграмму цепочки создания стоимости. Архитектурный результат может содержать один или несколько артефактов, и артефакты будут формировать содержимое архитектурного хранилища. Артефакт может считаться или не считаться результатом в зависимости от контрактной спецификации.
Структурный блок представляет собой компонент, который может быть объединен с другими структурными блоками для создания архитектуры и решений. Структурные блоки можно использовать повторно.
Структурные блоки могут быть определены на различных уровнях детализации, в зависимости от того, на какой стадии находится разработка архитектуры. Например, на ранней стадии структурный блок может состоять просто из названия или общего описания. Позже структурный блок может быть разбит на несколько вспомогательных структурных блоков и может сопровождаться полной спецификацией. Структурные блоки могут относиться к «архитектурам» или «решениям». И далее следуют еще две аббревиатуры, часто используемые в TOGAF.
Структурные блоки архитектуры (ABB) обычно описывают требуемые возможности и формируют спецификацию структурных блоков решения (SBB); например, на предприятии могут потребоваться возможности обслуживания клиентов, поддерживаемые многими SBB, такими как процессы, данные и прикладное программное обеспечение
Строительные блоки решения (SBB) представляют собой компоненты, которые будут использоваться для реализации требуемых возможностей. Например, сеть — это строительный блок, который может быть описан с помощью дополнительных артефактов и затем использован для реализации решений для предприятия.
Ниже представлено взаимодействие между артефактами и строительными блоками.
Например, документ с определением архитектуры — это конечный результат, который документирует описание архитектуры. Этот документ будет содержать ряд дополнительных артефактов, представляющих собой представления строительных блоков, относящихся к архитектуре. Может быть создана блок‑схема процесса (артефакт) для описания процесса обработки целевого вызова (структурный блок). Этот артефакт может также описывать другие структурные блоки, такие как участники процесса (например, представитель службы поддержки клиентов).
Ниже представлен пример такого отношения:
Заключение
В рамках данной статьи мы рассмотрели некоторые основные моменты, связанные с использование платформы TOGAF 10 для построения архитектуры предприятия.
Оценка готовности бизнеса к трансформации по TOGAF важна для понимания текущего состояния компании и успешного проведения изменений. Она позволяет выявить слабые места и риски, которые могут помешать трансформации, а также определить необходимые ресурсы и расставить приоритеты. Помогает создать реалистичную дорожную карту, согласованную с целями бизнеса. Про оценку и трансформацию поговорим на бесплатном вебинаре, который пройдёт уже сегодня.
А на странице курса вы можете посмотреть записи предыдущих вебинаров.
