SOA, или сервис-ориентированная архитектура. Основополагающий элемент построения сложных компьютерных систем, без правильного понимания которого невозможно строить никакие системы, кроме монолитных.
Неважно, какая архитектура задумывалась у конечных систем. Если в компании нет понимания, что такое сервис, все системы становятся сложными, настройки любых решений — запутанными. Размываются границы ответственности программ в подчинении департаментов, а также границы самих департаментов и отделов в компании.
В результате возникают многочисленные конфликты, а внедрение любых инноваций напоминает движение по минному полю: медленно, опасно и дойдут не все.
Микросервисы лучше?
Многие айтишники, услышав про SOA, могут многозначительно сказать что-то вроде «я знаю что это такое, но у нас микросервисная архитектура».
За редким исключением, эта фраза — верный признак непонимания SOA. А айтишник, который не понимает SOA, запутывает и бизнес-пользователя.
В результате управленцы воспринимают сервис-ориентированную архитектуру как какой-то непонятный принцип. Вроде полезный, но «микросервисы лучше».
В процессе консультирования клиентов KT.Team мы ещё ни разу не находили полностью безошибочно построенных сервисов. А ведь ошибки в построении сервисов могут стоить компании половины IT-бюджета!
Это столь важная тема, что в рамках нашего курса для проектных менеджеров и стратегических консультантов мы выделили её отдельно в блоке организационного контура предприятия. Мы учим не разделять IT-сервисы с оргсхемами и согласовательными бизнес-процессами.
Проблемы роста компании
Представьте, что ваша организация только появилась на свет. Должностей и отделов ещё нет, регламенты и договоренности о разделе полномочий отсутствуют, да и вообще вы все сидите в небольшом кабинете. На инженерном языке вас можно назвать монолитом.
Пока функций немного и ваши процессы максимально простые, за счёт мудрой головы управленца добавление новой обязанности или задачи в компанию организационно «стоит» недорого. Вы бодро побеждаете проблему за проблемой — и «машинка едет». Однако компания находится в режиме ручного управления.
Ваша компания растёт,и вместе с ней растут процессы. Вы уже не размещаетесь в одной каморке, вы занимаете целиком здание. Однако у вас еще нет оргструктуры, а без неё не может быть и сервисной архитектуры.
Процессы имеют всё больше нюансов, вероятность исполнения каждого нововведения уменьшается. Вы не можете уволить Машу за невыполненный пункт № 7 вашей инструкции по проверке договоров, потому что на ней держится десяток важных функций.
Маша вам говорит: «Виновата, больше не буду». В следующий раз, возможно, она и выполнит пункт № 7, но, вероятно, нарушит пункт № 9 и пункт № 3.
Полномочия отделов и отдельных сотрудников всё ещё перемешаны.
Вам пока не нужно, чтобы людей было как минимум столько же, сколько функций. Вы поделили так компанию, как казалось логичным — например, поделили по этажам, на которых сидят отделы.
Этот пример намеренно «притянут за уши». Конечно же, вы поделили отделы на условную бухгалтерию и отдел закупок, например. Но всё ли из бухгалтерии вы теперь можете требовать именно у бухгалтерии? Есть ли там понятные метрики? Нет ли случаев, когда бухгалтерия вам скажет: «Мы знаем про эту проблему, но виноват IT-отдел, который не сделал нужную фичу»? Нет ли случаев, когда отдел закупки материалов вам скажет, что покупал чётко по инструкции, но данные, которые есть в некой общей программе, некачественные: содержат дубли или неточности?
Такие ситуации сигнализируют о том, что у отделов нет власти в принятии решений для изменения их работы, следовательно, у вас нет власти требовать у отделов результат.
С течением времени без правильного разграничения сфер и полномочий, без делегирования полной ответственности вместе с ограничением управляемого контекста, организация становится неуправляемой. Руководитель на работе с утра до ночи, не отходит от ноутбука и телефона ни в отпуске, ни на выходных просто для того, чтобы «всё нормально работало». Измерить бухгалтерию и отдел закупок если и возможно, то ответственность за этот результат всегда у кого-то другого.
По красивой картинке у вас оргсхема предприятия. По факту у вас по-прежнему монолит.
Монолит — это такое состояние организации или программы, при котором каждое новое расширение функционала стоит дороже, чем предыдущее. На каждое следующее изменение требуется всё больше сервисных действий. Доходит до того, что у вас растёт количество людей, а прибыль нет.
Монолитная IT-архитектура абсолютно такая же. Внешне она может быть похожа на разные программы и сервисы, а по факту всё так плотно связано между собой, что добавление нового функционала всегда вызывает больше накладных расходов, чем ранее.
Компании нужны супергерои
Безусловно, ваша компания с плохо поделенными отделами (в IT это называют сильной связанностью) может как-то жить. Проблема в том, что в отделах должны работать суперлюди, которые могут решить любую проблему.
И работать эти супергерои у вас будут вплоть до выгорания.
В IT в условиях сильной связанности происходит то же самое. Каждый из команды понимает логику до какого-то предела. Но чем дальше, тем сложнее понять, что именно нужно сделать. Вам будет требоваться всё более крутой технарь, который будет разруливать любые проблемы — пока не выгорит. Нужно что-то делать, да? Реакции многих руководителей и инженеров в этой ситуации очень похожи.
Руководители читают Harvard Business Review, слушают модные конференции и Грефа — и узнают про Agile, про бирюзу или про какое-то супер-пупер решение, которое систематизирует ваш бизнес и сделает всю работу за них. «О боже, существует какая-то волшебная таблетка, которая все решит!»
Разработчики начинают судорожно читать модные статьи и узнают про микросервисную архитектуру или про какую-нибудь другую супер-пупер-систему, язык или подход. Вдохновившись, они приходят к управленцу и рассказывают про большие планы по изменениям.
В этот момент самая большая ошибка — поверить в магическое мышление. В то, что с помощью какой-то одной технологии можно одним махом решить организационные проблемы. В то, что у вас улучшится качество данных внедрением какой-нибудь новой системы. В то, что у вас ускорится разработка с помощью перехода на какой-нибудь новый подход…
Системное решение, которое позволит улучшить монолитной организационной структуры, — выделить какую-то часть функционала в отдельный блок. Но выделять по наитию нельзя — как в бизнесе, так и в IT. Более того, IT нужно делить ровно по тем же границам, как и бизнес.
Сервис и ценный конечный продукт
И вот мы добрались до того, зачем нужно понимание сервиса.
Сервис — это не какое-то магическое заклинание, которое вроде как лучше монолита, но хуже микросервиса. Сервисная архитектура — это карта функций ваших систем, разбитых на бизнес-блоки. Сервис определяется в парадигмах ценного конечного продукта или в определениях выхода процесса в процессном управлении. На выходе должно быть предельно ясно и прозрачно, что именно у этого сервиса «покупает» другая компания (или другой отдел в рамках вашей компании).
Например, посмотрим на организационную схему Хаббарда. Согласно этой схеме, в компании есть коммуникационное подразделение, а в нём, в свою очередь, есть отдел рекрутинга и ввода в должность. Назовем это HR-контекстом.
Этот отдел производит свой ценный конечный продукт «нанятые, введённые в должность и хорошо производящие свои продукты сотрудники».
Этот отдел будет ответственным за свой конечный продукт тогда и только тогда, когда у него будут все полномочия по исполнению ЦКП. HR-отдел должен работать в своей изолированной IT-системе ровно для того, чтобы самостоятельно управлять нужными изменениями.
Важно, чтобы HR-отдел выдавал в вашу организацию лишь то, что является его ЦКП. В реальном мире это сотрудники, а в мире IT — цифровая копия сотрудника. При этом HR-отдел должен выдавать цифровую копию сотрудников в таком формате, за который он мог бы нести ответственность, но работа его не зависела бы от того, какими решениями пользуются другие отделы.
Это называется слабой связанностью.
В нецифровом виде такая связь обеспечивается так: HR-отдел предоставляет досье сотрудника в общее место, куда другие отделы могут прийти и посмотреть эти досье — но не самостоятельно изменить.
А цифровая связь разных отделов между собой всегда должна обеспечиваться с помощью специальных решений, которые называются шинами. Именно они позволяют каждому отделу зафиксировать собственные правила предоставления нужной другим отделам информации.
Если завтра HR-отдел сменит свою программу 1С на облачный сервис, то единственное, что он должен сделать, — поменять в шине правило того, как обращаться к досье сотрудника.
Это часть полномочий HR отдела наравне с рекрутингом и вводом сотрудников в должность. Ведь цифровая копия сотрудника — это тот же самый сотрудник, только в цифровом виде.
Опасности магического мышления
Теперь представьте, что к вам приходит невероятно крутой айтишник и говорит: «Я внедрю суперархитектуру, которая все департаменты сделает лучше».
Будут ли полномочия у каждого отдельного отдела на нужную ему кнопку? Если будут, то сколько времени будет уходить на каждое внедрение? Если два изменения будут конкурировать за ресурсы, как будет решаться конфликт?
Вы можете строить IT-сервисы без учета целевых бизнес-процессов и сервисов, ориентируясь только на новые технологии. Но это приведёт к тому, что цифровая копия вашего предприятия и ваше предприятие всё больше и больше будут разделяться.
HR-отдел должен иметь полномочия сказать: «Мне не нужны ваши модные штучки, я хочу другое решение». Обязанности же IT-отдела — не заниматься микроменеджментом того, как работать другим отделам, а предоставлять общую инфраструктуру, чтобы каждый департамент мог предоставить цифровую копию своего ценного конечного продукта в общее пространство.
Это ни коим образом не означает, что совет директоров больше не ответственен за разработку технологии производства продукта или больше не принимает участие в определении правил и порядков. Это означает, что реализация и исполнение таких изменений в цифровом мире должна происходить точно так же, как и «в реальной жизни».
Когда ваш IT отдел приносит вам нововведение, вы должны рассматривать его не как магическое избавление от проблем, а переложить на процессы и убедиться, что автономность и гибкость отделов не будет потеряна.
Должна ли архитектура на всём предприятии быть единой?
Нет никаких микросервисных архитектур на всем предприятии, как нет единого размера департаментов.
В силу специфики бизнеса в HR-отделе у вас могут работать три человека с широкой специализацией, и для работы им будет нужна одна облачная программа. А бухгалтерия в то же время может состоять из сотен сотрудников, у каждого из которых будет очень узкая специализация. Сотрудники бухгалтерии будут объединены лишь едиными терминами и сущностями (в микросервисной архитектуре это называется «связанный контекст») и работать они будут в микросервисах.
А какой-нибудь отдел PR будет работать в монолитных программах. И это нормально — потому что цифровая копия отделов не может отличаться от реальности.
60 лет назад этот принцип описал Мэл Конви, публикацию которого Harvard Business Review сначала отклонил, потому что тот не предоставил убедительных доказательств своих выводов. Спустя 40 лет HBR наконец опубликовал все выводы Конви. Эпоха цифровизации наглядно показала, что происходит с компаниями, которые игнорируют эти законы.
Закон Конви
Organizations which design systems (in the broad sense used here) are constrained to produce designs which are copies of the communication structures of these organizations
Любая организация, которая разрабатывает систему (в широком смысле), вынуждена создавать проекты, структуры которых являются копией структуры связей организации.
Это же описывает Эрик Эванс в своей книге «Предметно-ориентированное программирование». Он уточняет: не только цифровая «версия» отделов, а даже цифровые копии бизнес-процессов и наименования сущностей не могут отличаться от того, что есть в реальной жизни. Книга написана для разработчиков, и если у вас нет технического бэкграунда, дальше второй главы читать вам будет скучно. Но начало и выводы книги плотно связывают реальности IT и менеджмента.
Эту литературу мы рекомендуем вслед за Дейвом Фарли, Мартином Фаулером, Томасом Эрлом. Их вклад в развитие компьютерной инженерии заставляет прислушаться к их рекомендациям.
Принцип построения IT-архитектуры
Прежде чем принимать решение об IT-архитектуре, убедитесь, что ваша техническая команда заинтересована в создании цифровой копии вашей компании, а не во внедрении модных технологий. Это ситуация распространённая и понятная: айтишникам интересно пробовать что-то новое и модное, что можно «положить в портфолио».
Чтобы избежать ошибок, сначала составьте на предприятии организационную структуру с отделами и подотделами. Потом нарисуйте карту секций с помощью бизнес-процессов согласовательного уровня. В зависимости от сложности процессов выход всего отдела или каждой секции станет сервисом. А будет ли он микро- или обычным, определяется не IT, а тем, как устроен ваш бизнес.
Понятно, что пока ваше предприятие небольшое, несколько сервисов будут выполнять одни и те же люди, а в случае программ — одни и те же программы. С ростом организации и, соответственно, ростом нагрузки на эти секции, они будут дробиться. В конечном итоге у бизнеса появится очень много очень простых функций, ответственных за очень узкие задачи. Если вы изначально планируете ваши департаменты правильным образом, то рост людей, бизнес-процессов и функционала в программном обеспечении будет расти синхронно.
Прелесть сервисов в том, что будучи правильно определены и правильно разделены, они не отделяют технологию от бизнеса, а подчиняют технологию бизнесу.
Но во многих компаниях мы видим, что подчинение построено в другом порядке: IT-департамент, не управляя стратегией и технологией работы и производства продукта, определяет технологию создания цифровых копий. Не IT живёт по правилам бизнеса, а остальные отделы живут по правилам IT.
При неправильном разделении на сервисы возникают конфликты, когда одна задача вроде бы должна решаться в одном месте, но частично решается ещё и в другом. Точно так же, как неправильное разделение отделов влечет к конфликтам между отделами и непрозрачным принятиям решений.
Технических примеров масса. Например, корпоративный сайт, будучи лишь интерфейсом к программе отдела закупок, формирует счёт самостоятельно вместо того, чтобы запрашивать его.
Или за качество данных отдела закупок чудесным образом начинает отвечать программа, лежащая не в ведомстве этого отдела.
Эта тема для понимания непростая. Обучая менеджеров, мы разбираем её и просим составлять сервисные карты, учим их моделировать в контексте бизнес-процессов организации и правильно находить конфликты между сервисами.
