Читая TOGAF Standard (10th Edition), TOGAF Fundamental Content – Architecture Development Method (ADM) решил сделать краткий конспект прочитанного для памяти и последующей адаптации и применения. Начну с TOGAF ADM Introduction (Введение) и далее по всем фазам ADM.
ADM, Enterprise Continuum, Architecture Repository
Циклы ADM (ядра TOGAF Standard, обобщенного метода разработки и управления жизненным циклом Enterprise Architecture) постоянно наполняют Architecture Repository архитектурными описаниями, моделями и паттернами (повторяющимися шаблонами, стереотипами), создавая непрерывный Enterprise Continuum (каркас и контекст в котором живет архитектура). Основная задача первоначально наполнить (ссылочными архитектурами, моделями и шаблонами) и поддерживать этот репозиторий (отдельный процесс в рамках управления IT) наполняя его от цикла к циклу (от снимка решения к последующему снимку решения) все более совершенными артефактами (в общем смысле building blocks), пригодными для повторного (в том числе более широкого) использования.
Данные циклы не только улучшают архитектурные описания, модели и шаблоны с точки зрения реализации конкретной корпоративной архитектуры, но и способны улучшить Foundation Architecture, то есть наиболее общее описание архитектуры (общие модели, определения политик и управления, выбор технологий), которое потом можно использовать для более осмысленного первоначального выбора для целей Enterprise Architecture. Также важно помнить про руководства, шаблоны, контрольные списки.
Цикл разработки архитектуры
ADM является итеративным, на протяжении всего процесса, между фазами и внутри фаз. Каждый раз нужно определять: охват, детализацию, продолжительность, используемые артефакты (внутренние с предыдущих циклов и внешние, например, отраслевые) в зависимости от ресурсов и получаемом value от обновленной архитектуры. ADM можно применять в сочетании с другими framework. Итерации ADM будут основываться на артефактах и возможностях, созданных во время предыдущих итераций. Необходимо документировать все модели на предприятии до уровня детализации, соответствующего потребностям текущего цикла ADM.
На протяжении всего ADM цикла необходимо проводить частую логическую проверку результатов на соответствие первоначальным ожиданиям как для всего ADM цикла, так и для конкретной фазы процесса.
Requirements Management есть всегда, это процесс, который постоянно заполняет Requirements Repository.
Адаптация ADM
ADM должен быть адаптирован к предприятию и встроен в модель корпоративного управления. При этом адаптация заключается не в принятии общих принципов через документ в компании, в то время как детали остаются “как в TOGAF”, а в адаптации всех элементов framework, даже самых детальных (в том числе через их исключение). Причинами адаптации могут быть: использование субподряда, централизация или децентрализация системного ландшафта и архитектуры.
В ADM может меняться порядок фаз, если это обусловлено спецификой процессов принятия решений на предприятии (уровнем зрелости). Например, Information Systems Architecture может предшествовать Business Architecture если необходимо поменять бизнес-процессы при roll-out проекте или Architecture Vision может быть после Business Architecture для дополнительных бизнес-обоснований. В зависимости от специфики предприятия можно выделить следующие подходы к ADM: планирование и развитие сверху вниз (проектирование всего взаимосвязанного мета-предприятия как единого объекта), шаблон (отдельные предприятия затем адаптируют его для того, чтобы вырабатывать архитектуру «инстанции», подходящую для конкретного соответствующего предприятия), пилот (разработка конкретной архитектуры для одного предприятия, ее внедрение в качестве подтверждения концепции, а затем использование в качестве «эталонной архитектуры» для клонирования на других предприятиях), разработка архитектуры линейки продуктов (адаптация ADM от ориентации на предприятия-пользователи ИТ к ориентации на предприятия-поставщики ИТ, продукция которых основана на ИТ). ADM можно адаптировать для поддержки стиля Agile Enterprise Architecture, а также для обеспечения гибкости предприятия.
Управление архитектурой
ADM, адаптированный организацией, ключевой процесс, который должен управляться таким же образом, как и другие артефакты архитектуры, классифицированные через Enterprise Continuum и хранящиеся в Architecture Repository.
Администрирование архитектурных артефактов, управление архитектурой и связанные процессы должны поддерживаться контролируемой средой (репозиторием с версионностью, процессами контроля и статусами).
Репозиторий управления должен иметь следующие области: ссылочные данные (внешние, например, COBIT, IT4IT Reference Architecture и внутренние руководства и инструкции, используемые во время внедрения проекта, а также описание самих процедур управления), статус процесса (вся информация о состоянии любых процессов управления для принятия управленческих решений), аудит процесса (все завершенные мероприятия процесса управления для последующей поддержки, включая ключевые решения и ответственных за них и ссылки на будущие разработки архитектурных и вспомогательных процессов, руководства и приоритеты).
Артефакты управления архитектурой и процесс сами по себе являются частью содержания Architecture Repository.
Необходим процесс контроля и управления изменениями артефактов как внутри цикла, так и между циклами. Изменения должны показать процесс перехода от базовой к целевой архитектуре.
Определение области применения архитектуры
Измерения для определения объема архитектурной проработки: ширина, глубина, период времени, архитектурные домены (бизнес, данные, приложение, технология)
Ширина
Для крупных предприятий возможна объединенная архитектура – независимо разработанные, поддерживаемые и управляемые архитектуры, которые впоследствии интегрируются в интеграционную структуру. Такая структура определяет принципы совместимости, миграции и соответствия. Это позволяет специфике бизнес-модулей разрабатывать архитектуры и управлять ими как автономными архитектурными проектами. То есть существует ряд различных Enterprise Architectures, которые ориентированы на конкретные временные рамки, бизнес-сегменты или функции и специфичные организационные требования.
Модель “публикации и подписки”
Эффективным способом управления этими Enterprise Architectures и их использованием является внедрение модели “публикации и подписки”, позволяющей встроить архитектуру в каркас управления. В такой модели разработчики архитектуры и потребители архитектуры в проектах (стороны спроса и предложения архитектурной работы) подписываются на взаимовыгодную систему управления, которая обеспечивает: качественный архитектурный материал, актуальный, пригодный для использования и публикации, и использование архитектурного материала может контролироваться, а соответствие стандартам, моделям и принципам может быть продемонстрировано. Для этого используется: процесс оценки соответствия требованиям, который описывает, на что подписывается потребитель и оценивает уровень соответствия требованиям, и процесса выдачи разрешений, который может предоставить освобождение от соблюдения архитектурных стандартов и руководящих принципов в конкретных случаях.
Глубина
Глубина проработки (уровни детализации) архитектуры доменов должны соответствовать друг другу (одинаковый уровень детализации), чтобы избежать перекосов (пропусков или загроможденности). Существует опасность сверх оптимизации со стороны архитекторов доменов в пределах их собственной сферы деятельности, а не на уровне всего предприятия. Целью всегда должно быть стремление к наивысшему уровню общности и сосредоточение внимания на масштабируемых и повторно используемых модулях, чтобы максимально увеличить повторное использование на уровне предприятия. Архитектура должна быть структурирована таким образом, чтобы приспособиться к будущей адаптации, расширению или повторному использованию. Глубина и детализация Enterprise Architecture должны быть достаточными для ее цели, и не более.
Этапность
ADM описывается в виде единого цикла Architecture Vision и набора Target Architecture (бизнес, данные, приложения, технологии), которые обеспечивают внедрение концепции. При этом предприятие может быть представлено несколькими различными экземплярами архитектуры, каждая из которых представляет предприятие в конкретный момент времени. Один экземпляр архитектуры будет представлять текущее состояние предприятия («как есть» или базовый уровень). Другой экземпляр архитектуры, возможно, определенной только частично, будет представлять конечное целевое состояние («видение»). Между ними могут быть определены промежуточные экземпляры или Transition Architecture, каждая из которых содержит свой собственный набор Target Architecture Descriptions.
Target Architecture
В этом случае необходимо разработать Target Architecture Descriptions для общей (крупномасштабной) системы, демонстрирующий реакцию на цели и проблемы заинтересованных сторон в течение относительно отдаленного периода времени. Затем разработать одно или несколько описаний Transition Architecture в виде приращений, каждое из которых соответствует Target Architecture Descriptions и сходится на нем, а также описывает специфические особенности соответствующего приращения.
В таком подходе Target Architectures (воплощают только ключевые стратегические архитектурные решения, остаются относительно универсальными и поэтому менее уязвимы к устареванию) носят эволюционный характер и требуют периодического пересмотра и обновления в соответствии с меняющимися бизнес-требованиями и разработками в области технологий.
Transition Architecture
Transition Architectures имеют (по замыслу) инкрементный характер и в принципе не должны эволюционировать (конечная цель не должна меняться при внедрении) на фазе внедрения приращения, чтобы избежать синдрома «движущейся цели». Это возможно только в том случае, если график внедрения находится под жестким контролем и относительно короткий.
Кроме того, подробные архитектурные решения намеренно откладываются, насколько это возможно (т.е. непосредственно перед внедрением), чтобы улучшить реакцию на новые технологии и продукты.
Домены архитектуры
Полная Enterprise Architecture должна охватывать все четыре области архитектуры (бизнес, данные, приложения, технологии). Architecture Description тоже охватывает четыре области архитектуры и строиться с учетом конкретной цели – конкретного набора бизнес-драйверов, которые управляют развитием архитектуры. Разъяснение конкретной проблемы (проблем), которую Architecture Description призвано помочь изучить, и вопросов, на которые оно, как ожидается, поможет ответить, является важной частью начальной фазы ADM.
Альтернативные целевые архитектуры
Существует несколько возможных целевых архитектур, которые соответствовали бы Architecture Vision, принципам архитектуры и требованиям. Необходимо определить альтернативные целевые архитектуры и сформировать понимание различных возможностей и определить компромиссы между альтернативными архитектурами. Создание архитектуры обычно требует компромиссов между конкурирующими силами, так как, как правило, не существует единой альтернативы, которая отвечала бы проблемам всех заинтересованных сторон. Представление различных альтернатив и компромиссов заинтересованным сторонам помогает архитекторам извлекать скрытые “повестки дня”, принципы и требования, которые могут повлиять на окончательную целевую архитектуру.
TOGAF обеспечивает технику, чтобы исследовать различные альтернативы и обсудить их с заинтересованными сторонами. Альтернативы определяются для каждого домена, что упрощает анализ различных альтернатив. Далее альтернативы для каждой области объединяются при общем анализе альтернатив для всей архитектуры. Первый шаг использует видение, принципы, требования и другую информацию для выбора наборов критериев, подходящих для различных альтернатив. Второй шаг определяет альтернативы на основе критериев и строит понимание каждого из них. Третий шаг либо выберет одну из альтернатив, либо объединит элементы из нескольких, чтобы создать предложенную альтернативу.
Резюме
В TOGAF ADM определяется рекомендуемая последовательность для различных фаз и этапов разработки архитектуры, но он не может рекомендовать охват – это должно определяться самой организацией, учитывая, что рекомендуемая последовательность развития в процессе ADM является итеративной, с увеличением глубины и ширины охвата и поставляемых результатов с каждой итерацией. Каждая итерация добавит ресурсы в Architecture Repository организации.
Хотя в качестве конечной долгосрочной цели полезно (по сути, существенно важно) иметь в виду полный framework, на практике необходимо принять ключевое решение относительно масштабов конкретных Enterprise Architecture усилий. В данном случае крайне важно понять, на какой основе принимаются решения об определении сферы охвата, и установить четкие ожидания в отношении цели этих усилий.
Основная рекомендация состоит в том, чтобы сосредоточиться на том, что создает ценность для предприятия, и соответственно выбрать горизонтальный и вертикальный объем и временные периоды (этапность). Независимо от того, происходит ли это впервые или нет, это упражнение будет повторено, и будущие итерации будут основываться на том, что создается в текущем усилии, добавляя большую ширину и глубину.