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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Как обеспечить внедрение результатов проекта разработки архитектуры

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

Обеспечение поддержки усилий по разработке архитектуры предприятия предполагает знания того, что действительно важно для людей, которые могут способствовать или "блокировать" процесс принятия соответствующих решений [6.22]. Этих людей можно условно разделить на три группы:

• руководство организации и руководители бизнес-направлений;

• среднее звено управления бизнесом;

• различный технический персонал, а также "продвинутые и влиятельные" пользователи.

В частности, высших руководителей в отношении архитектуры, как правило, интересуют три основные цели: сохранение своей автономии, минимизация затрат на ИТ и отсутствие препятствий со стороны ИТ в плане гибкости или надежности. Для обеспечения поддержки этой категории людей важны такие вещи, как примеры удачного опыта (case studies), сравнение с другими передовыми организациями (benchmarking), улучшение финансовых показателей и продуктивности.

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

Таблица 4. Различия в ожидании преимуществ от архитектуры

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

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

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

Один хороший метод в объяснении важности архитектуры ИТ для бизнес-руководителей и неспециалистов в области ИТ сводится к двум темам [6.23]:

• архитектура и решение сложных проблем;

• влияние архитектуры на затраты.

Естественным ожиданием руководства является то, что ИТ обеспечивают некоторые важные услуги для деятельности организации на должном уровне надежности. Архитектура ИТ, описывающая все области, связанные с ИТ на предприятии, включает несколько уровней, или областей. Каждая новая область вносит новый уровень ненадежности и затраты на ее существование. Реальность состоит в том, что надежность всего комплекса ИТ определяется как произведение надежностей каждого уровня и, соответственно, ненадежность хотя бы одного из них "сводит на нет" усилия по обеспечению надежности всего комплекса ИТ. Поэтому некоторый уровень сложности и связанные с этим затраты при эксплуатации ИТ-инфраструктуры неизбежны.

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

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

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

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

Более подробно эти аспекты рассматриваются в [6.5]. В частности, там выделяются группы внутри ИТ-службы, как показано в табл. 11.5.

Таблица 5.

Приведенные выше рекомендации полезны в том случае, если бизнес-стратегия еще не определена, но руководство организации в принципе понимает перспективы архитектуры предприятия и готово уделить часть времени для обсуждения этих задач. Возникает вопрос: "А что делать в "безвыходных ситуациях", когда предложенные выше подходы обоснования необходимости разработки архитектуры не работают?" Может ли инициативная группа в этих условиях добиться какого-либо прогресса?

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

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

Интернет университет информационных технологий.

http://www.intuit.ru/