Проектирование в облаке: архитектура Software + Services для проектирования занимает ведущие позиции в неспокойные временаВ. Гнанасекаран (V. Gnanasekaran), Март 2010 г. Краткое содержание.В статье описан количественный подход к процессу оценки архитектуры приложения и продемонстрировано, как количественные показатели вместе с наглядными отчетами обеспечивают более ясное представление архитектуры, чем качественная оценка. «Нельзя управлять тем, что невозможно измерить» — Билл Хьюитт ВведениеОценка архитектуры приложения – важный этап любого процесса определения архитектуры. На разных предприятиях значимость этого этапа варьируется в зависимости от многих факторов (например, размер приложения и его важность для бизнеса). В некоторых ИТ-компаниях этот этап является частью формального процесса, в других он выполняется лишь по специальному запросу заинтересованных лиц. В некоторых компаниях имеется «Комиссия по контролю за архитектурой», состоящая из опытных архитекторов, которые периодически проводят оценку архитектуры. Ниже перечислены сценарии процесса оценки архитектуры.
Ключевые цели проведения оценки архитектуры в контексте разработки нового приложения:
Проверка архитектуры также проводится на основании только одного показателя качества ПО, такого как «Производительность» или «Безопасность». Например, чтобы измерить, насколько безопасна архитектура, обладает ли она возможностью поддержки определенного числа транзакций в секунду и можно ли это реализовать. Процесс оценки архитектуры приложения включает первичную проверку по контрольному списку, который предоставляет поставщик платформы. Затем архитекторы проводят презентации, обсуждения и «мозговой штурм». Ключевые аспекты «мозгового штурма» включают обсуждение результатов оценки архитектуры на основе сценариев, которая выполняется согласно таким отраслевым стандартам, как метод анализа компромиссных архитектурных решений (Architecture Trade-Off Analysis Method, ATAM), метод анализа архитектуры ПО (Software Architecture Analysis Method, SAAM) и оценка архитектуры с точки зрения промежуточных решений (Architecture Reviews for Intermediate Designs, ARID). Также существуют и другие методы оценки архитектуры, основанные исключительно на таких факторах, как стоимость, модифицируемость и функциональная совместимость. Контрольный список, предоставляемый поставщиком платформы, гарантирует, что будут применены верные архитектурные шаблоны и соответствующие шаблоны проектирования. По инициативе группы Patterns & Practices корпорации Microsoft предоставляются контрольные списки и анкеты, касающиеся различных комплексных аспектов оценки архитектуры приложений, построенных на основе продуктов и платформ Microsoft. Как правило, результатом процесса оценки является отчет, содержащий характеристические заключения, такие как «В архитектуре слишком много слоев» или «Масштабирование невозможно, так как слои приложения тесно связаны». Если результатами процесса оценки являются не характеристические заключения, а какие-то числовые показатели (например, в медицине результатами анализа крови являются содержание эритроцитов и пр.), то заинтересованным лицам будет проще составить четкое представление о качестве архитектуры. В статье описана платформа, позволяющая применить количественный подход к оценке архитектуры и получить в результате более наглядные количественные результаты. Эти результаты не только укажут на области архитектуры, которые нуждаются в модификации или рефакторинге, но и пригодятся для дальнейших обсуждений и принятия стратегических решений. ПредпосылкиОценка архитектуры приложения аналогична оценке различных архитектурных решений, результаты которых в совокупности и формируют архитектуру приложения. Цели принятия этих решений можно рассматривать с различных точек зрения. Архитектурное решение принимается по одной из причин, перечисленных ниже:
Когда архитектурное решение принимается для достижения бизнес-цели или для применения передового практического метода, оно, возможно, косвенно повлияет на один или более показателей качества обслуживания. В типовых сценариях ключевыми показателями качества обслуживания, которые будут находиться в центре внимания, являются «Масштабируемость», «Безопасность», «Высокая доступность», «Надежность» и «Производительность», также известные под аббревиатурой SHARP (Security, High availability, Reliability and Performance). На ресурсах Microsoft Patterns & Practices, относящихся к архитектуре приложений, находятся контрольные списки и анкеты, включающие эти показатели качества и охватывающие множество подкатегорий. Использование вопросов из этих контрольных списков и анкет облегчает процесс оценивания. Поскольку эти вопросы являются результатом коллективного опыта экспертов Microsoft, оценка архитектуры на основе этих вопросов, несомненно, гарантирует, что архитектура приложения будет основываться на проверенных передовых практических методах, а также принципах и стандартах архитектуры и проектирования. Эти контрольные списки и анкеты облегчают нам жизнь, но архитекторам нужно прилагать усилия, чтобы использовать их в ходе оценки архитектуры приложения. Анкеты и контрольные списки необходимо распечатывать и на их основе проводить опросы архитекторов соответствующих приложений. Затем требуется вручную проводить анализ и комплексную проверку собранных данных, по итогам которых будет получен результат. Можно привести простой пример: все врачи понимают медицинские отчеты с четко обозначенными показателями. Подобно этому, если мы хотим получить ясные количественные результаты процесса оценки архитектуры, это невозможно будет сделать без платформы, которая поможет архитекторам применить количественный подход, основанный на контрольных списках, и получить результаты, которые помогут архитекторам и заинтересованным лицам мгновенно понять состояние архитектуры приложения. В статье описывается простая платформа, разработанная с учетом всего вышесказанного. Эта платформа может быть использована для процесса оценки архитектуры на предмет применения передовых практических методов и достижения желаемого уровня показателей качества обслуживания. Подход
Ключевыми исходными данными для описываемой платформы являются вопросы, содержащиеся на ресурсах Microsoft Patterns & Practices. В число этих досконально проработанных и всесторонних вопросов входят те, которые имеют отношение к комплексным аспектам и специфичным для конкретной платформы проблемам. Эти вопросы могут быть соответствующим образом настроены, чтобы итоговый репозиторий данных мог быть использован исключительно для оценки архитектуры. В сценариях, в которых необходимо оценить архитектуру приложений в разнородной среде, некоторые вопросы, специфичные для конкретной платформы, могут быть выборочно опущены или заменены. По сути, вопросы и контрольные списки, доступные на ресурсах Patterns & Practices, также включают аспекты, которые применимы в сценариях, независимых от технологий.
Рисунок 1. Платформа формирования количественных показателей для оценки архитектуры приложения (щелкните рисунок, чтобы увеличить изображение)Итоговый репозиторий будет являться набором контрольных списков на основе требуемых показателей качества обслуживания. Эти контрольные списки могут быть использованы архитекторами-рецензентами для опроса архитекторов, проектировавших соответствующие приложения. Кроме этого, ответы на вопросы контрольных списков могут быть получены из документов, например тех, которые описывают архитектуру системы и решения. За каждый положительный ответ вопросу присваивается значение 1, за каждый отрицательный – 0. По завершению этого процесса исследования на основании количества положительных ответов для всех показателей качества обслуживания, учитываемых при оценке архитектуры, будут подсчитаны баллы. Каждый балл является суммой баллов в соответствующей подкатегории. Баллы в каждой подкатегории являются суммой баллов, полученных за каждый положительный ответ на вопрос контрольного списка. Например, для показателя «Производительность» имеются такие подкатегории, как кэширование, доступ к данным, управление состоянием, управление ресурсами и параллелизм. Образец результатов представлен в таблице 1.
Таблица 1. Баллы за показатель качества обслуживания «Производительность»На основе реального количества вопросов, которые содержатся в репозитории для каждой подкатегории показателя «Производительность», мы можем рассчитать процент баллов, набранных оцениваемым приложением по показателю «Производительность». Тот же метод можно применить для получения процентных значений для других показателей качества обслуживания. Теперь вы можете предположить, что средний балл по всем показателям качества обслуживания – это итоговый балл, обозначающий качество архитектуры приложения. Однако это не совсем так. Рассмотрим, почему это происходит. Архитектурные компромиссыПриложение не может набрать 100 % по всем показателям качества обслуживания. Архитектура всегда является результатом компромиссных решений, которые затрагивают различные показатели качества обслуживания. Эти компромиссные решения принимаются на основе сценариев работы приложения, важных с точки зрения архитектуры и особенностей бизнес-доменов, для которых разрабатывается продукт. Кроме этого, один показатель качества обслуживания может оказывать позитивное или негативное влияние на остальные.
Таблица 2. Взаимное влияние показателей качества обслуживанияВ таблице 2 представлено взаимное влияние различных показателей качества обслуживания. Архитектурное решение, принятое с целью достичь желаемого уровня одного из показателей качества обслуживания, может неблагоприятно повлиять на другой. Например, в банковском приложении безопасность считается более важным показателем, чем производительность. Показатель качества обслуживания «Безопасность» будет оказывать негативное влияние на показатель «Производительность». Поэтому любое архитектурное решение, принятое с целью достичь высокой степени безопасности, негативно скажется на производительности приложения. Это известный компромисс, на который умышленно идут архитекторы. Поэтому оцениваемое приложение наберет меньше баллов в графе «Производительность». Чтобы архитектурные компромиссы не влияли на результат и не приводили в итоге к принятию ошибочных решений, мы вводим понятие назначения приоритетовпоказателям качества обслуживания. Приложение не может иметь два взаимоисключающих показателя качества обслуживания с одинаковым приоритетом. Например, приоритеты показателей «Производительность» и «Безопасность» не могут быть равны. Если основным приоритетом приложения является «Производительность», то «Безопасность» автоматически получает следующий из доступных приоритетов. Если оценка архитектуры основывается на показателях качества обслуживания SHARP и если приложение разрабатывается для бизнес-домена, в котором показатель «Производительность» имеет наивысший приоритет, архитектор-рецензент может расставить приоритеты так, как показано в таблице 3.
Таблица 3. Расстановка приоритетов показателей качества обслуживанияПриоритеты следует расставлять на основе бизнес-целей и пожеланий заинтересованных лиц. Также для анализа компромиссных архитектурных решений можно использовать метод ATAM. Использование метода ATAM гарантирует, что бизнес-цели и интересы вовлеченных сторон будут приняты во внимание. Эмпирический прием: максимальный номер приоритета не может превышать количество показателей качества обслуживания, учитываемых при оценке архитектуры. Кроме того, никакие два показателя качества обслуживания не могут иметь одинаковые приоритеты.
Таблица 4. Пороговые значения показателей качества обслуживанияКак показано в таблице 4, архитектор также может присвоить каждому показателю качества обслуживания пороговое значение, чтобы указать, в каких категориях архитектура приложения набирает недостаточно баллов. До перехода к следующему этапу важно провести обзор всех решений, которые затрагивали каждый показатель качества обслуживания. Пороговые значения субъективны. Они должны отражать общее мнение группы архитекторов на предприятии. Если полученный балл ниже порогового значения, это ясно показывает, какие аспекты архитектуры приложения имеют уровень ниже требуемого. Это также будет особенно полезным при слияниях и поглощениях. Например, компания A приобретает компанию Б и проводит процесс оценки. Компания А может отказаться от приложений, которые набрали балл намного ниже порогового значения. Архитектурный индексПосле рассмотрения баллов для каждого показателя качества обслуживания и расстановки приоритетов итоговую оценку качества архитектуры приложения можно получить с помощью формулы средневзвешенного значения, как показано в таблице 5. Архитектурный = «Производительность» (балл в %) × номер приоритета показателя «Производительность» ___________________________________________________________________________ номер приоритета показателя «Производительность» Таблица 5. Архитектурный индекс, рассчитанный по формуле средневзвешенного значения (щелкните рисунок, чтобы увеличить изображение)Результатом расчетов станет одно число, которое мы назовем «Архитектурный индекс». В таблице 6 показано значение архитектурного индекса, рассчитанное по формуле средневзвешенного значения на основании примерных значений различных показателей качества обслуживания и их приоритетов.
Таблица 6. Оценки показателей качества обслуживания и соответствующий архитектурный индексАрхитектурный индекс лежит в диапазоне от 0 до 100. Это число отражает непосредственную оценку архитектуры приложения. Поскольку итоговое число основано на передовых практических методах и правилах поставщиков платформ, оно будет отражать, какой может быть идеальная архитектура приложения. Например, если оценка выполнена на основе контрольных списков и вопросов, предоставленных группой Patterns & Practices корпорации Microsoft, то низкое значение архитектурного индекса означает, что архитектура приложения не соответствует проверенным передовым практическим методам. Поскольку положительный или отрицательный ответ на вопрос вносит прямой вклад в оценку определенного показателя качества обслуживания, мы можем легко определить влияние конкретного архитектурного решения на конкретный показатель и, следовательно, на общее качество архитектуры приложения. Наглядные отчетыХотя единый архитектурный индекс дает четкое представление о качестве архитектуры приложения, необходимо составить несколько наглядных отчетов, показывающих слабые места архитектуры. Эти отчеты могут быть использованы, чтобы провести эффективный рефакторинг или перестройку решения. Будет разумно создать инструмент или небольшую программу для автоматизации всего процесса и генерации отчетов. Если приложить немного усилий и написать несколько макросов, то Microsoft Office Excel способен творить чудеса. Наглядные отчеты крайне важны для того, чтобы архитектор приложения мгновенно смог быстро понять, в чем проблема (на основе архитектурного индекса) и немедленно отреагировать. На рисунках 2, 3 и 4 показаны снимки экрана для некоторых отчетов, которые были сгенерированы автоматически и способствовали успешному проведению совещаний, посвященных обсуждению архитектуры.
Рисунок 2. Общее качество архитектуры приложения (щелкните рисунок, чтобы увеличить изображение)
Рисунок 3. Качество архитектуры приложения с точки зрения показателя «Производительность»
Рисунок 4. Качество архитектуры приложения с точки зрения показателя «Безопасность»Допустим, что архитектура приложения оценена в 49 %. Архитектор может мгновенно определить, из-за какого показателя качества обслуживания получен невысокий балл. Если невысокий балл получен за показатель «Производительность», архитектор может обратиться к отчету о результатах анализа производительности, в котором будут показаны баллы в различных подкатегориях (например, кэширование и управление состоянием). Если в определенной подкатегории (например, кэширование) набрано меньше баллов, чем необходимо, архитектор может отследить, почему так много пунктов в этой подкатегории были оценены в ноль баллов. Он также может проконтролировать, как конкретное решение влияет на конкретный показатель качества обслуживания и, как следствие, на архитектуру в целом. При оценке архитектуры существующего приложения архитекторы могут использовать эти отчеты на встречах с заинтересованными лицами, чтобы сообщить, почему качество архитектуры приложения считается неудовлетворительным, и чтобы выделить области, которым необходимо уделить внимание. Это стимулирует принятие мер по исправлению соответствующих приложений. ЗаключениеПроцесс количественной оценки архитектуры обеспечивает кристально четкое представление о качестве архитектуры приложения. Данные, полученные по результатам этого процесса, помогают принимать конкретные корректирующие меры. Количественная оценка архитектуры приложения представляет большой интерес и позволяет получить более ясное представление как о состоянии архитектуры существующих приложений, так и о предложенной архитектуре новых приложений. Однако этот подход не может заменить процессы, основанные на сценариях, например такие, как метод ATAM для анализа компромиссных архитектурных решений. Метод ATAM более детально проработан и основан на сценариях, важных с точки зрения архитектуры, и может быть дополнен количественной оценкой. Результаты применения методов, подобных ATAM, являются качественными и основаны на анализе сценариев. Эта оценка на основе платформы позволяет получить количественные результаты и опирается на передовые практические методы и правила. Вернемся к примеру, рассмотренному в начале статьи: медицинскому анализу крови. Там на концептуальном уровне представлен ключевой стимул для применения количественного подхода к процессу оценки архитектуры. В медицине существуют критерии, признанные в этой сфере, которые используются как основа при характеристике заболевания конкретного пациента. Если поставщики платформ, организации по обслуживанию и ИТ-отделы компаний совместно выработают эталонные архитектурные индексы для приложений, основанные на различных факторах (например, бизнес-домен, стиль и шаблон архитектуры, требования SLA и различные комбинации показателей качества), то эти индексы могут стать ориентиром при создании грамотно спроектированных приложений. БлагодарностьОсобая благодарность выражается Бала Вариям (Bala Variyam), CTO, Чандеру Дамодарану (Chander Damodaran), ведущему архитектору, и Сохаилу (Sohail) из компании Collabera за предоставленные отзывы. Ресурсы
Другие онлайн-ресурсы Microsoft Patterns & Practices. Об автореВ. Гнанасекаран– ведущий архитектор компании Collabera, Бангалор, Индия. Среди областей его специализации – SOA и BPM, интеграция и корпоративная архитектура. Большую часть времени он уделяет консультированию в сфере архитектуры решений, исследованиям и разработкам с использованием новейших технологий и распространению технологий. В настоящий момент он занимается облачными вычислениями и корпоративной мобильностью. К нему можно обратиться по электронной почте gnana.sekaran@collabera.comили vgnanasekaran@gmail.com, а также посетить его блог по адресу www.gnanasekaran.com. |
.jpg)
.png)
.png)
.png)
.png)
.png)
.jpg)
.png)
.png)