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

Различные аспекты понятие архитектуры ис

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

• что делает система

• на какие части она разделяется

• как эти части взаимодействуют

• где эти части размещены

Архитектура
ИС — системная архитектура (архитектура
систем — SystemArchitecture)
или программная архитектура (архитектура
программного обеспечения -SoftwareArchitecture)

Определение архитектуры ис

Архитектура
систем — концепция, определяющая модель,
структуру, выполняемые функции и
взаимосвязь компонентов ИС.

В
книге «Архитектура ПО на практике,
2-е издание» Басс, Клементс и Казман
дают следующее определение

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

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

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

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

• ИТ-архитектура

• Архитектура данных

• Архитектура приложения или программная
  архитектура

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

Совокупность
архитектур данных и архитектуры
приложений называется архитектурой ИС

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

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

Основу
бизнес-архитектуры составляют:

Бизнес-стратегии
— собрание целевых установок, планов,
руководящих, принципов, политик,
стандартов и процедур, поддерживающих
реализацию этой стратегии.

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

Показатели
эффективности

Бизнес-архитектура
отображается на ИТ-архитектуру.

Ит-архитектура

Рассматривается
в трех аспектах:

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

• как среда, обеспечивающая реализацию
  бизнес-приложений

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

Архитектура данных…

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

Программная
архитектураотображает совокупность
программных приложений.

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

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

Платформенные архитектуры информационных систем

Централизованная
архитектура

70-е
годы. Эпоха мейнфреймов — больших
централизованных ЭВМ.

Основные
особенности:

Все
базовые функции приложения реализуются
в одном месте

Все
пользователи работают одновременно на
одном компьютере

Плюсы:

• Нулевое администрирование рабочих
  мест пользователей

• Централизованная разработка и
  обслуживание системы

Минусы:

• Дорогая аппаратура оправдана только
  для больших систем

• Взаимная зависимость пользователей
  на программном уровне

• Пользователь не может настроить рабочую
  среду под свои потребности

Персональный
компьютер

Начало
80-х — пк

Архитектура
«Файл-сервер»

Появились
локальные сети. Файлы начали передавать
по сети. Сначала были одноранговые сети
— все компьютеры равноправны.

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

Основные
особенности:

Функция
хранения данных вынесена на выделенный
компьютер — файл-сервер

Поддержка
многопользовательской работы.

Плюсы:

• Многопользовательский режим работы с
  данными

• удобство централизованного управления
  доступом

• низка стоимость разработки

• невысокая стоимость обновления и
  изменения ПО

Минусы

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

• Низка производительность

• плохая возможность подключения новых
  клиентов

• ненадежность системы

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]

• #
• #
• #
• #
• #
• #
• #
• #
• #
• #
• #

Неоднозначность трактовки терминов

Подборка по базе: 2-3-65 Подходы к определению «семья» Функции и виды семей.docx, Заключительная лекция.docx, Методы доходного подхода к оценке стоимости предприятия (бизнес, Лексикология лекция 9.pdf, «Анализ видеофрагментов учебных занятий с позиции системно-деяте, О применении математических методов в культурологии в свете теза, Задание по лекциям 2-12.docx24.docx, Биохимия ЛЕКЦИЯ 10.docx, 2 лекция.docx, 28.02.2023 Лекция 4. ЧС социального характера..docx

Лекция №1. Архитектурный подход к ИС

Учебные вопросы:

• Основные понятия и определения
• Характеристика ИС как объекта архитектуры
• Базовые типы ИС

Вопрос №1

архитектура — организационная структура системы;

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

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

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

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

Стоимость рисков определяется

стоимостью бизнес-рисков,

вероятностями технических рисков и

матрицей соответствия между ними.

Матрица соответствия определяется архитектурой ИС.

Типы рисков:

• проектные риски при создании системы;
• технические риски, состоящие в простоях, отказах, потере или искажении данных;
• риски бизнес-потерь, связанные с эксплуатацией системы (возникающие, в конечном счете, из-за технических рисков). Такие риски бизнес-потерь назовем бизнес-рисками. Каждый бизнес-риск принадлежит, по крайней мере, одному из вариантов бизнес-использования (business use case) системы. Например, для интернет-магазина бизнес-риски «Покупатель не может сделать заказ и уходит» и «Покупатель делает заказ, но уходит рассерженный функционированием системы» принадлежат вариантам бизнес-использования «Сделать заказ»;

Типы рисков:

• риски бизнес-потерь, связанные с вариативностью бизнес-процессов. При этом потери происходят оттого, что, во-первых, бизнес-процессы надо изменять, а ИС не готова к этому, и потери связаны с неоптимальным функционированием бизнеса; во-вторых, приходится платить за модификацию системы. Такие риски бизнес-потерь назовем неопределенностями.

Бизнес-риски

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

Таким образом, операционные риски являются источниками бизнес-рисков.

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

Бизнес-риск может быть парирован соответствующей организацией процесса и/или архитектурным решением.

Бизнес-риски

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

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

Вопрос №2

В соответствии с Федеральным законом Российской Федерации от 27 июля 2006 г. № 149-ФЗ «Об информации, информационных технологиях и о защите информации»:

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

Другое определение:

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

Выделяются следующие типы архитектур:

• бизнес-архитектура (Business architecture),
• ИТ-архитектура (Information Technology Architecture),
• архитектура данных (Data Architecture),
• архитектура приложения (Application Architecture) или программная архитектура (Software Architecture),
• техническая архитектура (Hardware Architecture).

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

ИТ-архитектура рассматривается в трех аспектах:

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

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

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

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

В последние годы все более широкое распространение получил доменный подход к описанию ИТ-архитектур.

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

Выделяются два типа доменов:

домены задач (Problem domains) и

домены решений (Solution Domains).

Вопрос №3

Информационно-управляющие системы (ИУС)

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

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

Обобщенная структура ИУС

Компоненты ИУС

• источники данных (ИД);
• основная база данных (ОБД);
• база данных для хранения промежуточных результатов (БДХПР);
• подсистема обработки(ПО);
• подсистема генерации отчетов (ГО);
• набор человеко-машинных интерфейсов.

Компоненты ИУС

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

Компоненты ИУС

ИД включают «сырые данные», с которыми работают транзакции;

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

Компоненты ИУС

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

Компоненты ИУС

ПО предназначена для обеспечения работы с транзакциями, в частности для сравнения результатов выполнения транзакции с эталонными значениями, хранящимися в ОБД.

Подсистема генерации отчетов (ГО) обеспечивает представление информации в удобном для пользователя виде.

Данные в ИУС принято разделять на три основные группы: оперативные, тактически и стратегические.

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

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

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

Управляющие системы (УС).

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

Основными элементами типовой УС являются основной процесс (ОП), датчики (Д), исполнительные механизмы (ИМ), контроллер (К).

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

Системы мониторинга и управления ресурсами (СМУР).

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

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

Системы мониторинга и управления ресурсами (СМУР).

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

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

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

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

Под термином «управление» понимается возможность изменения текущего состояния объекта, например, изменения его местонахождения.

В качестве примеров СМУР можно привести следующие системы:

• системы управления складами;
• банковские системы;
• системы управления документооборотом;
• системы управления торговыми сетями;
• системы управления транспортными потоками;
• системы управления глобальными сетями.

Системы управления производством (СУП).

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

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

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

СУП имеет ряд особенностей.

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

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

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

Концептуальная модель функционирования СУП

Практически во всех СУП можно выделить три основных аспекта:

• материальные потоки (преобразование сырья в конечный продукт);
• информационные потоки (планирование и управление производством);
• стоимостные потоки (финансовые аспекты).

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

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

• приобретение (получение) сырья у поставщика;
• собственно изготовление;
• дистрибуция (поставка на рынок);
• продажа товара.

Информационный поток обеспечивает управление производством и планирование производства.

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

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

• стратегический уровень планирования и принятия решений;
• тактический уровень планирования и принятия решений;
• оперативный уровень планирования и принятия решений.

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

• элементы,
• узлы,
• подсистемы,
• система.

Трехуровневая организация СУП.

Системы управления доступом (СУД).

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

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

В качестве примеров систем управления доступом можно привести следующие системы:

• банкоматы;
• торговые автоматы;
• системы безопасности.

Обобщенная структура эталонной модели доступа

основные элементы:

субъекты, объекты, база данных авторизаций (БДА), подсистема аудита безопасности (ПАБ) и движок.

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

Пароль служит идентификатором, который известен только пользователю и системе.

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

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

• файлы;
• директории;
• дисковые тома;
• сетевые объекты;
• почтовые ящики;
• очереди сообщений.

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

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

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

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

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

К ней предъявляются следующие типовые требования:

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

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

• прямое управление;
• мандатное управление;
• ролевое управление.

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

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

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

Ролевое управление доступом является наиболее гибким и простым с точит зрения администрирования.

Архитектура приложений и интеграции: гайд по основным понятиям простыми словами

Мини-туториал от лида-аналитика «ITQ Group» Виталия Якубина.

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

Что такое архитектура и для чего она нужна

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

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

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

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

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

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

Наиболее понятным, на мой взгляд, кажется определение, которое объединит эти два понятия:

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

Проще говоря, если мы решили использовать HEAD-FIRST подход (сначала думай, потом делай), то без проработки архитектуры нам не обойтись. Да и в ситуации, когда мы сначала всё сделали, а потом начали думать – к вопросу архитектуры мы тоже придем, только теперь с большим объемом кода, который надо переписывать.

Виды архитектуры ПО

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

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

Во-первых, микросервисная архитектура является подтипом сервис-ориентированной архитектуры.

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

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

Model-View-Controller (MVC, «Модель-Представление-Контроллер», «Модель-Вид-Контроллер») — схема разделения данных приложения и управляющей логики на три отдельных компонента: модель, представление и контроллер — таким образом, что модификация каждого компонента может осуществляться независимо.

• Модель (Model) предоставляет данные и реагирует на команды контроллера, изменяя своё состояние.

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

• Контроллер (Controller) интерпретирует действия пользователя, оповещая модель о необходимости изменений.

Model-View-Presenter (MVP) — шаблон проектирования, производный от MVC, который используется в основном для построения пользовательского интерфейса.

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

Model-View-ViewModel (MVVM) — шаблон проектирования архитектуры приложения, представленный в 2005 году Джоном Госсманом (John Gossman) как модификация шаблона Presentation Model. Ориентирован на современные платформы разработки, такие как Windows Presentation Foundation, Silverlight от компании Microsoft, ZK framework.

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

Про масштабируемость:

• Монолит —  масштабируется не рационально(поднимаем всё) + не всегда возможно, если монолит изначально не писался с учетом масштабируемости

• Микросервисы масштабируются рационально (увеличиваем количество экземпляров только нужных сервисов.)

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

Лайфхак: никто не догадается о том, что монолит, это монолит, если не допускать людей к кодовой базе!

Виды интеграций

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

Что это означает: если у Вас есть монолитное приложение (один .exe файл), и в этом приложении один метод вызывает другой через, например, REST API, то это просто ненужное усложнение. 

Интеграция, как следует из перевода, это «внедрение». Соответственно, внедрение одного приложения в другое – целесообразно, а внедрение методов приложения один в другой – совершенно бессмысленно.

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

Первый вопрос, которым мы зададим себе — какой вид обмена нам нужен: синхронный, либо асинхронный? 

Разберём, что такое синхронное взаимодействие.

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

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

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

• 200 – 299 (успешные) – кассир отдает Вам хлеб.

• 300 – 399 (перенаправление) – у кассира хлеба нет, но он есть в соседнем магазине, о чем он Вам и сообщает

• 400-499 (клиентские) – пожалуй, самые часто встречающиеся ошибки, например, при интернет-серфинге. Означает, что запрос составлен некорректно, или цитируя  группу “Научно-технический рэп” —  «не по понятиям». Означает, что, например, у кассира хлеб есть, но конкретно фиолетовый хлеб со вкусом утренней росы, который вы запросили — в ассортименте магазина отсутствует.

• 500-599 (ошибки сервера) – что-то не то с самим кассиром, например он уснул или идентифицирует себя не как кассир, а как булка хлеба, в связи с чем не хочет продавать вам своего собрата.

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

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

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

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

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

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

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

Файловый обмен

Данный метод интеграции появился достаточно давно и проверен временем. Смысл метода в том, что система номер 1 передает в систему номер 2 файл в установленном формате(например csv). 

Плюсы данного подхода:

• Простота 

• Отсутствие необходимости соединения между системами

Недостатки:

• Скорость

• Ненадежность

• Отсутствие возможности получить информацию о валидности файла со стороны вызывающей системы

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

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

База к базе (или общая база данных)

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

На самом деле для реализации  данного подхода не обязательно, чтобы база была общей. Например в СУБД Oracle присутствует механизм database links, который позволяет получать в одной базе данных данные из другой.

Плюс данного подхода:

• Простота

Недостаток:

• Подход создает сильную связанность между системами

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

Удалённый вызов

Идея данного метод интеграции в том, что система 1 удаленно вызывает метод системы 2, передавая туда нужные параметры. Способов, как конкретно можно реализовать данную идею довольно много. К методам удаленного вызова можно отнести, например, интеграцию через http/https, с использованием REST, SOAP, GRPC и т.д. 

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

1. GRPC – opensource фреймворк для удаленного вызова процедур.

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

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

Стоит отдельно выделить, что прото-файлы также поддерживают комментирование, что очень удобно.

В целом proto-файлы оформляются в стиле, похожем на код, а если быть точным, то они описываются языком  Interface Definition Language (IDL), что делает возможным генерировать сервисы на основе прото-файлов.

Пример прото-файла:

// The greeter service definition.
	service Greeter {
 		 // Sends a greeting
 		 rpc SayHello (HelloRequest) returns (HelloReply) {}
	}
 
	// The request message containing the user's name.
	message HelloRequest {
  		string name = 1;
	}
 
	// The response message containing the greetings
	message HelloReply {
  		string message = 1;
	}

Как видим файл достаточно нагляден.

RPC позволяет реализовать как синхронное, так и асинхронное взаимодействие между сервисами.

На картинке мы можем увидеть стандартную схему применения GRPC:

У нас есть сервер GRPC, написанный на каком-либо языке (в данном случае C++) и два клиента, написанных либо на том же, либо на других языках. Соответственно, сервер может общаться одновременно с большим количеством клиентов.

GRPC используется поверх протокола HTTP/2. 

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

1. SOAP — simple Object Access Protocol («простой протокол доступа к объектам»). 

SOAP появился достаточно давно, в 1998 и был одним из первых протоколов, предназначенных для работы в парадигме RPC. Поскольку это был один из первых протоколов такого назначения, он имеет ряд недостатков:

• SOAP поддерживает только SOAP-сообщения (сообщения, имеющие строго определенную структуру, в формате XML)

• SOAP достаточно громоздкий

• SOAP не поддерживает стриминговую передачу сообщений. Поэтому в SOAP всегда один запрос – один ответ.

Структура SOAP запроса:

Envelope («конверт»). Это корневой элемент. Определяет XML-документ как сообщение SOAP с помощью пространства имен xmlns:soap=»http://www.w3.org/2003/05/soap-envelope/». Если в определении будет указан другой адрес, сервер вернет ошибку.

Header («заголовок»). Включает в себя атрибуты сообщения, связанные с конкретным приложением (аутентификация, проведение платежей и так далее). В заголовке могут использоваться три атрибута, которые указывают, как принимающая сторона должна обрабатывать сообщение, — mustUnderstand, actor и encodingStyle. Значение mustUnderstand — 1 или 0 — говорит принимающему приложению о том, следует ли распознавать заголовок в обязательном или опциональном порядке. Атрибут actor задает конкретную конечную точку для сообщения. Атрибут encodingStyle устанавливает специфическую кодировку для элемента. По умолчанию SOAP-сообщение не имеет определенной кодировки.

Body («тело»). Сообщение, которое передает веб-приложение. Может содержать запрос к серверу или ответ от него.

Пример сообщения, которое запрашивает стоимость ноутбука в онлайн-магазине:

<?xml version="1.0"?>
<soap:Envelope
	xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
	soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Body> 
	<m:GetPrice xmlns:m="https://online-shop.ru/prices">
		<m:Item>Dell Vostro 3515-5371</m:Item>
	</m:GetPrice>
</soap:Body>
</soap:Envelope>

Пример ответа сервера онлайн-магазина:

<?xml version="1.0"?>
<soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope/"
	soap:encodingStyle="http://www.w3.org/2003/05/soap-encoding">
<soap:Body>
	<m:GetPriceResponse xmlns:m="https://online-shop.ru/prices">
		<m:Price>37299</m:Price>
	</m:GetPriceResponse>
</soap:Body>
</soap:Envelope>

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

• faultcode — код неполадки;

• faultstring — «человекопонятное» описание проблемы;

• faultactor — информация о программном компоненте, который вызвал ошибку;

• detail — дополнительные сведения о месте возникновения неполадки.

SOAP может использоваться поверх протоколов SMTP, FTP, HTTP, HTTPS.

1. REST —  архитектурный стиль взаимодействия компонентов распределённого приложения в сети.

Другими словами, REST — это набор правил того, как программисту организовать написание кода серверного приложения, чтобы все системы легко обменивались данными и приложение можно было масштабировать.  REST представляет собой согласованный набор ограничений, учитываемых при проектировании распределённой гипермедиа-системы. В определённых случаях (интернет-магазины, поисковые системы, прочие системы, основанные на данных) это приводит к повышению производительности и упрощению архитектуры. В широком смысле компоненты в REST взаимодействуют наподобие взаимодействия клиентов и серверов во Всемирной паутине. REST является альтернативой RPC.

В случае, если приложение построено, в соответствии с парадигмой REST (не противоречит ей), то такое приложение называют RESTful.

Но как же так вышло, что в данном определении указано, что  REST это альтернатива RPC, а мы его отнесли к RPC способам интеграции?

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

Концепция REST не предполагает, что у объекта на сервере есть состояние + в концепции REST все объекты имеют глаголы:

• GET — получение ресурса

• POST — создание ресурса

• PUT — обновление ресурса

• DELETE — удаление ресурса

Т.е, если нам нужно, например, изменить состояние объекта на сервере, то в случае с RPC это будет выглядеть, как 

“POST /modifyItem”  и далее в теле запроса  мы передаем информацию об объекте, который мы хотим изменить. Т.е мы вызываем метод класса  modifyItem

В случае с REST запрос будет выглядеть так:

“PUT /items/456“ и в теле запроса передается информация о том, к какому состоянию должен быть приведен объект с идентификатором 456.

Простыми словами:

• REST = глагол + тип объекта + идентификатор  + параметры запроса 

• RPC = метод + параметры метода

• REST запрос обычно состоит из тела, заголовков и параметров запроса.

Также для REST API существует такое понятие как «степень зрелости REST API».  Данная модель позволяет оценить, насколько веб приложение RESTful.

Уровень 0: Собачье болото (The Swamp of POX)

В википедии данный уровень зрелости называется болотом оспы, но мне такое название не очень нравится(звучит противно), поэтому добавим немного поэзии и переведем The Swamp of Plain Old XML, как болото Простого Старого Ыксемеля, что сокращенное читается, как ПСЫ, а значит собачье.

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

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

Однако, даже для такого спорного уровня зрелости существуют свои правила:

• В URL адресах должны использоваться дефисы (-), чтобы улучшить их читаемость. Это значит, что при составлении адресов должен использоваться spinal-case.

  Пример:

  http://api.example.com/blogs/guy-levin/posts/this-is-my-first-post — хорошо

  http://api.example.com/blogs/guylevin/posts/thisismyfirstpost — плохо

• Не должны использоваться нижние подчеркивания (_)

  Тут все очевидно – смотрим правило 1

• Предпочтительно использовать строчные буквы при составлении URL адресов

  Тут тоже все понятно:

  http://api.example.com/my-folder/my-doc — хорошо

  http://api.example.com/My-Folder/my-doc — плохо

• В URL нельзя включать расширения файлов

  Это значит, что когда мы хотим получить какой-либо файл с сервера, то мы не указываем его расширение:

  http://api.college.com/student/3248234/course/2005/fall — хорошо

  http://api.college.com/student/3248234/course/2005/fall.json — плохо

Уровень 1: Уровень Ресурсов

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

http://api.articles.com/article/addNewArticle

http://api.articles.com/article/dropArticle

и т.д.

Уровень 2: Уровень методов

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

Можно реализовать данную идею, использую HTTP глаголы. Если мы хотим получить список страниц – мы можем сделать Get запрос к ресурсу /page, но если мы хотим создать новую страницу, мы можем использовать POST глаголы, вместо GET к тому же ресурсу — /page.

Уровень 2.1: HTTP заголовки

HTTP заголовки, это одно из базовых правил разработки REST API. Они нужны для того, чтобы передать больше информации о самом ресурсе: метаданные, данные авторизации и другое.

Заголовки также предоставляют запрошенную информацию о запросе и ответе, либо об объекте, отправленном в теле сообщения.

Существует 4 вида заголовков:

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

• Заголовки запроса клиента: эти поля применяются для  запросов и ответов. 

• Заголовки ответа сервера: эти заголовки применяются только для сообщений ответа.

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

Уровень 2.2: Параметры запроса

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

• Пагинация – необходима для разбивки данных на части определенного объема.

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

• Сортировка – сортировка результата запроса к коллекции ресурсов. Параметры сортировки должны содержать имена атрибутов, к которым она применяется, и разделяться запятой.

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

Уровень 2.3: Коды статусов

Очень важно, при проектировании REST API использовать соответствующие HTTP-коды статусов, особенно при разработке и тестировании RESTful API.

Наиболее часто используемые коды статусов:

• 200 — ОК: Всё работает

• 201 – CREATED: Был создан новый ресурс 

• 204 – NO CONTENT: Ресурс был успешно удален, нет тела ответа

• 304 – NOT MODIFIED: Возвращенные данные, это кэшированные данные (данные не изменились)

• 400 – BAD REQUEST: Запрос некорректный или не может быть обработан. Конкретная ошибка должна быть объяснена в теле ответа, например «JSON IS Invalid»

• 401 – UNATHORIZED: Запрос требует аутентификации пользователя.

• 403 – FORBIDDEN: Сервер принял запрос, но отклонил, либо доступ к ресурсу запрещен

• 404 — NOT FOUND: Нет ресурса, расположенного по данному URL

• 500 — INTERNAL SERVER ERROR При разработке API стоит избегать данной ошибки. Все внутренние ошибки должны обрабатываться сервером и возвращаться в читаемом виде.

Уровень 3: Hypermedia Controls

Обычно все валятся при попытке реализовать данный уровень.

Он состоит из двух частей:

• Определение контента – отвечает за определение вида контента

• HATEOS – отвечает за действия, производимые над ресурсом

Определение контента 

Обычно определение контента производится соответствующим заголовком. Например  Content-type.

HATEOS

Расшифровывается как Hypermedia As Transfer Engine Of Application State (Hypermedia как механизм передачи состояния приложения). Это ограничение REST приложений, которое отличает их от приложений другой архитектуры.

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

Пример HATEOS ответа:

{ 
    "name": "John Doe", 
    "self": "http://localhost:8080/user/123", 
    "posts": "http://localhost:8080/user/123", 
    "address": "http://localhost:8080/user/123/address" 
}

Уровень 3.1 Версионирование

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

Существует множество способов версионирования API, но приведем два наиболее используемых:

• Заголовки.

  Это могут быть настраиваемые заголовки, вроде X-API-VERSION, или любой другой

  Либо заголовок «Accept», например «Accept: application/vnd.hashmapinc.v2+json»

• URL.

  Тут все просто. Версия указывается в запросе, например POST /v2/user.

Способы организации Микросервисной Архитектуры

Существует 2 способа организации МСА: оркестрация и хореография

• Оркестрация сервисов

Оркестрация служб представляет собой единый централизованный исполняемый бизнес-процесс (оркестратор), который координирует взаимодействие между различными службами (например Camunda). Оркестратор отвечает за вызов и объединение служб.

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

• Хореография сервисов

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

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

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

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

• https://blog.restcase.com/4-maturity-levels-of-rest-api-design/

• https://ru.wikipedia.org/

• https://habr.com/ru/post/215605/?ysclid=la5tluc5jd213875439

• https://stackoverflow.com/questions/4127241/orchestration-vs-choreography

• SOAP API

• https://ru.wikipedia.org/

ИТ-архитектура является одним из важнейших компонентов организации (корпоративной архитектуры). Есть различные стандарты, подходы и модели (framework) к построению и развитию ИТ-архитектуры и корпоративной архитектуры, например: ITIL, TOGAF, ISO 15288, 20000, 27000, Zachman, COBIT, IT4IT и др. В данной статье рассмотрим комплекс основных этапов, который уже многократно зарекомендовал себя и апробирован во многих организациях. Каждый этап состоит из набора взаимосвязанных задач и инструкций. Детально они рассмотрены в источниках [1], [2] и [3].

Для создания всех графических моделей, реестров и справочников (классификаторов) по ИТ-архитектуре рекомендуется использовать специализированные программные продукты, например Business Studio, Archi, Microsoft Visio + Excel. Ключевыми исполнителями данных работ являются: ИТ-архитектор и ИТ-департамент в целом, процессный офис (или департамент бизнес-архитектуры), рабочие группы (команды) по соответствующим направлениям.

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

12 этапов построения и развития ИТ-архитектуры организации

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

1. Разработка ИТ‑стратегии

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

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

2. Разработка иерархического реестра (каталога) всех ИТ‑систем и ИТ‑платформ организации

С точки зрения TOGAF должно быть построено два иерархических реестра (дерева): слой приложений (application layer), слой системных технологий и ИТ-платформ (technology layer).

Первый слой (реестр) необходимо детализировать до модулей и функций (см. Рис. 1). В зависимости от размера организации данный реестр может иметь 5-8 и более уровней детализации (иерархии).

Рис. 1. ИТ-архитектура (на примере банка, фрагмент) и карточка (набор параметров) ИТ-системы

Перечислим минимальный набор ИТ-систем (приложений), которые работают практически в каждой организации:

• CRM и Front-office (маркетинг, продажи, работа с клиентами),
• Электронный документооборот (ЭДО),
• Кадровые и зарплатные системы,
• Бухгалтерские системы,
• Офисные системы (работа с документами и таблицами),
• BPMS (управление процессами и задачами),
• Юридические системы (договора, законодательство),
• Системы информационной безопасности (Firewall, Antivirus).

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

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

3. Заполнение детальных параметров (карточек, спецификаций) всех ИТ‑систем и модулей

Карточка ИТ-системы (см. Рис. 1) должна давать наиболее полную, структурированную и актуальную информацию, которая включает следующее:

• Контуры функционирования: test (development), pre-production, production,
• Площадки и расположение: «облачное, cloud based» (за пределами организации), собственные ресурсы,
• Типы лицензий: временные (подписка), постоянные,
• Оборудование и ИТ-платформы, на которых работают ИТ-системы (приложения),
• Владелец ИТ-системы в организации (ответственный),
• Сроки (периодичность) обновления, сроки оплаченной внешней техподдержки,
• Версия и тип (категория) ИТ-системы,
• Финансовая информация: первоначальные вложения (CAPEX), стоимость сопровождения (OPEX),
• Операционные риски и риски информационной безопасности,
• Влияние на критичную архитектуру организации,
• Требования к отказоустойчивости, дублированию компонентов и резервному копированию,
• Срок восстановления системы в случае сбоев,
• Максимальное количество пользователей,
• Зависимость от иностранного программного обеспечения,
• Комментарии и техническая информация.

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

4. Разработка архитектурных моделей ИТ-систем

Архитектурная модель ИТ-системы (см. Рис. 2) показывает основные её технические и логические компоненты, а также их взаимодействия (потоки данных). Например, серверная часть (приложение), сервер баз данных, внешние и вспомогательные сервера, клиентская часть (приложение), другие виды устройств и компонентов.

Рис. 2. Архитектурная модель программного продукта (на примере Business Studio)

5. Разработка графических моделей по интеграции (связям) ИТ-систем

Необходимо отобразить ключевые потоки данных (см. Рис. 3) между ИТ-системами организации (ИС1 <=> ИС2), между ИТ-системами и базами данных (ИС1 <=> БД1), между ИТ-системами организации и внешними субъектами, другие виды связей (в зависимости от специфики организации). Дополнительно может быть указана информация о протоколах, шлюзах, сервисах, требованиях и т. п.

Рис. 3. Модели интеграции ИТ-систем (общий вид, без детализации названий фигур и стрелок)

6. Разработка иерархического реестра (каталога) всех баз данных (структур данных) и их параметров

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

7. Разработка технической архитектуры и дополнительных моделей (в зависимости от задач)

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

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

• Владелец оборудования в организации (ответственный),
• Зависимость от иностранных производителей,
• Сроки периодического технического обслуживания и ремонта,
• Финансовая информация: первоначальные вложения (CAPEX), стоимость сопровождения (OPEX),
• Влияние на критичную архитектуру организации,
• Расположение оборудования (локация),
• Операционные риски и риски информационной безопасности по оборудованию,
• Требования к отказоустойчивости, дублированию, резервированию,
• Комментарии и другая информация.

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

В дополнение к технической архитектуре могут разрабатываться другие модели под разные задачи, например в форматах (нотациях): BPMN, ArchiMate, UML. Большое количество примеров содержатся в источниках [1] и [3].

8. Установление связей объектов и моделей ИТ‑архитектуры с объектами и моделями бизнес-архитектуры

Очень важно, чтобы построение и развитие ИТ-архитектуры и бизнес-архитектуры выполнялось внутри одной базы данных и платформы, например Business Studio [4]. Только в таком случае мы сможем быстро и эффективно установить большое количество связей (со стратегией, бизнес-процессами, показателями KPI, организационной структурой), проследить взаимные влияния, оценить функционирование и полноту (целостность) всей корпоративной архитектуры.

9. Проработка операционных рисков (ИТ-рисков) и системы информационной безопасности

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

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

10. Разработка нормативных документов и форм документов

Все рассмотренные выше этапы (работы) и их результаты должны быть детально документированы, см. [1]. Разрабатываются и актуализируются нормативные документы, например:

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

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

11. Проведение аудита (оценки) ИТ-архитектуры по чек-листу и аналитических работ

Необходимо разработать и заполнить чек-лист с детальными требованиями (более 100). Фрагмент приведён на Рис. 4. Способы оценки требований: наблюдение за работой ИТ-систем и оборудования, наблюдение за работой ИТ-персонала, интервью и опросы сотрудников, изучение документов и отчётов (включая историю значений показателей, историю операционных рисков и др.). На основе проведённого аудита составляется план задач для проработки выявленных недостатков и включается в план развития (оптимизации) ИТ-архитектуры на следующий период (этап 1).

Рис. 4. Фрагмент чек-листа «Диагностика и аудит ИТ-архитектуры организации»

12. Сбор новых требований и задач к автоматизации и цифровизации от подразделений

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

Рекомендуемая литература и источники информации:

1. Большая библиотека системного аналитика и ИТ-архитектора.
2. Исаев Р. А. ИТ-архитектура организации и система регламентации ИТ-департамента.
3. Исаев Р. А. 60 примеров успешных и проблемных проектов организационного развития.
4. IT Architect: система управления ИТ-архитектурой.
5. Большая библиотека риск-менеджера и специалиста по операционным рискам

Опубликовано по материалам:
https://www.it-world.ru/cionews/business/184573.html

Май 2022 г.

Рекомендуемые материалы по тематике

Best practice проектов автоматизации бизнес-процессов. От методологии до инструментария. Часть 1 — интервью с руководителем консалтинговых проектов «Консист Бизнес Групп» Андреем Кочетковым

Применение процессной модели при внедрении информационных систем

Цифровой двойник организации: требования, структура, примеры

Подходы к автоматизации

Предложите, как улучшить StudyLib

(Для жалоб на нарушения авторских прав, используйте

другую форму
)