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

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

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

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

Для начала необходимо однозначно и ясно понять:

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

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

Сделаем небольшое отступление и поясним коллегам, что тема сбора и анализа требований требует отдельного разговора (довольно длительного). В наших планах определена веха по созданию курса по этой тематике, поэтому здесь мы не будем заострять Ваше внимание на данной активности, и вернемся к ней позже. При наличии интереса мы рекомендуем ознакомиться с книгой "классика" данного направления программной инженерии К.Вигерса "Разработка требований к программному обеспечению".

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

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

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

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

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

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

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

В данной области уже накоплен определенный успешный опыт образцов архитектур и архитектурного проектирования, которые объединены в шаблоны проектирования (design patterns).

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

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

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

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

Несмотря на подобное "гуманитарное" содержание его работ, в них приведены 3 стиля применения шаблонов, которые являются общеупотребительными в процессах проектирования:

• Статическое использование шаблонов:
  • Разработка архитектуры происходит перед началом разработки кода будущего программного продукта. Данный шаблон реализуется от начала и до конца при разработке определенной функциональности программы.
  • При применении этого шаблона используется больше времени и ресурсов на ранних стадиях с тем, чтобы получить экономию при последующем сопровождении и доработке;
• Эволюционное использование шаблонов;
  • Использование этого шаблона направлено на равномерное распределение ресурсов по стадиям проекта разработки программы. В этом случае уменьшаются "вложения" в начале проекта, что способствуют получению более быстрых начальных результатов в виде функциональности, но требуются дополнительные инвестиции при внедрение шаблона на стадии сопровождения/доработки;
  • Такой подход приводит к тому, что позднее потребуются доработки архитектуры и исправление допущенных ошибок, возникновение которых неминуемо. Этот шаблон подразумевает применение процессов рефакторинга и реинжиниринга при сопровождении и развитии системы.
• Неиспользование шаблонов:
  • Использование данного шаблона оправдано только для небольшого числа проектов. Например, при работе над старым кодом, в случае крайне ограниченных ресурсов/сроков в сочетании с невысокими требованиями к качеству/сопровождаемости программного продукта.

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

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

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

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

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

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

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

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

• Выполняемые бизнес операции;
• Структура используемых данных и её составляющие;
• Прототипы экранных форм;
• Модульность системы;
• И т.д.

На этапе выбора основной практики проектирования, применение которой планируется в качестве "базиса", для создания будущей архитектуры, необходимо иметь представление о тех существующих методиках, которые на текущий момент являются эталонными:

• Модель TOGAF;
• Модель Захмана;
• Модель META Group.

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

Часть недопонимания в большинстве случаев "снимается" за счет использования одной группы/семейства нотаций, способных поддерживать преобразования диаграмм и моделей, описывающих домен бизнес понятий и процессов, в конечный продукт (код программ). Выбор набора инструментов, а вернее CASE средств, набирающих популярность, начиная с 90-х годов (Неспроста!), в которых реализована подобная функциональность, должен обеспечить формирование необходимого и достаточного минимума моделей и артефактов. Данные атрибуты процесса архитектурного проектирования должны поддерживать различные уровни архитектуры программного обеспечения, необходимые для её разработки и последующего развития.

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

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

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

• Архитектура данных;
• Архитектура приложений;
• Архитектура технологий.

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

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

Следующая стадия – переход от архитектуры бизнес-процессов и данных к созданию архитектуры приложений.

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

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

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

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

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

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

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