В предыдущем посте мы начали знакомить вас с TOGAF. Теперь попробуем ответить на вопрос, вынесенный в заголовок. Если вы зайдете на сайт Открытой Группы (The Open Group), вы увидите, что там TOGAF называется стандартом Открытой Группы. Также об этом упоминается в следующем сообщении «Стандарт Архитектуры Организации используется ведущими организациями в мире для повышения эффективности бизнеса».
Но недавно один из наших клиентов спросил: «Что же это значит?» Очевидно, что признание TOGAF в качестве стандарта – это лишь один из способов, позволяющий проводить границу между TOGAF и любыми другими архитектурными фреймворками и методологиями. Но справедливо ли называть его «стандартом»? Или это всего лишь пример бессмысленной дифференциации на основе несущественных атрибутов?
Вот объяснение, которое мы дали нашему клиенту.
Во-первых, «производство стандартов» - одно из ключевых предназначений Открытой Группы. У них на сайте есть такое объяснение:
«Открытая Группа взаимодействует с клиентами и поставщиками ИТ-продуктов и услуг, с консорциумами и другими организациями, разрабатывающими стандарты, в целях сбора, уточнения и интеграции текущих и новых потребностей, установления стандартов и политик, а также для обмена передовым опытом. Наши стандарты обеспечивают открытость, совместимость и согласованность».
И, пожалуй, хорошо, что есть такие организации, как Открытая Группа, которые выполняют эту роль. Открытая Группа выступает в качестве катализатора усилий многих организаций-членов в вопросах создания полезной документации и руководств.
TOGAF является прекрасным примером результатов такой работы – это существенный объем знаний, и вполне разумно, что проведена работа по документированию того, что архитекторы организаций делают и как они это делают.
С другой стороны, слово «стандарт» подразумевает определенный уровень признания и соответствия, и можно утверждать, что это не то, что вы получаете от TOGAF. Например, стандарт бытового напряжения для электроэнергии в России составляет 220 вольт, а в США стандарт 120 вольт. Соответственно стандарт становится стандартом там, где он принимается в качестве стандарта. Я знаю некоторые организации, которые применяют методологию TOGAF, потому что это дает им основу для собственной архитектурной практики, а также потому, что TOGAF помогает обеспечивать последовательность при построении их учебных программ по корпоративной архитектуре. Но эти организации не расценивают TOGAF как «стандарт». Кроме того, эти организации обычно адаптируют методологию TOGAF для удовлетворения своих потребностей и дополняют ее материалами из дополнительных источников.
Так как же это поможет нам? Является ли TOGAF стандартом или нет?
Чтобы ответить на этот этот вопрос, я предлагаю посмотреть на некоторые из плюсов и минусов в признании понятия «стандарт».
Из положительных моментов можно выделить, что стандарт – это:
Все эти заключения очень достойны – и TOGAF обеспечивает все эти преимущества стандарта.
С отрицательной стороны стандарт может быть (и заметьте, я поставил все эти заключения в условное наклонение, поскольку эти ограничения могут применяться не для каждого случая):
Я уверен, что не описал здесь все плюсы и минусы. Но главная мысль заключается в том, что TOGAF, как и любой стандарт, имеет как преимущества, так и недостатки. Стандарт – это не жесткое правило, которое необходимо принимать и соблюдать. Возвращаясь к примеру с напряжением, мне, возможно, потребуется другая техника для работы при другом напряжении, а не другой стандарт, а также я могу использовать адаптер, чтобы подстроиться под принятый стандарт.
И конечно же, в TOGAF снова и снова повторяется сообщение – вы всегда должны адаптировать и настроить его для удовлетворения ваших конкретных потребностей!
Так что да – TOGAF можно считать стандартом. Но не ожидайте, что это означает, что TOGAF является фиксированным, жестким, неизменным, полным или универсальным.
Однако, если вы возьмете только строительные блоки (building blocks) и их интерфейсы из TOGAF, то вам будет сложно создать или настроить любую целевую архитектуру. Например, вы можете использовать какой-либо строительный блок, но не учтете предложенный интерфейс для ключевого элемента данных, и тогда такая выкладка станет бессмысленной.
Поэтому, если Вы не в состоянии описать различные архитектуры (текущую, промежуточную или целевую) в виде шаблона, то кому-либо еще сложнее понять состав и конфигурацию такой архитектуры. Вы сможете просто создавать прекрасные разноцветные графики, которые выглядят отлично, но без ссылки на базовый шаблон или стандарт.
