Цель: в качестве цели сегодняшней лекции мы ставим себе (да и Вам) задачу выработать теоретическое понимание и практическое восприятие области разработки архитектуры программного продукта как сугубо практического направления, изучить которое под силу любому интересующемуся данной областью специалисту.
Для реализации поставленной цели мы приведем обзор лучших практик создания архитектур программных продуктов, существующих на сегодняшний день не только в России, но и на мировом рынке разработки программных продуктов.
Мы покажем не только методы, которые позволяют создать качественную архитектуру, а и приведем необходимый и достаточный состав и структуру информации, которая должна учитываться на протяжении всех стадий жизненного цикла программного продукта.
Как мы определились ранее, архитектура присутствует в каждой программе или программном продукте даже тогда, когда о ней не особо задумывались на стадии разработки. В том случае, если для создаваемого программного обеспечения достаточно важны следующие характеристики:
тем больше внимания и ресурсов необходимо уделять его составу, структуре и качеству реализации. И дело не только в том, что программный продукт и его архитектура должны быть реализованы в соответствии с намеченными планами и в полном предполагаемом объеме, но и в том, как будет обеспечено их дальнейшее развитие и сопровождение. Информация, которая остается доступной после того, как программный продукт перешел в стадию промышленной эксплуатации, определяет качественный уровень развития информационной системы и необходимые для этого ресурсы.
В принципе, любые данные можно передать и на словах, в устной форме, но поддерживать "предания сарафанного радио" на длительном интервале эксплуатации любой системы представляется нам практически неосуществимым.
Архитектура и программный продукт требуют целенаправленного тренда развития и не приемлют "костыльного" к ним отношения. Оптимально организованное документирование методик, архитектуры в целом и её составных уровней, функциональности, организационных требований к бизнес процессам программного продукта позволят создать и в дальнейшем совершенствовать и развивать конкретный программный продукт. Соблюдение описанного пути будет претворяться с условием поддержки надлежащего уровня качества, в соответствии с актуальным состоянием конкретного бизнеса и видением руководства своей позиции на рынке определенного бизнес домена.
Описанию того:
будет посвящена наша сегодняшняя лекция.
Под уровнями архитектуры программного обеспечения понимаются логически разделенные блоки, каждый из которых включает в себя одну или несколько дисциплин, учитывать которые необходимо для достижения оптимального результата функционирования программного продукта.
Архитектура программного продукта состоит из набора иерархически подчиненных уровней, каждый из которых описывает отдельные аспекты информационной системы.
Для цельного понимания понятия архитектуры программного продукта следует выделить следующие уровни:
Аспекты каждого уровня детализируются определенными функциональными дисциплинами. Любая дисциплина связывает конкретный архитектурный уровень и бизнес домен, обеспечивая прозрачность управления соответствующими организационными и функциональными процессами. В качестве примера можно привести уровень приложения, в который входят следующие дисциплины:
Приведенные дисциплины являются отдельными, самодостаточными активностями, которые реализуют и поддерживают архитектуру и функциональность программных продуктов. Часть дисциплин относится к категории технологических, что маршрутизирует на работу с ними сотрудников соответствующих подразделений, в компетенцию которых входит работа над определенной технологией или функцией, которая задействует соответствующую технологию. Таким образом, бизнес процесс реализации и сопровождения каждого уровня активирует необходимые для работы ресурсы.
К примеру, уровень управления данными состоит из следующих дисциплин:
Каждый уровень и дисциплина детализируются настолько подробно, насколько необходимо для организации прозрачных бизнес процессов конкретной организации с заданными характеристиками функционирования на определенном уровне архитектуры.
После того, как рассмотрены и описаны уровни и дисциплины, необходимо обратиться к изучению продуктовых компонентов, реализующих функционирование дисциплин.
Они включают в себя необходимые сетевые протоколы, продукты, конфигурации, которые специфичны для каждой отдельной ситуации создания архитектуры. Примерами продуктовых компонентов для дисциплины СУБД являются:
При создании и последующей работе с регламентной архитектурной документацией, описывающей методологическую составляющую компоненты, должны быть приведены критерии, в соответствии с которым данная компонента была выбрана для функционирования в архитектуре или программном продукте. Выбор компонент и их характеристик должен проводиться на основе подробного и детального анализа, обосновывающего их дальнейшее использование.
Кроме того, документация на архитектурные компоненты должна определять международные и отраслевые стандарты, регламентирующие документы, применение которых необходимо учитывать на конкретном уровне архитектуры в целях соблюдения практик отрасли или законодательных актов. Именно применение подобной документации обеспечивает базис для принятия технологических и бизнес решений о тренде развития программных продуктов и его компонентах.
Помимо регламентной документации необходимо разрабатывать набор методических документов (подробно будет рассмотрено далее), которые должны соответствовать специфичным требованиям каждого уровня. В описании уровня рекомендуется использовать термины бизнес домена или доменов, для которых разрабатывается программный продукт. Преимуществом такого подхода к организации архитектурного документооборота является целостное представление описания архитектуры. Это позволяет эффективно организовать и управлять процессами жизненного цикла архитектуры и функциональности программного продукта.
Каждая организация должна самостоятельно определить и адаптировать требуемый набор документации, определяемый конкретными потребностями.
Многоуровневый принцип разработки архитектурной документации не является единственным.
Существуют альтернативные подходы, получившие достаточно широкое распространение в связи со стремлением диверсифицировать и специфицировать различные архитектурные аспекты в целях делегирования, при непосредственном контроле ответственных сотрудников и руководства за профессиональной дисциплиной, ответственности соответствующим исполнительным подразделениям организаций. Каждый аспект выделяется в субархитектуру, которая достаточно инкапсулирована от смежных архитектур, но при этом пересекается с ними во множестве взаимозависимых параметров.
Традиционно выделяют 4 взаимосвязанные субархитектуры, которые составляют целостную информационную архитектуру не только отдельных программных продуктов, но и информационной системы определенной компании:
Если детализировать представленный вид архитектуры, то наибольший интерес вызывает процессная часть, реализуемая в виде бизнес-процессов, пронизывающих структуру каждой современной организации.
В этом виде архитектуры рассматривается аспект данных (локальные справочники, мастер справочники и т.д.), используемые организациями, их представление, взаимозависимости и взаимовлияние не только друг на друга, но и на функционал конкретного программного продукта.
В этом разделе описываются технические параметры архитектуры организации, которые формируют сетевую архитектурную инфраструктуру, на основе которой осуществляется фактическое размещение необходимых аппаратных средств.
Если мы говорим об архитектуре организации, то в этой главе рассматривается архитектура отдельного программного продукта, который является составной частью этой организационной системы и то, как он влияет на смежные с ней системы и на "систему систем". Если же мы обсуждаем отдельный программный продукт, то тут выделяют составляющие его компоненты.
В составе бизнес-архитектуры выделяют определенное количество доменов, зависящее от специфики компании, для которой разрабатывается архитектура. Выделение доменов выполняется по определенным признакам, определяемым компанией, её спецификой и манерой ведения бизнеса. В качестве примера можно привести:
В каждом из бизнес доменов могут быть выделены отдельные архитектурные компоненты, изучать и описывать которые следует под различными углами.
В архитектурно-субархитектурном описании отдельное внимание уделяется GAP-компоненте, назначение которой описывать существующие расхождения между текущим и желаемым состоянием архитектуры организации или отдельного программного продукта. GAP-компонента позволяет выявлять системные причины, оказывающие влияние на ряд смежных или зависимых компонент или систем, фиксировать их и определять план по работе с ними.
Помимо описания в архитектурной документации следует приводить результативные и хорошо себя зарекомендовавшие практики и тенденции, описывающие принципы эффективной работы отдельных направлений рассматриваемых доменов и менеджмента в целом.
На стадии проектирования программных продуктов, архитекторы закладывают грандиозные программные замыслы. Но эталонная модель требуемой системы и её фактическая реализация, как правило, сильно различаются.
Трудозатраты группы проектирования можно представить следующим образом:
Подобное соотношение затрачиваемых сил наглядно демонстрирует, что основной объем ресурсных задач связанных с реализацией архитектуры и функциональности программных продуктов концентрируется в области практических процессов, направленных на воплощение спроектированного.
Рабочие компромиссы достигаются за счет сбалансированного использования доступных ресурсов, технологий и времени. Для достижения заданных целей разработки, проектирования и документирования программных продуктов принято использовать эффективные подходы, которые в состоянии обеспечить требуемый результат. На сегодняшний день выделяют следующие подходы:
Один из первых и при этом, пожалуй, наиболее распространенный подход к проектированию и описанию архитектуры информационных систем принадлежит Дж. Захману. Предложенная модель (рис 1) с момента первой публикации эволюционировала с методики описания архитектуры программных продуктов до востребованного метода описания архитектуры компании в целом. Организациями и компаниями, которые применяют её в работе можно считать:
FEAF является ответвлением модели Захмана. Эта методика представляет собой самостоятельную модель описания архитектуры, созданную целенаправленно для применения в федеральных и муниципальных органах США. Данный вид модели отличается высокой степенью комплексности политики, процессов и моделей, что отражает специфичные требования к использованию информационных технологий в деятельности американского правительства.
TOGAF так же, как и FEAF, является самостоятельным ответвлением модели Захмана. Данная методология используется в коммерческих организациях, с развитым уровнем информационных технологий. TOGAF рекомендуется для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса. Этот вид интеграционной архитектуры сильно зависит от принимаемых решений в остальных областях, поэтому в рамках TOGAF рассматриваются смежные домены, влияющие на эффективность архитектуры в целом.
DoDAF методология построения архитектуры предприятий, созданная по заказу Министерства обороны США (DoD). DoD неоднократно являлось инициатором создания стандартов в области бизнес-моделирования процессов и программных продуктов. Рассматриваемая нами ранее нотация IDEF также создана при непосредственном участии Министерства обороны США. Специфика DoDAF определяется спецификой создания программных продуктов по заказу DoD. DoD – один из крупнейших заказчиков и разработчиков сложных программных продуктов. В предприятиях по созданию таких систем участвуют тысячи подрядчиков, от слаженной работы которых зависит достижение поставленных результатов. Компании, которые стремятся взаимодействовать с DoD на коммерческой основе, должны выполнять DoDAF. Это обстоятельство послужило толчком к началу распространению DoDAF.
Модель Захмана базируется на дисциплине классической, строительной архитектуры, которую мы уже неоднократно упоминали. В первоначальной работе Захман определил архитектуру, как "набор описательных представлений (моделей), которые применимы для описания программного продукта в согласовании с требованиями руководства, которые могут развиваться в течение определенного периода". В соответствии с поставленными целями, была предложена модель архитектуры компании (Zachman Framework for Enterprise Architecture). Модель предлагает решение двух основных архитектурных задач:
В период создания модели Захмана, в сфере разработки программного обеспечения стала набирать популярность концепция "жизненного цикла", состоящая из следующих стадий:
На каждой стадии "жизненного цикла" рассматриваются вопросы, влияющие и определяющие архитектуру и функциональность реализуемого программного продукта. Модернисткой идеей Захмана, изложенной в его модели, было предложение рассмотрения не отдельных частей архитектуры в разные моменты времени, как это подразумевает классическая дисциплина анализа требований, а рассмотрение информационной системы в целом с разных точек зрения/перспектив. Основной посыл этого предположения заключается в возможности обеспечения поэтапного документирования каждого отдельного значимого поведения архитектуры во взаимосвязи со всеми остальными, и создании соответствующего описания.
Чуть ранее мы определились с тем, что когда говорим об архитектуре программных продуктов, то имеем в виду программное обеспечение, которое является сложной, комплексной и высокотехнологичной системой, обладающей относительно большим числом связей и разнонаправленной функциональности, цельное рассмотрение которых в определенный момент времени достаточно затруднительно.
В случае если попытаться рассмотреть отдельную деталь информационного продукта оторвано от системы, в подавляющем количестве случаев - это приводит к спорным и необоснованным решениям касательно настоящего и будущего архитектуры и функционала программного обеспечения. Все детали, которые явно или потенциально взаимосвязаны друг с другом, должны рассматривать едино во взаимосвязи.
Подобная модель рассмотрения архитектуры представлена в модели Захмана, которая по сути отображена в виде таблицы, имеющей 5 строк/уровней и 6 столбцов/колонок.
В строках отражена следующая информация:
Колонки определяют и формируют уровни смысловой информации, которая будет составлять базис архитектуры и функциональности программного продукта. Каждая колонка в соответствующем уровне представления состоит из следующего перечня вопросов:
Используемые данные. Необходимо описать данные, которые будут обоснованно поддерживать реализацию выполнения процессов и функций, на каждом конкретном уровне, в соответствии c заданными показателями качества. От характеристик, целевого назначения и функционального использования данных зависит достижение результата на уровне, в котором они используются.
Данные являются необходимым "топливом", приводящим в движение бизнес процессы организации.
Процессы и функции. Описываются процессы и функции, специфичные для каждого конкретного уровня. Чем ниже уровень, тем ниже степень неопределенности и абстракции процессов и образующих их функций.
Если на верхних уровнях речь идет об управленческих, то на нижних рассматриваются технические процессы, реализующие и поддерживающие архитектуру и функциональносить предприятия или программного продукта.
Места выполнения этих действий. Отражается информация о том, где должны выполняться конкретные процессы. Если описывается бизнес-процесс то может быть приведено описание конкретного отдела или географического места, где выполняется значимая функция, в том случае, когда декомпозируется автоматизируемый технический процесс, то уместно привести описание программного продукта или выделенного модуля/компонента с которым взаимодействуют пользователи системы.
Участники - организации и персоналии–участники. Необходимо указать роли и исполнителей, которые выполняют процессы, формирующие архитектуру информационной системы. В том случае, когда выполнение процесса закреплено за организацией, то необходимо указать сферу ее ответственности.
Управляющие действия. Здесь представлены данные о управляющих действиях, решениях принятых руководством или закрепленным на законодательном или корпоративном уровне управляющей структуры компании, которые являются движущей силой процессов и обеспечивают их планомерное выполнение и последующее развитие. Здесь могут быть представлены специфичные методологии или политики, которые лежат в основе определенных процессов (тестирования, разработки) конкретной организации.
Цели, задачи и ограничения, определяющие работу системы. Указывается обоснованная мотивация, приведшая к необходимости создания архитектуры. Кроме указания верхнеуровневых целей каждого уровня необходимо отражать задачи, с помощью которых предполагается достигать обозначенные цели и ограничения, формирующие ее рамки.
Сам Захман при описании своей модели сравнивал ее с таблицей, описывающей повторяющиеся представления компании, и при этом отмечал, что подобное представление необходимо в том случае, когда информационная система становится чем-то большим, чем просто программной процедурой. Сложность и интеграционная комплексность архитектурного проектирования должна реализовываться не неожиданным чудом, а реальным повторяемым процессом.
При заполнении модели таблицы следует соблюдать следующие правила:
Модели, каждая из которых включена в определенную ячейку, в совокупности составляют определенный уровень, а уровни образуют описание всей системы.
Каждый столбец представляет собой полное описание системы с определенной перспективы.
При подобных правилах заполнения становится очевидным, что попытка пропуска ячейки, при заполнении любого уровня или столбца, является недопустимой и может привести к смене или потери фокуса разрабатываемой архитектуры. "Дыры" в отдельных ячейках могут привести к тому, что целостная архитектура модифицируется в швейцарский сыр, на котором возвести прочный базис бизнес-процессов современной организации вряд ли получится.
Игнорирование отдельных ячеек или уровней ( переход от концептуальной модели бизнес-процесса к ее физической реализации ), приведет к разрыву понимания между заказчиками и исполнителями отдельных процессов или функций, что негативно скажется на результатах процессов разработки. Стремления отдельных участников архитектурных процессов к подобной манере работы не так уж редки. На практике это происходит постоянно и связано, в основном, с тем, что бизнес стэйкхолдеры жаждут получить результат как можно скорее.
В модели Захмана подобное отношение к архитектуре программных продуктов является недопустимым.
(рис 1) Модель Захмана (пример)
Подводя итог обсуждения модели Захмана нужно вывести следующие преимущества:
Следующим рассматриваемым подходом к созданию и документированию архитектуры программного продукта будет Модель "4+1". Она сыграла важную роль в области развития направления архитектурного проектирования. Основоположником этой модели, созданной в 1995 году, является Филипп Кратчен. Методика "4+1" позиционируется в качестве простого и понятного инструмента описания программной архитектуры.
Как следует из названия, рассматриваемая модель предлагает использовать пять различных категорий/представлений/точек зрения.
Первые четыре:
Данное представление играет роль модели проектирования разрабатываемой информационной системы. Может различаться в зависимости от выбранной технологии реализации программного обеспечения. Цель логического представления методики "4+1" - фиксация функциональных требований к программному продукту.
Это представление применяется для описания аспектов порядка и синхронизации исполнения бизнес-процессов. Процессное представление, как правило, учитывает ряд критичных нефункциональных требований (производительность, безопасность и т.д.) и описывает такие аспекты, как интеграция процессов и систем. Архитектура процессов представляется на различных уровнях абстракции:
В этом представлении отражены детали связанные с физическим размещением программных компонент системы на аппаратных платформах. В нем должны быть рассмотрены все нефункциональные требования к программному продукту.
Представление уровня разработки описывает статическую организацию программной системы в среде разработки программного продукта
Связующим артефактом разрабатываемой архитектуры программного продукта ("+1"), в представленной модели "4+1", являются специализированные сценарии использования (use cases). На основе ключевых сценариев использования во многом происходит формирование конечного вида программного продукта. Ключевые сценарии объединяют представления в единую и неделимую систему, описывающую последовательность взаимодействия объектов и процессов. При описании акцент сделан на наиболее важных требованиях, формирующих конечный результат процессов архитектурного проектирования и разработки программного продукта. Сценарии использования должны удовлетворять следующим требованиям:
Современная методика "Стратегическая модель архитектуры" (Strategic Architecture Model) представляет собой инструмент анализа и документирования архитектуры программного продукта и связанных с ним предметных бизнес доменов. Данная методика получила широкое распространение по причине активного внедрения компанией Microsoft в свои внутренние и внешние проекты. Но, несмотря на такого авторитетного покровителя, ее авторство принадлежит английской консалтинговой компании Systems Advisers Ltd.
SAM построена на основе использования специфичной нотации "сфер интересов". Нотация "Сфер интересов" представляет адекватный набор достоверных фактов об автоматизируемом предприятии и взаимоотношениями, связывающими факты в группы. Это позволяет достоверно и относительно объективно взглянуть на структурную и функциональную архитектуру организации. При определенном взгляде на эту методику, ее можно отнести к "над" архитектурной модели Захмана. На основе смоделированной нотации "Сфер интересов" представляется возможным определить и спроектировать, для конкретной компании, оптимальную архитектуру разрабатываемого программного продукта.
В "SAM" рекомендуется использовать итеративный подход при создании бизнес архитектуры, при этом, в процессе работы сочетаются подходы описания как "сверху–вниз", так и "снизу–вверх".
Если выбран подход описания в направлении "снизу–вверх", тогда необходимо идти путем сбора информации, относящегося к бизнес домену, поднимаясь от конкретных автоматизируемых артефактов. Если же избран принцип "сверху–вниз", тогда необходимо идти путем поэтапной декомпозиции определенного бизнес домена, опускаясь до конкретных артефактов.
Подобные методы поэтапного описании и соответствующего представления разнообразных бизнес сфер и структур организации достаточно детализировано определяют элементы сфер, что способствует выявлению явных и скрытых связей между разными объектами компании. Адекватное управление выявленными связями может позволить оптимизировать бизнес деятельность различных направлений компании.
Наиболее приоритетны следующие сферы:
Наименования сфер достаточно информативны и во многом соответствуют объектам рассмотрения всех архитектур, которые мы рассматриваем в ходе данной лекции. С точки зрения SAM имеет смысл выделить артефакт бизнес-компонента и рассмотреть его более пристально.
Технические компоненты, которые лежат в основе бизнес-компонент, являются значимыми элементами современных подходов к разработке архитектур программных продуктов. Их корректное и целевое применение позволит реализовать оптимальную архитектуру программного продукта. В качестве примера можно выделить:
Для построения качественной архитектуры по модели SAM, необходимо классифицировать разрабатываемые сферы интересов по следующей топологии:
Эти сферы должны описывать наиболее стабильные элементы бизнеса. Именно они будут представлять базисные структуры, лежащие в основе архитектуры. Безусловно, мы прекрасно понимаем, что современный рынок товаров и услуг очень изменчив и диктует требования к перманентному изменению и развитию, но, как правило, фундаментальные элементы подвержены наименьшей корректировке.
Сферы этой классификации должны описывать то, что на конкретном предприятии находится в процессе постоянных изменений. Это позволит обеспечить адекватную реакцию на изменяющиеся внутренние и внешние условия.
Эти сферы определяют направление бизнеса, что порождает изменение программных продуктов. В них необходимо включать области, которые должны постоянно изменяться.
Приведенная классификация позволяет:
Модель архитектуры "SAM", рассмотренная нами, обладает спецификой и представляет интерес для рассмотрения и применения, но необходимо помнить о том, что самодостаточной её считать сложно и нужно использовать комплексно вместе с более техническими моделями.
Лидеры рынка информационных технологий, компании, которые во многом определяют и формируют архитектуры современных программных продуктов (Microsoft, IBM, SAP и пр.), занимаются созданием собственных методик разработки архитектуры информационных систем. Во многом это является не просто дорогой прихотью, а их обязанностью. Это следует из того, что "линейка" информационных продуктов, предлагаемых обозначенными компаниями-гигантами, покрывает подавляющую часть комплексной архитектуры предприятия. Поэтому компаниям, которые склоняются в сторону выбора решений предлагаемых технологий, необходимы адекватные практические рекомендации, подкрепленные на практике успешным опытом использования.
Наиболее популярным подходом к разработке архитектуры информационных систем и созданию релевантной технологической инфраструктуры являются группы методов, разработанных компанией Microsoft. При создании своих методик в компании Microsoft были выделены четыре основных объекта рассмотрения:
Рассматриваются, преимущественно, процессные бизнес аспекты определенной компании.
Описываются и изучаются характеристики и необходимая структура организации работ с данными.
В этом разделе представлены информационные системы с помощью которых выполняется автоматизация и оптимизация бизнес процессов предприятия.
Приведено описание необходимых физических аппаратных средств и схемы их логического взаимодействия.
Обозначенные представления, как и в большинстве рассмотренных нами методов, рассматриваются на различных уровнях понимания (концептуальном, логическом и физическом). В архитектурных концепциях Microsoft так же выделяют и описывают задачи связанные с разработкой прикладных систем, организацией процессов эксплуатации технологической инфраструктуры и создания соответствующих архитектурных шаблонов, которые могут использоваться при проектировании и разработке архитектуры программных продуктов.
Собственно выделяют следующие методики, каждая из которых отвечает на определенный тип вопросов и решает соответствующие им задачи:
Как создавать программные продукты?
Как эксплуатировать технологическую инфраструктуру?
Как правильно создавать технологическую инфраструктуру?
Как правильно создавать процессы управления технологической инфраструктурой?
Методики MSF и MSA представляют ответы на вопросы о процессах разработки архитектуры программных продуктов и инфраструктуры. Методики MOF и MSM описывают аспекты управления и эксплуатации технологической инфраструктуры и программных продуктов. Также необходимо иметь в виду, что все методики взаимосвязаны и дополняют друг друга с точки зрения комплексности представления архитектуры программного продукта конкретного предприятия, но нацелены на различные фазы жизненного цикла ИТ-решений.
Собственно, методики Microsoft сфокусированы на системном уровне архитектуры программных продуктов и обеспечивающей их технологической инфраструктуры. Каждая методика имеет своей целью реализацию определенной модели, которая должна представлять архитектуру на определенном уровне восприятия с включением концептуального, логического и физического представлений системы.
Традиционно компанией Microsoft выделена пара типов руководств и обеспечивающих методик, задача которых заключается в оптимизации процессов разработки необходимых моделей при максимальновозможной минимизации рисков.
Один из типов руководств описывает подходы к архитектурному проектированию. Оно обеспечивает:
Другой тип руководств, назначение которого имеет более широкие рамки применения в процессах разработки и проектирования - архитектурные шаблоны. Этот тип документа основан сугубо на успешном практическом опыте большого количества реализованных проектов создания программных продуктов на основе приведенных выше методик и представляет собой определенного вида архитектурный шаблон. Они содержат лучшие практики проектирования информационных систем и средства по минимизации возникающих рисков.
Эти документы – архитектурные концепции и шаблоны – должны использоваться на различных уровнях проектирования архитектуры программных продуктов.
Выше мы осветили основные архитектурные методики, которые распространены и успешно применяются при разработке программных продуктов, но это не полный список. Существует множество других методик, которые не так распространены, но находят применение в практической деятельности.
TEAF
Архитектура Казначейства США. Она создана на основе уже рассматриваемой нами методики FEAF, но отличие состоит в более глубинной специфической проработке. Причина этого – предназначение для использования в определенной организации. В состав TEAF включены шаблоны документов для большинства рассматриваемых предметных областей.
RM-ODP
В основе справочной модели открытых распределенных вычислений (RM-ODP – Reference model of open distributed processing), находятся принципы анализа информационной системы под углом зрения на разные представления реализации системы и объектно-ориентированная парадигма разработки программных продуктов. Эта методика применяется при описании архитектуры электронного правительства Германии.
В этой модели ключевыми атрибутами являются системные представления разрабатываемой модели, функции и средства обеспечения прозрачности распространения.
Модель определяет пять основных представлений:
Кроме представлений, RM-ODP содержит описание следующих функций:
Функция управления определяет то, как системой управляют, начиная с уровня узлов (серверов) и вплоть до программных объектов, которые выполняются на конкретных узлах.
Функция координации детализирует вопросы взаимосвязи событий в системе.
Функция репозитория описывает, как информация организована и хранится.
Функция безопасности описывает вопросы управления безопасностью в системе, а также методы авторизации доступа, обеспечения целостности, аудита, управления правами доступа.
Под средствами прозрачности в модели RM-ODP понимается технология обеспечения ясности, однозначности и понятности разрабатываемых функциональных, не функциональных и прочих характеристик программного продукта и его архитектуры.
В архитектурной модели RM-ODP выделено девять средств обеспечения прозрачности:
RM-ODP является достаточно интересной и эффективной моделью проектирования, но при этом нельзя сказать, что она обладает какими-то уникальными конкурентными преимуществами по сравнению с уже рассмотренной моделью Захмана или методиками Microsoft, что ставит под сомнение ее дальнейшее развитие и распространение, по крайней мере, на территории РФ.
CAFCR
Последней методикой описания архитектуры, которую мы хотим рассмотреть сегодня, является модель CAFCR , разработанная для удовлетворения потребностей компании Philips. Формально, CAFCR относится не к специфическим моделям архитектуры предприятия и предназначается для разработки определенных архитектур программных продуктов. К примеру, можно упомянуть, что рассматриваемая методика применяется при реализации глобальных систем управления автомобильным движением.
Аббревиатура СAFCR образована из названий пяти основных представлений данной модели;
Пара "верхних" представлений помогают найти ответы на вопрос "зачем создается система?". Функциональное представление описывает, "что должна система выполнять?".
Не функциональные требования к разрабатываемому программному продукту также отображены в этом виде представления и должны быть описаны в достаточном и необходимом объеме. Предпоследнее представление отвечает на вопрос "как должно осуществляться функционирование системы?" и является средством общения со спонсорами и бизнес стэйкхолдерами разрабатываемой архитектуры программного продукта. Последнее представление должно подробно описывать реализацию информационной системы. Главной задачей системного архитектора, взявшегося за разработку архитектуры по модели СAFCR является создание гармоничной, эффективной и согласованной системы, которая должна решать следующие задачи:
Отметим, что рассмотренный нами список методик и моделей, безусловно, не полный, но самые значительные и современные мы отразили. Выбор конкретной методики зависит от ряда объективных и множества субъективных факторов, но умение специалиста эффективно адаптироваться и ориентироваться в конкретном окружении отличие зрелого архитектора от новичка.
В предыдущем абзаце мы рассмотрели набор архитектурных методик, каждая из которых предоставляет собственный инструментарий, необходимый для визуализации разрабатываемой архитектуры программного продукта. Но когда речь заходит о выборе оптимальной архитектурной нотации, как правило, большинство департаментов информационных технологий (или ответственные за создание архитектуры подразделения) современных компаний склоняется к созданию собственной нотации, скомпилированной из хорошо себя зарекомендовавших, для данного предприятия, нотаций и способов моделирования бизнес процессов и структур данных архитектуры и функциональности разрабатываемого программного продукта.
Несмотря на наличие большого числа соответствующих стандартов в области описания архитектуры (ISO, IEEE, The Open Group и пр.), ни одна из них не доминирует на рынке соответствующего направления области информационных технологий.
Опрос, проведенный не так давно институтом разработки корпоративной архитектуры (США) продемонстрировал, что:
Можно сделать выводы о том, что "best practice" в проектировании и разработке соответствующей документации для обеспечения полного жизненного цикла программного продукта заключается в применении всего лучшего, что накоплено в базе знаний отрасли. В связи с этим системному архитектору или специалисту, задействованному в проектировании и реализации архитектуры программного продукта, важно детально представлять и понимать преимущества и недостатки существующих методик и нотаций, соотнесенные с ясной целью и четкими задачами, которые должны быть определены перед стартом разработки архитектуры информационной системы определенной организации.
Для проектирования и последующей реализации архитектуры программного продукта следует:
В сфере проектирования и разработки архитектуры на текущий момент развития области информационных технологий отсутствует единый источник стандартов. Следовательно, вполне корректно использовать всю доступную информацию по имеющимся методологиям для создания на их основе собственной, наиболее подходящей под конкретные нужды, адаптированной под реалии процессов проектирования и разработки архитектуры и функциональности программных продуктов.
Достоинствами этого подхода являются:
Из недостатков подобного подхода к созданию документационного обеспечения конкретной организации можно выделить то, что документация будет уникальна для конкретной компании и ее масштабирование и последующее использование в других предприятиях потребует ресурсов.
При выборе необходимых нотаций из существующих или разработке собственных методик документирования архитектуры, критично детально изучить примеры реализованных артефактов, которые достаточно эффективно описывают архитектуру программных продуктов в заданных условиях функционирования компании. При этом важно понимать, что нет догм о составе и объеме необходимых нотаций и документов. Каждый раз, сталкиваясь с специфичными особенностями определенной ситуации, необходимо по возможности адаптировать имеющиеся шаблоны и расставлять приоритеты в соответствии с практическими потребностями в тех или иных элементах описания архитектуры. Основным требованием к выбранным артефактам является их согласованность между собой, с архитектурной методикой в целом, с процессами управления и поддержки программной архитектуры.
Попытка включить в описание дополнительные нотации или документы, необходимость которых не обоснована реальными условиями или требованиями к последующему развитию архитектуры приведет к "холостому" перерасходу ресурсов.
Важно определить те области архитектуры, практическое использование которых будет определять успех конкретного программного продукта и сфокусироваться на их детальном моделировании и последующем документировании.
В процессе создания архитектурных артефактов, как обеспечивающих (документирование, проектирование и т.д.), так и основных (разработка, тестирование и т.д.) процессов реализации программных продуктов, задействованные исполнители (системный архитектор, аналитики и т.д.) выполняют проработку базиса информационной системы. Исчерпывающий набор действий, определяющий рамки создания архитектурного фундамента информационной системы, взаимосвязан с использованием выбранных нотаций или языков моделирования бизнес процессов, структур данных и т.д. Наиболее встречающимся языком архитектурного моделирования является UML, который мы рассмотрели выше. UML, как было показано, не является "панацеей" домена архитектурного проектирования программных продуктов. При этом данный язык включает в себя средства, которые поддерживают многие характеристики, составляющие большинство применяемых архитектурных моделей.
Для создания полноценного и самодостаточного программного продукта потребуется выполнить активности моделирования. Создаваемые архитектурные модели позволяют демонстрировать ожидаемую структуру и поведение функционала программного продукта в виде, доступном для понимания адресату создаваемых архитектурных артефактов. Реализованные модели архитектуры следует использовать для:
К примеру, в области строительства сооружений применяется множество видов моделирования, каждое из которых преследует определенные цели:
Мы привели пример из сферы архитектурного строительства, как "предтечи" архитектурного проектирования программных продуктов, но во множестве современных практических направлений деятельности, имеющих различную природу, к моделированию прибегают постоянно. В таких гуманитарных предметах, как социология, экономика, или не совсем гуманитарном менеджменте, моделирование используют для проверки теоретических положений и предвидения новых идей с минимально возможными рисками и затратами.
Создание эффективных моделей функциональных процессов и архитектур программных систем способствует выработке объективного обоснования рамок, которые должны охватить бизнес-процессы необходимые для автоматизации в конкретном информационном продукте. Критичным требованием к достижению результата разработки оптимального программного продукта является требование к точному соблюдению рамок внедрения и последующего функционирования системы. Если позволить рамкам "расползтись" под давлением влиятельных стэйкхолдеров, стремящихся получить более "объемный" и качественный продукт за счет ранее согласованного количества ресурсов, то результат реализации архитектуры, с высокой долей вероятности подтвержденной соответствующей статистикой, будет не достигнут и от этого, прежде всего, пострадает организация-заказчик.
Рекомендации по соблюдению рамок функциональности программных продуктов и соответствующих архитектур, а так же поддерживающей и обеспечивающей их документации состоят в необходимости соблюдения первоначальных объемов автоматизириуемых бизнес-процессов.
В ходе сегодняшней лекции мы выполнили подробное рассмотрение уровней, формирующих оптимальную архитектуру программных продуктов, изучили существующие подходы к документированию информационных архитектур, детально взглянули на современные методики документирования программных продуктов.
Обзор архитектурных моделей, пожалуй, является ядром данной лекции и должен стать отправной точкой в изучении архитектур для тех коллег, которые видят свое профессиональное развитие в сфере реализации эффективных и результативных информационных архитектур современного программного обеспечения различной степени сложности и надежности.
На сегодняшний день накоплен внушительный массив различных реализаций архитектурных моделей, каждая из которых зарекомендовала себя на практике в определенных внутренних и внешних условиях. Несмотря на это, еще рано говорить о сложившемся самодостаточно предмете архитектурного моделирования в силу недостаточной теоретической обоснованности многих практических моделей и неспособности их массового тиражирования в различных условиях.
Именно в силу необходимости подробного документирования, аналитического рассмотрения и последующей синтетической реализации, необходимо использовать эффективные модели документирования результативных архитектур программных продуктов.
Цель: в качестве цели сегодняшней лекции мы ставим себе (да и Вам) задачу выработать теоретическое понимание и практическое восприятие области разработки архитектуры программного продукта как сугубо практического направления, изучить которое под силу любому интересующемуся данной областью специалисту.
Для реализации поставленной цели мы приведем обзор лучших практик создания архитектур программных продуктов, существующих на сегодняшний день не только в России, но и на мировом рынке разработки программных продуктов.
Мы покажем не только методы, которые позволяют создать качественную архитектуру, а и приведем необходимый и достаточный состав и структуру информации, которая должна учитываться на протяжении всех стадий жизненного цикла программного продукта.
Как мы определились ранее, архитектура присутствует в каждой программе или программном продукте даже тогда, когда о ней не особо задумывались на стадии разработки. В том случае, если для создаваемого программного обеспечения достаточно важны следующие характеристики:
тем больше внимания и ресурсов необходимо уделять его составу, структуре и качеству реализации. И дело не только в том, что программный продукт и его архитектура должны быть реализованы в соответствии с намеченными планами и в полном предполагаемом объеме, но и в том, как будет обеспечено их дальнейшее развитие и сопровождение. Информация, которая остается доступной после того, как программный продукт перешел в стадию промышленной эксплуатации, определяет качественный уровень развития информационной системы и необходимые для этого ресурсы.
В принципе, любые данные можно передать и на словах, в устной форме, но поддерживать "предания сарафанного радио" на длительном интервале эксплуатации любой системы представляется нам практически неосуществимым.
Архитектура и программный продукт требуют целенаправленного тренда развития и не приемлют "костыльного" к ним отношения. Оптимально организованное документирование методик, архитектуры в целом и её составных уровней, функциональности, организационных требований к бизнес процессам программного продукта позволят создать и в дальнейшем совершенствовать и развивать конкретный программный продукт. Соблюдение описанного пути будет претворяться с условием поддержки надлежащего уровня качества, в соответствии с актуальным состоянием конкретного бизнеса и видением руководства своей позиции на рынке определенного бизнес домена.
Описанию того:
будет посвящена наша сегодняшняя лекция.
Под уровнями архитектуры программного обеспечения понимаются логически разделенные блоки, каждый из которых включает в себя одну или несколько дисциплин, учитывать которые необходимо для достижения оптимального результата функционирования программного продукта.
Архитектура программного продукта состоит из набора иерархически подчиненных уровней, каждый из которых описывает отдельные аспекты информационной системы.
Для цельного понимания понятия архитектуры программного продукта следует выделить следующие уровни:
Аспекты каждого уровня детализируются определенными функциональными дисциплинами. Любая дисциплина связывает конкретный архитектурный уровень и бизнес домен, обеспечивая прозрачность управления соответствующими организационными и функциональными процессами. В качестве примера можно привести уровень приложения, в который входят следующие дисциплины:
Приведенные дисциплины являются отдельными, самодостаточными активностями, которые реализуют и поддерживают архитектуру и функциональность программных продуктов. Часть дисциплин относится к категории технологических, что маршрутизирует на работу с ними сотрудников соответствующих подразделений, в компетенцию которых входит работа над определенной технологией или функцией, которая задействует соответствующую технологию. Таким образом, бизнес процесс реализации и сопровождения каждого уровня активирует необходимые для работы ресурсы.
К примеру, уровень управления данными состоит из следующих дисциплин:
Каждый уровень и дисциплина детализируются настолько подробно, насколько необходимо для организации прозрачных бизнес процессов конкретной организации с заданными характеристиками функционирования на определенном уровне архитектуры.
После того, как рассмотрены и описаны уровни и дисциплины, необходимо обратиться к изучению продуктовых компонентов, реализующих функционирование дисциплин.
Они включают в себя необходимые сетевые протоколы, продукты, конфигурации, которые специфичны для каждой отдельной ситуации создания архитектуры. Примерами продуктовых компонентов для дисциплины СУБД являются:
При создании и последующей работе с регламентной архитектурной документацией, описывающей методологическую составляющую компоненты, должны быть приведены критерии, в соответствии с которым данная компонента была выбрана для функционирования в архитектуре или программном продукте. Выбор компонент и их характеристик должен проводиться на основе подробного и детального анализа, обосновывающего их дальнейшее использование.
Кроме того, документация на архитектурные компоненты должна определять международные и отраслевые стандарты, регламентирующие документы, применение которых необходимо учитывать на конкретном уровне архитектуры в целях соблюдения практик отрасли или законодательных актов. Именно применение подобной документации обеспечивает базис для принятия технологических и бизнес решений о тренде развития программных продуктов и его компонентах.
Помимо регламентной документации необходимо разрабатывать набор методических документов (подробно будет рассмотрено далее), которые должны соответствовать специфичным требованиям каждого уровня. В описании уровня рекомендуется использовать термины бизнес домена или доменов, для которых разрабатывается программный продукт. Преимуществом такого подхода к организации архитектурного документооборота является целостное представление описания архитектуры. Это позволяет эффективно организовать и управлять процессами жизненного цикла архитектуры и функциональности программного продукта.
Каждая организация должна самостоятельно определить и адаптировать требуемый набор документации, определяемый конкретными потребностями.
Многоуровневый принцип разработки архитектурной документации не является единственным.
Существуют альтернативные подходы, получившие достаточно широкое распространение в связи со стремлением диверсифицировать и специфицировать различные архитектурные аспекты в целях делегирования, при непосредственном контроле ответственных сотрудников и руководства за профессиональной дисциплиной, ответственности соответствующим исполнительным подразделениям организаций. Каждый аспект выделяется в субархитектуру, которая достаточно инкапсулирована от смежных архитектур, но при этом пересекается с ними во множестве взаимозависимых параметров.
Традиционно выделяют 4 взаимосвязанные субархитектуры, которые составляют целостную информационную архитектуру не только отдельных программных продуктов, но и информационной системы определенной компании:
Если детализировать представленный вид архитектуры, то наибольший интерес вызывает процессная часть, реализуемая в виде бизнес-процессов, пронизывающих структуру каждой современной организации.
В этом виде архитектуры рассматривается аспект данных (локальные справочники, мастер справочники и т.д.), используемые организациями, их представление, взаимозависимости и взаимовлияние не только друг на друга, но и на функционал конкретного программного продукта.
В этом разделе описываются технические параметры архитектуры организации, которые формируют сетевую архитектурную инфраструктуру, на основе которой осуществляется фактическое размещение необходимых аппаратных средств.
Если мы говорим об архитектуре организации, то в этой главе рассматривается архитектура отдельного программного продукта, который является составной частью этой организационной системы и то, как он влияет на смежные с ней системы и на "систему систем". Если же мы обсуждаем отдельный программный продукт, то тут выделяют составляющие его компоненты.
В составе бизнес-архитектуры выделяют определенное количество доменов, зависящее от специфики компании, для которой разрабатывается архитектура. Выделение доменов выполняется по определенным признакам, определяемым компанией, её спецификой и манерой ведения бизнеса. В качестве примера можно привести:
В каждом из бизнес доменов могут быть выделены отдельные архитектурные компоненты, изучать и описывать которые следует под различными углами.
В архитектурно-субархитектурном описании отдельное внимание уделяется GAP-компоненте, назначение которой описывать существующие расхождения между текущим и желаемым состоянием архитектуры организации или отдельного программного продукта. GAP-компонента позволяет выявлять системные причины, оказывающие влияние на ряд смежных или зависимых компонент или систем, фиксировать их и определять план по работе с ними.
Помимо описания в архитектурной документации следует приводить результативные и хорошо себя зарекомендовавшие практики и тенденции, описывающие принципы эффективной работы отдельных направлений рассматриваемых доменов и менеджмента в целом.
На стадии проектирования программных продуктов, архитекторы закладывают грандиозные программные замыслы. Но эталонная модель требуемой системы и её фактическая реализация, как правило, сильно различаются.
Трудозатраты группы проектирования можно представить следующим образом:
Подобное соотношение затрачиваемых сил наглядно демонстрирует, что основной объем ресурсных задач связанных с реализацией архитектуры и функциональности программных продуктов концентрируется в области практических процессов, направленных на воплощение спроектированного.
Рабочие компромиссы достигаются за счет сбалансированного использования доступных ресурсов, технологий и времени. Для достижения заданных целей разработки, проектирования и документирования программных продуктов принято использовать эффективные подходы, которые в состоянии обеспечить требуемый результат. На сегодняшний день выделяют следующие подходы:
Один из первых и при этом, пожалуй, наиболее распространенный подход к проектированию и описанию архитектуры информационных систем принадлежит Дж. Захману. Предложенная модель (рис 1) с момента первой публикации эволюционировала с методики описания архитектуры программных продуктов до востребованного метода описания архитектуры компании в целом. Организациями и компаниями, которые применяют её в работе можно считать:
FEAF является ответвлением модели Захмана. Эта методика представляет собой самостоятельную модель описания архитектуры, созданную целенаправленно для применения в федеральных и муниципальных органах США. Данный вид модели отличается высокой степенью комплексности политики, процессов и моделей, что отражает специфичные требования к использованию информационных технологий в деятельности американского правительства.
TOGAF так же, как и FEAF, является самостоятельным ответвлением модели Захмана. Данная методология используется в коммерческих организациях, с развитым уровнем информационных технологий. TOGAF рекомендуется для описания интеграционных компонент, использующихся для поддержки широкого спектра корпоративных приложений, прежде всего, критичных для бизнеса. Этот вид интеграционной архитектуры сильно зависит от принимаемых решений в остальных областях, поэтому в рамках TOGAF рассматриваются смежные домены, влияющие на эффективность архитектуры в целом.
DoDAF методология построения архитектуры предприятий, созданная по заказу Министерства обороны США (DoD). DoD неоднократно являлось инициатором создания стандартов в области бизнес-моделирования процессов и программных продуктов. Рассматриваемая нами ранее нотация IDEF также создана при непосредственном участии Министерства обороны США. Специфика DoDAF определяется спецификой создания программных продуктов по заказу DoD. DoD – один из крупнейших заказчиков и разработчиков сложных программных продуктов. В предприятиях по созданию таких систем участвуют тысячи подрядчиков, от слаженной работы которых зависит достижение поставленных результатов. Компании, которые стремятся взаимодействовать с DoD на коммерческой основе, должны выполнять DoDAF. Это обстоятельство послужило толчком к началу распространению DoDAF.
Модель Захмана базируется на дисциплине классической, строительной архитектуры, которую мы уже неоднократно упоминали. В первоначальной работе Захман определил архитектуру, как "набор описательных представлений (моделей), которые применимы для описания программного продукта в согласовании с требованиями руководства, которые могут развиваться в течение определенного периода". В соответствии с поставленными целями, была предложена модель архитектуры компании (Zachman Framework for Enterprise Architecture). Модель предлагает решение двух основных архитектурных задач:
В период создания модели Захмана, в сфере разработки программного обеспечения стала набирать популярность концепция "жизненного цикла", состоящая из следующих стадий:
На каждой стадии "жизненного цикла" рассматриваются вопросы, влияющие и определяющие архитектуру и функциональность реализуемого программного продукта. Модернисткой идеей Захмана, изложенной в его модели, было предложение рассмотрения не отдельных частей архитектуры в разные моменты времени, как это подразумевает классическая дисциплина анализа требований, а рассмотрение информационной системы в целом с разных точек зрения/перспектив. Основной посыл этого предположения заключается в возможности обеспечения поэтапного документирования каждого отдельного значимого поведения архитектуры во взаимосвязи со всеми остальными, и создании соответствующего описания.
Чуть ранее мы определились с тем, что когда говорим об архитектуре программных продуктов, то имеем в виду программное обеспечение, которое является сложной, комплексной и высокотехнологичной системой, обладающей относительно большим числом связей и разнонаправленной функциональности, цельное рассмотрение которых в определенный момент времени достаточно затруднительно.
В случае если попытаться рассмотреть отдельную деталь информационного продукта оторвано от системы, в подавляющем количестве случаев - это приводит к спорным и необоснованным решениям касательно настоящего и будущего архитектуры и функционала программного обеспечения. Все детали, которые явно или потенциально взаимосвязаны друг с другом, должны рассматривать едино во взаимосвязи.
Подобная модель рассмотрения архитектуры представлена в модели Захмана, которая по сути отображена в виде таблицы, имеющей 5 строк/уровней и 6 столбцов/колонок.
В строках отражена следующая информация:
Колонки определяют и формируют уровни смысловой информации, которая будет составлять базис архитектуры и функциональности программного продукта. Каждая колонка в соответствующем уровне представления состоит из следующего перечня вопросов:
Используемые данные. Необходимо описать данные, которые будут обоснованно поддерживать реализацию выполнения процессов и функций, на каждом конкретном уровне, в соответствии c заданными показателями качества. От характеристик, целевого назначения и функционального использования данных зависит достижение результата на уровне, в котором они используются.
Данные являются необходимым "топливом", приводящим в движение бизнес процессы организации.
Процессы и функции. Описываются процессы и функции, специфичные для каждого конкретного уровня. Чем ниже уровень, тем ниже степень неопределенности и абстракции процессов и образующих их функций.
Если на верхних уровнях речь идет об управленческих, то на нижних рассматриваются технические процессы, реализующие и поддерживающие архитектуру и функциональносить предприятия или программного продукта.
Места выполнения этих действий. Отражается информация о том, где должны выполняться конкретные процессы. Если описывается бизнес-процесс то может быть приведено описание конкретного отдела или географического места, где выполняется значимая функция, в том случае, когда декомпозируется автоматизируемый технический процесс, то уместно привести описание программного продукта или выделенного модуля/компонента с которым взаимодействуют пользователи системы.
Участники - организации и персоналии–участники. Необходимо указать роли и исполнителей, которые выполняют процессы, формирующие архитектуру информационной системы. В том случае, когда выполнение процесса закреплено за организацией, то необходимо указать сферу ее ответственности.
Управляющие действия. Здесь представлены данные о управляющих действиях, решениях принятых руководством или закрепленным на законодательном или корпоративном уровне управляющей структуры компании, которые являются движущей силой процессов и обеспечивают их планомерное выполнение и последующее развитие. Здесь могут быть представлены специфичные методологии или политики, которые лежат в основе определенных процессов (тестирования, разработки) конкретной организации.
Цели, задачи и ограничения, определяющие работу системы. Указывается обоснованная мотивация, приведшая к необходимости создания архитектуры. Кроме указания верхнеуровневых целей каждого уровня необходимо отражать задачи, с помощью которых предполагается достигать обозначенные цели и ограничения, формирующие ее рамки.
Сам Захман при описании своей модели сравнивал ее с таблицей, описывающей повторяющиеся представления компании, и при этом отмечал, что подобное представление необходимо в том случае, когда информационная система становится чем-то большим, чем просто программной процедурой. Сложность и интеграционная комплексность архитектурного проектирования должна реализовываться не неожиданным чудом, а реальным повторяемым процессом.
При заполнении модели таблицы следует соблюдать следующие правила:
Модели, каждая из которых включена в определенную ячейку, в совокупности составляют определенный уровень, а уровни образуют описание всей системы.
Каждый столбец представляет собой полное описание системы с определенной перспективы.
При подобных правилах заполнения становится очевидным, что попытка пропуска ячейки, при заполнении любого уровня или столбца, является недопустимой и может привести к смене или потери фокуса разрабатываемой архитектуры. "Дыры" в отдельных ячейках могут привести к тому, что целостная архитектура модифицируется в швейцарский сыр, на котором возвести прочный базис бизнес-процессов современной организации вряд ли получится.
Игнорирование отдельных ячеек или уровней ( переход от концептуальной модели бизнес-процесса к ее физической реализации ), приведет к разрыву понимания между заказчиками и исполнителями отдельных процессов или функций, что негативно скажется на результатах процессов разработки. Стремления отдельных участников архитектурных процессов к подобной манере работы не так уж редки. На практике это происходит постоянно и связано, в основном, с тем, что бизнес стэйкхолдеры жаждут получить результат как можно скорее.
В модели Захмана подобное отношение к архитектуре программных продуктов является недопустимым.
(рис 1) Модель Захмана (пример)
Подводя итог обсуждения модели Захмана нужно вывести следующие преимущества:
Следующим рассматриваемым подходом к созданию и документированию архитектуры программного продукта будет Модель "4+1". Она сыграла важную роль в области развития направления архитектурного проектирования. Основоположником этой модели, созданной в 1995 году, является Филипп Кратчен. Методика "4+1" позиционируется в качестве простого и понятного инструмента описания программной архитектуры.
Как следует из названия, рассматриваемая модель предлагает использовать пять различных категорий/представлений/точек зрения.
Первые четыре:
Данное представление играет роль модели проектирования разрабатываемой информационной системы. Может различаться в зависимости от выбранной технологии реализации программного обеспечения. Цель логического представления методики "4+1" - фиксация функциональных требований к программному продукту.
Это представление применяется для описания аспектов порядка и синхронизации исполнения бизнес-процессов. Процессное представление, как правило, учитывает ряд критичных нефункциональных требований (производительность, безопасность и т.д.) и описывает такие аспекты, как интеграция процессов и систем. Архитектура процессов представляется на различных уровнях абстракции:
В этом представлении отражены детали связанные с физическим размещением программных компонент системы на аппаратных платформах. В нем должны быть рассмотрены все нефункциональные требования к программному продукту.
Представление уровня разработки описывает статическую организацию программной системы в среде разработки программного продукта
Связующим артефактом разрабатываемой архитектуры программного продукта ("+1"), в представленной модели "4+1", являются специализированные сценарии использования (use cases). На основе ключевых сценариев использования во многом происходит формирование конечного вида программного продукта. Ключевые сценарии объединяют представления в единую и неделимую систему, описывающую последовательность взаимодействия объектов и процессов. При описании акцент сделан на наиболее важных требованиях, формирующих конечный результат процессов архитектурного проектирования и разработки программного продукта. Сценарии использования должны удовлетворять следующим требованиям:
Современная методика "Стратегическая модель архитектуры" (Strategic Architecture Model) представляет собой инструмент анализа и документирования архитектуры программного продукта и связанных с ним предметных бизнес доменов. Данная методика получила широкое распространение по причине активного внедрения компанией Microsoft в свои внутренние и внешние проекты. Но, несмотря на такого авторитетного покровителя, ее авторство принадлежит английской консалтинговой компании Systems Advisers Ltd.
SAM построена на основе использования специфичной нотации "сфер интересов". Нотация "Сфер интересов" представляет адекватный набор достоверных фактов об автоматизируемом предприятии и взаимоотношениями, связывающими факты в группы. Это позволяет достоверно и относительно объективно взглянуть на структурную и функциональную архитектуру организации. При определенном взгляде на эту методику, ее можно отнести к "над" архитектурной модели Захмана. На основе смоделированной нотации "Сфер интересов" представляется возможным определить и спроектировать, для конкретной компании, оптимальную архитектуру разрабатываемого программного продукта.
В "SAM" рекомендуется использовать итеративный подход при создании бизнес архитектуры, при этом, в процессе работы сочетаются подходы описания как "сверху–вниз", так и "снизу–вверх".
Если выбран подход описания в направлении "снизу–вверх", тогда необходимо идти путем сбора информации, относящегося к бизнес домену, поднимаясь от конкретных автоматизируемых артефактов. Если же избран принцип "сверху–вниз", тогда необходимо идти путем поэтапной декомпозиции определенного бизнес домена, опускаясь до конкретных артефактов.
Подобные методы поэтапного описании и соответствующего представления разнообразных бизнес сфер и структур организации достаточно детализировано определяют элементы сфер, что способствует выявлению явных и скрытых связей между разными объектами компании. Адекватное управление выявленными связями может позволить оптимизировать бизнес деятельность различных направлений компании.
Наиболее приоритетны следующие сферы:
Наименования сфер достаточно информативны и во многом соответствуют объектам рассмотрения всех архитектур, которые мы рассматриваем в ходе данной лекции. С точки зрения SAM имеет смысл выделить артефакт бизнес-компонента и рассмотреть его более пристально.
Технические компоненты, которые лежат в основе бизнес-компонент, являются значимыми элементами современных подходов к разработке архитектур программных продуктов. Их корректное и целевое применение позволит реализовать оптимальную архитектуру программного продукта. В качестве примера можно выделить:
Для построения качественной архитектуры по модели SAM, необходимо классифицировать разрабатываемые сферы интересов по следующей топологии:
Эти сферы должны описывать наиболее стабильные элементы бизнеса. Именно они будут представлять базисные структуры, лежащие в основе архитектуры. Безусловно, мы прекрасно понимаем, что современный рынок товаров и услуг очень изменчив и диктует требования к перманентному изменению и развитию, но, как правило, фундаментальные элементы подвержены наименьшей корректировке.
Сферы этой классификации должны описывать то, что на конкретном предприятии находится в процессе постоянных изменений. Это позволит обеспечить адекватную реакцию на изменяющиеся внутренние и внешние условия.
Эти сферы определяют направление бизнеса, что порождает изменение программных продуктов. В них необходимо включать области, которые должны постоянно изменяться.
Приведенная классификация позволяет:
Модель архитектуры "SAM", рассмотренная нами, обладает спецификой и представляет интерес для рассмотрения и применения, но необходимо помнить о том, что самодостаточной её считать сложно и нужно использовать комплексно вместе с более техническими моделями.
Лидеры рынка информационных технологий, компании, которые во многом определяют и формируют архитектуры современных программных продуктов (Microsoft, IBM, SAP и пр.), занимаются созданием собственных методик разработки архитектуры информационных систем. Во многом это является не просто дорогой прихотью, а их обязанностью. Это следует из того, что "линейка" информационных продуктов, предлагаемых обозначенными компаниями-гигантами, покрывает подавляющую часть комплексной архитектуры предприятия. Поэтому компаниям, которые склоняются в сторону выбора решений предлагаемых технологий, необходимы адекватные практические рекомендации, подкрепленные на практике успешным опытом использования.
Наиболее популярным подходом к разработке архитектуры информационных систем и созданию релевантной технологической инфраструктуры являются группы методов, разработанных компанией Microsoft. При создании своих методик в компании Microsoft были выделены четыре основных объекта рассмотрения:
Рассматриваются, преимущественно, процессные бизнес аспекты определенной компании.
Описываются и изучаются характеристики и необходимая структура организации работ с данными.
В этом разделе представлены информационные системы с помощью которых выполняется автоматизация и оптимизация бизнес процессов предприятия.
Приведено описание необходимых физических аппаратных средств и схемы их логического взаимодействия.
Обозначенные представления, как и в большинстве рассмотренных нами методов, рассматриваются на различных уровнях понимания (концептуальном, логическом и физическом). В архитектурных концепциях Microsoft так же выделяют и описывают задачи связанные с разработкой прикладных систем, организацией процессов эксплуатации технологической инфраструктуры и создания соответствующих архитектурных шаблонов, которые могут использоваться при проектировании и разработке архитектуры программных продуктов.
Собственно выделяют следующие методики, каждая из которых отвечает на определенный тип вопросов и решает соответствующие им задачи:
Как создавать программные продукты?
Как эксплуатировать технологическую инфраструктуру?
Как правильно создавать технологическую инфраструктуру?
Как правильно создавать процессы управления технологической инфраструктурой?
Методики MSF и MSA представляют ответы на вопросы о процессах разработки архитектуры программных продуктов и инфраструктуры. Методики MOF и MSM описывают аспекты управления и эксплуатации технологической инфраструктуры и программных продуктов. Также необходимо иметь в виду, что все методики взаимосвязаны и дополняют друг друга с точки зрения комплексности представления архитектуры программного продукта конкретного предприятия, но нацелены на различные фазы жизненного цикла ИТ-решений.
Собственно, методики Microsoft сфокусированы на системном уровне архитектуры программных продуктов и обеспечивающей их технологической инфраструктуры. Каждая методика имеет своей целью реализацию определенной модели, которая должна представлять архитектуру на определенном уровне восприятия с включением концептуального, логического и физического представлений системы.
Традиционно компанией Microsoft выделена пара типов руководств и обеспечивающих методик, задача которых заключается в оптимизации процессов разработки необходимых моделей при максимальновозможной минимизации рисков.
Один из типов руководств описывает подходы к архитектурному проектированию. Оно обеспечивает:
Другой тип руководств, назначение которого имеет более широкие рамки применения в процессах разработки и проектирования - архитектурные шаблоны. Этот тип документа основан сугубо на успешном практическом опыте большого количества реализованных проектов создания программных продуктов на основе приведенных выше методик и представляет собой определенного вида архитектурный шаблон. Они содержат лучшие практики проектирования информационных систем и средства по минимизации возникающих рисков.
Эти документы – архитектурные концепции и шаблоны – должны использоваться на различных уровнях проектирования архитектуры программных продуктов.
Выше мы осветили основные архитектурные методики, которые распространены и успешно применяются при разработке программных продуктов, но это не полный список. Существует множество других методик, которые не так распространены, но находят применение в практической деятельности.
TEAF
Архитектура Казначейства США. Она создана на основе уже рассматриваемой нами методики FEAF, но отличие состоит в более глубинной специфической проработке. Причина этого – предназначение для использования в определенной организации. В состав TEAF включены шаблоны документов для большинства рассматриваемых предметных областей.
RM-ODP
В основе справочной модели открытых распределенных вычислений (RM-ODP – Reference model of open distributed processing), находятся принципы анализа информационной системы под углом зрения на разные представления реализации системы и объектно-ориентированная парадигма разработки программных продуктов. Эта методика применяется при описании архитектуры электронного правительства Германии.
В этой модели ключевыми атрибутами являются системные представления разрабатываемой модели, функции и средства обеспечения прозрачности распространения.
Модель определяет пять основных представлений:
Кроме представлений, RM-ODP содержит описание следующих функций:
Функция управления определяет то, как системой управляют, начиная с уровня узлов (серверов) и вплоть до программных объектов, которые выполняются на конкретных узлах.
Функция координации детализирует вопросы взаимосвязи событий в системе.
Функция репозитория описывает, как информация организована и хранится.
Функция безопасности описывает вопросы управления безопасностью в системе, а также методы авторизации доступа, обеспечения целостности, аудита, управления правами доступа.
Под средствами прозрачности в модели RM-ODP понимается технология обеспечения ясности, однозначности и понятности разрабатываемых функциональных, не функциональных и прочих характеристик программного продукта и его архитектуры.
В архитектурной модели RM-ODP выделено девять средств обеспечения прозрачности:
RM-ODP является достаточно интересной и эффективной моделью проектирования, но при этом нельзя сказать, что она обладает какими-то уникальными конкурентными преимуществами по сравнению с уже рассмотренной моделью Захмана или методиками Microsoft, что ставит под сомнение ее дальнейшее развитие и распространение, по крайней мере, на территории РФ.
CAFCR
Последней методикой описания архитектуры, которую мы хотим рассмотреть сегодня, является модель CAFCR , разработанная для удовлетворения потребностей компании Philips. Формально, CAFCR относится не к специфическим моделям архитектуры предприятия и предназначается для разработки определенных архитектур программных продуктов. К примеру, можно упомянуть, что рассматриваемая методика применяется при реализации глобальных систем управления автомобильным движением.
Аббревиатура СAFCR образована из названий пяти основных представлений данной модели;
Пара "верхних" представлений помогают найти ответы на вопрос "зачем создается система?". Функциональное представление описывает, "что должна система выполнять?".
Не функциональные требования к разрабатываемому программному продукту также отображены в этом виде представления и должны быть описаны в достаточном и необходимом объеме. Предпоследнее представление отвечает на вопрос "как должно осуществляться функционирование системы?" и является средством общения со спонсорами и бизнес стэйкхолдерами разрабатываемой архитектуры программного продукта. Последнее представление должно подробно описывать реализацию информационной системы. Главной задачей системного архитектора, взявшегося за разработку архитектуры по модели СAFCR является создание гармоничной, эффективной и согласованной системы, которая должна решать следующие задачи:
Отметим, что рассмотренный нами список методик и моделей, безусловно, не полный, но самые значительные и современные мы отразили. Выбор конкретной методики зависит от ряда объективных и множества субъективных факторов, но умение специалиста эффективно адаптироваться и ориентироваться в конкретном окружении отличие зрелого архитектора от новичка.
В предыдущем абзаце мы рассмотрели набор архитектурных методик, каждая из которых предоставляет собственный инструментарий, необходимый для визуализации разрабатываемой архитектуры программного продукта. Но когда речь заходит о выборе оптимальной архитектурной нотации, как правило, большинство департаментов информационных технологий (или ответственные за создание архитектуры подразделения) современных компаний склоняется к созданию собственной нотации, скомпилированной из хорошо себя зарекомендовавших, для данного предприятия, нотаций и способов моделирования бизнес процессов и структур данных архитектуры и функциональности разрабатываемого программного продукта.
Несмотря на наличие большого числа соответствующих стандартов в области описания архитектуры (ISO, IEEE, The Open Group и пр.), ни одна из них не доминирует на рынке соответствующего направления области информационных технологий.
Опрос, проведенный не так давно институтом разработки корпоративной архитектуры (США) продемонстрировал, что:
Можно сделать выводы о том, что "best practice" в проектировании и разработке соответствующей документации для обеспечения полного жизненного цикла программного продукта заключается в применении всего лучшего, что накоплено в базе знаний отрасли. В связи с этим системному архитектору или специалисту, задействованному в проектировании и реализации архитектуры программного продукта, важно детально представлять и понимать преимущества и недостатки существующих методик и нотаций, соотнесенные с ясной целью и четкими задачами, которые должны быть определены перед стартом разработки архитектуры информационной системы определенной организации.
Для проектирования и последующей реализации архитектуры программного продукта следует:
В сфере проектирования и разработки архитектуры на текущий момент развития области информационных технологий отсутствует единый источник стандартов. Следовательно, вполне корректно использовать всю доступную информацию по имеющимся методологиям для создания на их основе собственной, наиболее подходящей под конкретные нужды, адаптированной под реалии процессов проектирования и разработки архитектуры и функциональности программных продуктов.
Достоинствами этого подхода являются:
Из недостатков подобного подхода к созданию документационного обеспечения конкретной организации можно выделить то, что документация будет уникальна для конкретной компании и ее масштабирование и последующее использование в других предприятиях потребует ресурсов.
При выборе необходимых нотаций из существующих или разработке собственных методик документирования архитектуры, критично детально изучить примеры реализованных артефактов, которые достаточно эффективно описывают архитектуру программных продуктов в заданных условиях функционирования компании. При этом важно понимать, что нет догм о составе и объеме необходимых нотаций и документов. Каждый раз, сталкиваясь с специфичными особенностями определенной ситуации, необходимо по возможности адаптировать имеющиеся шаблоны и расставлять приоритеты в соответствии с практическими потребностями в тех или иных элементах описания архитектуры. Основным требованием к выбранным артефактам является их согласованность между собой, с архитектурной методикой в целом, с процессами управления и поддержки программной архитектуры.
Попытка включить в описание дополнительные нотации или документы, необходимость которых не обоснована реальными условиями или требованиями к последующему развитию архитектуры приведет к "холостому" перерасходу ресурсов.
Важно определить те области архитектуры, практическое использование которых будет определять успех конкретного программного продукта и сфокусироваться на их детальном моделировании и последующем документировании.
В процессе создания архитектурных артефактов, как обеспечивающих (документирование, проектирование и т.д.), так и основных (разработка, тестирование и т.д.) процессов реализации программных продуктов, задействованные исполнители (системный архитектор, аналитики и т.д.) выполняют проработку базиса информационной системы. Исчерпывающий набор действий, определяющий рамки создания архитектурного фундамента информационной системы, взаимосвязан с использованием выбранных нотаций или языков моделирования бизнес процессов, структур данных и т.д. Наиболее встречающимся языком архитектурного моделирования является UML, который мы рассмотрели выше. UML, как было показано, не является "панацеей" домена архитектурного проектирования программных продуктов. При этом данный язык включает в себя средства, которые поддерживают многие характеристики, составляющие большинство применяемых архитектурных моделей.
Для создания полноценного и самодостаточного программного продукта потребуется выполнить активности моделирования. Создаваемые архитектурные модели позволяют демонстрировать ожидаемую структуру и поведение функционала программного продукта в виде, доступном для понимания адресату создаваемых архитектурных артефактов. Реализованные модели архитектуры следует использовать для:
К примеру, в области строительства сооружений применяется множество видов моделирования, каждое из которых преследует определенные цели:
Мы привели пример из сферы архитектурного строительства, как "предтечи" архитектурного проектирования программных продуктов, но во множестве современных практических направлений деятельности, имеющих различную природу, к моделированию прибегают постоянно. В таких гуманитарных предметах, как социология, экономика, или не совсем гуманитарном менеджменте, моделирование используют для проверки теоретических положений и предвидения новых идей с минимально возможными рисками и затратами.
Создание эффективных моделей функциональных процессов и архитектур программных систем способствует выработке объективного обоснования рамок, которые должны охватить бизнес-процессы необходимые для автоматизации в конкретном информационном продукте. Критичным требованием к достижению результата разработки оптимального программного продукта является требование к точному соблюдению рамок внедрения и последующего функционирования системы. Если позволить рамкам "расползтись" под давлением влиятельных стэйкхолдеров, стремящихся получить более "объемный" и качественный продукт за счет ранее согласованного количества ресурсов, то результат реализации архитектуры, с высокой долей вероятности подтвержденной соответствующей статистикой, будет не достигнут и от этого, прежде всего, пострадает организация-заказчик.
Рекомендации по соблюдению рамок функциональности программных продуктов и соответствующих архитектур, а так же поддерживающей и обеспечивающей их документации состоят в необходимости соблюдения первоначальных объемов автоматизириуемых бизнес-процессов.
В ходе сегодняшней лекции мы выполнили подробное рассмотрение уровней, формирующих оптимальную архитектуру программных продуктов, изучили существующие подходы к документированию информационных архитектур, детально взглянули на современные методики документирования программных продуктов.
Обзор архитектурных моделей, пожалуй, является ядром данной лекции и должен стать отправной точкой в изучении архитектур для тех коллег, которые видят свое профессиональное развитие в сфере реализации эффективных и результативных информационных архитектур современного программного обеспечения различной степени сложности и надежности.
На сегодняшний день накоплен внушительный массив различных реализаций архитектурных моделей, каждая из которых зарекомендовала себя на практике в определенных внутренних и внешних условиях. Несмотря на это, еще рано говорить о сложившемся самодостаточно предмете архитектурного моделирования в силу недостаточной теоретической обоснованности многих практических моделей и неспособности их массового тиражирования в различных условиях.
Именно в силу необходимости подробного документирования, аналитического рассмотрения и последующей синтетической реализации, необходимо использовать эффективные модели документирования результативных архитектур программных продуктов.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.