Расшифровка выступления.
Спасибо, что пришли послушать мой 45-минутный рассказ о том, что такое архитектура предприятия и какую роль она играет в крупных организациях. Как видите на слайдах, я сейчас работаю техническим директором в Google в подразделении, которое мы называем офис технического директора. Я работаю в основном с техническими и генеральными директорами крупных компаний, либо с архитекторами предприятий, и помогаю создать правильный формат использования облачных технологий. Этот формат включает в себя архитектурные и организационные изменения. Поэтому многое из того, о чем я буду сегодня говорить, вышло из таких разговоров и моего опыта работы в Allianz. До этого я работал в Google AdWords. В Allianz я был старшим архитектором, возглавлял департамент архитектуры предприятия. Когда я заступал на эту должность, я не понимал толком, что означает архитектура предприятия и чем должен заниматься архитектор предприятия.
С годами я понял, что это такое и в чем заключается ценность архитектуры. Кроме того, я понял множество ограничений, где эта практика не применима и стал видеть ее неправильное использование. И давайте я начну именно с этого. Когда мы говорим об архитектуре предприятия, я вижу две основные проблемы. Первая проблема это - (пауза). Первая проблема заключается в том, что не работает переключение слайдов. Что же тут надо сделать, а вот, все, получилось. Первая проблема заключается в том, что архитекторов предприятия видят такими людьми в башнях из слоновой кости. Они рисуют свои диаграммы, но они не решают настоящих проблем, по их мнению, это задача других людей. Основная причина такого поведения в том, что организации просто допускают такое поведение архитекторов. И, конечно, намного проще рисовать картинки, чем заставить программное обеспечение правильно работать. Поэтому если в вашей организации такое поведение поощряется и люди могут рисовать картинки и продолжать работать и получать повышения за рисование картинок, то именно этим многие и займутся.
К сожалению, это не принесет вашей организации никакой пользы, и я бы вообще не считал это практикой архитектуры предприятия. Я считаю такие должности синекурой для людей, которые не обладают достаточными техническими навыками и не могут поставлять программное обеспечение. Это работает совсем не так.
Вторая проблема заключается в том, что когда люди говорят об архитекторе предприятия, то на ум приходит Архитектор Матрицы.
Человек настолько умный, что он все знает и все решает. Конечно, это представление точно так же ущербно, как и первая позиция, потому что такого человека не существует. Никто не может знать все и принимать решения за всех. Да и в фильме это не человек, а компьютерная программа. Так что эта аналогия неверна. Почему такое нереалистичное представление так распространено? Потому что очень удобно иметь того, кто решит все твои проблемы и примет все важные решения. Принимать решения, вообще говоря, непросто. Обязательно что-то пойдет не так и вы примете неверное решение. И если есть какой-то человек, который принимает такие решение, то это не ваша проблема, это проблема этого человека.
И еще раз, практика архитектуры предприятия работает совсем не так. Поэтому давайте проговорим еще раз, что такое практика архитектуры предприятия и в чем заключается роль архитектора предприятия. А потом поговорим немного о том, как должна выглядеть правильная работа архитектора предприятия. Как на самом деле должна работать эта штука. Наиболее важным моментом я считаю понимание того, как архитектура предприятия связана с ИТ архитектурой. По большей части, когда говорят про архитекторов, то имеют в виду архитекторов ПО, архитекторов инфраструктуры, архитекторов облачных решений и т.д.
На стороне ИТ столько разных видов архитекторов, и поэтому довольно удивительно понимать, что на стороне бизнеса вы редко встретите архитектора. И это подозрительно, потому что большая часть ИТ существует ровно для того, чтобы поддерживать деятельность, ведение бизнеса. Вы можете спросить, а где все те люди, которые задают целевое видение бизнеса? Ведь целевое видение бизнеса во многом определяет то, какими должны быть целевые ИТ решения.
И вы обнаружите, что в последнее время стало чуть больше народа, который занимается практикой бизнес-архитектуры, которая формализует бизнес-решения примерно так же, как практика ИТ-архитектуры формализует ИТ-решения. Но по большей части бизнес-архитекторами являются руководители бизнес-подразделений, вы найдете их среди операционных директоров, вице-президентов, руководителей департаментов. В их должности обычно нет слова "архитектор", но если вы всмотритесь в то, чем они занимаются и как они мыслят о своей работе, как они проектируют бизнес-подразделения, дивизионы, продуктовые линейки, то вы обнаружите, что они ведут себя точно так же, как архитекторы из ИТ.
И вот ИТ-архитекторы и бизнес-архитекторы должны работать совместно и это является главной задачей архитектора предприятия. В роли архитектора предприятия я должен удостовериться, что ИТ-архитектура соответствует бизнес-архитектуре, потому что все крутые навороты, которые мы сделали в ИТ, будут не нужны, если они не поддерживают операционную деятельность компании. И тогда разработка контейнера Kubernetes становится хобби за деньги работодателя.
Если ИТ разработка не нужна бизнесу, это худший вариант того, что с вами может произойти. Естественным следствием этого является то, что практика архитектуры предприятия служит связующим звеном между бизнес-архитектурой и ИТ-архитектурой. И чем больше в данный момент расхождение между бизнес-архитектурой и ИТ-архитектурой, тем больше будет востребована практика архитектуры предприятия.
И это одна из причин, почему в цифровых компаниях типа Google не бывает больших отделов архитекторы предприятия. Это не означает, что Google не занимается практикой архитектуры предприятия, это следствие того, что бизнес и ИТ в таких компаниях тесно переплетены. Им просто не нужны посредники. Им не нужна помощь архитекторов предприятия, они сами выполняют эту практику. И это круто, что они могут выполнять эту практику и им не нужен отдельный департамент архитектуры предприятия. Но такой департамент нужен традиционным организациям, и он у них есть. Дивизионы традиционных организаций разделены, у них общие поставщики ИТ услуг по самым разным направлениям. Поэтому бизнес и ИТ в традиционных организациях находятся дальше друг от друга, чем в цифровых компаниях. В традиционных организациях архитектура предприятия играет важнейшую роль.
Я не могу дать вам трех простых шагов для правильного запуска архитектуры предприятия. Не существует какого-то простого подхода, но я думаю, что может вам по-настоящему помочь, так это понимание цепочки создания ценности архитектуры предприятия. Вы работаете на основную деятельность, поэтому вам надо создавать для нее ценность и приносить пользу.
Если вы приносите пользу, то она не появляется из ниоткуда. Эта польза как-то создается. Она создается в какой-то цепочке создания ценности. То есть точно также, как у бизнеса есть цепочка создания ценности, когда вы покупаете сырье, собираете продукт, поставляете его и продаете в рознице, где его покупают потребители, которые используют продукт и получают пользу.
Вот точно так же у практики архитектуры предприятия есть цепочка создания ценности:
1. Понять бизнес-стратегию
2. Перевести ее в ИТ-стратегию
3. Создать прозрачность
4. Описать картинку целевого состояния ИТ
5. Определить план перехода
6. Согласовывать решения и осуществлять корпоративное управление ИТ-ландшафтом
7. Собирать обратную связь и уточнять планы и цели
8. Наставлять и тренировать
И в первой части нашей беседы мы пройдемся по этой цепочке создания ценности. Я хотел бы обратить ваше внимание на то, что цепочка создания ценности получила свое название не просто так. Точно так же, как в обычной цепи, если у вас порвано одно звено, то у вас разорвана вся цепь. Вот точно также если вы пропускаете какой-то пункт из цепочки создания ценности для архитектуры предприятия, вы не можете создать ценность от этой практики.
Вы можете понимать стратегию бизнеса лучше генерального директора, но вы не сможете принести пользу, потому что вы не доходите до конца. В конце моего выступления вы поймете, что ничего особо сложного в этих шагах нет. Если вы внимательно посмотрите на эти пункты, вы в целом поймете, о чем я говорю. Это не какая-то черная магия, сложность в том, что надо делать эту работу в запутанных условиях большой организации довольно сложно. И в этом заключается основная сложность применения практики архитектуры предприятия.
Так что давайте начнем сверху и дойдем до последнего пункта цепочки создания ценности архитектуры предприятия, как бы банально мои слова не звучали.
Первое, что вы должны понять, так это понять бизнес. И в данном контексте надо понять про две части, из которых состоит бизнес. Бизнес как то, чем компания занимается на рынке, что она продает. И вы должны понять бизнес как организацию. Понять то, как он построен.
Я работал в страховой компании пять лет и я точно знаю, что большинство людей считают страховой бизнес довольно скучным местом. Что-то вроде немолодого человека, который ходит в костюме и с маленьким чемоданом, стучит в вашу дверь и продает вам страховые полисы на автомобиль или квартиру, и он занимается этим 30 лет и 30 лет назад все было ровно так же. В случае с Allianz это совсем не так, это глобальная страховая компания.
Вы покупаете страховку на время поездки при покупке билета по Интернету, когда у вас всплывает окошко с предложением страховки за 5 долларов. Кроме того, самолет, на котором вы полетите, тоже там застрахован, застрахована нефтяная платформа, которая добывает нефть, и трубопровод и нефтеперерабатывающий завод, который поставляет керосин, на котором этот самолет полетит.
Поэтому, когда вы видите по новостям о каких-то катастрофах и чрезвычайных происшествиях, вы должны понимать, что убытки по этим событиям покрывает какая-то крупная страховая компания типа Allianz. Это все реальные примеры страховых случаев, которые покрывала Allianz, начиная с крушения дирижабля Гинденбург. Allianz довольно старая компания. Чтобы обработать такие страховые случаи, вам нужно объединить работу кучи специалистов, а не только тех, кто выплачивает страховое покрытие. Вам нужны те, кто будет заниматься управлением кризисными ситуациям, людям, которые будут заниматься защитой бренда, которые будут спасать людей, будут возобновлять нормальную деятельность. Так что работа в страховой компании намного интереснее, чем это кажется снаружи.
Ребята в ИТ общем-то достаточно самонадеянно считают, что их работа намного интереснее, потому что есть клевые Kubernetes контейнеры и квантовые вычисления, а бизнес продает скучные страховые полисы. Такая самонадеянность очень опасна, потому что когда вы вглядитесь в бизнес повнимательнее, там тоже есть куча интересных вещей. Так что, в общем-то это вопрос того, чтобы их увидеть, эти интересные штуки. И, конечно, следующая очень важная вещь - это понять, где бизнес делает деньги. И делать деньги означает получать выручку, но у вас может быть выручка, но маржа может быть нулевой или отрицательной. Так что надо понимать, где у бизнеса находятся зоны роста, где он собирается расти. Собирается ли бизнес продавать какие-то подразделения или наоборот, покупать другие организации. Вы можете подумать: "Да мне-то какое дело до этого, я работаю в ИТ, а покупка и продажа других бизнесов - это забота генерального директора. Почему мне надо об этом думать?" Но если вы немного подумаете, вы поймете, что такие решения сильно влияют на ИТ. Если вы будете приобретать бизнесы, это означает кучу задач по интеграции, это неизбежно. Поэтому я, например, поездил по Азии и изучил, что же происходит там в реальности. Филиппины, например, в основном живут продажами страховок жизни. В Малайзии самые большие продажи страхования имущества.
Allianz продал свой бизнес в Южной Корее, он начал вести дела в Гонконге. Вы начинаете понимать, насколько динамичный это бизнес. Кроме того, вы должны понимать организационную структуру, не так ли? Большинство организаций вынуждены жить в нескольких измерениях. У них распределенная география, разные продуктовые линейки, разные функции.
Вы можете работать в Азии и продавать страхование жизни и быть в продажах или работать в Европе и заниматься страхованием имущества и работать в претензионном отделе. Это бизнес-архитектура. У них есть три измерения. И им надо создать организацию в этих измерениях. Обычно они организованы по странам, потом по продуктам и потом по функциям. Это все довольно интересно знать, потому что вам как архитектору предприятия надо связать бизнес-архитектуру и ИТ-архитектуру, и это означает, что вам надо знать и понимать нужных людей.
Чтобы понять, как организационно структурирован бизнес, чтобы работать на выбранных рынках, архитекторы обычно делают реверс инжиниринг.
Обычно он у нас хорошо, получается, не так ли? Мы можем делать такие штуки очень хорошо. Мы понимаем структуру систем. В данном случае не просто технических систем, а организационных систем. Может показаться, что эта работа не очень похожа на наши обычные должностные обязанности, но вообще-то ваш мозг уже оснащен для выполнения такой работы. И последняя вещь, которую вы должны понять на самом верху вашей цепочки создания ценности - это понять как ИТ встроено в остальную организацию.
Обычно ИТ заканчивается на офисе ИТ-директора (CIO, chief information officer). Этот человек распоряжается всем бюджетом ИТ и большинство людей в ИТ в конце концов подчиняются ИТ директору. Это довольно сложная работа. Куча людей шутят, что CIO расшифровывается как career is over, карьера закончена. Это не смешная шутка, потому что это очень сложная работа, особенно сейчас. Вам надо снижать издержки и внедрять инновации.
Вам нужны облачные вычисления. И вы знаете, кибербезопасность может стать причиной вашего увольнения. Да, именно так, обычно именно ИТ-директора увольняют, если что-то случается. Поэтому это интересная работа. Что важно, так это то, как бизнес смотрит на ИТ-директора и чего ожидает от него или нее и от ИТ организации в целом. Основной причиной роста отдела ИТ в организации стала автоматизация. ИТ сокращали издержки: сегодня мы делаем эти операции вручную, и это стоит кучу денег в фонде оплаты труда, а потом ставим компьютер, и я могу все делать на экране своего компьютера. Автоматизация сберегает мне кучу денег, так? Это хорошо. И это было причиной того, что ИТ росло 50 последних лет и стало таким большим.
Фишка в том, что ИТ-подразделения очень нацелены на снижение затрат, все ИТ нацелено на снижение издержек. Помните, мы говорили про реверс инжиниринг организации? Чтобы понять, считает ли ваша организация главной функцией ИТ снижение издержек, надо просто проверить, кому подчиняется отдел ИТ. Если ИТ-директор подчиняется финансовому директору, то его целью будет снижение затрат, потому что финансовый директор — это человек, который оплачивает счета. Поэтому если ваша отчетность подчинена деньгам, то именно этим ваша ИТ-организация и будет заниматься, она будет экономить. И это очень важная мысль, потому что представьте себе вы пришли с классной идеей гибридных облаков, например Docker Kubernetes.
В контейнерах этих гибридных облаков происходит оркестровка, вы можете убирать и добавлять, у вас есть CCD pipeline, вы можете поставить софт в любой момент. ИТ-директора это не заинтересует, потому что его начальника это не заинтересует. Потому что целью является снижение затрат. А вы только что говорили про скорость и гибкость.
Вы продавали скорость и гибкость кому-то, кому интересно снижение затрат и поэтому продаже не бывать. Это обычно приводит к тому, что люди в ИТ разочаровываются и говорят: "Никто не хочет давать денег на мой проект. Какие они глупые, не понимают, как эти контейнеры важны для компании". Так ведь? Но вы просто едете не по той стороне шоссе коммуникаций. Эти вещи важны, и вы можете увидеть, как переподчинение ИТ отдела приводит к смене способа мышления.
И многие организации меняют подчиненность ИТ-директора и переносят его под операционного директора. И это большой шаг вперед, потому что теперь вы начинаете разговаривать о возврате на инвестиции. Операции готовы вложить деньги, если деньги вернутся с прибылью. Такой маневр позволяет ИТ в первую очередь уйти из-под функции, где нет денежного потока в место, где есть денежные потоки. И в крупных организациях становится важным эффект масштаба, потому что изменения накатываются на всю организацию.
Это все касается стандартизации и гармонизации. Те люди были озабочены вопросом как бы сделать все на одной версии Linux. Не самая вдохновляющая задача, прямо скажем. Но вещи становятся интереснее по мере того, как мы двигаемся вправо. В этом месте ИТ становится не обеспечивающей функцией и технологией, а частью бизнеса.
Я часто привожу в пример компакт-диски. Любители музыки не требовали самих компакт-дисков. Им просто был нужен определенный трек и чтобы не надо было мотать кассету несколько минут. ИТ смогли реализовать эту скрытую потребность. Не было пользователя, который сказал, что ему нужна была крутящаяся штука с дырочками, которые выжег лазер, и чтобы было считывающее устройство, не так ли? Пользователи так не говорят.
И это, в свою очередь, объясняет, почему компакт-диски так быстро уступили место стриминговым сервисам. Потому что стриминговые сервисы лучше закрывали потребность в немедленном доступе к нужному треку. И в этом месте все становится интересным, потому что из этих разных моделей вытекают разные логические выводы. Если ИТ нацелено на снижение издержек, то вам надо аутсорсить его в то место, где эти услуги стоят дешевле. Многим из нас это не понравится, но это логичный шаг.
А если вы ищете способ раскрыть пользу для бизнеса, то вам, наоборот, надо отвязаться от якоря снижения издержек, и нацелиться на гибкость. Никаких сотрудников в Бангалоре. Гибкость — это способность правильно маневрировать. Гибкость — это правильный курс действий.
И если ваше ИТ находится внутри, нет никаких контрактов, то у вас сокращается коммуникационное расстояние. У вас общие цели. Легче войти в этот Эджайл. Все ровно наоборот. Если вы посмотрите на организации с большим ИТ вне штата, то они никуда не двигаются. Они, скорее всего, по-прежнему находятся внизу слева. Организации, которые возвращают ИТ в штат, двигаются вправо.
Еще вы можете обнаружить, что ИТ-директор переходит в подчинение к CDO, chief digital officer. Эти люди поняли, что мир цифровизации подчиняется другим правилам, и ИТ-директор должен подчиняться напрямую генеральному директору и ИТ-директор также важен, как и остальные функции типа финансов или операций, маркетинга и продаж. Они должны быть одинаково важны, это действительно так, ИТ — это хороший бизнес.
Этого разделение между ИТ и бизнесом уже не существует. Я называю это экономикой скорости, в противоположность экономике масштаба. Люди осознали, что в цифровом мире не так важно, насколько ты крупный, важно, насколько ты быстрый. Поэтому надо преобразовывать бизнес-стратегию в ИТ-стратегию.
И тут я бы хотел напомнить, что стратегия — это не реальность. Это направление, в котором вы двигаетесь.
Однажды у меня была стратегия, я хотел упаковывать приложения в контейнеры и одним из результатов было то, что приложения должны упаковываться в эти контейнеры. Не то, чтобы я хотел, чтобы это случилось на 100% и прямо сейчас, это была цель, в направлении которой мы двигались.
И еще, не я это придумал, но есть такая фраза, что когда вы говорите, что стратегия — это быстрее, лучше, дешевле, то это не стратегия, это принятие желаемого за действительное. Стратегия означает фокус, а фокус означает исключение чего-то. Последнее, о чем бы я тут хотел еще упомянуть, так это то, что на крупные предприятия очень сильно влияют поставщики решений. Потому что в самом деле, зачем разрабатывать решения самим, когда надо заниматься вещами, которые отличают вас на рынке. И это точно не ИТ-инфраструктура.
Поэтому вы покупаете эти решения, арендуете сервера, но при этом может легко так получиться, что стратегия поставщика решений может подменить вашу ИТ-стратегию. А это очень опасно, потому что стратегия поставщика отличается от вашей. Да, они думают в верном направлении, но это не означает, что это направление для вас лучшее.
И у поставщиков очень специфический взгляд на ваш бизнес, потому что они продают свой продукт. У них нет полного понимания ситуации, а ведь вам именно этого и надо, вам нужна комплексная стратегия. Вы должны знать, куда вы идете, что для вас важно. Может быть, для вас важна автоматизация. И вы идете к поставщику и спрашиваете: "А как вы устанавливаете приложения?" И если для установки приложения требуется что-то больше, чем просто нажать одну кнопку, вы говорите: "Извините, это не соответствует моей стратегии".
Может быть, поставщик может это исправить. Но это именно тот разговор, который должен происходить с поставщиком, он должен понимать, что для вас важно. Работает ли приложение из облака, можно ли его поместить в контейнер, можно ли его полностью автоматизировать. И тогда вы поймете, соответствует ли продукт вашей стратегии. И выбирать решения другим способом, отличным от этого, очень опасно.
Самой первой книгой про архитектуру предприятия была книга про стратегию архитектуры предприятия. И как это часто бывает с первыми книгами, это, конечно, важная книга, но не самая лучшая книга, потому что она отражает самые начальные представления о предмете. Так что я скажу, что в этой книге есть самая важная диаграмма, в виде матрицы 2 на 2. Хорошая новость заключается в том, что руководство привыкло к матрицам 2 на 2, к ним они привыкли, потому что такие матрицы любят McKinsey and Co.
Поэтому руководители хорошо понимают идеи, которые изложены в матрице 2 на 2. И если вы хотите, чтобы руководство поняло вашу мысль, используйте этот инструмент. Но эта диаграмма все-таки потребует пояснений. Одна ось показывает уровень стандартизации процессов, другая уровень интеграции. Внизу слева у вас будет интересный бизнес, в котором отсутствует стандартизация и интеграция. Это, например, Siemens или GE или любая другая компания, которая делает все подряд от локомотивов до атомных электростанций и от поездов до холодильников.
В этой ситуации максимум, что вы можете сделать — это попытаться получить экономию масштаба за счет перевода на общую инфраструктуру, но у них никогда не будет одинаковых приложений, потому что они выполняют совсем разные задачи. Все, что вы можете для них сделать — это правильно подать им обед, что-то типа того.
Или у вас может быть среда репликации, например, рестораны Макдональдс по франшизе. Все бизнесы одинаковые, поэтому вы можете предоставить всем одинаковый набор приложений, и это будет модель SaaS, приложения как услуга. Все, что надо будет сделать новому подразделению Макдональдс — это залогиниться в облако и раз, у них есть все, что надо, от приема платежей до организации поставок.
Это хорошо подходит для репликации, потому что новый Макдональдс очень похож на любой существующий Макдональдс. В этом сила франшизы. Но с другой стороны каждый ресторан Макдональдс действует абсолютно независимо от других. Единственная вещь, которая консолидируется в такой системе - это финансовые показатели. Поэтому для вас важна стандартизация общего набора приложений, но почти неважна интеграция. И это полная противоположность бизнесам, которые территориально распределены, но требуют стандартизации процессов. Тогда для вас становятся важными хранилища данных, озера данных. И это примеры того, как операционная модель влияет на ИТ-стратегию.
Чем дальше ваша модель от модели Макдональдса, тем важнее для вас интеграция. Чем ближе вы к Макдональдсу, тем важнее для вас скорость репликации. Может быть, вам важны оба параметра. Бизнес-модель определяет вашу ИТ-стратегию и эта матрица показывает критический шаг преобразования вашей бизнес-стратегии в ИТ-стратегию.
Третий пункт касался прозрачности. И звучит это намного банальнее, чем это является в жизни. Потому что, если у вас нет прозрачности, вы ничего не можете сделать. Вы не можете украсть организацию бизнеса у конкурентов.
К сожалению, реальность выглядит примерно так. И я всегда шучу, что это отличная архитектура, потому что она очень хорошо масштабируется. А причина, по которой она хорошо масштабируется, следующая.
Видите базу данных слева внизу? Она ни к чему не подключена, вот в чем секрет масштабируемости, по-моему, это очевидно. Она должна быть на 100% избавлена от состояний. Но, шутки в сторону. Создать прозрачность в крупной организации - огромная задача.
Причем вам надо не задокументировать реальность, вам нужна модель, которая будет отображать реальность, рассуждать про нее, которая позволит вам создать план по изменению реальности. И это следующий шаг в цепочке создания ценности.
Итак, у вас есть бизнес-стратегия, у вас есть ИТ-стратегия, у вас есть реальность и у вас всегда есть разница между реальностью и стратегией. И тогда вы создаете план развития. На одной конференции в Австралии кто-то выразил эту мысль очень хорошо: "Начальство доверяет планам". Начальство любит планы, поэтому когда архитекторы показывают только конечную точку, они не понимают.
Картинка будущего им нравится, но они хотят увидеть, как они к ней придут. Руководителям нравятся правильные планы. Например, вы понимаете, что одна из самых больших проблем сейчас — это то, что приложения разъединены. Нельзя объединить данные по продажам и у подразделений мало общей инфраструктуры. Поэтому мы создаем платформу и интеграцию через API и в конце концов все работает на общих серверах. Если все получится, конечно. Сейчас есть очень большое дублирование, шахты данных, никакой интеграции. В каждой базе свой фреймворк, нет автоматизации работы, развертывания. Все задублировано. Нам нужен API и интеграции для таких вещей, чтобы мы могли выращивать платформу снизу.
Эти приложения, возможно, не нужны для продажи, бизнес не видит в них прямой ценности. Вам нужно гармонизировать эти приложения, а потом разбить их на микросервисы. Из-за того, что рабочая среда недостаточно хороша, вам будет очень сложно разбить все на микросервисы.
Если у вас три огромных приложения, у каждого из которых своя рабочая среда, своя автоматизация и свой мониторинг, то может получиться. Но если есть хотя бы 100 сервисов, то у вас не получится. Это классический план развития ИТ. Мы развиваем платформу, потом разбиваем ее на сервисы, и теперь, когда у вас общая рабочая среда, вы можете абстрагироваться от инфраструктуры. И тогда у вас есть гибкость и вы можете перенести приложения со своих серверов в облако.
Такая классическая стратегия 80-х, которая понятна руководству. Руководство поймет такую стратегию. Но вам еще надо, чтобы исполнители поверили в такой план развития. И для этого вам надо, чтобы этот план развития отражал те штуки, которые у вас есть.
