# БИБЛИОТЕКА Курсы Системная инженерия Сознание, интеллект Политэкономия Сумма технологии Экстраполяция в будущее ПРОЦЕССЫ Ресурсы Цикл разработки ПО Waterfall RUP Agile Kanban Управление Теория ограничений АНАЛИЗ Ресурсы ПО для Аналитика Кто аналитики? Бизнес-процесс Требования Уровни и типы Источники Стейкхолдеры Нотации АРХИТЕКТУРА Ресурсы ПО для Архитектора Кто архитекторы? Архитектурные слои язык Archimate GAP-анализ SOA Микросервисы ESB Solution Design DDD РАЗРАБОТКА Ресурсы Continuous Integration git Frontend HTTP/REST Apache Регулярка JS Perl Linux ТЕСТИРОВАНИЕ Ресурсы QA и QC Цикл тестирования 1 Тест-анализ 2 Тест план 3 Тест-дизайн и покрытие Уровни тестирования Виды тестирования Баг-репорт Шаблоны XPATH Безопасность Нагрузочное Android Автоматизация Selenium Генератор ИНН ДАННЫЕ Об информации SQL MongoDB
Эта страница:
Черпнуть мудрости ПО для работы с Архитектурой Архитекторы - кто? Архитектурные слои язык Archimate Архитектурный цикл кратко GAP-анализ Сервис-ориентированная архитектура (SOA) Микросервисы ESB (Enterprise Service Bus) CQRS - отделение чтения от записи
Ещё в этом разделе:
АРХИТЕКТУРА Solution Design Document DDD
Другие разделы:
# АНАЛИТИКА АРХИТЕКТУРА ДАННЫЕ РАЗРАБОТКА БИБЛИОТЕКА ПРОЦЕССЫ ТЕСТИРОВАНИЕ
Архитектура
Черпнуть мудрости

Разное

Книги

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

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

TOGAF это методологический фреймворк управления изменениями множества вложенных систем, совокупность которых называется Корпоративной Архитектурой (Enterprise Architecture).
Необходимо понимать, что любой фреймворк спроектирован избыточно, соответственно, брать из него следует только ключевое -- архитектурный цикл ADM -- и то что покажется полезным и необходимым в конкретной организации.
ПО для работы с Архитектурой
Архитекторы - кто?
В реальности могут встретиться следующие:
  1. Менеджер по стратегии -- занимается разработкой карты сбалансированных показателей (BSC, balanced scorecard) и декомпозицией стратегии предприятия на подцели.
  2. Корпоративный архитектор -- занимается архитектурой Предприятия (Enterprise architecture) и архитектурным надзором.
  3. Бизнес-архитектор -- занимается бизнес-архитектурой (Business architecture), т.е. разработкой элементов бизнес-процессов (совместно с Бизнес-аналитиками).
  4. IT-архитектор -- занимается архитектурой данных (Data), архитектурой приложений (Application) и технологической архитектурой (Technology), архитектурным надзором.
  5. Архитектор решений -- занимается архитектурой данных (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. (Архитектору предприятия) Стратегические цели Предприятия и Сбалансированная карта показателей
  2. Имеющееся архитектурное описание Бизнес-процессов AS IS;
  3. Имеющееся архитектурное описание уровней Application, Component AS IS эксплуатируемых ИС;
  4. Бизнес-требования и Проектная концепция к доработке/внедрению ИС.

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

  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 меньше возможностей по детализации, чем в этих языках моделирования, но он позволяет связать описания различных областей и разработать интегрированное представление организации.

Что изучить на тему:

Слои в Archimate

Отношения между блоками

Архитектурный цикл кратко
  1. Подготовить и согласовать со всеми причастными сторонами архитектурное видение
  2. разработать структуру сервисов уровня бизнес-архитектуры
  3. разработать структуру бизнес-процессов и бизнес-функций
  4. разработать структуру бизнес-ролей, связанных с процессами
  5. разработать организационную структуру, связанную со структурой бизнес-ролей
  6. разработать модель данных компании
  7. разработать архитектуру корпоративной информационной системы
  8. разработать технологическую архитектуру
  9. выбрать конкретные решения для всех уровней архитектуры
  10. разработать пакеты работ
  11. реализовать проект
  12. провести аудит
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)

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

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

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


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

TBD

Микросервисы
Ресурсы:

Микросервисная архитектура = метод создания распределённых приложений в виде набора независимо разрабатываемых и развёртываемых в изолированном окружении небольших служб.

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

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

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

Поскольку асинхронное событийное взаимодействие -- практически стандарт в микросервисной архитектуре, то надо разбираться в создании событийной архитектуры (Event Driven Architecture), а сами микросервисы должны соответствовать требованиям Reactive.

ESB (Enterprise Service Bus)

ESB - примеры решений

  • Облачные решения ESB:
    • Azure Service Bus
    • Amazon Simple Queue Service
  • On-premise решения ESB:
    • RabbitMQ
    • Kafka
    • IBM Integration Bus (IBM)
    • Oracle Service Bus (Oracle)
    • BizTalk (Microsoft)
    • ActiveMatrix Service Bus (TIBCO)
    • MuleESB (MuleSoft)
    • JBoss Fuse ESB (Red Hat)
  • Самописное решение ESB:
    1. Таблица в БД с сообщениями
    2. Читать логи транзакций БД

Плюсы ESB

  1. Асинхронные развязки при обработке команд
  2. Маршрутизация данных, брокер очереди сообщений (Message Queue, MQ)
  3. Гарантированная доставка информационных сообщений
  4. Преобразование: обогащение/фильтрация сообщений, преобразование протоколов (нормализация)
  5. Синхронизация изменений
  6. Протоколирование (логирование) Бизнес-операций
  7. (в современных ESB) MFT = Managed file transfer

Минусы ESB

  1. Добавляется ещё одна ИС, которую надо обслуживать
  2. Потребуется закупать мощности для развёртывания и включения в текущие тестовые контуры ещё одной ИС
  3. ESB может стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM. Всё это усугубляется при стремящемся к нулю кол-ве специалистов, знающих Шину;

Что Шина НЕ даёт

  1. Описание и прототипирование API (Swagger, Postman et cetera)
    Это может быть размещено в CoreAPI.
  2. Stream processing (Kafka)
  3. Интеграция данных (ETL, ...)
  4. Средства управления сервисами (circuit breaker)

Уроки

Пробежавшись по статьям о ESB, можно извлечь несколько уроков из чужого опыта:
  1. не совать в Шину бизнес-логику. Использовать только как транспорт, оркестровку (синхроника), хореографию (асинхроника).
    Это помимо того, что совать бизнес-логику в вендорные решения и фреймворки -- нарушение принципов DDD и постановка предприятия в зависимость от вендора/фреймворка;
  2. ESB может стать "узким горлышком", когда множество команд других ИС ждёт доработок от команды ESB. Больше зависимостей --> больше общий TTM. Всё это усугубляется при стремящемся к нулю кол-ве специалистов, знающих Шину;
  3. на Шину со множеством адаптеров обязательно нужны автотесты, руками регресс десятков-сотен кейсов адаптеров не покроется, особенно если регресс раз в несколько дней, ведь на Шине с большой связанностью постоянно будет что-то меняться. Вопрос: стоит ли "вешать" разработку и тестирование на вендора?
    Автотесты требуют всегда актуальных артефактов п.4;
  4. д.б. выстроен процесс сохранения и актуализации артефактов проектирования, разработки, тестирования Шины и всех ИС, работающих с Шиной. Нужны Архитекторы, и они должны быть "пишущие".
CQRS - отделение чтения от записи