Ключевых документов TOGAF

Какой минимальный набор документов для архитектурного проекта? Думаю, вы уже поняли важность этого вопроса. Лишние документы

– лишние затраты времени и денег. По опыту компании Orbus Software, для архитектурного проекта минимальный джентельменский набор должен состоять из 8 документов:

1. Business Principles, Goals, Drivers. Для команды архитектурного проекта важно погрузиться в контекст бизнеса компании. Вам нужно понимать миссию, цели, стратегию компании. Зафиксировать бизнес‐принципы. Шаблон называется «TOGAF 9 Template ‐ Business Principles ‐ Goals ‐ Drivers.doc»

2. Architecture Principles. Архитектурные принципы – это правила, которыми руководствуются в работе над архитектурой. На их основе принимают архитектурные решения. Принципы нужно сформулировать на основе примеров из TOGAF. Использование принципов при работе над архитектурой доказало свою эффективность. Шаблон –

«TOGAF 9 Template ‐ Architecture Principles.doc»

3. Architecture Vision. По определению, видение архитектуры

– это высокоуровневое описание желательного конечного продукта архитектурного проекта. То есть это те результаты, которых нужно достичь. Описание решения тех проблем и задач, ради которых стартуют проект. Этот документ важен для взаимодействия со спонсором проекта и другими заинтересованными лицами. Шаблон – «TOGAF 9 Template ‐ Architecture Vision.doc»

4. Statement of Architecture Work. Устав проекта. То есть соглашение между спонсором и проектной командой о выполнении работ. В него включают все рамки, ограничения, предположения, сроки, бюджет, правила проекта. В нем конкретно назначают менеджера проекта и

 

прописывают его права и обязанности. Сюда же включают как приложение видение архитектуры как описание рамок проекта. Шаблон – «TOGAF 9 Template ‐ Statement of Architecture Work.doc»

5. Architecture Definition. Описание архитектуры. Это представление текущей и целевой архитектуры. Он охватывает каждый из архитектурных доменов (бизнес, данные, приложения, технологии). А также анализ расхождений между текущим и будущим состоянием. Шаблон – «TOGAF 9 Template ‐ Architecture Definition.doc»

6. Architecture Requirements Specification. Спецификация требований к архитектуре. Документ, в котором собраны все требования, ограничения, предположения, критерии достижения. Шаблон – «TOGAF 9 Template ‐ Architecture Requirements Specification.doc»

7. Transition Architecture. Переходная архитектура. Реализация целевой архитектуры проходит в несколько этапов. Каждое промежуточное состояние должно быть работоспособно и давать компании бОльшую ценность. В этом документе сгруппированы проекты по каждому из таких этапов. Шаблон – «TOGAF 9 Template ‐ Transition Architecture.doc»

8. Implementation and Migration Plan. План реализации и миграции. Это сводный план реализации проектов, направленных на достижение целевой архитектуры. В него также включают выгоды, рамки, сроки, стоимость, риски, контрольные точки проектов. Шаблон – «TOGAF 9 Template ‐ Implementation and Migration Plan.doc»

Такой набор документов можно сделать максимально быстро и без больших затрат. Но рекомендую включить в ваш набор ещё один документ – архитектурный контракт. Это соглашение между архитекторами и исполнителями ИТ‐проекта. Шаблон – «TOGAF 9 Template – Architecture Contract.doc» При приемке проекта вам будет легче получить нужный результат, если вы о нем заранее договорились.

И напоследок, рекомендации по разработке описания Архитектуры Предприятия:

1. Краткость – сестра таланта. Не стоит писать документы ради документов. Каждое предложение, схема и таблица должны иметь цель. Не создавайте сущностей сверх меры.

2. Как сказал Джон Захман: «Лучше схема, чем текст».

3. Используйте существующие модели, лучшие практики, стандарты и т.д.

 

Как выбрать инструменты для разработки Архитектуры Предприятия?

Для разработки Архитектуры Предприятия на рынке представлены десятки инструментов. От бесплатных до дорогих. Внедрение некоторых из них может стоить сотни тысяч долларов. Но в этой главе расскажем про бесплатные и дешевые способы по трем важным причинам:

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

2. На начальном этапе лучше использовать простые и знакомые инструменты, они не требуют дополнительного внедрения и обучения. Скорость внедрения определяет успех.

3. Вам нужно наработать опыт, получить первые результаты, чтобы дать адекватные требования для настройки дорогой системы.

Какие минимальные требования к инструментам? Что они должны помогать вам делать?

1. Писать и редактировать тексты, составлять схемы, вести таблицы, делать презентации и т.д.

2. Размещать их на общедоступном ресурсе, регулировать права доступа к информации, обсуждать эти материалы.

Итак, два метода реализации эти требований для TOGAF.