Светлого времени дня, уважаемые коллеги!

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

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

Архитектурные концепции и методики Microsoft

Лидеры рынка информационных технологий, компании, которые во многом определяют и формируют архитектуры современных программных продуктов (Microsoft, IBM, SAP и пр.), занимаются созданием собственных методик разработки архитектуры информационных систем. Во многом это является не просто дорогой прихотью, а их обязанностью. Это следует из того, что «линейка» информационных продуктов, предлагаемых обозначенными компаниями-гигантами, покрывает подавляющую часть комплексной архитектуры предприятия. Поэтому компаниям, которые склоняются в стороны выбора решений предлагаемых технологий, необходимы адекватные практические рекомендации, подкрепленные на практике успешным опытом использования.

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

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

Рассматриваются, преимущественно, процессные бизнес аспекты определенной компании

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

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

• Программные продукты;

В этом разделе представлены информационные системы с помощью которых выполняется автоматизация и оптимизация бизнес процессов предприятия

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

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

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

Собственно выделяют следующие методики, каждая из которых отвечает на определенный тип вопросов и решает соответствующие им задачи:

• Microsoft Solutions Framework (MSF):
• Как создавать программные продукты?
• Microsoft Operations Framework (MOF):
• Как эксплуатировать технологическую инфраструктуру?
• Microsoft Systems Architecture (MSA):
• Как правильно создавать технологическую инфраструктуру?
• Microsoft Solutions for Management (MSM):
• Как правильно создавать процессы управления технологической инфраструктурой?

Методики 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 образована из названий пяти основных представлений данной модели;

• Customer objectives – Задачи заказчика;
• Application – Приложения;
• Functional – Функциональность;
• Conceptual – Концепция;
• Realization – Реализация;

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

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

• Быть ценной для стэйкхолдеров с точки зрения подтверждения их ожиданий;
• Быть технически реализуемой;
• Быть оптимальной и доступной по затратам для реализации, совершенствования и развития;

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

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

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

Несмотря на наличие большого числа соответствующих стандартов в области описания архитектуры (ISO, IEEE, The Open Group и пр.), ни одна из них не доминирует на рынке соответствующего направления области информационных технологий.

Опрос, проведенный не так давно институтом разработки корпоративной архитектуры (США)продемонстрировал, что:

• 52% предпочитали собственные наработки;
• 30% применяли модель Захмана;
• 18% использовали прочие методики;

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

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

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

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

Достоинствами этого подхода являются:

1. Концепции, структуры описания архитектуры и прочие значимые шаблоны будут разработаны с учетом конкретных факторов и условий, определяющих программный продукт и его архитектуру. В случае использования репозитория «best practice» архитектурного направления, можно с высокой долей вероятности гарантировать, что разработанные артефакты будут определяться процессами и понятиями, гармонизированными с наиболее успешными и качественными образцами отрасли;
2. После соответствующей адаптации разработанные методики будут отражать именно те детали, которые характерны для конкретной компании:
• Квалификация персонала;
• Уровень корпоративной культуры компании;
• Степенью ресурсных затрат различных иерархических уровней предприятия для поддержки работ над архитектурой программных продуктов;
• Размер финансирования;
• Пр.

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

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

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

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

Рамки архитектурных документов

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

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

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

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

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

• Архитектурное моделирование зданий – детальная визуализация создаваемых сооружений с учетом внешних факторов;
• Математическое моделирование зданий - подробное исследование вероятных нагрузок различного характера и оптимизация проекта инженерной конструкции;

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

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

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

Выводы

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

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

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

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

Иван Никитин

Михаил Цулая