02.04.2018

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

«Недавно я попытался задуматься об истории системной инженерии. И то, что система была спроектирована, совсем не значит, что проектировщик держал в уме именно саму систему, а не ее отдельные компоненты. Самая ранняя система, о которой я читал в подробностях — это венецианский арсенал в период его рассвета около 1200-1400. У них была производственная линия, и к моменту, когда корабль сходил с линии, веревки, мачты, паруса и даже обученная команда были на своих местах и корабль сразу же отплывал! Через регулярные интервалы времени новый корабль выходил из арсенала. Это ранний пример производства типа «вовремя», включая людей, которые были должным образом подготовлены к моменту производства оборудования.»

В данной работе предпринимается попытка осознать необходимость принципов системной архитектуры, системной инженерии для развития ФИНТЕХа  в сфере государственного управления, а также возможность классификации и применения уже сложившейся терминологии и подходов при проектировании информационных систем в сфере государственных финансов.

ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем (см. ISO/IEC 15288:2008)

ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)

ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом (см. ISO/IEC 16326)

ГОСТ Р ИСО/МЭК 15288-2005 Информационная технология. Системная инженерия. Процессы жизненного цикла систем (см. ISO/IEC 15288:2008)

ГОСТ Р ИСО/МЭК 12207-2010 Информационная технология. Системная и программная инженерия. Процессы жизненного цикла программных средств (см. ISO/IEC 12207:2008)

ГОСТ Р ИСО/МЭК ТО 16326-2002. Программная инженерия. Руководство по применению ГОСТ Р ИСО/МЭК 12207 при управлении проектом (см. ISO/IEC 16326)

ГОСТ Р ИСО 15926-1-2008 Промышленные автоматизированные системы и интеграция. Интеграция данных жизненного цикла для перерабатывающих предприятий, включая нефтяные и газовые производственные предприятия (см. ISO 15926-1:2004)

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

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

Первое правило системной инженерии — если оптимизировать компоненты, то, вероятнее всего, производительность системы будет испорчена. Это очень сложный для понимания момент. Обычно кажется очень разумным, что вся система улучшится, если улучшить отдельный её компонент, но это неверно. Более вероятно, что производительность системы ухудшится.

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

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

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

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

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

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

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

Факторы формирования системной архитектуры в сфере государственных финансов региона — cтруктура междисциплинарных связей 

Sysarch

Для более подробного описания принципов построения архитектуры стандарт ISO/IEC/IEEE 42010-2011 вводит следующие понятия.

Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания.

Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры.

Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом стейкхолдеров.

Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам.

Вид модели (англ. model kind) — соглашения по средствам моделирования (например, сети Петри, диаграммы классов, организационные диаграммы и т. д.).

Архитектурный артефакт — конкретный документ, отчет, аналитический отчет, модель или любой другой компонент архитектурного описания.

Эталонная модель бизнеса (BRM) — термин FEA, обозначающий бизнес-представление различных функций правительства.

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

Архитектура данных — архитектура принадлежащих предприятию данных (обычно хранящихся в базах данных).

Эталонная модель производительности (PRM) — термин FEA, обозначающий стандартные способы описания терминов, связанных с оценкой полезности.

Рентабельность инвестиций (ROI) — величина (в процентах) ценности проекта, равная приросту прибыли (либо благодаря увеличению доходов, либо благодаря снижению расходов), деленному на стоимость проекта.

Виды системной архитектуры

Свод знаний по системной инженерии (SEBoK) делит архитектуру на логическую и физическую

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

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

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

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

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

Архитектурное описание

Архитектура может быть зафиксирована с помощью полного архитектурного описания (АО). Стандарт ISO/IEC/IEEE 42010-2011 предписывает различать концептуальную архитектуру системы и одно из описаний данной архитектуры, являющееся конкретным продуктом или артефактом.

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

Концептуальный подход

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

Например, роли между «системой» и «средой» могут читаться: «„система“ живёт в „среде“» и «„среда“ влияет на „систему“».

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

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

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

«Любая система существует для реализации в своей среде одной или более миссий.»

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

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

Функциональная группа описаний

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

Логическая группа описаний

Данная группа обеспечивает представление с точки зрения руководителя или заказчика. Логическое представление включает продукты, которые определяют системные границы с её окружением и функциональные интерфейсы с внешними системами, также основные функции и поведение системы, потоки информации, внутренние и внешние наборы данных, внутренних и внешних пользователей, и внутренние функциональные интерфейсы. Примером продуктов могут быть блочные диаграммы функциональных потоков[en] (FFBD), контекстные диаграммы, IDEF0-диаграммы, данные поточных диаграмм и различных стейкхолдеров — характерные продукты (в том числе бизнес-зависимые продукты).

Физическая группа описаний

Данная группа обеспечивает представление с точки зрения проектировщиков. Включает в себя:

— продукты, которые определяют физические границы системы;

— физические компоненты системы и то, как они взаимодействуют и влияют друг на друга;

— внутренние базы данных и структуры данных;

— инфраструктуру информационных технологий (ИТ) системы;

— внешнюю ИТ-инфраструктуру, с которой система взаимодействует;

— требования, необходимые для развития системы.

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

Применение архитектурных описаний

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

— анализ альтернативных архитектур;

— деловое планирование перехода от унаследованной архитектуры к новой;

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

— коммуникация между заказчиками и разработчиками как часть подготовки соглашения;

— критерии для сертификации соответствия реализации данной архитектуре;

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

— исходные данные для последующих мероприятий по системному проектированию и разработке;

— исходные материалы для инструментов создания и анализа системы;

— эксплуатационная и инфраструктурная поддержка; управление конфигурацией и ремонт; перепроектирование и обслуживание систем, подсистем и компонентов;

—  поддержка планирования и финансирования.

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

Исчерпывающего списка типов (групп) стейкхолдеров не существует, так как для различных целевых систем они могут значительно отличаться. Можно привести примеры наиболее распространённых типов (групп) стейкхолдеров, которые упоминаются в стандартах (ГОСТ Р ИСО/МЭК 15288:2005, ISO/IEC 29148:2011, ГОСТ Р ИСО/МЭК 12207:2010, OMG Essence), Своде знаний по системной инженерии (SEBoK) и учебниках по системной инженерии:

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

— Заказчик, или клиент (англ. customer) — организация или физическое лицо, получающее продукт или услугу.

— Разработчик (англ. developer) — организация или физическое лицо, которое выполняет задачи разработки, включая анализ требований, проектирование, тестирование в течение всего жизненного цикла.

— Поставщик (англ. supplier) — организация или физическое лицо, которое вступает в соглашение с приобретающей стороной на поставку продукта или услуги.

— Пользователь (англ. user) — лицо или группа лиц, извлекающих пользу в процессе применения системы.

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

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

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

— Аккредитор, или инспектор (англ. accreditor) — организация или физическое лицо, выполняющее проверку системы на соответствие требованиям в процессе сдачи системы в эксплуатацию.

— Регулирующий орган (англ. regulatory bodies) — организация или физическое лицо, проверяющее систему на соответствие требованиям в процессе эксплуатации.

— Остальные — персонал поддержки (англ. supporters), инструкторы (англ. trainers), операторы (англ. operators).

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

Роль стейкхолдеров в управлении портфелем проектов

В стандарте ГОСТ Р ИСО/МЭК 12207:2010 (ISO/IEC 12207:2008) отмечено, что в механизме управления изменениями контракта необходимо отразить роли и ответственность руководства, уровень формализации заявок на предложенные изменения и дополнительных переговоров по контракту, а также связи со стейкхолдерами.

В результате успешного управления портфелем проектов:

— уточняются, расставляются по важности и выбираются возможности, инвестиции или потребности деловой сферы с учетом рисков;

— определяются и распределяются ресурсы и денежные средства для каждого проекта;

— изменяются или ликвидируются проекты, не удовлетворяющие условиям соглашения или запросам стейкхолдеров;

— формулируются полномочия и ответственность руководства проектом;

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

Роль стейкхолдеров в управлении качеством

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

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

Роль стейкхолдеров в управлении рисками

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

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

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

Роль стейкхолдеров в технических процессах

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

Роль стейкхолдеров в процессе определения требований

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

Результатами успешного осуществления процесса определения требований стейкхолдеров является:

— требуемые характеристики и условия использования услуг;

— формализованные ограничения для системных решений;

— возможность прослеживания от требований стейкхолдеров к стейкхолдерам и их потребностям;

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

— основа для валидации соответствия услуг;

— сформированная основа для ведения переговоров и заключения соглашений о поставке услуги или продукции.

Процесс идентификации требований состоит из решения следующих задач:

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

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

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

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

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

— Архитектура программного обеспечения (англ. software architecture) — совокупность важнейших решений об организации программной системы.

— Архитектурный подход (англ. architectural framework) — соглашения, принципы и практики для описания архитектуры, установленные для конкретной области применения и/или конкретным сообществом заинтересованных лиц.

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

—  Информационная архитектура (Enterprise Information Architecture, сокр. EIA), набор методик и инструментов, описывающий информационную модель предприятия. Включает:

— базы данных и хранилища данных;

— информационные потоки (как внутри организации, так и связи с внешним миром).

— Архитектура прикладных решений (Enterprise Solution Architecture сокр. ESA) – представляет архитектуру приложений, включающую в себя совокупность программных продуктов и интерфейсов между ними. Делится на два направления:

-область разработки прикладных систем;

-портфель прикладных систем.

Техническая архитектура (Enterprise Technical Architecture сокр. ETA) — совокупность программно-аппаратных средств, методов и стандартов, обеспечивающих эффективное функционирование приложений. Описывает полное представление инфраструктуры предприятия, включая:

-информацию об инфраструктуре;

-системное программное обеспечение (СУБД, системы интеграции);

-стандарты на программно-аппаратные средства;

-средства обеспечения безопасности (программно-аппаратные);

-системы управления инфраструктурой.

Бизнес-архитектура (Enterprise Business Architecture, ЕВА) — целевое построение организационной структуры, увязанное с его миссией, стратегией, бизнес-целями. В ходе построения бизнес-архитектуры определяются необходимые бизнес-процессы, информационные и материальные потоки, а также организационно-штатная структура.

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

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

— Архитектурная группа описаний (англ. architectural view) — представление системы в целом с точки зрения связанного набора интересов. Каждая группа описаний относится к одному или более стейкхолдеру. Термин «группа описаний» употребляется для выражения архитектуры системы при некотором методе описания.

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

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

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

Архитектурное описание (англ. architectural description) — рабочий продукт, использующийся для выражения архитектуры.

Архитектурный метод описания (англ. architectural viewpoint) — спецификация соглашений для конструирования и применения группы описаний. Шаблон или образец, по которому разрабатываются отдельные группы описаний посредством установления назначений и аудитории для группы описаний, а также приемы их создания и анализа. Метод описания устанавливает соглашения, по которым группа описаний создается, отображается и анализируется. Тем самым метод описания определяет языки (включая нотации, описания или типы продуктов), применяемые для определения группы описаний, а также все связанные методы моделирования или приемы анализа, применяемые к данным представлениям группы описаний. Данные языки и приемы применяются для получения результатов, имеющих отношение к адресуемым интересам.

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

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

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

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

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

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

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

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

В качестве Слоев рассматриваются конструктивные субсистемы, образующие некое самодостаточное представление (срез) организации. А Аспекты в свою очередь относят элементы, к одному из трех основных типов:

—  Активный структурный элемент (active structure element) позиционирует его, как некую сущность, которая способна выполнять определенные действия

— Пассивный структурный элемент (passive structure element) позиционирует его, как некоторый объект, над котором выполняются действия.

— Элемент поведения (behavior element) определяется как некоторая единица действия, выполняемая одним или несколькими активными структурными элементами.

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

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

-Подход «статус-кво». Разработка рассматривается как реакция на те или иные возникающие затруднения или воздействия.

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

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

Требования и стандарты

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

-Даются ссылки (код, наименование, редакция и т. д.) на внешние стандарты. При необходимости приводятся полностью или частично тексты внешних стандартов.

-Описываются внутренние стандарты (стандарты предприятия) с указанием кода (если присвоен), наименования, редакции и утвердившего органа.

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

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

Прикладная архитектура

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

Техническая архитектура

-Сетевая архитектура. Содержит описания территориальной коммуникационной инфраструктуры и локальных вычислительных сетей (ЛВС).

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

-Архитектура данных. Базы и хранилища данных. Содержит описание баз данных и иным способом организованных информационных массивов.

-Системы управления базами данных. Содержит описание используемых систем управления базами данных.

План миграции

Содержит план миграции от текущей системной архитектуры к перспективной.

Если предполагается поэтапная миграция, то сюда же включаются промежуточные миграционные планы.

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

Системная архитектура

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

Прикладная архитектура включает в себя:

-прикладные системы (приложения), обеспечивающие исполнение бизнес- функций и бизнес-процессов;

-интерфейсы взаимодействия прикладных систем между собой и с внешними системами и источниками или потребителями данных;

-средства и методы разработки и сопровождения приложений.

Архитектура данных включает в себя:

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

-применяемые для этого системы управления базами данных или хранилищами данных;

-правила и средства санкционирования доступа к данным.

Техническая архитектура состоит из сетевой архитектуры и архитектуры платформ.

Сетевая архитектура включает в себя:

— локальные и территориальные вычислительные сети, включая физические собственные и арендованные каналы связи и каналообразующую аппаратуру;

— используемые в сетях коммуникационные протоколы, сервисы и системы адресации;

— аварийные планы по обеспечению бесперебойной работы сетей в условиях чрезвычайных обстоятельств.

Архитектура платформ включает в себя:

— аппаратные средства вычислительной техники — серверы, рабочие станции, накопители и другое компьютерное оборудование;

— операционные и управляющие системы, утилиты и офисные программные системы;

— аварийные планы по обеспечению бесперебойной работы аппаратуры (главным образом — серверов) и баз данных в условиях чрезвычайных обстоятельств.

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

Технологическая архитектура (архитектура инфраструктуры)

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

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

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

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

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

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

— вычислительная инфраструктура — операционные системы и аппаратное обеспечение (приложения для настольных систем, операционные системы для настольных систем, мобильные устройства — ноутбуки, беспроводные устройства, персональные цифровые помощники, серверы приложений/данных, сетевые операционные системы, принтеры), среда для веб-инфраструктуры (браузеры, веб-порталы, веб-серверы, средства управления и создания контента, серверы каталогов, форматы публикации информации), системы хранения (Storage Area Network — сети хранения данных, накопители на магнитных лентах, накопители на оптических дисках и CD, системы хранения высокой надежности RAID), средства системного управления (средства сетевого управления, администрирование IP), топологии (топология распределенных приложений);

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

— сервисы безопасности — авторизация, аутентификация (внутренняя и внешняя аутентификация — РКГ), сетевая безопасность (Network Firewall, Internet Firewall), физическая безопасность центров обработки данных, прочие сервисы безопасности (обнаружение вторжений, защита от вирусов).

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

Достаточно легко определить тенденции в современном ИТ-мире: аутсорсинг, глобализация, увеличение степени правовой регламентации, постоянное усложнение задач.

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

— на первом уровне, директорском (так называемый Clevel management, включающий генерального директора — CEO, директора по оперативному управлению — СОО, СЮ, финансового директора — CFO и др.), принимаются решения о стратегически важной деятельности. В центре внимания здесь находятся ключевые компетенции, используемые компанией для производства продукции. Одна из главных обязанностей СРО — определять основной курс управления бизнес-процессами, создавать и внедрять необходимые методы, инструменты и платформы;

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

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

Для лиц, выполняющих эту роль, особенно важны следующие  управленческие навыки:

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

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

CGO (Chief Governance Officer) — директор по корпоративному управлению. Он отвечает за организацию эффективного взаимодействия всех отделов друг с другом и развитие системы коммуникаций в организации. Поле деятельности для CGO не ИТ, а БТ — прикладные технологии. Внедрять нужно только те новые технологии, которые позволяют решать задачи.

Лицензия Creative Commons
Это произведение, автор которого — Aleksei Prytkov (Алексей Прытков), доступно на условиях лицензии Creative Commons С указанием авторства-Некоммерческая-С сохранением условий 4.0 Всемирная.