Развитие сервисного архитектурного стиля

Современные технологии предлагают совершенно новые возможности изучения даже очень сложных объектов, но проблема не в том, чтобы получить данные о предприятии, а в том, как эти данные интерпретировать для формирования целостной и подробной картины. И тут на помощь приходит системный подход в виде такой дисциплины, как архитектура предприятия (Enterprise Architecture), имеющей уже полувековую историю и за этот период испытавшей и взлеты, и падения [1, 2]. Основной взлет пришелся на конец XX века, когда государственные и военные организации США увидели, что ее использование помогает более эффективно и результативно управлять ИТ-проектами, в частности — выполнять разработку и внедрение программных систем. В развитие архитектуры предприятия были вложены значительные средства, однако, не получив планируемой отдачи, инвесторы охладели к этой области. Интерес к теме угас, появились статьи, в которых отмечалось, что дисциплина зашла в тупик (habr.com/ru/post/345424). И действительно, многие материалы по архитектуре предприятия были слишком далеки от практического использования.

Однако, как часто бывает, разочарование, скорее всего, было связано с завышенными ожиданиями и невниманием к особенностям использования инструментов архитектурного проектирования [3]. Мало что меняется от того, что предприятие отрапортовало о продвижении по пути архитектурного подхода, о создании архитектурного совета и найме архитекторов. Архитектурный подход, так же как и другие технологии, развивается по кривой Gartner: сначала — большие надежды и, соответственно, значительные инвестиции, а потом — спад интереса из-за завышенных ожиданий. И лишь впоследствии технология выходит на относительно ровное плато эффективного и разумного использования.

Архитектура системы в широком смысле — это элементы системы в их взаимосвязи и развитии, поэтому архитектура вне зависимости от отношения к ней есть у каждой системы, включая и предприятие. А вот будем ли мы рассматривать различные модели и описания этой архитектуры, зависит от стоящих перед нами задач и от нашей компетентности. Отказ от системного подхода в рассмотрении предприятия повышает риск упустить что-то важное — «не увидеть леса за деревьями». Действительно, как без системного подхода объяснить синергетические, холистические свойства предприятия, которые появляются у его элементов после объединения в систему?

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

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

Рис. 1. Основные элементы классического архитектурного подхода

Первые три стадии относятся к классическому архитектурному подходу, который характеризуется последовательным, постепенным построением целевой архитектурной модели на основании анализа уже существующей. Ярче всего это проявилось на стадии «Планирование» в развиваемом и поддерживаемом The Open Group фреймворке TOGAF, который по праву считается наиболее популярным для архитектурного подхода (рис. 1) (https://www.bcs.org/content-hub/what-is-agile-enterprise-architecture).

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

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

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

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

Цикл разработки Agile Architecture в общем виде выглядит так:

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

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

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

Для того чтобы добиться гибкости (заменяемости) архитектурных компонентов и при этом не нарушить целостность, системность и надежность архитектуры предприятия, необходимо формализовать интерфейсы. Эта идея развивается уже достаточно давно — еще с технологии CORBA (Common Object Request Broker Architecture) OMG, в которой был, в частности, определен язык описания интерфейсов (Interface Definition Language, IDL).

Следующим серьезным шагом на пути к Agile Architecture стала сервисная архитектура (Service Oriented Architecture), которая также строится на стандартизации связей между элементами (сервисами), определяемыми как «видимые ресурсы, выполняющие повторяющуюся задачу и описанные внешней инструкцией». Для сервисов определены:

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

На рис. 2 приведена архитектурная модель SOA в виде основных связей между ключевыми элементами этого стиля [4].

Рис. 2. Модель связей основных элементов SOA

Однако в этой модели отсутствуют элементы контроля сервисов, хотя они и определены в SLA следующим образом: «Сервисные соглашения, которые заключаются между сущностями, выступающими в роли поставщиков и пользователей. Эти соглашения основываются на сервисных инструкциях, реализация самих сервисов инкапсулирована». Однако на схеме (рис. 3) SLA в числе основных элементов SOA не указаны.

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

Сервисная архитектура — довольно подробно описанный архитектурный стиль, реализуемый через методики, стандарты и фреймворки: веб-сервисы, включая такие стандарты, как SOAP (Simple Object Access Protocol), UDDI (Universal Description Discovery & Integration); WSDL (Web Service Definition Language); ESB (Enterprise Service Bus) и пр. Однако в них также не уделяется достаточного внимания качеству сервисов. Однако, по мере, с одной стороны, усложнения программных систем, а с другой — повышения требований к их качеству, не удается ограничиться просто реализацией отдельных архитектурных элементов и их связей. Заказчик должен понимать, не только какие сервисы он получит, но и каким качеством они будут обладать: насколько они будут надежными, безопасными, стабильными, эффективными, удобными и т. д. Таким образом, традиционная сервисная архитектура, нашедшая свое воплощение, в частности, в SOA, требует обновления — перехода на следующий уровень. В частности, можно предложить модель, расширяющую модель сервисной архитектуры (рис. 3).

В сервисной архитектуре, управляемой соглашениями [5], у владельца сервиса появляются рычаги управления сервисом на основе SLA. При этом сохраняются все преимущества сервисной архитектурной модели — реализация сервисов по-прежнему может меняться. А при изменении требований к сервису (например, в области информационной безопасности, доступности или надежности) может потребоваться замена сервиса, если он не может предоставить требуемый уровень качества. Данный подход потребует от производителей делать сервисы более гибкими и выносить в настройки параметры их уровня. Такая расширенная сервисная архитектурная модель гибче, чем классическая.

Как уже отмечалось, качеству сервисов уделяется достаточно внимания в международных стандартах и методиках, однако SLA ранее не включали в архитектурные модели. В частности, в TOGAF выделен ряд областей качества архитектурных элементов.

1. Доступность. Степень доступности чего-либо: управляемость — способность собирать информацию о состоянии и управлять им; эксплуатационная пригодность — способность идентифицировать проблемы и выполнять корректирующее действие; производительность — способность компонента выполнять задачи за требуемое время; надежность — устойчивость к сбоям; восстанавливаемость — способность восстанавливать рабочее состояние системы; локализуемость — способность найти систему при необходимости.
2. Гарантии, включая: безопасность — защита информации от неавторизованного доступа; целостность — гарантии того, что данные не будут разрушены; доверие — уровень доверия к целостности системы и ее данных.
3. Удобство использования — простота выполнения операций пользователем, включая международные операции с учетом многоязычных и мультикультурных особенностей.
4. Адаптивность, включая: интероперабельность — как внутри, так и вне организации (например, интероперабельность функций календаря); масштабируемость — способность компонента увеличивать или уменьшать производительность или мощность соответственно потребностям среды своего выполнения; портируемость данных, людей, приложений и компонентов; расширяемость — способность расширять функциональность.

В комплексе стандартов ISO/IEC 19086, посвященном SLA для участников облачных вычислений, а конкретно в стандарте ISO/IEC 19086-1:2016 «Информационные технологии. Облачные вычисления. Концепция соглашений о качестве услуг (SLA). Часть 1. Обзор и концепции», приводится структура качества сервиса (рис. 4).

Рис. 4. Структура качества сервиса, приведенная в ISO/IEC 19086-1:2016

Кроме того, вопросам качества сервисов программных продуктов посвящен комплекс стандартов SQuaRE (Systems and software Quality Requirements and Evaluation. Требования и оценка качества систем и программного обеспечения). В ГОСТ Р ИСО/МЭК 25010-2015 приведена следующая структура качества ПО: эффективность (результативность, сокращение затрат, производительность); удовлетворенность (полноценность, доверие, удовольствие от использования, комфорт); риски (смягчение рисков, сокращение вероятности наступления рисков); качество (полнота контекста, гибкость, надежность).

Объединяя модели TOGAF, ISO/IEC 19086 и SQuaRE, можно предложить следующую структуру SLA для сервисной архитектурной модели:

1. Пригодность: покрытие функциональных потребностей; удобство использования; удобство эксплуатации; мультиязычность.
2. Эффективность: производительность, доступность, надежность.
3. Безопасность/риски: доступность; конфиденциальность; восстанавливаемость; защита персональных данных; устойчивость к риску.
4. Гибкость: управляемость; интероперабельность; масштабируемость; переносимость; стабильность.

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

***

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

Литература

1. Марина Аншина. Системный подход к архитектуре предприятия // Открытые системы.СУБД. — 2008. — № 10. — С. 45. URL: https://www.osp.ru/os/2008/10/5831818 (дата обращения: 21.09.2021).

2. Марина Аншина. Нужна ли нам архитектура? // Открытые системы.СУБД. — 2008. — № 6. — С. 48. URL: https://www.osp.ru/os/2008/06/5344593 (дата обращения: 21.09.2021).

3. Santos, J., Allega, P. Hype Cycle for Enterprise Architecture. 2018. Gartner (2018).

4. OASIS Reference Model for Service Oriented Architecture 1.0. 2006.

5. Аншина М.Л. Структура и взаимодействие SLA САУС в эталонных моделях цифровой трансформации. Инжиниринг предприятий и управление знаниями (ИП&УЗ-2019). Сборник научных трудов XXII Российской научной конференции. 25–26 апреля 2019 г. Т. 1. С. 83–91.

Марина Аншина (anshina@mail.ru)  — председатель  правления Российского союза ИТ-директоров, доцент Финансового университета (Москва).