Творческий характер архитектурного процесса

Итак, для описания архитектур существует множество различных методик и вариантов, отличающихся группировкой рассматриваемых понятий. Для упорядочения выполняемых работ предложены специальные методы – например, описанный выше TOGAF ADM. Казалось бы, что разработка архитектуры в этих условиях будет являться достаточно простым, повторяемым и рутинным процессом. На самом деле, в этих рассуждениях опущено одно очень важное звено: организации и их системы уникальны, и процесс проектирования архитектуры по необходимости должен являться творческим. Реально каждый новый проект представляет собой (в идеале) достижение компромисса между применением стандартных шаблонов и учетом специфических особенностей. Этот процесс формализуется труднее всего. Но здесь есть и положительная сторона – многие творческие приемы, которые были разработаны и успешно применены в смежных дисциплинах, таких как системное проектирование или разработка программного обеспечения, могут быть применены и для развития архитектуры предприятия в целом и, в частности, ИТ-архитектуры.

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

В условиях быстро изменяющейся внешней среды изменяются и сами методы разработки: все большее значение приобретают гибкие, динамичные (agile) подходы, вплоть до методов так называемого " экстремального (XP) программирования".

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

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

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

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

Несмотря на, казалось бы, увеличение числа анализируемых объектов, такой подход при определенных условиях позволяет ускорить решение задачи. Это достигается, прежде всего, за счет выделения отдельных компонентили интерфейсов, которые либо более просты для понимания, либо для их реализации могут быть применены уже известные решения (прототипы, шаблоны или паттерны); или же задача может быть распараллелена для анализа несколькими членами команды.

Рис. 11.5. Пример количественной параметризации

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

Например, при реализации системы управления документами одними из важнейших параметров будут являться число пользователей и число документов. Соответствующая диаграмма показывает в этих координатах характерные области для таких различных систем, как промышленные электронные архивы (пример – DB2 Content Manager от IBM), системы управления документами Documentum (EMC), Дело (ЭОС) или БОСС-Референт (АйТи), настольные приложения или поисковые системы Интернет.

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

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

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

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

Интересным " нестандартным" примером из практики авторов явилось проведение динамического моделирования архитектуры комплексной информационной системы Госкомстата России (ныне Федеральная служба государственной статистики) с использованием универсальных средств моделирования Rethink и среды выполнения G2 компании Gensys. Данная информационная система строится по трехуровневому принципу и включает центральный узел, территориальные центры и районные (городские) отделения. Задачей системы является сбор и обработка большого количества информации по более чем 500 задачам статистического наблюдения от нескольких миллионов предприятий и выбранных для мониторинга домохозяйств. Задачей моделирования являлся выбор оптимального (с точки зрения соблюдения заданных сроков обработки при общей минимальной стоимости системы) числа и мест размещения территориальных центров обработки данных в стране, а также конфигурации вычислительных средств в этих центрах, с учетом существенно неравномерного распределения субъектов наблюдения по регионам, сезонных колебаний объемов обрабатываемой информации, наличия каналов связи. Исходная задача имела около 107 параметров, которые после ряда упрощений были сведены примерно к 102 параметрам, однако и в такой постановке задача не поддавалась аналитическому решению. Для решения упрощенной задачи выбора оптимальной конфигурации была создана модель в среде G2/Rethink, которая позволила получить оценки для наиболее важных метрик, характеризующих параметры работы системы в условиях заданной нагрузки и с учетом влияния дополнительных случайных факторов.