Читать книгу Конспект ИТ-архитектора - Евгений Сергеевич Штольц - Страница 3
Архитектура
ОглавлениеГОСТ Р 57100-2016 (docs.cntd.ru/document/1200139542) на основе международного стандарта ISO/IEC/IEEE 42010 даёт определение архитектуры как "Основные понятия и свойства системы в окружающей среде, воплощённых в её элементах, отношениях и конкретных принципах её проекта и развития". Разновидностей её существует довольно много, но мы выделим основные по уровню абстракции: архитектуру приложения (Application Architecture), программною архитектуру (Software Architecture), архитектуру приложений (Solution Architecture) и корпоративную архитектуру компании (Enterprise architecture). Архитектор приложения занимается разработкой архитектуры самого приложения, используя для этого паттерны проектирования и распределение задач, и, зачастую, совмещает свою роль с ролью Team-Lead или ведущего разработчика ответственных компонентов (Tex-Lead). Software Architect занимается тем же, что и архитектор приложения, но работает с несколькими командами, добавляя унификацию используемых ими технологиями. Часто это позиция востребована в аутсорсинге, где много проектов и есть возможность снять нагрузку с Team-Lead, чтобы они больше общались с заказчиками и командой. Для этой позиции характерны требования для вакансии по знанию языка программирования и основного стека используемых на проектах. В такой ситуации архитектор ограничен в выборе технологий и найме им новых сотрудников. Начиная с появления в 1959 году, архитектор занимался декомпозицией системы, распределением частей по разработчикам и отвечал за последующую интеграцию разработанных компонентов в изначально требуемую систему. Ныне ситуация упростилась с появление микросервисов.
Корпоративный архитектор проектирует взаимосвязи между системами использую интеграционную шину данных предприятия, а архитектор приложений проектирует сами системы, декомпозируя их на приложения. Границы между приложениями определяются границами использования: разработки, развёртывания, предоставлению поставщику. Ранее, приложения, также объединялись по технологическим платформам и технологиями, но с приходом контейнеризации, положение могут содержать компоненты, созданные на разных платформах, языках и стеках, заключённые в контейнерах. Также потеряла актуальность формирования границ на основе выкатки приложения в силу того, что выкатываются компоненты (контейнера) и уже тестируются в окружении других компонентов. В идеале группа микро-сервисов сгруппирована по выполняемой функцией бизнесом и командой, разрабатывающей ею, но зачастую в бизнес-процессах участвуют общие компоненты, что размывает границы приложений. Подобная специфика привела к появлению отдельной специализации – Cloud Solution Architect.
Исходя из уровня архитектуры, который предполагается проектировать, можно из абстрактного вопроса – как стать архитектором – можно превратить в набор требований, необходимый для решений поставленной задачи: от чисто технической, до организационной. Так программный архитектор может все организационные мероприятия делегировать на Team Lead и сосредоточится чисто на техническом описании структуры программы, и зачастую он является чистым технарём и по совместительству Tex-Lead, но никак не может делегировать техническую. В противовес, корпоративный архитектор может быть не техническим специалистом, например, директором, проводя коммуникацию для организации связей автоматизированных систем и удовлетворения этих систем нуждам заказчиков. Исходя из этого можно догадаться, что на вопрос – как становятся архитекторами – можно ответить, что архитекторами до Solution Architect эволюционно по технической ветке, а корпоративным, либо по технической ветке, либо по менеджерской, включая бизнес—аналитика. При этом стать архитектором можно в любое количество лет.
Solution Architect и микросервисы
Внедрение микросервисов начинается с бизнеса, когда маркетинг начинает делать эксперименты – запрашивать фичи в виде MVP, потом тестировать на рынке, после либо браковать (что редко), либо дорабатывать. Доработка требуется как после подтверждения предположения, так и ошибочного в виде корректировки. Для службы эксплуатации это означает выкатку огромного количества фич, которые были разработаны впопыхах и могут обрушить основное приложение – монолит. Эта служба пытается запускать эти изменения в изолированной среде в виде отдельного функционала, для чего просит отдел разработки, разрабатывать их отдельно – в виде микросервисов.
Нужно разделять два уровня разделения: технологическое и доменное. Технологические особенности в работе едины, так как что сервисы, что его компоненты, если он разбит на составные части технологически запускаются и поддерживается одинаково. Но, в отличии от сервисов, которые должны быть минимально взаимосвязаны с другими сервисами и должны обеспечивать определённое API и SLA, то компоненты сильно связанны. Причиной разделения на компоненты имеют технологическую природу. Например, интернет-магазин содержит сервисы, такие как сама интернет-витрина, сервисы оплаты, складские сервисы, а интернет-витрина представляет из себя сервис на CMS Joomla! и систему управления базой данных (СУБД) MySQL. Здесь разделение сервиса на составные части произошло из-за разных программных продуктов, написанных на разных языках программирования. При этом, для заказчика это единый сервис на CMS Joomla!, выполняющий единую функцию предоставления интерфейса для заказа пользователям в онлайн, предоставляемый хостингом как единый сервис (по отдельности не будет работать), может работать как каталог товаров без других сервисов (оплаты, заказа). С технологической точки зрения компоненты сервисы:
* По одиночки не функциональны;
* Сильно связанны, так как на каждый запрос к CMS формируется множество запросов;
* Интерфейсы взаимодействия сложны и разнообразны – тут применяется даже не API, а язык взаимодействия SQL;
* Сильно связанны функционально через сложное техническое API – для пользователя известно лишь
поддерживаемая совместимость одних версий CMS с другими версиями СУБД.
Разделение системы на микросервисы начинается с анализа их границ, анализ выгод от разделения и привнесённых сложностей распределённой системой. Отделять микросервисы лучше при комбинации необходимости:
* Технологической необходимости, например, большая нагрузка, которую сложно выдержать без отделения, например, масштабированием, другой вид поддержки (SLA);
* Для бизнеса выделяемый сервис уже является отдельной и мало зависимой функцией – далее рассмотрим подход DDD (model-driven design + ubiquitous language) к реализации микросервисов;
* Необходима смена технологической платформы.
Микросервис отвечает следующим характеристикам, по мнению М. Фаулера (martinfowler.com). Их можно свести к:
* 1. Должен из себя представляет компонент или сервис. Каждый микросервис – законченный полноценны независимый сервис с точки зрения разработчика, системного администратора и пользователя. Он должен обладать возможностью быть легко заменённым на другой, как в коде разработчика, как в процессе работы (должны быть), так и представлен другим или убран в интерфейсе пользователя. Не выполнения условий заменимости на разных уровнях приводят к одному сервису разделённому на части – распределённому монолиту;
* 2. Организация бизнес-возможностей;
* 3. Продукты – не проекты;
* 4. Умные конечные точки и глупые связи. Не требующая сложной интеграции с отлаженными сервисами (интеграцию сложных систем занимается сервис ориентированная архитектура SOA);
* 5. Децентрализованное управление. Здесь имеется в виду оркестрация, например, Kubernetes, управление сетью, например, Istio, управление доставкой, например, KNative;
* 6. Децентрализованное управление данными. В силу самодостаточности сервиса и независимости от других он должен иметь независимое состояние – базу данных, а чтобы и выбор системы управления базой данных был независимы – есть и её свою;
* 7. Автоматизированная инфраструктура. Процесс деплоя, масштабирования и откатов должен быть автоматизированы, что позволяет быстро автоматически откатываться, фиксировать в коде изолированность работы сервиса;
* 8. Предусмотрен отказ в работе. Для визуализации отказов можно посмотреть на Jaeger и Prometheus, для локализации проблем сервисы должны быть изолированы, представлять один единый сервис, что позволяет изолировать, ограничить пагубное воздействия на другие сервисы при отказе и автоматизировать откат;
* 9. Эволюционирующий дизайн. Система наращивает отростки в виде сервисов – обрастает ими, при этом не требуется изменение её структуры. Neal Ford и Rebeca Parsons в "Микросервисы как эволюционирующая архитектура" ориентируются на постоянные улучшения.
Взгляд со высоты бизнеса и бизнес-архитектора
Бизнес-архитектура (Enterprise Architect) – это IT архитектура всей компании. Она оперирует абстракциями и сущностями на уровне бизнеса, это стратегии, бизнес-процессы, услуги и тому подобного. Системы и взаимосвязи, обеспечивающие работу бизнеса, именуют ИТ ландшафтом, потому что она содержит множество систем, не образующих единое целое, связанные бизнес-процессами, в которых они участвуют и которые не ограничиваются ими. Бизнес- архитектора (Enterprose Architect) работает на этом уровне, подстраивая текущий ландшафт под текущую потребности бизнеса. Зачастую, для традиционных компаний, которые развивались не в высокотехнологической сфере в синем океане, он привлекается когда ИТ ландшафт сложился и возникают сложности его развития и адаптации под изменившиеся условия, в технологический стартапах создаётся минимально способный продукт (MVP). Бизнес-архитектор корпоративного ИТ ландшафта должна решать проблемы с низкой скоростью внесения изменений (из-за невозможности локального тестирования, откладывания распределённых изменений, иском поломки после накатки распределённых изменений) – Time To Market, быстрой адаптаций к ожиданиям пользователей – Customer Experience и стоимость – Cost. Первая решается последовательными активностями архитектора по наведению порядка, снижая связанность и запутанность, что упрощает и ускоряет процесс внесения изменений и как и в любой наукоемкой сфере, где основной затратой является человеко-часы работников, уменьшает стоимость. Архитектору всё чаще и чаще не предоставляются требования, он подключается на самых ранних этапах их формирования, после его возможности сильно ограниченны. Для этого ему нужно активно участвовать в переговорах и собраниях, чтобы корректировать требования. Далее сформировать несколько возможных решений с разным уровнем сложности, от простого и быстрого, но не эффективного ("решения на коленке"), через оптимальное, и до масштабного и гибкого. Далее сформировать архитектурный комитет, на котором предложить решения для выбора и скорректировать выбор в сторону оптимального.
Изменение существующий архитектуры может осуществляться тремя способами: сопровождение текущей, полной заменой текущей, дополнение текущей. Замена текущей требует проведение долгого и длительного исследования функционала текущей системы, далее выяснения функционала, который на текущий момент востребован и проведения поиска отличий между текущем функционалом и ожидаемым, после этого рассчитывается стоимость и время разработки. При презентации, в большинстве случаев будет получен отказ в разработке системы, так как заказчику не нужно техническое обновление существующего функционала, а ему нужен новы и корректировка старого, и тем более не за время и средства, которые были потрачены на создание текущей системы. При последовательном улучшении системы нельзя добиться фундаментальных изменений системы, так как архитектурно отличающийся функционал одной части противоречить другим и изменения архитектурного стиля не достигается последовательными улучшениями частей из-за комплексной природы.
Стратегия Enterpris Architect по-разному реализует разные стратегии компании:
* Стратегия роста (масштабирования), когда рынок свободен – архитектура унифицирует и отлаживает процессы;
* Стратегия инноваций (поиск гипотез по Lean Startup). Максимально быстра создание и доставка фич и проверка гипотез о востребованности этих фич;
* Стратегия интеграции. Необходимо разработать открытый наиболее масштабируемый и версионированный API;
* Стратегия адаптации. Не стратегии, с помощью Agile подстройка под рынок;
* Стратегия быстрых принятий решений. Последовательные изменения.
Корпоративная архитектура
Корпоративная архитектура – это архитектура всего ИТ ландшафта компании. Корпоративный архитектор руководствуется принципами создания архитектуры, своего рода конституцией. Принципы описаны в третьем заделе TOGAF 9.2 под пунктом 20. Они регулируют, каким требованиям будет соответствовать, например, принцип ориентированности на заказчика или бережливого производства. Важно, чтобы все участники (стейкхолдеры) были согласны придерживаться одних и тех же принципов. Принципы разделяются по применимости к слоям архитектур: бизнес, данных, приложения и технологической.
На практике, корпоративная архитектура развивается в трёх направлениях: унификация технологий, разработка концептуальных архитектур, унификация ландшафта. Под ландшафтом понимается не столько карта АС, сколько набор унифицированных решений, на основе которых строится бизнес-система, и с которыми она взаимодействует, обычно, инфраструктурными системами (логирования, мониторинга). Для построения самой бизнес-системы применяются унифицированные решения и технологии. Для унификации решений адаптируются старые или создаются новые решения, заказчиком которых является отдел корпоративных архитекторов. Для унификации технологий создаются рабочие группы корпоративных архитекторов – исследователей, которые проверяют возможности имеющихся решений, аналогов и принимают решения или об распространения уже имеющихся, или об внедрении новых. На основе исследований архитекторы – исследователи создают стандарты, описывающие пограничные возможности их применимости и регулирую их использование. В зависимости от активностей, у корпоративного архитектора могут быть разные заказчики: руководство организации, регулирующими подразделения (безопасность, поддержки и другие), команды разработки платформенных решений, архитекторы команд разработки (для создания концептуальной архитектуры их будущего сервиса).
При построении бизнес-системы её отроют из уже имеющихся унифицированных решений, нового функционала, задействуют уже имеющиеся технологии и инфраструктурные системы. Например, унификации и стандартизации набора языков программирования. Здесь критериями выступаю в том числе и экономические показатели стоимости разработки (скорости разработки на каком-то языке и стоимости самих разработчиков необходимой квалификации на этом языке), гарантий по сопровождению (наличию достаточного числа свободных кадров и резюме), сложность поддержки, аутсорсинга и других.
Enterprose Architect участвует в процессе разработки сервиса как минимум на двух этапах – на проверки разработанной концептуальной архитектуры сервиса и при проверке соответствия детальной архитектуры разработанного сервиса ей и стандартов на приёмосдаточных испытаниях. На практике, он делает концептуальную архитектуру сервиса сам и сам добавляет её в карту сервисов, так у него есть необходимый опыт и знание всех стандартов. На практике, Enterprose Architect помогает в разработке детальной архитектуры сервиса архитектору сервиса в её составлении и под концептуальную архитектуру в соответствии с видением архитектора сервиса. По факту концептуальная архитектура является архитектурой интеграции сервиса с другими сервисами для внесения её в ландшафт сервисов, в то время как детальная – реализацией сервиса в соответствии с ожиданиями стейкхолдеров (заказчиков, контролирующих отделов). Именно реализация должна соответствовать ограничениям, накладываемым Enterprise Architect на реализацию, например, по унификации технологий. Если же совместной работы не происходит, то Enterprise Architect становится контролирующим органом, который блокирует развёртывание сервиса критическими замечаниями или устанавливает технический долг со сроками устранения.
Корпоративный архитектор при разработке концептуальной архитектуры договаривается с архитекторами сервисов, с которыми необходимо его сервису интегрироваться и находит компромиссные решения, а также другими заинтересованными сторонами, например, сотрудниками безопасности. Договорившись, он выносит на более высокий уровень согласования, для подтверждения консенсуса. Корпоративному архитектору необходимы знания сервисов и стандартов, коммуникационные навыки и знания интеграционных архитектору, таких как сервисная шина предприятия и умение быстро создавать архитектуру при недостаточности информации в жёстко ограниченные сроки.
Возможно применение более мягкого процесса проверки стандартам на основе аудита, которые часто можно свести к чек листам или автоматическим проверкам соответствия. На практике, такие чек листы архитектор сервиса может пройти под руководством Enterprise Architect для правильной интерпретации в самом начале и далее проходить по мере необходимости для корректировки соответствия. Современные системы предоставляют их настройку в виде конфигурационных файлов, что позволяет автоматизировать проверку по списку таких систем и их конфигурационным файлам. Большинство из них работает в асинхронном режиме, то есть асинхронно приводится состояния соответствующих систем к состоянию, описанному в этих конфигурационных файлах – IaaC. В большинстве случае состояние, к которому приводится систем, можно получить в декларативном виде в формате или JSON или YML. Эти форматы совместимы и взаимно конвертируемы. Существует проект OPA (Open Policy Agent) по консорциумом CNCF (Cloud Native Computing Foundation) который позволяет создать правила в декларативном виде, для проверки им соответствия JSON конфигураций. Проверка осуществляется в синхронном и асинхронном виде. Для большинства систем, применение изменений возможно в виде IaaC, то есть как отправка новых конфигурационных файлов в системы, на основе который состояние систем приводится в соответствие с ними. По факту, применяются отличия между ними. Это означает, что не нужно проверять текущее состояние системы, а можно проверить сами отравляемые конфигурационные файлы. В результате мы имеем конфигурационный файл валидации изменений в декларативном формате – GaaS (governance as a code). Рассмотрим несколько слоёв, которые можно проверить:
* Слой виртуальных машин (OpenStack, VMWare vSphere JSON Template);
* Слой сети (VMWare NSX);
* Слой настройки серверов (Ansible AWX);
* Слой настройки сервисов (Hashicorp Terraform/AWS CloudFormation);
* Слой настройки контейнеров сервисов (Kubernetes/OpenShift);
* Слой маршрутизации трафика между сервисами (Istio, Envoy);
* Слой библиотек приложений (NPM для JavaScript, Maven для Java, Composer для PHP).
Взаимодействие между сервисами (маршрутизация трафика) описывается конфигурационными файлами Istio и Envoy (более тонкая настройка), которые подаются в Kubernetes и являются конфигурационными файлами Kubernetes. OpenShift предоставляет расширение Kubernetes, но и его конфигурационные файлы является нативными к Kubernetes. Сам Kubernetes настраивается с помощью YML или JSON конфигов, передающихся асинхронно. Например, конфигурационные файлы Kubernetes полностью описывают состояние контейнеров (kubectl get deployment -o yaml), разрешённый входной и выходной трафик из сервиса (kubectl get NetworkPolicy -o YAML), сервисные аккаунты (kubectl get ca -o yaml), шифрование между сервисами при применении Istio (kubectl get Destination Rule -o yaml) и так далее.
Многие облачные провайдеров, предоставляющие API к своим облакам по управления сервисами, имеют либо свои конфигурации IaaC поверх них, например, AWS CloudFormation, или интегрируются с абстракцией Terraform, под который можно разработать свой модель. Сами конфигурации описываются в декларативном виде, но на своём языке конфигураций. Но, можно получить состояние приводимое состояние системы в формате JSON:
terraform init
terraform plan –out tfplan.binary
terraform show -json tfplan.binary > tfplan.json
Ansible AWX является надстройкой над Ansible и принимает его конфигурационные файлы. Сами конфигурационные файлы пишутся в формате YAML. Ansible приводит состояние серверов из списка (в файле inventory) к описанному в конфигурационном файле. Выделение серверов в OpenStack, в какой-то мере, можно описать также в YML формате. На уровне в VMWare NSX описывает в конфигурационных файлах межсегментное взаимодействие в том же YML формате, что и другие. Если говорить о слое библиотек, то многие сборщики устанавливают и до устанавливают пакеты в соответствии с конфигурационными файлами, так NPM в NodeJS работает с JSON конфигурацией package.JSON, Composer в PHP работает также с JSON конфигурацией composer.JSON. Conda в Python использует конфигурационный файл conda.YAML в формате YAML, который однозначно преобразуется в JSON. Исключением является Maven в Java, который хранит XML конфигурацию в файле pom.xml, но, как показывает практика, преобразовать pom.xml в валидный JSON формат с помощью Python/NodeJS не составляет труда.
Архитектор сервиса
Архитектор сервиса или Solution архитектор отвечает за разрабатываемый сервис. Он подключается на самых ранних этапах согласования сервиса менеджментом, что иметь возможность повлиять на принимаемые решения в отношении этого сервиса до того, как они будут приняты. Причём, это решения не технические, а управленческие, например, сроки и бюджет. Если эти решения будут приняты без него, то архитектору придётся не решать выбор стека и типа архитектуры, а выбирать что и в какой степени он сможет реализовать. Также архитектор осуществляет надзор во время реализации архитектурных решений и архитектурный контроль при принятии сервиса. Обычно, архитектор сервиса сопровождает сам сервис и на приёмке, защищает архитектуру и осуществляет приёмку работы перед заказчиком на приёмочных испытаниях.
Архитектор сервиса – роль, при этом по должности он может быть и разработчиком, инженером по базам данных, и бизнес-аналитиком и директором. Обычно, когда формируется направление, эту роль выполняет формирующий её директор. Позднее, когда известны отдельные сервисы он подключает или технического специалистов с высокими коммуникационными навыками, или бизнес-аналитика с помощником в виде ведущих технических специалистов этого сервиса.
Чаще всего эту роль берёт на себя технический специалист, так как нарастить техническую базу, чтобы они могут опускаться с верхних слоёв абстракции до самых нижних и видеть технические проблемы и узкие места, нетехническим специалистам практически не представляется возможным. Именно умение переключаться между разными уровнями абстракции и эффективно на них работать является ключевым навыком архитектора. Но технические специалисты за счёт своих коммуникационных навыков привлекают технических специалистов, там, где им не хватает экспертизы, что технические специалисты не привыкли делать. Это проходит, так как техническим специалистам не хватает ресурсов охватить всё самим. По привычке, когда у них была одна задача в их профессиональной сфере 1 они погружались в неё для её решения, в роли же архитектора, они не могут стать специалистами всех технических профилей и сделать всё самим, на это нет столько ресурсов и от них этого и не требуется – реализовывать будет команда и затронутые в проекте специалисты. Обратной же стороной является, то, что технические специалисты в силу возможности углубиться в проблемы каждого компонента могут их это учитывать, но это возможно на небольших проектах, на более крупных это решается привлечением экспертов и корпоративных архитекторов практиков для аудита, следованию стандартов, что знакомо менеджерам. Другим различием является понимание бизнес-требований, в частности, в финансовой сфере, сроков и интеграций. Если у технических специалистов проблем с интеграциями, как правило не возникаем, то у не технических, наоборот, переложив их на других, он могут оказаться с тем, что собрать всё в едино сложно. С другой, у жёсткие требования по финансам и срокам в заказной разработке может провалить проект, так как заказчик может от него отказаться и ещё потребовать неустойку, причём в силу слабых коммуникативных способностей – в конце реализации проекта. Тоже, наблюдается, при защите архитектором проекта у директоров, особенно у финансового, когда архитектор не может обосновать выбор ему понравившейся, но дорогой технологии, когда в данной ситуации нет видимых объективных оснований, например, Java вместо PHP, Oracle вместо MySQL, микро-сервисов вместо монолита, самописного решения вместо CMS для небольшого интернет-магазина.
В целом задачами разработки архитектуры является согласование компонентов, выбора новых технологий, достижения нужного результата без переделок, упрощение приёмки. Основной задачей для менеджеров разработки архитектуры – ускорение внедрения и ускорение вхождения новых сотрудников. Для заказчика – соответствие реализации замыслу и в случае отклонений при разработке корректировки на ранних этапах, что снижает стоимость исправлений. Для разработчиков – быстрое и простое внедрение в производственный процесс.
В идеале, архитектура неизменна, но в реальности это часто не так. В основном, краеугольным камнем становится коммуникационные навыки архитектора, который умеет договариваться, находить компромиссы и доносить решения. Для донесения сути разрабатываемой архитектуры применяют различные отображения, срезы, которые отображаю архитектуру с разных сторон. Для IT это разработка архитектуры различных слоёв. Слои могут быть по TOGAF: бизнес-архитектура, информационная архитектура, Solution Architect, интеграционная архитектура, техническая архитектура). На каждом уровне необходимо отобразить компоненты системы (структурная схема) и бизнес-процессы (динамическая схема).
В общем, архитекторов можно разделить на две группы: Enterprise Architect и Solution Architect. Enterprise Architect занимается поиском и унификацией технологий, в то время как Solution Architect разработкой архитектуры конкретной системы на основе утверждённых технологий и внесение её в карту приложений. В небольших компаниях, в которых разрабатываемых архитектур систем невелико, корпоративная архитектура не выделяется – её заменяет составляющая архитектуры системы, а именно интеграционная архитектура.
Solution Architect должен обладать очень хорошими Soft- навыками (коммуникационными навыками). В бытовом представлении может сложиться образ человека, сидящего и рисующего квадратики и стрелочки между ними. Но, давайте представим ситуацию: приходит архитектор на проект, видит команду что-то разрабатывающую и слышит слова от заказчика: продукт тормозит и нестабильно работает, нужно исправить ситуацию. Что, где и почему тормозит и падает, да и просто, где его проект не понятно. Никакие глубокие технические навыки сейчас не нужны, да и проекты разные (на стандартном проекте архитектор не нужен) и уже есть на нём эксперты. Здесь основное отличии не в уровне работы, по сравнению с разработчиком, а в принципиально другой – вместо решения поставленной задачи формирование самой задачи. Если разработчик берёт готовую задачу из системы постановки задач (например, Jira) и её выполняет, иногда, уточняя условия у постановщика, то у архитектора огромное количество уходит на поиск стейкхолдеров, выработку оптимального решения на основе требований и нахождение компромиссного решения. Есть обратиться к менеджеру, тим лиду, разработчику, то ни один из них не скажет в чём проблема. Если же пойти в инфраструктуру, то ситуация ещё интереснее – кто-то, что-то, где-то разворачивал, а как-то это всё работает, а кому задать вопрос тоже не ясно. Если система более ли менее сложная, то интеграций очень много, и за каждой стоит отдельные люди, найти зачастую которых можно, узнав только у тех, кому довелось с ними работать. При этом напрямую просто так задать вопрос интеграторам не получится – у них свои задачи, и зачастую на связь они не выходят. Это типичная ситуация менеджера в проекте, поэтому, в этой части можно архитектора программного обеспечения рассматривать как технического менеджера, который управляет не задачами, а архитектурными компонентами.
Рассмотрим более конкретно коммуникацию и взаимодействия архитектора сервиса:
* Он контактирует с TeamLead, чтобы ознакомиться с текущим бэклогом команды. Бэклог содержит дорожную карту и требования. Это позволит и определить объём работы, который она сможет выполнить и их приоритеты.
* Он контактирует с Product Owner для получения бизнес описания необходимого сервиса, и на какие фичи тот договорился с заказчиком, бизнес-процессов.
* Он контактирует с корпоративным архитектором для получения концептуальной архитектуры функциональной области сервиса и требований стандартов, под которые попадает сервис.
* Он контактирует с архитектором платформы для получения компонентной базы.
* Он контактирует с архитекторами серверов, с которыми он интегрируется.
* Он контактирует со специалистами, отвечающими за закупки (если используются новые сервера, платное ПО), безопасность, техническую поддержку сервиса (если используются новые стеки), сопровождение, юридическим отделом (если используются OpenSource продукты).
При приходе в проект, как и менеджер, необходимо ознакомиться с тем, что имеется и определить заинтересованные стороны (stakeholder). Stakeholder – имеющий отношение к проекту. Он может быть заинтересован в успехе или наоборот, не заинтересован. В ITIL4 (IT Infrastructure Library version 4), сборника рекомендаций по использованию ITSM (IT Service Management) от 2019 года созданный более 150 авторами для построения IT развивающийся с 1986 года, определяется такие основные типы, как Спонсор, Заказчик, Пользователь, Поставщик услуг и другие:
* Пользователь – человек, который пользуется услугой. К примеру, если система разрабатывается для отдела бухгалтерии, то пользователями будут бухгалтера, хотя заказчиком может выступать руководитель этого подразделения. Зачастую они и будет тестировать разрабатываемый продукт и его оценивать;
* Заказчик – предъявляете требования и отвечает за результат от её потребления. Например, если система разрабатывается для внутреннего отдела, то руководитель отдела заказывает эту систему для своих сотрудников в расчёте, что их работу станет более эффективной;
* Спонсор – это владелец ресурсов, который утверждает оплату. Для нашего примера, это может быть финансовый директор, который посчитал экономически оправданным затраты на разработку этой системы для повышения эффективности на такой объём с такими рисками в текущей ситуации;
* Подрядчик – заинтересованная сторона, ответственная за предоставление услуг. Подрядчик может быть как внутренним, так и внешним. Для архитектуры, они могут быть команда разработки, системные инженеры, отдельные подразделения, осуществляющие интеграцию с различными их сервисами и другие;
* Владелец услуги – роль, ответственная за предоставление услуги. Для архитектора обычно это руководители подразделений, разрабатывающие сервисы, с которыми его продукт интегрируется.
По ITIL4 услуга (сервис) – это способ обеспечения совместного создания (содействия) ценности через совместную деятельность для достижения результата нужного заказчику, без несения заказчиками рисков и отдельных затрат. Именно наличие содействия отличает сервис от продукта. То есть заказчик заказывает результат в надежде его гарантированно получить оплатив его полностью, а не оплачивая его части. Соответственно, результатом работу архитектора в связке со стейкхолдерами должна быть ценность, при этом заказчик возлагает отдельные риски и решения на него, что он будет их решать. При этом ценности независимая работа архитектора не имеет, а появляется только при совместной деятельности. Так, разработанные архитектором схемы ценности – это видение личное архитектора, о котором никто не знает, которое не понятны, с с которым не согласны. Следовательно, в отрыве схемы не несут пользы, а несёт ценность осведомлённость стейкхолдеров об необходимых работах и составе проекта на основе этих схем. Важно заметить, что ценность получают все заинтересованные лица, за редким исключением. Совместное создание ценности происходит через сервисные функции.
В общем, ITIL4 выделяет основные принципы:
* Сотрудничайте;
* Концентрируйтесь на ценности;
* В данной ситуации;
* Действуйте итерационно, но системно;
* Не усложняйте;
* Оптимизация и автоматизация.
Важно заметить, что не стоит вести проектную деятельность по ITSM, предназначенной для потоковой, такой как техническая поддержка.
Также важно заметить, что архитектор сервиса является техническим руководителем и ему необходимы управленческие навыки. Отличии заключается в том, что менеджер больше уделяет психологии и финансам, чтобы повысить экономическую привлекательность реализации при неизменных решениях, а архитектор – технической составляющей. Но, что и менеджеру, что и архитектору, необходимо либо вписаться в бюджет и сроки проекта или отстоять его увеличение. Вписываться, они будут разными способами. Во временные границы менеджер может увеличить число работников или их квалификацию, а архитектор – упрощением архитектуры или заменой на готовые решения её элементов. Также важно заметить, что менеджер может управлять как операционной деятельностью, так и гибкими методологиями, в то время как архитектор, как правило, работает с проектом, хотя архитектурный циклы и могут напоминать спринты Scrum.
Использование в управлении ITIL 4, PMBOOK и COBIT 5
Архитектор хоть и технический управляющий, но всё же управляющий, поэтому познакомимся с азами управления. Давайте рассмотрим различные типы организаций групп людей и управленцев в них. Я дам им общие характерные названия, но они не являются правилом. Я отсортировал их от минимального размера к более масштабируемым и требующих большую управленческую подготовку:
* "старший разработчик" – один из разработчиков, который всё может сделать в одиночку, делегирует повторяющиеся или простые задачи на начинающих, для экономии своего времени;
* "тимлид" – выстраивает иерархию, декомпозирует на мелкие задачи, распределяет эти задачи, контролирует их процесс выполнения. Он понимает, как будут решаться задачи, понимает сложность или требует чёткой оценки. Всё идёт по плану и по графику;
* "менеджер" – менеджер не владеет знаниями технических специалистов, а представляет их как функции. Менеджер сосредоточен на видение результата и процесса, не вникая в реализационные моменты;
* "совет директоров" – каждый представляет своё направление. Это может быть совет директоров, например, технического (CTO), финансового (CFO) и других директоров. А может быть и группа разнородных специалистов, например, Front-End, Back-End, SRE и DBA, среди которых не пересечения ни по технологиям, ни по языкам программировании, но они имеют общее представление, чем занимаются коллеги. Для их слаженной работы необходима коммуникация для принятия единого решения.
По наличию экспертизы можно разделить деятельность на три категории и в зависимости от вида деятельности, применяются свои методологии управления:
* Исследовательская работа – гибкие методологии, например, SCRUM;
* Проектная деятельность – жёсткие методологии, например, PMI;
* Операционная деятельность – процессное или сервисное управление, например, ITIL.
Проектная деятельность описана в PMBOOK и PRINCE 2, и основана на тройственных ограничениях: времени, ресурсах и сколько задач.
Операционная деятельность часто декомпозируется на несколько процессов, которые предоставляют конечным пользователям сервисы. Принципы работы по сервис ориентированному принципу и управления ими описан в IT service management (ITSM). ITSM описывает 34 практики управления процессами, например, такие:
* Управление инцидентами, например, критическими неисправностями, которые нужно сейчас исправить "заплаткой", чтобы восстановить работу;
* Управление изменениями, такими как, разработка;
* Управление конфигурациями;
* Управление безопасностью;
* Управления проблемами;
* Управления релизами;
* Управления уровнем услуг;
* Управления мощностями;
* Управления доступностью;
* Управления непрерывностью;
* Управления финансами.
Для управления разработаны фреймворки. Корпоративные фреймворки на базе ITSM, например, IBM IT Process Medel, Microsoft Operations Framework (MOF), IP ITSM Reference Model и SUN SunTone. Популярный фреймворк ITIL, базирующийся на ITSM и разработаны по заказу правительства Великобритании и дорабатываемый многими фирмами – ITIL (IT Library). Он не предписывает следованию определённым процессам, не является инструкцией и не описывает идеальную модель, а является набором практики управления IT услугами – практические подходы к решению определённых проблем. Это сделано намерено, так как разрабатывался для различных IT компаний государства.
В ITIL3 основные группы процессов: предоставления услуг и поддержка услуг.
Процессы поддержки услуг:
* Управление инцидентами;
* Управление проблемами;
* Управление изменениями;
* Управление конфигурациями;
* Управление релизами;
Предоставление услуг:
* Управление уровнем услуг;
* Управление доступностью;
* Управление мощностями;
* Управление непрерывностью ИТ-Услуг;
* Управление финансами ИТ.
После разработки продукта он из продукта становится услугой, которой процессно управляют. Процесс проходит четыре этапа
в цикле Деминга PDC: планирование, действие, проверка, корректировка. Процесс по уровняю зрелости (контроля и автоматизации)
в соответствии с CMMI (Capability Maturity Model Integration) делить на уровни:
0. Отсутствующий;
1. Начальный;
2. Повторяемый по интуиции;
3. Предписанный;
4. Управляемый и измеримый;
5. Оптимизируемый – просто требует улучшений.
Архитектор не только сам управляет, но и находится в системе управления. Для эффективной работы необходимо понимать занимаемое в ней место и принципы эффективного взаимодействия руководством, заказчиками и отделами. Структуру IT в большой компании описывает модель COBIT, принятая как основа многими ведущими компаниями. COBIT (Control Objectives for Information and Related Technology), даны просто название COBIT, изначально разрабатывался для проведения аудита IT компаний на предмет возможности стабильно удовлетворять потребности заказчика. Разрабатывается международной компанией ISACA, основанной в 1969 году. Занимается она разработкой и сертификацией в области безопасности и качества информационных систем. В последнее время, для большего распространения и под влиянием OpenSource стратегий развития продуктов, она уже позволяет скачивать COBIT 5. Сам COBIT представлен несколькими книгами: основанной и книгами по направлениям. Он позиционируется как всеобъемлющая едина книга, в которой интегрированы различные методологии, такие как методологии проектного управления PMBOOK, методологии сервисного обслуживания ITIL и методологии проведения архитектурных работ TOGAF. В COBIT содержатся ссылки на различные издания, для большей детализации. COBIT ставит своей целью дать набор стандартизованных рекомендаций для построения высокоуровневых процессов и аудита IT в компании. Поэтому он адресован в первую очередь правлению, во вторую – управленческому персоналу, а именно на методологов процессов (для унификации существующих процессов), руководителей ИТ (необходимые процессы для достижения целей), аудиторам ИТ (проведения аудита зрелости процессов и соответствия идеальной организации), заказчику ИТ (для выставления целей и их мониторинга).
С каждой версией она наращивает COBIT в охвате сферы компании, добавляя к существующим в прошлых версиям новые слои:
* 1996 COBIT 1 – аудит;
* 1998 COBIT 2 – контроль;
* 2000 COBIT 3 – управление;
* 2005 COBIT 4.0 – руководство IT;
* 2007 COBIT 4.1 – руководство IT;
* 2012 COBIT 5 – руководство IT в организации;
* 2019 COBIT 2019 – интеграция IT во всю корпорацию.
COBIT 2019 описывает руководство и управление корпоративной информацией и технологиями, охватывающая всю организацию. Он включает DevOps, Agile, Cloud, SIAM, Интернет вещей (IoT). Процессы заменены на задачи для руководства. Добавились задачи на управление данными, проектами и аудитом. Мы же вернёмся к получившей распространение COBIT 5. COBIT 5 (адресован в первую очередь правления, во вторую – управленческому персоналу, а именно не доступен для скачивания на различных языка, включая русский язык бесплатно.
BOBIT 5 состоит из книг (COBIT PAM) и опирается на 5 принципов:
* Соответствие потребностям заинтересованных сторон, через каскад целей;
* Комплексный взгляд на предприятие (ИТ – типовая часть предприятия, как и другие подразделения);
* Применение единой интеграционной методологии, включающей другие методологии (ITIL, ISO 20000, PMBOOK);
* Обеспечение целостности подхода (не только сами услуги важны);
* Разделение руководства (выявление целей и мониторинг) и управление (создание бизнес-процессов).
Рассмотрим более подробно каскад целей для соответствия потребностям заинтересованных сторон. В самом начале рассматриваются потребности и далее детализируются до конкретной реализации в процессах. Весь процесс проходит через пять этапов:
* Движущие силы заинтересованных сторон;
* Цели руководства: получение выгод, оптимизация рисков и ресурсов;
* Цели предприятия: 17 стандартный целей;
* ИТ цели: 17 стандартный целей;
* Факторы виляния: 37 стандартных процессов, организационная структура, социум, принципы, информация, услуги и персонал.
Подход близок к ведению проекта PMBOOK у целей руководства при тройственных ограничениях и TOGAF в слоённости структуры. Переход с целей предприятия на ИТ целей по таблице.
BOBIT 5 предоставляет удобный инструмент: система сбалансированных показателей (Balanced Scorecard) по целям руководства и области проблемы необходимые действия. Представлено три цели руководства: получение выгод, оптимизация рисков и оптимизация ресурсов. Областей проблем (точек воздействия) четыре:
* Финансы;
* Заказчик;
* Внутреннее управление;
* Обучение и развитие.
Система сбалансированных показателей из себя она представляет таблицу связей, в строках которой 17 возможных целей предприятия, сгруппированных в группы и в столбцах 3 цели руководства. Например, если нужно сосредоточиться на заказчике и в качестве целей выбрано получение прибыли, то мы получим по таблице 4 цели предприятия и 5 целей ИТ:
