Архитектура

• Архитектура
  • Зачем
  • Задачи IT-архитектора
  • Процесс
  • Законы архитектуры
  • Класс систем
  • Элементы архитектуры

Зачем

• __Архитектура ~ Architecture:
  • структура системы в определенном Стиле архитектуры
  • включающая все
    • компоненты ПО из которых она состоит
    • оборудование и людей
  • устанавливает границы между разными компонентами приложения и их ответственностями
  • обеспечивающая необходимые Качества архитектуры (архитектурные характеристики)
  • исходя из НФТ
  • предоставляющая интерфейсы компонентов
    • Требования для интерфейса внешнего устройства API ~ external interface requirement —
      • описание интерфейса между системой ПО и пользователем
      • другой системой ПО - интеграции
      • или оборудованием
  • взаимосвязи между этими компонентами и поведение компонентов, видимое другим компонентам (слои приложения)
  • построеной на технологической базе ПО (тех стек)
  • совокупность правил, методов и Шаблонов Паттернов разработки приложений

Архитектор знает

• когда полезно использовать определенную технологию исходя из Критерией выбора решения, самое главное – когда этого не нужно делать
• какие есть риски
• общепринятые Reference Architecture
• Подходы к Документированию архитектуры

Задачи IT-архитектора

• Обеспечить баланс между стоимостью разработки и гибкостью решения для быстрого внедрения будущих требований.
  • We design software to reduce its cost. The cost of software is ≈ the cost of changing the software.
    • The cost of changing the software is ≈ the cost of the expensive changes (power laws and all that).
      • The cost of the expensive changes is generated by cascading changes — if I change this then I have to change that and that, and if I change that then.
  • Coupling between elements of a design is this propensity for a change to propagate.
  • So, design ≈ cost ≈ change ≈ big change ≈ coupling. Transitively, software design ≈ managing coupling
• Фиксировать и распространять знания
• Преодолевать разрыв между предметной областью и технической командой

Critical Skills:

• Анализирует бизнес-требования в рамках задач направления. Предлагает альтернативы.
• Разрабатывает и согласовывает архитектурное решение по задачам направления
• Проектирует компонентную, информационную, системную, техническую (деплой) архитектуру
  • Использует на практике профильные нотации описания архитектуры (например, C4).
  • Проектирует интеграцию систем. Определяет способы, протоколы, инструменты интеграции (очереди rabbit, kafka, ESB, ETL инструменты)
• Контролировать реализацию: заложить каркас системы и провести архитектурный надзор.
• Использует на практике архитектурные подходы проектирования(SOA, MSA, ED,…)
• Проводит декомпозицию вновь создаваемых решений, владеет подходом Domain Driven Design
• Понимает и иcпользует на практике требования информационной безопасности
• Разрабатывает нефункциональные требования
• Определяет техстек, компонентный состав решений. Знает языки и фреймворки, классы и экземпляры БД
• Архитектор декларирует общие концепции: аналитик, разработчик реализует их (пример шаблон API, ПЗ)
  • императивное программирование — как сделать. Пример: Купить овощи, замешать, сварить борщ
  • декларативное программирование — что сделать. Пример: Сделайте борщ.
    • декларативное программирование по-прежнему использует императивное программирование под капотом, поэтому невозможно писать только декларативный код

Other Skills:

• Применяет знания предметной области бизнеса
• Знает типовые концепты и ИТ-решения рынка бизнеса
• Владеет разными нотациями описания архитектуры
• Владеет языками программированиями, принципами проектирования БД
• Владеет и использует на практике стандарты и методологии гибкой разработки

Процесс

• Групповые ревью - коллективный архитектор

Порядок (пирамида) проработки архитектуры решения:

• Функциональная(use case, ПЗ, БТ)
• Информационная(модель данных, предметная область, сущность, связи)
• Анализ вариантов
  • Компромис бизнес проблем, целей и тех решения с учетом дальнейшего развития
  • плюсы и минусы
  • Посчитать в деньгах, трудоемкости
• Прикладная(взаимодействия компонентов)
• Интеграционная(РИПВ)
• Технологическая(инфраструктура, ИБ)

Законы архитектуры

• Everything in software architecture is a trade-off. Любое решение является компромиссом.
  • Нет плохих решений - есть цели и контекст бизнеса (пример: сделать самолет военный, гражданский)
• Вопрос “почему” является важнее вопроса “как”
  • Библиотеки и фреймворки - детали реализации, которые должны быть скрыты.
• Закон Конвея — «Организации проектируют системы, которые копируют структуру коммуникаций в этой организации»

Класс систем

• APM
• CDC
• CDN
• IAM
• DWH
• Report
• Mobile
• SIEM
• DSE
• BPMS

Элементы архитектуры

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