Автор статьи: Рустем Галиев

IBM Senior DevOps Engineer & Integration Architect. Официальный DevOps ментор и коуч в IBM

Привет, Хабр! В основном всем понятно, чем занимаются архитекторы решений, архитекторы по интеграции, системные архитекторы, но у многих возникают вопросы по поводу Архитекторов Предприятий, они же Enterprise Architects.

Архитектура предприятия (EA) — это практика проектирования, планирования и управления общей структурой и работой организации. Она связана с согласованием технологий, процессов и людей организации с ее бизнес-целями и стратегией.

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

EA часто используется для того, чтобы:

  • Определять и документировать текущее состояние систем и процессов организации.

  • Определять желаемое будущее состояние и создавать дорожную карту для его достижения.

  • Определять приоритеты областей для улучшения и модернизации.

  • Убедиться, что инвестиции в новые технологии соответствуют бизнес-целям и стратегии.

  • Способствовать общению и сотрудничеству между отделами и уровнями организации.

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

Существует несколько платформ и методологий, которые можно использовать для поддержки EA, в том числе Open Group Architecture Framework (TOGAF), Zachman Framework и Federal Enterprise Architecture Framework (FEAF). Эти рамки содержат общий словарь и набор принципов, которым должны следовать специалисты по АП, и могут помочь организациям обеспечить всеобъемлющий и последовательный характер их усилий по АП.

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

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

Open Group Architecture Framework (TOGAF) — это широко используемая структура корпоративной архитектуры (EA), которая помогает организациям проектировать, планировать и управлять общей структурой и работой своих систем и процессов. Разработанный и поддерживаемый The Open Group, глобальным консорциумом из более чем 600 организаций, TOGAF спроектирован так, чтобы быть независимым от поставщиков и масштабируемым, что делает его подходящим для организаций любого размера и в любой отрасли.

В основе TOGAF лежит метод разработки архитектуры (ADM), систематический подход к разработке и поддержке архитектуры предприятия. ADM состоит из ряда этапов, которые помогают организациям в процессе определения и реализации своего EA. Эти этапы включают:

  • Этап A: Цикл разработки архитектуры. На этой фазе устанавливаются общая структура и цели EA, включая объем и границы архитектуры, заинтересованные стороны и механизмы управления, а также принципы, которыми будет руководствоваться разработка архитектуры.

  • Этап B: Бизнес-архитектура. На этом этапе основное внимание уделяется бизнес-целям и стратегии организации, включая бизнес-факторы, влияющие на архитектуру, бизнес-возможности и процессы, необходимые для поддержки этих целей, а также заинтересованные стороны организации и их потребности.

  • Этап C: Архитектура данных. На этом этапе рассматриваются требования организации к данным и информации, включая структуры данных и модели, необходимые для поддержки бизнес-процессов, источников и приемников данных, а также политик руководства и управления данными.

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

  • Этап E: Технологическая архитектура. На этом этапе рассматривается базовое оборудование, программное обеспечение и инфраструктура, поддерживающие архитектуры приложений и данных, включая аппаратные и программные платформы, сетевую инфраструктуру и инфраструктуру безопасности, а также центры обработки данных и облачную инфраструктуру.

  • Этап F: Возможности и решения. Этот этап включает в себя определение возможностей для улучшения и инноваций в архитектуре, а также разработку решений и дорожных карт для реализации этих возможностей.

  • Этап G: Планирование миграции. На этом этапе основное внимание уделяется планированию и выполнению миграции до желаемого будущего состояния архитектуры, включая идентификацию и управление рисками, зависимостями и заинтересованными сторонами, а также разработку подробного плана миграции.

  • Этап H: Управление реализацией. Эта фаза касается руководства и управления архитектурой во время и после внедрения, включая создание процессов управления, мониторинг и измерение архитектуры, а также текущее обслуживание и развитие архитектуры.

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

Федеральная структура архитектуры предприятия (FEAF) — это структура, используемая федеральным правительством США для разработки и поддержки архитектуры предприятия (EA). Разработанный Управлением управления и бюджета (OMB), FEAF призван помочь агентствам федерального правительства привести свои технологии, процессы и людей в соответствие с их миссией и целями.

FEAF состоит из пяти основных компонентов:

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

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

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

  • Техническая эталонная модель (TRM): это представление базовой технологической инфраструктуры федерального правительства, включая аппаратные и программные платформы, сетевую инфраструктуру и инфраструктуру безопасности, а также центры обработки данных и облачную инфраструктуру.

  • Эталонная модель услуг (SRM): это представление услуг, предоставляемых федеральным правительством, включая функциональные и нефункциональные требования к этим услугам, проектирование и интеграцию этих услуг, а также развертывание и эксплуатацию этих услуг.

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

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

Zachman Framework — это инструмент, используемый для организации и классификации архитектуры предприятия. Это матрица, состоящая из шести строк и столбцов, где каждая ячейка представляет определенный аспект архитектуры. Строки представляют шесть вопросов «wh» (who, what, where, when, why, and how): кто, что, где, когда, почему и как; а столбцы представляют шесть категорий: контекста, мотива, масштаба, перспективы, реализации и эволюции.

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

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

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

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

На самом деле, помимо базовых трех существует много разных подходов. Например, возьмем IBM:

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

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

В дополнение к инфраструктуре RAIE IBM также предлагает ряд других инструментов и ресурсов для архитектуры предприятия, в том числе IBM Rational System Architect, который представляет собой инструмент для проектирования и моделирования сложных систем и процессов, а также IBM Enterprise Architecture Practice, который включает команду экспертов, которые предоставляют консультации и рекомендации по проектам архитектуры предприятия.

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

Теперь, думаю, у многих отпали вопросы по поводу роли Архитектора Предприятия (Enterprise Architect).

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

  • Рассмотрят определение бизнес-архитектуры как метод структурного управления инвестициями.

  • Изучат общие принципы декомпозиции архитектуры предприятия, определение доменов и «строительных» блоков (ABB, SBB).

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

Регистрация на урок открыта по ссылке.

Комментарии (3)


  1. bipiem
    11.01.2023 18:57
    +3

    Регистрация на урок открыта

    EA в своем репертуаре: только обучение чему-то, но ни одного примера результата. Про это много говорилось в Enterprise Architecture vs алхимия предприятия. Ключевые мифы:

    Напоминаю, что главная проблема Enterprise Architecture (ЕА) – это отсутствие конкретных примеров этой самой ЕА в открытом доступе. Алхимики их хранят «как зеницу ока», видимо потому, что если их публиковать, то откроется страшный секрет «платья короля» и все скажут: А король то голый!

    Даже единственный пример (аж самого PwC), и тот "похоронен" (ищи его только в web архиве):

    https://habr.com/ru/post/345424/#comment_10616896

    Нет ни одного полноценного реального примера этого мифа ЕА, но проповедников и учителей (и "умных книжек", включая ТОГАФ) - много. Как так? Бред-оправдание про "раскрытие конкурентных преимуществ" - давно устарел. Скрывают совсем иное.


  1. AlexGorky
    12.01.2023 09:28

    Enterprise Architect - очень мощная программа, но у неё совсем нет бесплатной версии (trial не считается).

    Мы в команде используем Visual Paradigm Community Edition. Рекомендую.


    1. itGuevara
      12.01.2023 11:45

      Enterprise Architect - очень мощная программа

      В статье под этим понимают роль, а не ПО.

      Теперь, думаю, у многих отпали вопросы по поводу роли Архитектора Предприятия (Enterprise Architect).

      Очень оптимистично и самонадеянно.