Описание и оценка архитектуры организации

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

Таблица 3.2

Состав архитектурного описания

N9

п/п

Раздел

Содержание раздела

1

Резюме

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

2

Организация

проекта

Цели и задачи проекта, участники разработки, состав и содержание проектных работ, выбранная методология и средства описания архитектуры

3

Функциональные

требования

Функциональные спецификации и интерпретирующая их информация (каждое требование должно быть конкретным, измеримым и принципиально выполнимым)

4

Связь

функционального и технологического контекстов

Список функций (сервисов)корпоративной информационной системы и матрица соответствия между функциональными требованиями и ИТ-сервисами

5

Существующее

состояние

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

6

Целевое

состояние

Описание предполагаемого результата и вариантов реализации основных бизнес-процессов в стратегической перспективе (видение будущего организации)

7

Концептуальная

архитектура

Архитектурные требования и принципы с обоснованием важности каждого из них и прогнозированием следствий его соблюдения (формируется матрица корреляции между принципами и функциональными требованиями, которая позволяет оценить относительную важность принципов)

8

Основные домены архитектуры

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

9

Анализ

расхождений

Заключение о необходимости развития (сохранения, замены или модификации) отдельных компонент архитектуры организации (делается на основании сравнения существующего и целевого состояний доменов с учетом отраслевых тенденций)

Окончание табл. 3.2

п/п

Раздел

Содержание раздела

10

Структурные преобразования

Заключение о необходимости изменений в организационной структуре, полномочиях, ответственности, поощрениях и наказаниях

11

Планирование преобразований

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

12

Управление архитектурным процессом

Специализированные структуры, регламенты и документальное сопровождение управления архитектурным процессом

13

Приложения

Приводятся разработанные документы, архитектурные модели, схемы организации процессов поддержки жизненного цикла архитектуры, технико-экономические обоснования, описание перспективных технологий и другие моменты, не нашедшие отражения в основной части архитектурного описания

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

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

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

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

Как всякий проект, разработка и внедрение архитектуры организации всегда предполагают оценку уровня полученного результата. Для этого рекомендуется использовать шкалу (табл. 3.3), с помощью которой текущее архитектурное описание организации относят к одному из пяти уровней зрелости. Вообще-то концепция зрелости {Capability Maturity Model — СММ) нашла широкое распространение в измерениях качественных процессов. В приложении 7 приведена таблица с расшифровкой критериев, которым должна удовлетворять архитектура организации на различных уровнях своего развития.

Таблица 3.3

Характеристики уровней организационной зрелости

п/п

Уровень

Основные характеристики

1

Начальный

Характеризуется спонтанностью информационных связей, хаотичностью и непоследовательностью отношений

2

Повторяемый

Предполагает выделение базовых процессов и повторяемых операций

3

Определенный

Характеризуется стандартизацией процессов и наличием интеграционных процедур

4

Управляемый

Предполагает контроль качества и использование обратных связей для выработки управленческих решений

5

Оптимизированный

Предполагает постоянное развитие, самоадаптацию и самообучение организации

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

 
Посмотреть оригинал
< Пред   СОДЕРЖАНИЕ   ОРИГИНАЛ     След >