Важной частью процесса внедрения IdM/IGA-решений является их проектирование в соответствии с потребностями и требованиями заказчика. Руководит работой на этом этапе системный архитектор, который выполняет роль связующего звена между компанией-заказчиком и командой разработки, и его главная цель – спроектировать полезную и эффективную систему, которая поможет заказчику решить поставленные задачи в сфере управления доступом.

О роли системного архитектора в проектах внедрения IdM-системы Solar inRights, ключевых навыках, необходимых в этой профессии, и особенностях работы над проектами в интервью Алёне Зубковой рассказывает системный архитектор Станислав Кравчук.

Кто такой системный архитектор? Какова его роль на проекте, какая у него зона ответственности?

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

Я бы сказал, что системный архитектор выполняет роль промежуточного звена между потребностями заказчика и техническими специалистами, которые занимаются реализацией технического решения. Это своего рода переводчик с языка бизнеса и его требований на технический язык разработчиков и инженеров.

Системный архитектор ‒ это всегда рост снизу к этой позиции, этап поступательного движения?

Это действительно некоторый этап развития: невозможно заниматься проектированием IdM-решений, не имея опыта взаимодействия с такими системами. Необходимо заранее ознакомиться с таким типом систем, поработать с ними в разных ролях ‒ например, на стороне технической поддержки или команды внедрения. При проектировании решения архитектор должен думать о том, как эту систему коллеги будут разрабатывать, как ее сопровождать и обновлять или масштабировать в дальнейшем, насколько удобно с ней будет работать заказчику.

В целом от архитектора зависит успешность самой системы ‒ то, насколько она удобна, отказоустойчива, насколько хорошо выполняет свою основную функцию, насколько просто ее сопровождать и развивать.

Получается, архитектор знает систему не понаслышке и может предлагать выверенные и взвешенные решения?

Да, конечно. Архитектор знает, как работает система, видит ее с разных сторон и при принятии того или иного решения, может оценить, что получится в итоге при реализации. Предполагает, в какой части исполнения процессов могут возникнуть проблемы и надо над этим дополнительно поработать. Иногда даже приходится пожертвовать чем-то несущественным или перестроить, оптимизировать какой-то процесс ради достижения глобальной цели и ощутимых для бизнеса результатов.
Подумать о всех стейкхолдерах[1] системы ‒ это наша главная задача, я бы даже сказал, это вообще основная задача архитектора: заранее продумать, насколько успешно система будет работать, решать задачи и приносить пользу всем подразделениям компании и заинтересованным лицам.

Архитектор ‒ это все-таки больше про бизнес или про творчество, разработку, проектирование?

Я бы сказал, что архитектор ‒ это про все сразу, про связь бизнеса с проектированием и разработкой. Архитектор проектирует и разрабатывает решение для бизнеса в условиях проектных и технических ограничений. Без творчества и креативного подхода здесь не обойтись: ограничения подталкивают нас на поиск каких-то нестандартных подходов или к решению задач совершенно новым способом.

Это поиск, путь компромиссов – без них невозможно обойтись в разработке решений такого класса. Мы всегда стараемся максимально решить бизнес-потребность заказчика и уложиться в поставленные сроки.

Какие софт-скиллы чаще всего нужны в работе системного архитектора?

Могу сказать, что достаточно полезным и универсальным софт-скиллом является умение конструктивно вести диалог со всеми сторонами, заинтересованными в проекте внедрения. То есть не с одним лишь владельцем проекта в компании заказчика (как правило, это руководитель подразделения безопасности), а в том числе с представителями других подразделений, которые будут использовать систему или будут связаны с ее работой.

Умение выявить заинтересованных лиц – как я говорил выше, их называют стейкхолдерами, ‒ это еще один полезный навык. Работающая система по управлению доступом (IdM), так или иначе, затрагивает практически все подразделения компании, т. к. всем сотрудникам нужны права доступа к информационным ресурсам, эти права нужно выдавать, согласовывать, удалять, контролировать. Поэтому задача по выявлению потребностей и заинтересованности в каждом из подразделений компании – это ключевой аспект, от которого зависит успех проекта в целом. И, возвращаясь к нашему вопросу, нужно именно на начальном этапе определить всех стейкхолдеров системы, нужно понять их заинтересованность и степень погружения в работу и процесс эксплуатации системы, выявить их боли и задачи по автоматизации. А уже далее, на основании собранной информации, помочь разработать требования – техническое задание, либо скорректировать уже предъявленные требования, если они были разработаны ранее. Все это как раз и укладывается в понятие «ведение конструктивного диалога».

А какими хард-скиллами обязательно должен обладать архитектор? Должен он уметь программировать, знать нотации, что-то еще?

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

Также из хард-скиллов очень полезным будет знание нотации языков моделирования, таких как UML[2], ArchiMate[3], BPMN2.0[4]. Такие навыки являются достаточно надежным инструментом для общения с заказчиком. Все мы понимаем, что хорошо проиллюстрированная информация лучше усваивается и помогает более эффективно доносить свою точку зрения до заказчика и команды.

Можно ли дать какой-нибудь вредный совет по части внедрения IdM-решения: что обязательно нужно сделать, чтобы точно ничего не получилось?

Главный вредный совет здесь будет такой: чтобы с внедрением IdM-системы ничего не получилось и проект провалился, нужно один раз составить ТЗ на систему, не проводить обследование, не актуализировать с заказчиком требования, не уточнять потребности, а сразу начинать проектирование и работы по сборке. Созданная в таких условиях система вряд ли получится успешной.

Процесс составления ТЗ на разработку IdM-решения ‒ это двусторонняя подробная коммуникация, которая может пройти через несколько витков. Мы не просто выслушиваем верхнеуровневые пожелания заказчика относительно системы, мы помогаем эти пожелания уточнить и сформировать из них четкие требования. Эти требования декомпозируются, тщательно прорабатываются архитектором ‒ это нужно, чтобы точно понять, какие потребности за ними стоят.

После такого своеобразного исследования ТЗ всегда актуализируется, так как выявляются дополнительные нюансы, которые не были на поверхности и которые обязательно требуется учесть. Иногда достаточно большую часть технического задания приходится скорректировать, чтобы учесть все аспекты: какие-то требования добавить, какие-то скорректировать или убрать и подготовить такой документ, на основании которого можно успешно реализовать проект и получить работающую платформу, которая решает поставленные задачи и приносит пользу бизнесу.

То есть наша цель не в том, чтобы сделать как по написанному, а так, как заказчику необходимо на самом деле, ‒ а это далеко не всегда одно и то же?

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

Так мы приходим к компромиссному и, главное, работающему решению. Интересное наблюдение: если попробовать сравнить исходное ТЗ и полученную систему, может обнаружиться, что между ними очень мало сходства ‒ настолько тщательно и глубоко мы проработали все поставленные задачи и выявленные потребности.

Есть ли какой-то способ, помогающий заказчику самостоятельно понять, какие бизнес-процессы в первую очередь нуждаются в автоматизации?

Если обратиться к бизнес-процессам, то прежде нужно оценить их критичность с точки зрения трудозатрат департамента ИТ или ИБ. Если основной целью внедрения системы стоит высвобождение ресурсов от рутинной работы, что в первую очередь важно для ИТ, то, конечно, сначала нужно реализовывать именно требования, которые будут закрыты автоматизацией.

Если мы хотим усилить бизнес-процесс с точки зрения ИБ или закрыть какой-то пробел в безопасности, то в MVP[5] системы попадет именно этот функционал.

Часто, работая над проектом, ‒ и это, кстати, абсолютно нормальная ситуация, ‒ заказчик меняет фокус внимания, и изначально важные некоторые требования теряют приоритет, уступая новым. Это нормально и правильно, потому что в ходе обследования выявляются какие-то новые подробности, несовершенства бизнес-процессов, серые зоны, о которых прежде не было известно, и нам также приходится смещать в процессе разработки фокус внимания. В этом нам помогает гибкий подход: с самого начала роадмап[6] нашего проекта мы разрабатываем с учетом того, чтобы заказчику в первую очередь отгрузить релиз необходимого работающего функционала, но в базовом варианте. Это нужно для того, чтобы заказчик, попользовавшись этим функционалом, посмотрев на него, понял, как дальше этот функционал развивать в правильном направлении ‒ в рамках ТЗ, конечно же.

Такая гибкость позволяет нам даже немного отходить в сторону от ТЗ в процессе разработки, если мы понимаем, что это действительно поможет проекту. Справедливо и обратное: если мы понимаем, что какие-то требования к проекту в реальной жизни не пригодятся, например какой-то специфический автособираемый отчет, над которым надо поломать голову, мы заранее предупредим заказчика о предполагаемых сложностях и выясним, действительно ли необходима именно эта функция, именно в таком виде. Может быть, ее можно заменить на более оптимальный вариант получения информации, который мы предложим.

Насколько часто приходится сталкиваться именно со зрелыми бизнес-процессами?

К сожалению, не так часто, как хотелось бы. Зрелые процессы ‒ это описанные, задокументированные алгоритмы, которые исполняются в компании, понятны всем участникам, логически выстроены. Наиболее часто мы встречаем такую ситуацию: у заказчика уже есть действующие процессы, но они разрозненные. Они описаны, соблюдаются на каждом отдельном этапе, но ни у кого нет единой информации о том, как этот процесс устроен в комплексе. Например, один отдел знает, как заявку создать, другой ‒ как ее выполнить, третий ‒ как задокументировать свои выполненные работы. То есть в процессах управления доступом нет целостности – единого видения. Либо есть примерное понимание, но в общем процесс не оптимизирован и его нужно дополнить или скорректировать. Именно здесь мы и приходим на помощь.

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

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

Получается, что наиболее эффективный и выгодный вариант ‒ это все-таки пройти тот самый этап консалтинга, для того чтобы избежать подводных камней?

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

Помимо процессов, важно помнить и про работы с целевыми системами: для интеграции с IdM в конечной системе должны быть консистентные данные и настроенные интерфейсы взаимодействия. Иначе не получится подключить коннектор и добиться необходимого качественного результата по управлению правами доступа. Если на стороне интегрируемой системы подготовительные работы заранее не проведены, их придется выполнять уже в рамках проекта внедрения, увеличивая и сроки, и бюджет на проект. Если на стороне заказчика не были проведены заранее необходимые доработки целевой системы для обеспечения взаимодействия с ней, приходится компенсировать это на этапе проекта совместными усилиями, иначе, если пойти по неоптимальному пути интеграции, это обязательно скажется на результатах проекта и на стабильности работы ПО.

Разработчики IdM-решений часто говорят о кастомизации: насколько IdM-системы кастомизируемы? В каких случаях это следует или не следует делать?

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

Если говорить о нашем продукте ‒ Solar inRights, он хорошо поддается кастомизации, поэтому мы и называем его платформой. Мы можем без изменений в исходном коде переопределить ряд функционала системы, ее дизайн. Также сейчас у нас в продукте появилась возможность переопределять поведение системы с помощью BPM-движка Camunda. Благодаря этому, мы можем для заказчика визуализировать поведение системы в виде бизнес-процесса ‒ это перспективная инновация. Я надеюсь, что она поможет нам быстрее приступать к инженерным работам, быть более гибкими и отвечать тем самым требованиям к кастомизации, о которых идет речь.

Насколько известно, на системного архитектора нигде не учат. Как ты пришел к этой роли и в профессию?

Все верно, на системного архитектора специально нигде не обучаются ‒ это просто некий этап развития технического специалиста, инженера. Наверное, здесь можно привести аналогию, что нельзя сразу обучиться на тренера по боксу или футбольного тренера. Это, как правило, путь от игрока и получение необходимого опыта. Так и у нас, сначала нужно пройти путь инженера, «пощупать» различные решения, увидеть их реализацию, и, когда накопится достаточный опыт, в том числе и сугубо технический, а также собственное понимание процесса разработки, можно попробовать себя в роли архитектора.

Касательно того, как я пришел в профессию: мой личный опыт работы в IT-сфере – 12 лет. До того, как я стал выполнять роль системного архитектора на проектах, я работал на абсолютно различных позициях: от администратора баз данных до специалиста, занимающегося таможенным ПО.

Впервые с системами класса IdM я познакомился шесть лет назад. Тогда я занимал должность инженера третьей линии техподдержки в крупном российском банке. После этого я работал инженером внедрения в «Ростелеком-Солар», ну а чуть позже стал системным архитектором.

Архитектору лучше занишеваться в какой-то конкретной области, например в области тех же самых IdM-решений, или же, просто, обладая хорошим техническим бэкграундом, пробовать себя в разных областях?

Я думаю, здесь нужен комплексный подход: можно занишеваться в какой-то определенной области, но и периодически посматривать вокруг, открывать для себя какие-то новые системы, технологии, наращивать собственный технологический стек. Тут мы можем немножко вернуться к вопросу про хард-скиллы: чем шире технический бэкграунд, тем лучше. Чем больше ролей архитектор попробовал перед тем, как приступить к исполнению своих обязанностей именно на этой позиции, тем лучше будет для команды и для реализации проектов.

Что бы ты мог посоветовать другим ребятам, которые, возможно, только сейчас собираются становиться архитекторами?

Не думаю, что у кого-то может быть прям вот такая цель ‒ стать архитектором, это достаточно абстрактная постановка задачи. С моей точки зрения, лучше ориентироваться по принципу «хочу стать классным специалистом в своей определенной области». И дальше, исходя из этого желания, решать, в каком конкретно направлении развиваться. В зависимости от того, что будет ближе: если сбор и оценка данных, выявление закономерностей, выведение предложений для бизнеса – то добро пожаловать в аналитику. Если захочется остаться техническим специалистом ‒ пожалуйста, ты и так замечательный инженер. А если захочется общаться с заказчиком, принимать решения, согласовывать эти решения, проектировать концепцию внедрения, то значит, твой путь лежит в системную архитектуру.

[1] Стейкхолдер – представитель заказчика и/или команды разработки, чья профессиональная деятельность связана с разрабатываемой системой.

[2] UML, Unified Modeling Language – графический язык моделирования бизнес-процессов, системного проектирования и отображения организационных структур.

[3] ArchiMate – язык моделирования архитектуры корпоративной деятельности внутри и за пределами бизнес-процессов.

[4] BPMN2.0 – нотация для моделирования бизнес-процессов в виде диаграмм.

[5] MVP, Minimum Viable Product – тестовая версия системы/продукта, обладающая минимальным, но при этом полезным для заказчика функционалом, подлежащая дальнейшему развитию.

[6] Роадмап (roadmap) – дорожная карта, план реализации проекта разработки, разделенный на этапы с фиксированными сроками.