# ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации Vision (Концепция) Сервисы АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Типы интеграции Solution Design (Проектное решение) DDD Микросервисы и service mesh ESB HTTP/REST RPC DevOps CI/CD/CDP VM и Docker Контракты API Оценка задачи git Frontend Apache Регулярка Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования Уровни тестирования Виды тестирования Баг-репорт Шаблоны Тестирование требований Тест-анализ Тест план Тест дизайн Метрики качества Автотесты Selenium XPATH Генератор данных Безопасность Нагрузочное ДАННЫЕ Ресурсы MDM Big data Об информации SQL intro MongoDB intro БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее Красивые диаграммы Арт
Эта страница:
Черпнуть мудрости ПО для работы с Архитектурой Архитекторы - кто? Архитектурные слои язык Archimate GAP-анализ Сервис-ориентированная архитектура (SOA) Типы интеграции Оркестрация и хореография CQRS - отделение чтения от записи
Другие страницы:
АРХИТЕКТУРА Solution Design Document DDD Микросервисы и service mesh ESB HTTP/REST RPC
Другие разделы:
# АНАЛИЗ АРХИТЕКТУРА ДАННЫЕ DevOps БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Архитектура
last update: 17-10-2020, 08:17
Черпнуть мудрости

О легаси, монолитах

Книги

  • (PDF) Introduction to Solution Architecture (Alan McSweeney, 2019)
  • (PDF) Эволюционная архитектура. Поддержка непрерывных изменений (Н.Форд, Р.Парсонс, П.Куа, 2019)

Управление архитектурой предприятия (Enterprise architecture management, EAM)

Как управляют архитектурой в крупных компаниях, банках: скачать схему в формате diagrams.net (бывший draw.io)

Методологический фреймворк TOGAF

TOGAF это методологический фреймворк управления изменениями множества вложенных систем, совокупность которых называется Корпоративной Архитектурой (Enterprise Architecture).
Необходимо понимать, что любой фреймворк спроектирован избыточно, соответственно, брать из него следует только ключевое -- архитектурный цикл ADM -- и то что покажется полезным и необходимым для конкретной организации.

Идеальный архитектурный цикл:

  1. подготовить и согласовать со всеми причастными сторонами архитектурное видение
  2. разработать структуру сервисов уровня бизнес-архитектуры
  3. разработать структуру бизнес-процессов и бизнес-функций
  4. разработать структуру бизнес-ролей, связанных с процессами
  5. разработать организационную структуру, связанную со структурой бизнес-ролей
  6. разработать модель данных компании
  7. разработать архитектуру корпоративной информационной системы
  8. разработать технологическую архитектуру
  9. выбрать конкретные решения для всех уровней архитектуры
  10. разработать пакеты работ
  11. реализовать проект
  12. провести аудит: убедиться в достижении целей, какой ценой, какие были совершены ошибки.
ПО для работы с Архитектурой
Архитекторы - кто?
В реальности могут встретиться следующие вариации:
  1. Менеджер по стратегии -- занимается разработкой карты сбалансированных показателей (BSC, balanced scorecard) и декомпозицией стратегии предприятия на подцели.
  2. Корпоративный архитектор (Enterprise architect) -- занимается всей архитектурой Предприятия (Enterprise architecture) и архитектурным надзором. В подчинении архитекторы по направлениям/уровням.
  3. Бизнес-архитектор (Business architect) -- занимается бизнес-архитектурой (Business architecture), т.е. разработкой элементов бизнес-процессов (совместно с Бизнес-аналитиками).
  4. IT-архитектор -- занимается архитектурой данных (Data), архитектурой приложений (Application) и технологической архитектурой (Technology).
  5. Архитектор решений (Solution architect) -- занимается архитектурой данных (Data) и архитектурой приложений (Application) в ключе проектирования интеграционного взаимодействия ИТ-систем.
  6. Системный архитектор -- занимается архитектурой данных (Data) и архитектурой конкретного приложения (Application).

Базовые знания для архитектора:

  1. Системная инженерия (systems engineering), хотя бы базовое ознакомление.
    Это порядка 30 часов лекций + изучение статей и книг-первоисточников.
    !! Не путать с т.н. "системным инженером" - в российских реалиях это системный администратор.
    (опционально) общее знакомство с ISO 15288-2015 и ГОСТ Р 57193-216. Именно это и есть системная инженерия.
  2. ЖЦ разработки ПО (software development lifecycle). Проистекает из концепции ЖЦ систем, о котором речь идёт в системной инженерии.
  3. Понимание что такое Корпоративная архитектура (enterprise architecture) и IT-архитектура в частности (Архитектура данных и Архитектура приложений).
    Это порядка 25 часов на лекции + изучение статей и первоисточников.
  4. Понимание архитектурного цикла (ADM) и сути TOGAF. Не обязательно штудировать весь фреймворк от корки до корки, достаточно общего ознакомления.
    Это порядка 10 часов лекций + изучение статей и первоисточников.
  5. Знакомство с Теорией ограничений (ToC, theory of constraints).
    Это порядка 10 часов на вдумчивое чтение работы Голдратта.
  6. Понимание сути Сервис-ориентированной архитектуры (SOA, service-oriented architecture).
    Это порядка 5 часов на лекции + изучение статей и первоисточников.
  7. Понимание сути Цепи поставки ценности (value chain).
    Это максимум 2 часа на лекции + изучение статей и первоисточников.
  8. Понимание сути Сбалансированной системы показателей (BSC, balanced scorecard).
    Это максимум 2 часа на лекции + изучение статей и первоисточников.
  9. Умение читать BPMN, UML, UML sequence diagram, Use case, ...
  10. Свободное владение языком архитектурного моделирования Archimate.
    Это порядка 15 часов на лекции + изучение статей и первоисточников.
    Затем практика, практика и ещё раз практика.
  11. Владение каким-либо из ПО для архитектурного описания: Archi, Enterprise Architect, Modelio BA / Modelio SA, Modelio SD.
  12. Знание принципов DDD (domain driven design), BPM (business process modeling), microservices.
  13. Знание английского на уровне, достаточном, чтобы спокойно читать статьи, смотреть/слушать лекции.
  14. (опционально) образование по специальностям: ЭВМКСиС | АСУ | ПОВТ | Информатика в экономике | Информационные системы и технологии.
  15. (опционально) опыт работы
    • в компаниях системных интеграторах
    • в консалтинговых компаниях на ролях системного-/бизнес- аналитика-консультанта
    • системным аналитиком
    • Разработчиком, участвовавшим в интеграции зоопарка ИС

Какие возможности должны быть у Архитектора в рамках Предприятия

  1. доступ к описанию Бизнес-процессов Предприятия
  2. доступ к описанию ИТ-систем Предприятия, их Интерфейсов, компонентов
  3. доступ к описанию Технологического слоя (возможно, CMDB)
  4. доступ к использованию с рабочего места бесплатного ПО Archi И платного ПО Enterprise Architect ИЛИ платного ПО Enterprise-версии Modelio: Modelio BA, Modelio SA, Modelio SD.
  5. максимально оперативно и безотказно получать информацию от Аналитиков, Разработчиков, Тестировщиков, консультантов, методологов, бизнес-подразделений, других Архитекторов для максимально быстрого пополнения знаний об архитектуре AS IS.

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

  1. Архитектору предприятия (Enterprise architect) и Бизнес-архитектору (Business architect):
    • Стратегические цели Предприятия и Сбалансированная карта показателей;
    • IT-стратегия Предприятия;
    • описание текущей (AS IS) Бизнес-архитектуры и IT-архитектуры;
    • Бюджет;
  2. Архитектору решений (Solution architect):
    • описание текущей (AS IS) Бизнес-архитектуры и IT-архитектуры;
    • Имеющееся архитектурное описание Бизнес-процессов AS IS;
    • Имеющееся архитектурное описание уровней Application, Component AS IS эксплуатируемых ИС;
    • Бизнес-требования и Проектная концепция к доработке/внедрению ИС.
    • Бюджет проекта;

Что Архитектор делает и производит

  1. (Бизнес-архитектор) моделирование архитектуры Бизнес-процессов As Is и To Be;
  2. моделирование IT-архитектуры As Is и To Be, реализующей необходимые Бизнес-процессы;
  3. совместно с Бизнес-аналитиком (Методологом) -- консультация по Ограничениям, заранее отсеивая безумные варианты реализации бизнес-идеи;
  4. совместно с Заказчиком, Бизнес-аналитиком (Методологом), Ключевым пользователем -- обсуждение/уточнение возможных Use Cases;
  5. совместно с Системным аналитиком -- определение границ изменяемой/разрабатываемой ИС и контекста её работы;
  6. принимать решения по изменению структуры и поведения конкретных ИС, обеспечивающих основные и вспомогательные Бизнес-процессы Предприятия;
  7. составление Проектного решения (Solution Design)
  8. поддержка архитектурного репозитория в актуальном состоянии
  9. самообучение: 4+ часов в неделю на ознакомление со смежными/новыми технологиями и практиками
Архитектурные слои

Если кратко, то
Корпоративная Архитектура / Архитектура Предприятия / Enterprise Architecture = совокупность структур, которые образуют компанию.
Т.е. все три строчки:

Объекты работ Работы (действия) Исполнители
объекты деятельности процессы/практики люди слой Деятельности (business layer) - Архитектура бизнес-процессов
данные функционал программы слой Приложений (application layer) - Архитектура IT-решения
информобъекты функционал оборудование слой Технологический (technology/component layer) - Технологическая архитектура

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

Полный архитектурный цикл TOGAF можно уложить в слои Archimate 3:

Пример отображения трёх архитектурных слоёв на языке Archimate

Слой "Мотивация"

Пример:

(скачать это представление в формате ARCHIMATE)

язык Archimate

Archimate (Архимейт) = язык архитектурного описания корпоративных и инженерных систем (моделирования архитектуры Предприятия). ArchiMate предназначен для высокоуровневого моделирования и анализа различных областей предприятия и взаимосвязей между ними.
Он не фокусируется на деталях реализации и не заменяет UML, BPMN или ERD, а дополняет их. В Archimate меньше возможностей по детализации, чем в этих языках моделирования, но он позволяет связать описания различных областей и разработать интегрированное представление организации.

Что изучить на тему:
GAP-анализ
Ресурсы:

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

Прямо по "правой" половине архитектурного цикла TOGAF:

  1. Архитектор должен быть снабжён очень серьёзными полномочиями, в противном случае всю дальнейшую работу будет ждать саботаж.
    В больших компаниях всегда есть некомпетентные и ленивые работники, есть завистники, есть желающие перехватить власть и/или бюджет, любители использовать чужой успех для личного карьерного роста, да и просто противники изменений.
    Спектр возможных негативных последствий - от личных трагедий до потерь миллионов денежных знаков Предприятия.
  2. Опросив руководителей высшего уровня, определить, что является мотивацией (Motivation) к последующим изменениям в Предприятии.
    • Опросить наиболее важных стейкхолдеров (от генерального директора до линейных руководителей) о существующих проблемах.
    • Зафиксировать озвученные проблемы (Driver), по каждой дать оценку (Assessment), являющую собой причину проблемы, определить цель (Goal) как решение проблемы, и требования (Requirement), которые должны привести к цели.
    • Могут (и будут) быть зафиксированы заведомо известные ограничения (Constraint), встающие на пути к цели.
    Результат - нечто подобное:
  3. Ознакомление со стратегическими целями Предприятия
    И сбалансированной картой показателей ИЛИ результатами применения Теории Ограничений (Theory of Constraints).
    ЕСЛИ нет стратегических целей и неизвестно где в Предприятии "узкое горылшко", то их необходимо определить и обозначить.
    Без них невозможно будет создать адекватную целевую архитектуру, а изменения ради изменений это ерунда.
    Необходимо знать чего хочет достигнуть руководство Предприятия, от этого зависит какие изменения потребуется внести в бизнес-процессы и оргструктуру, от этого - какие изменения внести в ИТ-архитектуру, в физические объекты и т.д.
  4. На основе опросов руководителей (и авторитетных специалистов) всех уровней, а также ознакомления с принятыми регламентами, стандартами и служебными инструкциями
    • составить представление о текущей архитектуре (baseline architecture) Предприятия (или вверенного вам его участка, например, производство), а именно о, последовательно:
      1. Бизнес-архитектуре:
        • отражена структура Предприятия;
        • отражены связи Акторов (действующих лиц - структурных подразделений, их начальников и т.п.) и Ролей (Business Role)
        • отражены связи Ролей и Бизнес-функций (Business Function) или Бизнес-процессов (Business Process)
        • выстроены в цепочки Бизнес-процессы, отражена их связь с Подпроцессами (бизнес-операциями)
        • отражены связи Бизнес-операций/Бизнес-процессов с Бизнес-объектами (Business Object) и с Продуктом (Product)
        • отражены связи Бизнес-операций/Бизнес-процессов (Business Process) И Бизнес-ролей (Business Role) с Положениями/Регламентами/Стандартами (Contracts), описывающими как именно выполняются работы, в какой последовательности, при каких условиях и т.п.
        Бизнес-архитектура, таким образом, может получить вид трёх подуровней, сверху вниз: взаимодействие бизнес-функций, бизнес-процессы, бизнес-операции.
      2. ИТ-архитектуре. Важно понимать, что ИТ-Система тоже может исполнять Бизнес-роль, т.е. по-сути быть актором, автоматически выполняющим некие операции в Бизнес-процессе.
      3. Технологической архитектуре
    • (опционально) уже сейчас могут быть зафиксированы локальные проблемы (Gap).
    Результат - для Бизнес-архитектуры нечто подобное (очень поверхностная модель, для примера):
  5. Опираясь на стратегические цели, последовательно составляем целевую архитектуру (target architecture) Предприятия, отражающую желаемое и финансово возможное целевое состояние Предприятия.
  6. Сравнивая целевую и текущую архитектуры, приходим к пониманию - что именно необходимо сделать (какие работы/проекты реализовать), чтобы привести Систему (Предприятие) из текущего состояния в целевое.
    Соотносим необходимые работы с нашими возможностями, определяем какие именно проекты по изменению Предприятие может себе позволить реализовать.
    Небольшие примеры:
(скачать эти представления в формате ARCHIMATE)

Сервис-ориентированная архитектура (SOA)

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

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

Интерфейс = зона доступа Сервиса для внешнего окружения.

Ключевая логика сервис-ориентированной архитектуры и умозрительный пример:


(скачать эти представления в формате ARCHIMATE)

Типы интеграции

Грубо обмен данными можно распределить по уровням:

  1. Интеграция на уровне отображения, интеграция через человека.
    Некий UI (HTML-страница, десктопное приложение, физический интерфейс) отображает для человека информацию из разных АС/сервисов, передаточным звеном является человек, который черпает информацию из одной условной "части" UI и вставляет (с обработкой или без) в другую "часть" UI, откуда информация "идёт" в определённую АС.
  2. Интеграция на уровне приложений.
    1. прямые вызовы точка-точка по шаблону request-reply (запрос-ответ) или one-way (отправка в одну сторону)
    2. обмен через слой среднего уровня.
      Например, через message brokers (системы управления очередями) типа RabbitMQ и Kafka
      ИЛИ при посредстве КСШ (ESB)
    3. комбинации перечисленного (например, service mesh с их маршрутизацией)
  3. Интеграция на уровне СУБД.
    Общая БД для нескольких АС, процессы ETL/ELT, федеративные данные (из различных источников через обёртки, см. federated database systems)

Что требуется для разработки интеграционного решения

  1. Список АС участников интеграции
  2. Операции и функции, которые выполняют АС как часть взаимодействия
  3. Бизнес-объекты, участвующие во взаимодействии, их атрибуты
  4. Интеграционные потоки
  5. Задачи по преобразованию данных
  6. Типы взаимодействия: только ли запрос или запрос-ответ, синхронность/асинхронность, индивидульное или пакетное
  7. Технические интерфейсы и протокол
  8. Требования безопасности интеграции (аутентификация и авторизация, обеспечение конфиденциальности, правила доступа к данным).
  9. Нефункциональные требования:
    • последовательность реализации (пп.1-7)
    • безопасность(п.8)
    • доступность и надёжность (уровень доступности %, окна обслуживания, время на восстановление, ожидаемое время между сбоями)
    • обработка ошибок (типы ошибок технические/бизнесовые, стратегия повтора доставки данных, правила логирования, корректировка данных после ошибок)

Оркестрация и хореография
Что почитать на тему:

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

Оркестрация

Оркестрация = императивное управление бизнес-процессом из единого центра (обычно это какой-то отдельный Сервис), который согласно алгоритму вызывает исполнителей, проводя бизнес-процесс от начала до конца.
Языки/нотации: BPMN, BPEL.

Пример:

  1. AAA: BBB, смотри какая Великая Задача, работай над ней
  2. AAA: CCC, держи Задачу, надо обработать напильником
  3. AAA: DDD, доделай Задачу
  4. AAA тискает готовую Задачу, довольный уходит

In orchestration, a central process takes control over the involved web services and coordinates the execution of different operations on the web services involved in the operation. The involved SOA services do not know (and do not need to know) that they are part of a composition or a higher business process. Only the central coordinator of the orchestration knows this, so the orchestration is centralized with explicit definitions of operations and the order of invocation of SOA services.

Хореография

Хореография = чистый событив, без единого центра управления процессом, все Сервисы настроены на работу по реакциям на события и/или по расписанию, зная при наступлении каких условий что они должны выполнять.
В качестве единого места хранения информации по прогрессу бизнес-процесса можно сделать отдельный Сервис, в который все исполнители будут "отчитываться".
Языки/нотации: BPMN, WS-CDL, ebXML BPSS.

Пример:

  1. AAA: Ставлю задачу! (клеет на Задачу бирку и кладёт Задачу в мешок)
  2. У BBB по крону звонит будильник в 07:00
  3. BBB: А нет ли для меня задач? (копается в мешке, читая бирки на Задчах)
  4. BBB: О, Задача! (делает как может, переклеивает бирку, бросает Задачу в CCC)
  5. CCC: %#@! О, Задача (делает как может, переклеивает бирку, отдаёт Задачу AAA
  6. AAA: О, решённая Задача (тискает Задачу, довольный уходит)

Choreography on the other hand does not rely on a central coordinator. Rather, each SOA service involved in the choreography knows exactly when to execute its operations (based on defined trigger criteria) and whom to interact with. Choreography is a collaborative effort focused on exchange of messages. All participants of the choreography need to be aware of the business process, operations to execute, messages to exchange, and the timing of message exchanges.
CQRS - отделение чтения от записи