• Архитектура ИТ решений. Часть 1. Архитектура предприятия (Алексей Радзишевский, 2018)
• Конференция архитекторов. Масса видео с выступлениями на темы: кто такие архитекторы, какие бывают, для чего нужны, как архитекторов искать и собеседовать, как "выращивать", архитектура и agile, практика Корпоративной архитектуры, об Архитектуре решений. К сожалению, звук видео очень тихий.
  Наиболее интересные и полезные презентации с конференции:
  • (PDF) Слайды доклада "Виды архитекторов и их навыки" (Дмитрий Романов, Уралвагонзавод, 2019)
  • (PDF) Слайды доклада "Архитектор решений в организации" (Иван Лукьянов, ДИТ Москвы, 2019)
  • (PDF) Слайды доклада "Архитектор в госпроектах" (Лучков Александр, АО Бортовые Аэронавигационные Системы, 2019)
• (DOC) Драфт текущей версии соглашения о моделировании SysArchi (Анатолий Левенчук, 2018)
• Микросервисная архитектура и service mesh
• Архитектура с использованием ESB (enterprise service bus, корпоративной сервисной шины, КСШ)
• документ Solution Design и с чем его едят
• Архитектура платежной системы (Филипп Дельгядо, 2018)

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

• A collection of practices and patterns to support software evolution, modernization, maintenance, migration and improvement of software systems. Своего рода свод знаний (постоянно пополняемый) о паттернах и методах модернизации систем.

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

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

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

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

• TOGAF® Standard, Version 9.2 веб-версия
• (PDF) TOGAF® Standard, Version 9.2 в виде файла. (альтернативная ссылка). К сожалению, русскоязычной версии не нашёл, а самому переводить слишком трудоёмко...
• Методология управления изменениями на основе методологии TOGAF и языка моделирования Archimate. Небольшая обзорная статья, рассказывающая о самой-самой сути.
• Обучающий курс по архитектурному фреймворку TOGAF на русском языке, теория и практика (Александр Кварцхава, 2021).
  15 видеолекций (по 05..30 минут) на тему TOGAF, сервисно-ориентированной архитектуры, совместного использования Archimate и TOGAF, управления изменениями архитектуры и т.п.
  Автор последовательно проходит по всем фазам Архитектурного Цикла.
• Курс по корпоративной архитектуре (Александр Кварцхава, 2019), описывающий принципы построения архитектуры уровня небольшого предприятия:
  список видео

  1. Сквозной пример. Часть нулевая. Тезисы
  2. Сквозной пример. Часть первая. Постановка задачи.
  3. Сквозной пример. Часть вторая. Архитектурное видение
  4. Сквозной пример. Часть третья. Разбираемся с сервисами
  5. Сквозной пример. Часть четвёртая. Разбираемся с функциями
  6. Сквозной пример. Часть пятая. Разбираемся с процессами
  7. Сквозной пример. Часть шестая. Разбираемся с ролями
  8. Сквозной пример. Часть седьмая. Разбираемся с исполнителями
  9. Сквозной пример. Часть восьмая. Этапы и операции процессов
  10. Сквозной пример. Часть девятая. Модель данных часть первая
  11. Сквозной пример. Часть девятая. Модель данных часть вторая
  12. Сквозной пример. Часть десятая. Структура КИС
  13. Сквозной пример. Часть одиннадцатая. Модель работы КИС
  14. Сквозной пример. Часть двенадцатая. Низкоуровневое проектирование
  15. Сквозной пример. Часть тринадцатая. Материальная архитектура
  16. Сквозной пример. Часть четырнадцатая. Технологическая архитектура
  17. Сквозной пример. Часть пятнадцатая. Трансформация. Завершение.
  18. Сквозной пример. Часть шестнадцатая. Что было сделано и вопросы следующего цикла.
• О том как преодолеть слабое место TOGAF (Александр Кварцхава, 2018).
  Что приоритетнее — BSC (balanced scorecoard, сбалансированная система показателей), МР (менеджмент рисков), TOGAF. Откуда брать драйверы изменений (Drivers). Как важно и в какой момент приступать к выбору инструментов.

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

1. подготовить и согласовать со всеми причастными сторонами архитектурное видение
2. разработать структуру сервисов уровня бизнес-архитектуры
3. разработать структуру бизнес-процессов и бизнес-функций
4. разработать структуру бизнес-ролей, связанных с процессами
5. разработать организационную структуру, связанную со структурой бизнес-ролей
6. разработать модель данных компании
7. разработать архитектуру корпоративной информационной системы
8. разработать технологическую архитектуру
9. выбрать конкретные решения для всех уровней архитектуры
10. разработать пакеты работ
11. реализовать проект
12. провести аудит: убедиться в достижении целей, какой ценой, какие были совершены ошибки.

• (бесплатное) Archi — most-popular Archimate modelling tool
  Простой, понятный, быстрый инструмент.
  Полезные статьи, связанные с этим ПО:
  • Автоматизируем работу с ArchiMate в CI пайплайнах (статья благодарного читателя).
• (платное, есть trial на 30 дней) Enterprise Architect ( и могут установить EA под WINE).
  В высшей степени могущественный инструмент. Преимущества — версионирование, мощная трассировка, работа с разрывами (gap), репозиторий с записью в БД.
  Полезные статьи, связанные с этим ПО:
  • Готовим проект в Sparx Enterprise Architect. Наш рецепт (ГК ЛАНИТ).
  • Единый репозиторий для управления Enterprise Architecture (Райффайзенбанк).
• (бесплатное) Modelio Open Source — UML, BPMN, ArchiMate, SysML, ...
• (платное) Enterprise-версии Modelio: Modelio BA, Modelio SD.
  Для Бизнес-архитектуры (TOGAF, Archimate, UML, BPMN), Системной архитектуры (SysML, UPDM, NAF, DODAF, MODAF), дизайна Приложений (конвертация UML в Java, C#, C++, SQL) соответственно
• (платное) SAP Power Designer.

Основные встречающиеся в реальности виды архитекторов:

скачать схему в формате diagrams.net (бывший draw.io)

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

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

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, ...
   Оценить затрудняюсь, N десятков часов — без зубрёжки, но с некоторой самопрактикой.
10. Свободное владение языком архитектурного моделирования Archimate.
    Это порядка 15 часов на лекции + изучение статей и первоисточников.
    Затем практика, практика и ещё раз практика.
11. Владение каким-либо из ПО для архитектурного описания (Archi, Enterprise Architect, Modelio BA / Modelio SA, Modelio SD, ...) на уровне, достаточном, чтобы не испытывать стыда и паники.
    До 10 часов практики на более-менее реальных задачах.
12. Знание принципов DDD (domain driven design), BPM (business process modeling), microservices.
    Прочитать книжку Вернона по DDD и десяток статей по остальному.
13. Знание английского на уровне, достаточном, чтобы спокойно читать статьи, смотреть/слушать лекции.
14. (опционально) образование по специальностям: ЭВМКСиС | АСУ | ПОВТ | Информатика в экономике | Информационные системы и технологии.
15. (опционально) опыт работы
    • в компаниях системных интеграторах
    • в консалтинговых компаниях на ролях системного-/бизнес- аналитика-консультанта
    • системным аналитиком
    • Разработчиком, участвовавшим в интеграции зоопарка ИС

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

1. доступ к описанию Бизнес-процессов Предприятия;
2. доступ к описанию ИТ-систем Предприятия, их Интерфейсов, компонентов;
3. доступ к описанию Технологического слоя (возможно на предприятии даже есть CMDB);
4. доступ к использованию на рабочем месте ПО для работы с архитектурными схемами.
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 предназначен для высокоуровневого моделирования и анализа различных областей предприятия и взаимосвязей между ними.
Он не фокусируется на деталях реализации и не заменяет UML, BPMN или ERD, а дополняет их. В Archimate меньше возможностей по детализации, чем в этих языках моделирования, но он позволяет связать описания различных областей и разработать интегрированное представление организации.

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

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

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

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

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

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

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

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

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

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

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

1. Интеграция на уровне UI, внезапно интеграция через человека.
   Когда человек для выполнения задачи использует UI нескольких систем (HTML-страница, десктопное приложение, физический интерфейс), и для того чтобы что-то ввести данные в одну систему, он ищет нужное значение в другой системе. Такие ручные процессы, кстати, отличные кандидаты на автоматизацию.
2. Интеграция на уровне приложений.
   1. прямые вызовы точка-точка по шаблону request-reply (запрос-ответ) или one-way (отправка в одну сторону).
      Например, Для протокола HTTP чаще всего встречаются реализация посредством REST API или RPC-взаимодействия.
   2. обмен через слой среднего уровня.
      Например, через message brokers (системы управления очередями) типа RabbitMQ и Apache Kafka
      ИЛИ при посредстве КСШ (ESB)
   3. комбинации перечисленного (например, service mesh с их маршрутизацией)
3. Интеграция на уровне данных, расположенных на едином ресурсе.
   • Файлы. В рамках одной файловой системы или по удалённому подключению посредством, например, FTP/sFTP
   • Общая БД для нескольких АС, процессы 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.