Вадим Алджанов - ИТ-архитектура от А до Я: Теоретические основы. Первое издание

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

• Обоснованность и своевременность изменений – Изменения в информационной системе и приложениях производятся только в соответствии с запросами бизнеса, но в случае появления такой необходимости – в нужное время.

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

• Минимизация разнообразия – Уменьшение числа различных вариантов применяемых платформ, продуктов и версий.

Архитектурная практика представляет из себя практику внедрения архитектурного проекта в организации. Архитектурная практика состоит из четырех ключевых элементов:

•Люди. Они основа любой деятельности в компании. Если люди не знают, не умеют, не используют, не участвуют, не делают, не хотят, то все остальное бесполезно. Забыли про людей – забудьте про результаты.

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

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

• Управление. Без правильного управления архитектурная практика обречена на провал. Требуется заранее определить рамки и правила практики, взяв за основу стандартные процессы, артефакты, роли и т. д. Придумывать правила по ходу игры очень опасно. Люди будут дезориентированы, процессы будут сбоить, результаты будут не те и не тогда, когда нужно.

Рисунок: Управление Архитектурной Практикой «TOGAF»

Процесс управления архитектурной практикой необходим для того, чтобы исключить обычные ошибки, совершаемые людьми в процессе работы над задачей или проектом. Люди чаще всего не достигают результатов, если:

•залезают в дебри теорий и исследований;

•выполняют бесполезную работу;

•долго готовятся к выполнению работы;

•изобретают велосипед;

•«оптимизируют» свою работу вместо её выполнения;

•излишне теоретизируют;

•ищут ответственных и виноватых;

•считают себя самыми умными;

•избегают неприятной работы.

Подход к управлению архитектурной практикой состоит из шести основных элементов:

• Методология — это основной элемент подхода. Он определяет процессы компании для разработки, обновления и реализации Архитектуры Предприятия. Роли и их обязанности.

• Артефакты – набор, шаблоны и правила заполнения документов, таблиц, схем, при помощи которых описана Архитектура Предприятия.

• Стандарты – это стандарты (законы, правила) ведения бизнеса и ИТ, которые использует компания в своей работе. Это могут быть международные стандарты, российские стандарты, стандарты отрасли, региона, компании.

• Лучшие практики и готовые модели – доказанные способы реализации решений, проверенные в вашей или в других компаниях.

• Регламенты и правила – документы, в которых описаны цели, задачи, организационная структура, правила работы и границы архитектурной практики. Правила работы с другими подразделениями. Полномочия архитекторов. Регламенты должны быть интегрированы с другими регламентами компании, особенно ИТ департамента.

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

Порядок внедрения архитектурной практики. Во-первых, разработать все эти элементы для компании с нуля – это неподъемная задача. Поэтому для её решения нужно взять уже созданные методологии и адаптировать их к нуждам компании. Во-вторых, внедряйте их постепенно, как часть развития практики. Внедрение каждого элемента должно давать ценность практике. В-третьих, соблюдайте баланс между бюрократией и личной инициативой. И последнее – экспериментируйте. Проверяйте новые подходы. Если они дают ценность, опишите их в регламенте и используйте в ваших следующих проектах.

Для внедрения методологии TOGAF возникает вопрос какой минимальный набор документов необходим для ведения архитектурного проекта? Лишние документы – лишние затраты времени и денег. По исходя из собственного опыта и теории (при подготовке к сертификации), минимальный «джентельменский набор» может состоять из восьми документов:

• Основы методологии (Templates, Business Principles, Goals, Drivers). Необходим для понимания миссию, цели, стратегию компании. Зафиксировать бизнес принципы. Шаблон «TOGAF 9 Templates, Business Principles, Goals, Drivers.doc»

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

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

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