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

В организациях выстраивается сеть профессиональных сервисов. Эти сервисы взаимозависимы и управляются некоторыми правилами, есть SLA на предоставление результатов и так далее. Основная задача управляющих этой сетью — постоянное рефлексирование на тему совершенствования работы сервисов в рамках customer focused потребностей.

Понятия «холократия», «SAFe», «LeSS», «бирюзовые организации» появились в ответ на желание построить более оптимальную структуру, чем древовидные иерархии.

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

Вообще, если рассматривать работу отдельной компании и работу веб-сервисов, можно заметить сходство. Например, работа службы поддержки очень похожа на работу связки nginx и сервера приложений.

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

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

Но что дальше? Что может быть следующим шагом в эволюционном пути?

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

И вот тут появляются архитекторы таких экосистем.

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

Первое — потому что чем больше компаний и отделов, тем сложнее коммуникации между ними. И тем важнее сохранить простоту и прозрачность.

Второе — потому что важно понимание процессов, умение их оптимизировать и масштабировать.

Третье — потому что, чем больше опыт взаимодействия с другими компаниями и людьми, тем менее болезненно внедряются изменения.

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

Давайте на конкретном примере, чтобы было понятнее.

Допустим, у нашей компании появляется цель — «мотивировать сотрудников через персональное развитие каждого из них».

Что нужно сделать для ее достижения? Как минимум понять потребности и желания каждого сотрудника (1). Затем выработать для каждого персональную траекторию, включающую и желания сотрудника, и возможности компании (2). Например, ее продукты, через работу над которыми он будет развиваться. Дальше еще нужны наставник или ментор, который будет поддерживать сотрудника и помогать где теорией, где практикой (3). Но наставники, очевидно, должны быть внутри компании (4), поскольку внешние консультанты слишком долго будут изучать всю нашу внутреннюю кухню. И вряд ли смогут постоянно присутствовать в компании.

Итак, видим 4 требования, необходимых для достижения цели.

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

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

Обращаемся к архитектору экосистем и получаем предложение. «Есть компании, которые занимаются обучением с помощью привлеченных экспертов — вот, например, «Нетология» или OTUS. У компаний есть методисты, инструменты обратной связи «студент-преподаватель» и многое другое, что нужно для выращивания наставников». Архитектор выстраивает взаимодействие с этими компаниям, мы отправляем ребят. Они несколько раз читают свои мини-курсы, оттачивая навыки преподавания. И через какое-то время начинают обучать людей внутри уже нашей компании. И нам польза, и нашим площадкам, кирпичикам образовательной экосистемы.

И так архитектор справляется с каждым нашим требованием.

Где взять таких людей? Пока не знаю точно.

Но думаю, что они начинают появляться внутри компаний, которые пошли по новому пути развития — открытому, прозрачному пути поставки ценности своим клиентам.