Модель архитектуры предприятия TOGAF была разработана много лет назад и в определенной степени стала стандартом, описывающим различные варианты создания архитектуры. Но помимо сторонников TOGAF у нее есть также и свои противники и в этой статье мы попробуем рассмотреть и ответить на некоторые доводы, которые они приводят.
Но для начала я напомню суть модели архитектуры TOGAF.
Архитектура TOGAF
Платформа TOGAF (The Open Group Architecture Framework) является широко распространенным решением для построения корпоративной архитектуры, которая предоставляет общий язык, методологию и инструменты для проектирования, планирования и внедрения ИТ‑инфраструктуры организации. Одним из ключевых компонентов TOGAF является метод разработки архитектуры (ADM), который описывает пошаговый процесс создания архитектуры предприятия и управления ею. В рамках ADM существуют различные методы, которые могут быть использованы для разработки архитектуры организации. В рамках данной статьи мы рассмотрим некоторые из них.
Стандарт TOGAF является основой для корпоративной архитектуры. Он может свободно использоваться любой организацией, желающей разработать корпоративную архитектуру для внутреннего использования. В свою очередь цель корпоративной архитектуры — оптимизировать в масштабах всего предприятия часто фрагментированные унаследованные процессы (как ручные, так и автоматизированные) в интегрированную среду, которая реагирует на изменения и поддерживает реализацию бизнес‑стратегии.
Стандартом TOGAF поддерживаются различные виды архитектур проектов. Прежде всего это бизнес‑архитектура (Business Architecture), которая определяет бизнес‑стратегию, управление, организацию и ключевые бизнес‑процессы используемые в организации.
Также TOGAF может использоваться для описания структуры логических и физических ресурсов организации, а также ресурсов управления данными (Data Architecture).
Архитектура приложения (Application Architecture) обеспечивает схему развертывания отдельных приложений, их взаимодействия и взаимосвязи с основными бизнес‑процессами организации и также является подмножеством TOGAF.
И наконец, подмножество технологическая архитектура (Technology Architecture) описывает цифровую архитектуру и логические возможности программной и аппаратной инфраструктуры, а также стандарты, необходимые для поддержки развертывания бизнес‑служб, служб передачи данных и приложений. Данный раздел включает в себя цифровые сервисы, Интернет вещей (IoT), инфраструктуру социальных сетей, облачные сервисы, ИТ‑инфраструктуру, промежуточное программное обеспечение, сети, коммуникации, обработку данных, стандарты и т. д.
С основными принципами архитектуры TOGAF мы разобрались и теперь самое время перейти к критике этой методологии.
TOGAF это про маркетинг
Обвинение в том что та или иная методология, технология, фреймворк или приложение это больше про маркетинг и выкачивание денег, чем про конкретную пользу можно услышать в адрес множества различных решений от TOGAF и ITIL до операционных систем и аппаратных решений.
Применительно к TOGAF можно встретить следующие критические доводы:
Он широко известен, и все используют случайные ссылки на него.
Он неприемлем и бесполезен при беседе с людьми.
Для разговора и эффективного общения людям нужен общий словарь.
Стандарт, занимающий сотни страниц, не является подходящим набором инструментов для технического общения
TOGAF отдаляет архитекторов от кода и проектирования
Единственная цель TOGAF это генерировать денежный поток для The Open Group посредством сертификации
Подобные критические отзывы на практическое использование TOGAF мне удалось найти на тематических ресурсах. Давайте постараемся ответить на каждый из них.
Известность и бесполезность TOGAF
Итак, TOGAF широко известен, но при этом многие используют случайные ссылки на эту методологию. Здесь критики говорят о том, что с одной стороны фреймворк вроде бы как хорошо известен в среде специалистов, но с другой многие не слишком хорошо знают TOGAF и применяют или как минимум цитируют его без должного понимания.
Здесь возможно проблема кроется не столько в самой методологии TOGAF столько в том, насколько хорошо люди ее знают и применяют. Как уже упоминалось выше, методология состоит из отдельных слоев, которые относятся к бизнес архитектуре, архитектуре приложений и техники. Соответственно, грамотное применение нужных разделов к соответствующим задачам позволит сделать архитектуру эффективной. Например, использование Business Layer без грамотного применения Technology Layer вряд ли будет действительно эффективным.
Часто TOGAF обвиняют в том, что любой архитектор может нарисовать «коробки» которые делают что‑то что нужно. Но при этом архитектор не может подробно разрисовать содержимое этих коробок. Другими словами он недостаточно компетентен в том, что проектирует.
Здесь вопрос скорее к компетенции архитекторов, разрабатывающих решение, которые читали TOGAF по той диагонали, которая позволяет спроектировать «коробки» но при этом не знают, что должно быть в этих коробках.
Трудности перевода
TOGAF бесполезен при работе с заказчиками, потому что он оперирует множеством терминов, без которых его использовать невозможно. Этот довод на самом деле немного странный. Удобно говорить с заказчиком на одном языке, поэтому на самом деле если мы понимаем под одним и тем же термином одно и то же содержимое, то разговор пойдет гораздо легче.
Так, общее понимание таких терминов как ключевые бизнес процессы и бизнес цели поможет исполнителю и заказчику быстрее договориться о том, каких целей они хотят добиться в результате выполнения проекта.
Да, если представители заказчика совершенно незнакомы с терминологией TOGAF, то тут могут возникнуть некоторые сложности и действительно некоторые определения придется доносить до заказчика что называется вручную.
Однако, в целом наличие готовой терминологии это однозначно хорошо и это скорее достоинство TOGAF чем недостаток.
Многостраничный стандарт
Не все любят читать многостраничные документы, тем более не все любят потом сдавать экзамены по знанию этих документов. Однако, те, кто все‑таки осилили эти мануалы как правило говорят им спасибо за то, чему они научили.
Да, TOGAF не содержит рекомендаций по использованию конкретных продуктов и решений, атак как мир технологий слишком быстро меняется и не одному стандарту за ними не угнаться. Но он позволяет классифицировать и декомпозировать требования бизнеса и на его основе разрабатывать техническую архитектуру.
Зачастую архитекторы лишены возможности участвовать в анализе и обсуждении бизнес‑процессов. В результате плохая бизнес‑практика рискует перейти в плохую технологию, поэтому TOGAF — это целостная структура, которая позволяет работать как с бизнес требованиями, так и с требованиями на уровне приложений и технологий.
Оторванность от техники
Еще один довод, это отдаленность фреймворка от реального проектирования. Здесь основная претензия заключается в том, что по этой методологии архитекторы не должны заниматься инженерными задачами и вопросами разработки, а должны основное время тратить на взаимодействие с заказчиками, анализ бизнес процессов и собственно проектирование. Не всем архитекторам это нравится, но в реальности это действительно так.
Архитектор/ГИП на крупном проекте это уже скорее технический менеджер, чем инженер. Архитектор должен много времени тратить на взаимодействие с заказчиком и выяснение различных бизнес требований. Вопросами внедрения и настройки систем должны заниматься инженеры. Да, многим архитекторам с богатым инженерным бэкграундом это не слишком по душе, но это действительно так, и это не вина TOGAF и суровая реальность.
Если же говорить об оторванности TOGAF от техники, то на самом деле есть ряд решений построенных на основе TOGAF. Достаточно вспомнить язык моделирования ArchiMate, который позволяет отображать архитектуру организации и её компоненты. Вместе с TOGAF ArchiMate помогает создавать наглядные модели, что упрощает коммуникацию между участниками проекта.
Деньги, ничего кроме денег
В излишней коммерциализации объединяют всех от политиков до рок‑музыкантов. И конечно ИТ‑шные сертификации не исключение. За свою карьеру в ИТ я сдавал MCSE, CCNA, CCNP, чуть позже CISSP, сейчас занимаюсь сертификацией по российским Линуксам и везде можно услышать упрек в том, что сертификация это средство выкачивания денег. Но строго говоря, часто сертификаты нужны работодателям для поддержания партнерских отношений и тогда они сами готовы за них платить. Также вас никто не заставляет получать сертификат за свои деньги. Конечно, наличие в резюме заветных аббревиатур является некоторым преимуществом, но в серьезных компаниях на собеседовании все равно проверят ваш уровень знаний и если вы ничего не знаете, то никакая бумажка вас не спасет. Так что винить TOGAF в том он только зарабатывает деньги для The Open Group будет некоторым преувеличением.
Заключение
Давайте подведем итоги тому, о чем мы поговорили в этой статье. TOGAF это целостная система, позволяющая построить архитектуру проекта начиная от бизнес требований и заканчивая техникой. Данный фреймворк дает единую терминологию, позволяющую упростить общение с заказчиком. Благодаря TOGAF архитектор может видеть проект в целом, при необходимости погружаясь в отдельные его части. Ну а сертификация… те, кому она не нужна могут не тратиться на сдачу экзамена, ведь главное это знания а не бумажка.
Заинтересовались архитектурой систем и хотите прокачать свои навыки?
Приглашаем вас на два открытых урока, где разберёмся в современных подходах к системному анализу и архитектуре:
TOGAF: зачем он нужен и как поможет вашей карьере? — 3 июля в 19:00
Lego для корпораций: строим бизнес‑архитектуру с TOGAF — 22 июля в 19:00
А также рекомендуем пройти вступительное тестирование по курсу «Архитектура корпорации. Togaf 10» — это отличная возможность проверить свой уровень знаний для поступления на курс.