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

Разное

Книги

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

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

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

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

TOGAF это методологический фреймворк управления изменениями множества вложенных систем, совокупность которых называется Корпоративной Архитектурой (Enterprise Architecture).
Необходимо понимать, что любой фреймворк спроектирован избыточно, соответственно, брать из него следует только ключевое -- архитектурный цикл ADM -- и то что покажется полезным и необходимым для конкретной организации.
ПО для работы с Архитектурой
Архитекторы - кто?
В реальности могут встретиться следующие вариации:
  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 меньше возможностей по детализации, чем в этих языках моделирования, но он позволяет связать описания различных областей и разработать интегрированное представление организации.

Что изучить на тему:
Архитектурный цикл кратко
В идеальном идеале:
  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)

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

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

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

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

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

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

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

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


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

CQRS - отделение чтения от записи