Главная картинка статьи №38

Архитектурное документирование. Что и Как? Начало


Доброго настроения духа, Уважаемые коллеги!

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

Введение

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

  • Масштабируемость;
  • Сложность;

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

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

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

Описанию того:

  • Что документировать?
  • Каким именно образом?
  • Что включать в документы?
  • Что учитывать в качестве факторов, которые не соприкасаются непосредственно с программным продуктом и его архитектурой, но при этом оказываю на неё сильно влияние?

будет посвящена наша сегодняшняя и несколько следующих статей.

Уровни архитектуры программного обеспечения

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

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

Для цельного понимания понятия архитектура программного продукта следует выделить следующие уровни:

  • Уровень приложения;
  • Уровень данных;
  • Уровень информации;
  • Интеграционный уровень;
  • Уровень безопасности;
  • Сетевой уровень;
  • Уровень платформы;
  • Уровень системы;

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

  • Управление доступными ресурсами/активами;
  • Управление изменениями;
  • Управление событиями;
  • Управление событиями;
  • Обеспечение уровня предоставления сервиса для бизнес процессов;

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

К примеру, уровень управления данными состоит из следующих дисциплин:

  • СУБД;
  • Файловые системы;
  • Конкретные реализации модели данных;
  • И т.д.;

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

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

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

  • SQL Server;
  • ERWin;
  • И т.д.;

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

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

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

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

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

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

Традиционно выделяют 4 взаимосвязанные субархитектуры, которые составляют целостную информационную архитектуру не только отдельных программных продуктов, но и информационной системы определенной компании:

  • Бизнес-архитектура:

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

  • Архитектуру информации:

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

  • Технологическая архитектура:

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

  • Архитектура приложений/составных компонентов:

Если мы говорим о архитектуре организации, то в этой главе рассматривается архитектура отдельного программного продукта, который является составной частью этой организационной системы и то, как он влияет на смежные с ней системы и на «систему систем». Если же мы обсуждаем отдельный программный продукт, то тут выделяют составляющие его компоненты;

В составе бизнес-архитектуры выделяют определенное количество доменов, зависящее от специфики компании, для которой разрабатывается архитектура. Выделение доменов выполняется по определенным признакам, определяемых компанией, её спецификой и манерой ведения бизнеса. В качестве примера можно привести:

  • Функциональный признак:
    • Страхование /бухгалтерский учет/интеграционное взаимодействие и т.д.;
  • Тематический признак:
    • услуги гражданам/внутренние процессы и т.д.;

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

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

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

Итоги

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

До скорой встречи!

Авторы статьи

Иван Никитин

Михаил Цулая