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

Книги

Разное

TOGAF

TOGAF это методологический фреймворк управления изменениями множества вложенных систем, совокупность которых называется Корпоративной Архитектурой (Enterprise Architecture).
Необходимо понимать, что любой фреймворк спроектирован избыточно, соответственно, брать из него следует только ключевое (архитектурный цикл ADM) + то что покажется полезным и необходимым в конкретной организации.
ПО для работы с Архитектурой
Архитекторы - кто?
В реальности могут встретиться следующие:
  1. Корпоративный архитектор -- занимается архитектурой Предприятия (Enterprise), т.е. всем.
  2. Бизнес-архитектор -- занимается бизнес-архитектурой (Business).
  3. Системный архитектор -- занимается архитектурой данных (Data) и архитектурой приложений (Application).
  4. Технологический архитектор -- занимается технологической архитектурой (Technology).
  5. IT-архитектор -- занимается архитектурой данных (Data), архитектурой приложений (Application) и технологической архитектурой (Technology), т.е. всем кроме бизнес-слоя
Архитектурные слои

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

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

Предприятие - это все три строчки.

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

TBD

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

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

язык Archimate

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

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

Слои в 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)

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

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

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


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

TBD

Функциональная архитектура
Принципиальная диаграмма решения (solution concept diagram) для банка:
старый черновик

Здесь я попытался подойти к размышлениям над архитектурой намеренно до ознакомления с мировыми практиками и фреймворками типа TOGAF.

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

Роли это маски (алиасы) конкретных исполнителей (действующих лиц).
Роли в современном мире играют и Люди и ИТ-Системы. И чем дальше - тем меньше Ролей играется людьми. Это автоматически означает, что ушло то время подхода, когда идёт отделение Людей от Систем и их ролей друг от друга.
Роль, например в банковском деле, Андеррайтера сегодня играет человек, но по-сути человек это всего лишь Система, которая произвела некие вычисления внутри себя и приняла решение обменяться информацией с другой Ролью. Т.е. завтра, например, Роль = Андеррайтер сможет играть ИТ-Система.

(скачать схему в формате XML)

Подход к архитектуре предприятия через примат Функции

При построении Архитектуры для нового предприятия логично в первую очередь опираться на Функции, вокруг которых будет обрастать та или иная Архитектура (логическая, физическая).

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

(скачать схему в формате .XLOGIC)

Например, мы хотим построить Предприятие = Банк.
Один из Сценариев (получения денег) это выдача Потребительского Кредита.

Верхнеуровнево, у Потребительского Кредита есть Процесс, выполняющий следующие Активности/Функции:

  1. Принять Клиента ФЛ (физически и/или электронно)
  2. Запомнить Клиента ФЛ (физически и/или электронно)
  3. Принять Заявку (физически и/или электронно) на Потребительский Кредит у Клиента ФЛ
  4. Запомнить Заявку (физически и/или электронно)
  5. основываясь на знании о Клиенте ФЛ, Разведать платёжеспособность Клиента ФЛ (физически и/или электронно)
  6. Запомнить результаты разведки (физичесик и/или элеткронно)
  7. основываясь на результатах разведки, Оценить платёжеспособность и пригодность для выдачи Потребительского Кредита (физически и/или электронно)
  8. Зафиксировать (физически и/или электронно) Сделку с ним
  9. Запомнить (физически и/или электронно) Сделку
  10. основываясь на данных из Сделки, выдать Деньги (физически и/или электронно)
  11. основываясь на данных из Сделки, производить (ир)регулярное изъятие/приём у Клиента ФЛ денег (физически и/или электронно) в счёт оплаты кредита
  12. основываясь на данных из Сделки, закрыть Сделку (физически и/или электронно)

Всё это кто-то должен выполнять, т.е. на каждое действие имеем некоторую Роль.
Верхнеуровнево, у нас будут следующие Роли:

Активность/Функция Роль
1 Принять Клиента ФЛ (физически и/или электронно) Взаимодействователь (интерфейс) с Клиентом
2 Запомнить Клиента ФЛ (физически и/или электронно) Хранитель Данных
3 Принять Заявку (физически и/или электронно) на Потребительский Кредит у Клиента ФЛ Взаимодействователь (интерфейс) с Клиентом
4 Запомнить Заявку (физически и/или электронно) Хранитель Данных
5 основываясь на знании о Клиенте ФЛ, разведать платёжеспособность Клиента ФЛ (физически и/или электронно) Взаимодействователь (интерфейс) с Бюро Кредитных Историй
6 Запомнить результаты разведки (физичесик и/или элеткронно) Хранитель Данных
7 основываясь на результатах разведки, оценить платёжеспособность и пригодность для выдачи Потребительского Кредита (физически и/или электронно) Расчётчик
8 Зафиксировать (физически и/или электронно) Сделку с ним Взаимодействователь (интерфейс) с Клиентом
9 Запомнить (физически и/или электронно) Сделку Хранитель Данных
10 основываясь на данных из Сделки, выдать Деньги (физически и/или электронно) Выдаватель Денег (Учётчик)
11 основываясь на данных из Сделки, производить (ир)регулярное изъятие/приём у Клиента ФЛ денег (физически и/или электронно) в счёт оплаты кредита Расчётчик
Заполучатель Денег / Приёмник
12 основываясь на данных из Сделки, закрыть Сделку (физически и/или электронно) Расчётчик
Хранитель Данных

Далее, каждую Роль может играть и человек и ИС, иногда даже делить эту роль (если точки входа разные, например гаджеты, ПК и физический офис)
Верхнеуровнево получаем следующие условные соответствия:

Роль ИС Человеческая должность
Взаимодействователь (интерфейс) с Клиентом Сайт в Интернет, Мобильное приложение, Банкомат менеджер
Взаимодействователь (интерфейс) с Бюро Кредитных Историй Система, делающая запросы вовне выспрашиватель
Хранитель Данных БД писарь
Расчётчик Система с логикой проверок расчётчик
Выдаватель Денег (Учётчик) Банкомат, АБС Учётчик
Заполучатель Денег / Приёмник Банкомат, АБС менеджер, учётчик, громила

Т.е. тут мы получаем минимальный и достаточный список Систем или Должностей, которые должны присутствовать в нашем Предприятии, для того чтобы обеспечивать выполнение Функций Процесса, дающего достижение цели - получение дохода
Далее, основыаясь на аналитике ниши/рынка/географии/предполагаемых_объёмов, уже необходимо расчитать количество таких систем.
Далее, основываясь на логике Процесса - логическую Архитектуру связи Ролей.
Далее - конкретную физическую Архитектуру ИС, конкретную физическую Архитектуру инфраструктуры Предприятия и т.п.

ИТ-архитектура

Два функциональных ядра Архитектуры (cores)

  • Аналитическое ядро (analytics core), читает/анализирует:
    • Карточки Клиентов
    • очки скоринга Клиентов (scoring)
    • поведение Клиента
      (что-то подобное реализовано в Яндекс.Деньги - выявление отклонений в действиях Клиента на основе статистики)
    • workflow Бизнес-процессов (на основе статистики прохождения шагов, сравнения постан дч)
    • нагрузку шин ПО адаптерам И потокам данных
    • (?)риски (risks)
  • Синтезирующее ядро (synthesis core), создаёт/изменяет:
    • правила скоринга Клиентов (scoring rules)
    • workflow Бизнес-процессов
      (требует настраиваемого workflow - Camunda?)
    • Продукты (Products)
    • Сервисы (Services)
    • Маркетинговых Кампаний (marketing)
    • правила работы Шины (bus rules)

Максимально автоматизированы.

Мантия Архитектуры (mantle)

Мантия 1 (mantle 1)
  • т.н. demilitarized zone (DMZ)
    • авторизация (authentication, authorization)
    • маршрутизация (routing)
    • балансировщик нагрузки (load balancer)
    • служба логирования (logging service)
    • репликация данных сессии (session replication)
    • т.н. автоматический "размыкатель" (circuit breaker)
    • служба аудита (audit service)
Мантия 2 (mantle 2)
  • шина для командных запросов (command queries bus)
  • шина для событийных запросов (event bus). RabbitMQ?
    • (event dispatcher)
    • (event handlers)
    • хранилище событий (event store)
    • (replay events)
    • ...

Возможные каналы доставки/взаимодействия (delivery channels)

  • Лицом к лицу - курьер (Face2Face.Courier). исх
  • Лицом к лицу - отделения Банка (Face2Face.Branches). вх/исх
  • Мобильные - Приложение - Андроид (Mobile.App.Android). вх/исх
  • Мобильные - Приложение - iOS (Mobile.App.iOS). вх/исх
  • Мобильные - SMS (Mobile.SMS). вх/исх
  • Интернет - Сайт - десктопная версия (Web.Desktop). вх
  • Интернет - Сайт - мобильная версия (Web.Mobile). вх
  • Интернет - Сайт - GUI-доступ для Администраторов (Web.AdminGUI). вх.
  • Интернет - Консольный доступ для Администраторов по SSH. (Web.CLI). вх.
  • Банкоматы (ATM). вх
  • Платёжные терминалы (POS / ATM.mini). вх
  • Телефонные звонки - Колл-центр (Phone.CallCenter). вх/исх
  • Телефонные звонки - Озвучивание заранее записанных сообщений Клиенту (Phone.IVR). исх
  • Email. вх/исх
  • Партнёры (Partners). вх/исх
    • Государство - законодательное API (Partners.Government.Legislative)
    • Государство - различные сервисы Единого Окна (Partners.Government.SingleWindowService)
      Например, Госуслуги
    • Общественное питание (Partners.FoodService, Partners.Catering)
    • Здравоохранение (Partners.Healthcare)
    • Образование (Partners.Education)
    • Страхование (Partners.Insurance)
    • Розничная торговля (Partners.Retail)
    • Телекоммуникации (Partners.Telecom)
    • др. Банки (Partners.Banking)
    • агенты недвижимости (Partners.Estate)
  • киоски/стенды (Kiosk). вх/исх
  • социальные сети (SocialNetworks) вх/исх
  • ТВ (TV). исх. возможно, стоит отнести как подраздел к Партнёры
  • гейминг (Gaming). вх/исх . возможно, стоит отнести как подраздел к Партнёры
  • имплантируемые микрочипы (MicrochipImplant). вх/исх
вх/исх - относительно организации

Безопасность каналов (security)

  • шифрование протоколов передачи данных (encryption)
  • физическая невидимость для посторонних передаваемых физических предметов, шевеления губ при переговорах (visibility).
    На физическом уровне, например, это перегородки.
  • физическая неслышимость для посторонних переговоров Клиента с Организацией (audibility).
    На физическом уровне. например, это перегородки.
Чем выше безопасность для Канала Доставки - тем более широкий спектр Сервисов/Продуктов он может "поддерживать".

Что должны поддерживать каналы

  • многоязычность (Multi-Language)
  • многовалютность (Multi-Currency)
  • ...

Методы аутентификации (authentification)

? По степени возрастания надёжности:

  1. пароль (password)
    • многоразовый пароль
    • одноразовый пароль
  2. биометрия (biometric)
    • радужная оболочка глаза
    • отпечатки пальцев
  3. мультифакторная аутентификация (multi-factor authentication)
    Например, пароль + SMS ИЛИ пароль + биометрия..

Верификация методом электронной цифровой подписи (digital signature).

Чем надёжнее метод аутентификации при использовании Канала Доставки - тем более широкий спектр Сервисов/Продуктов он может "поддерживать", тем меньше физических контактов необходимо между представителями Организации и Клиентом.
Также, например, передача копий документов, заверенных ЭЦП (электронной цифровой подписью) ликвидирует необходимость в физическом контакте с Клиентом.

Инфраструктура (infrastructure)

Обязательные функциональные модули/подсистемы:

  • Библиотека/репозиторий Правил Регуляторов (regulators rules)
    • Интернациональные правила (international)
      • законы (legis, laws)
      • институциональные/предметная_область (institutional, domain). Например, SWIFT.
    • Национальные правила (national)
    • Местные/локальные правила - регион страны, населённый пункт (local)
  • Библиотека/репозиторий Продуктов
  • Библиотека/репозиторий Сервисов
  • Библиотека/репозиторий шаблонов Документов
  • Библиотека/репозиторий Карточек Клиентов
  • Cимулятор ЖЦ Продукта/Сервиса (simulation)
  • ...

Должны иметь доступный в интрасети API.