Введение

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

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

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

Практики архитектурного проектирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

С другой стороны, если сравнивать с ситуацией зарождения эры создания архитектур, то ситуация не так радужна, но насколько это сравнение корректно?

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

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

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

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

Этот «полуфабрикат», в дальнейшем, путем существенных и затратных усилий, «допроектируется» в собственное программное решение, которое постоянно надо развивать и поддерживать собственными силами.

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

• IBM (Web Sphere);
• BEA (Web Logic);
• Oracle (Oracle Application Server);
• Cordys;
• InterSystems;
• Novell;
• SAP and Sun Microsystems.

В отдельных функциональных направлениях имеются свои лидеры, как например, компания SAP является многолетним флагманом в области прикладных платформ для управления ресурсами предприятия (ERP системы).

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

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

«Правильная» архитектура уровня программных приложений представляет собой гармоничное сочетание 3 основных типов программных решений, связанных в единую систему:

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

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

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

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

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

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

Итоги

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

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

До скорого!

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

Иван Никитин

Михаил Цулая