Фаза A: Архитектурное видение

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

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

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

Характер проекта

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

Стандарт TOGAF не предоставляет четкого определения "проекта", аналогичного определению "предприятия". Тем не менее, он отмечает тенденцию к тому, что крупномасштабные архитектурные разработки принимают форму объединенных архитектур. Эти объединенные архитектуры представляют собой независимо разрабатываемые, поддерживаемые и управляемые архитектуры, которые впоследствии интегрируются в метаархитектурную структуру.

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

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

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

Разработка архитектуры проекта начинается с определения бизнес-функций, которые будут реализованы посредством этой архитектуры. На этом этапе важно перечислить ключевые факторы бизнеса, требующие использования MSA, такие как требования к масштабируемости, отказоустойчивости, аварийному переключению и т. д. Важно прояснить роль уровня MSA в общей архитектуре. Какие наименьшие единицы бизнес-функций (ABF) предоставляет этот слой? Рабочая группа MSA понимает, что ABF - это наименьшая единица бизнес-функции внутри предприятия, которая обеспечивает ценность и обычно поддерживает одну бизнес-возможность. Необходимо определить интерфейсы, в которых входные и выходные данные микросервисов обмениваются с другими архитектурными уровнями. Управление и управление изменениями унаследованы от общей архитектуры предприятия.

Эта архитектура уровня проекта будет расширена до Архитектуры решения на более поздних этапах процесса разработки архитектуры. 

Уровень детализации спецификации реализации

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

Определение и планирование проекта решения осуществляются на этапах E (Возможности и решения) и F (Планирование миграции) TOGAF ADM, а группа архитекторов играет надзорную роль на этапе G (Управление внедрением).

Архитектура предприятия применяется к каждому компоненту предприятия и описывает их общие аспекты. Управление, управление изменениями, стандарты и необходимая инфраструктура могут быть определены в архитектуре предприятия и унаследованы всеми проектными архитектурами.

Видение

Архитектурное видение включает в себя описание планируемой окончательной архитектуры на высоком уровне. В рамках MSA, которая является подмножеством SOA, используется специальный язык, включающий термины как "микросервис", "композиция" и "контракт", а также различные модели, например матрицы, для иллюстрации использования сервисов в бизнес-процессах и взаимодействия приложений с сервисами. Онтология микросервисов (https://webprotege.stanford.edu/ - требуется регистрация и вход) может обеспечить таксономическую и онтологическую поддержку на языке архитектуры, основанном на микросервисах. Хотя высокоуровневое описание, созданное на этапе A, может не содержать детальных моделей, разрабатываемых на этапах B, C и D, оно отражает сервис-ориентированную природу задуманной архитектуры.

Заинтересованные стороны, проблемы и требования бизнеса

После завершения этапа А в рамках методологии TOGAF начинаются три последующих этапа, на которых детально описывается архитектура для документирования архитектурных решений. На каждом из этих этапов архитектор:

Этот процесс итеративный и продолжается до тех пор, пока архитектор не убедится, что все проблемы этапа были рассмотрены, а требования выполнены.

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

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