Меня зовут Варвара Фролочкина, я работаю менеджером направления концептуального проектирования инициатив в дирекции по архитектуре Х5 Tech. Хочу рассказать о том, как выглядит процесс согласования архитектурных решений в нашей компании и какие вообще архитектурные решения у нас существуют. И постараюсь объяснить, почему же так важно обращаться к архитектору на самом раннем этапе проекта.
Моя статья будет полезна прежде всего представителям корпораций, планирующих построить эффективный процесс ИТ-производства. Также надеюсь, что полезную информацию для себя найдут коллеги из архитектуры разных направлений.
Кто такой корпоративный архитектор и какова его роль?
Корпоративная архитектура управляет развитием ИТ-ландшафта в соответствии со стратегией бизнеса. Главная цель – это оптимизация затрат компании на реализацию задач бизнеса при поддержании необходимого уровня качества.
Корпоративный архитектор предлагает решения, оптимальные с точки зрения общего процесса. Он видит картину целиком, поэтому знает, каким образом изменения в одних процессах влияют на другие части процесса. Также он находит баланс между стоимостью текущей задачи и сроком реализации в зависимости от амбициозности проекта.
Например, можно провести аналогию с градостроительством. Отличная широкая дорога из качественного асфальта банально может не вписаться в маленький микрорайон. Или огромный жилищный комплекс не может полноценно существовать без инфраструктуры: магазинов, школы. В ИТ-архитектуре суть абсолютно та же.
В Х5 Tech корпоративные архитекторы знают, какие системы есть в компании, для чего они предназначены и на каком этапе жизненного цикла они находятся. Все решения обсуждаются коллегиально, поэтому всем известно, какие системы появятся и какие будут заменены. Также корпоративный архитектор всегда рядом с бизнесом, понимает его потребности и учитывает его стратегические планы при формировании целевой архитектуры. Заказчиками для Х5 Tech являются все бизнес-единицы Х5 Group.
Кроме конкретного архитектурного решения в рамках бизнес-инициативы, корпоративный архитектор ещё и прорабатывает целевую архитектуру – при аналогии с градостроительством это генеральный план поселения. И архитектурный принцип – по аналогии это архитектурный эскиз одного или нескольких домов в этом посёлке.
Помогаем бизнесу, или зачем идти в архитектуру?
Бывает, что у бизнеса возникают искушения не заходить в архитектуру, а напрямую идти к поставщику за «коробкой». Есть иллюзия, что так он сможет сократить время и деньги. Часто «решение под ключ» выглядит экономически выгодным. И только потом выявляются многие отягощающие факторы: например, поставщик может умышленно не афишировать, что многие расходы и работы просто не входят в данное решение.
По полюбившейся уже мне аналогии с архитектурой этот путь выглядит примерно так: заказчик дома, не посоветовавшись ни с прорабом, ни с дизайнером, просто сносит стену. Минимальные сроки и вложения. И как будто бы результат достигнут. И только потом может оказаться, что стена была несущая и её отсутствие несёт риск обрушения всего дома. И в сильно сжатые сроки заказчик вынужден мчаться и к прорабу, и к дизайнеру, чтобы сначала всё восстановить, а уже потом возвращаться к решению первоначальной проблемы.
Были конкретные кейсы, когда бизнес сначала рассматривал несколько вендоров. Но только архитектура смогла выявить, что требования были неполными, а это существенно уменьшает стоимость решения. Или вендор уверенно предлагал объём работ, которые ранее на рынке никто не предоставлял. То есть фактически не было никакой гарантии, что это вообще возможно реализовать. Задача архитектуры здесь – предоставить актуальную информацию бизнесу, конкретные аргументы, предоставить техническую экспертизу.
Ещё был кейс в нашей практике, когда только при непосредственной проработке архитектурной задачи архитектор выявил требования, которые приводили к бизнес-конфликту, и принял непосредственное участие в поиске компромиссного решения. Польза привлечения архитектуры на начальном этапе очевидна – смогли избежать больших убытков, внеся ряд ограничений в требования.
Архитектурный процесс от идеи до запуска инициативы: как это устроено в Х5
В самом начале развития архитектурной функции в Х5 начал образовываться процесс согласования архитектурных решений (далее АР). Сначала это были беспротокольные встречи «бывалых» сотрудников, которые давно работают, стоят у истоков компании и недавно присоединившихся к команде архитекторов. И в тот момент этого было достаточно.
В рамках анализа задачи появлялась архитектура, количество задач стремительно увеличилось. Процесс согласования АР стал затягиваться на неопределённый срок. Пришли к выводу, что самое простое – выделить ключевых людей из разных направлений и совместно с разработкой и инфраструктурой согласовывать такие решения.
С 2018 года начали письменно фиксировать договорённости таких встреч, и за год мы уже полностью перешли на протокольный формат, трансформируя процессы. Например, так как не все задачи нужно нести на архитектурный комитет, стали формироваться критерии выноса, распределился поток задач.
Чтобы избежать ошибок в архитектурной схеме, мы выстроили определённый процесс с иерархией принятия решений:
Этап № 1 – это АрхРевью, наш коллективный разум. Место синхронизации всех архитекторов, возможность послушать, что и как делают коллеги. На эту встречу приглашаются все направления архитекторов. Проводится она два раза в неделю, длится два часа. Она носит рекомендательный характер. Во встрече одновременно участвуют 30-45 архитекторов. Сюда приходят посоветоваться, получить обратную связь, замечания или рекомендации. Это даёт возможность архитектору не упустить ключевые вещи, посмотреть под другим углом на решение поставленной задачи.
АрхРевью проходит в формате диалога, здесь не даются никакие фиксированные поручения, а только рекомендации, советы. При этом мы понимаем, что встреча может выглядеть достаточно дорогой, так как в ней участвует большое количество архитекторов. Но мы убеждены в её ценности, учитывая обмен бесценным опытом, который здесь получают коллеги.
Этап № 2. Для выхода на следующий этап архитектору необходимо зайти в архитектуру данных и создать подзадачу на согласование от них. Хочу отметить, что нам важно именно на этом этапе синхронизироваться с архитекторами данных. Это даёт возможность на достаточно ранней стадии проработки решения исключить дублирование Information Objects и определить целевые системы с источниками данных. Только после этого решение допускается на следующий этап.
Этап № 3 – это Архитектурный совет. Место принятия АР всеми архитектурными функциями/подразделениями Х5 Tech. На него выносится уже готовое решение, целевая архитектура или архитектурный принцип. На АрхСовете решение может быть согласовано без поручений, с поручениями или вовсе не согласовано с блокирующими поручениями, требующими повторного выхода на защиту.
Право голоса имеют руководители всех архитектурных направлений. Проводятся АрхСоветы у нас два раза в неделю, длятся один час. Когда возникает необходимость рассмотреть бОльшее количество решений, мы вводим дополнительную встречу, чтобы не затягивать период согласования.
После прохождения этого этапа архитектор выносит решение на согласование с коллегами из разработки и инфраструктуры. Здесь также решение может быть согласовано без поручений, с поручениями или же не согласовано. Проводится один раз в неделю, длится полтора часа.
И финальный этап № 4 – Архитектурный комитет. На него выносятся те решения, в которых появляются новые системы, целевая архитектура ключевого бизнес-направления или корневых систем, архитектурные принципы, изменения в техстеке. Или же если мы находим работающую схему, о которой ничего пока не знаем, или решения, если в них создаётся новый продукт, или внедряется информационная система, или решение затрагивает интересы нескольких доменов. Короткое отступление про домены в Х5 Tech: мы уже несколько лет работаем с технологиями для бизнеса в рамках доменной структуры. Домен – это единая точка взаимодействия бизнеса и IT. Главная задача доменов – это максимально реализовать технологический потенциал в бизнес-подразделении.
Проводится такой комитет один раз в неделю, длится один час. Здесь могут быть даны поручения (блокирующие или нет), но решение принимается исключительно единогласно. Даже если один участник с правом голоса против рассматриваемой архитектуры, то решение уходит в доработку.
По этой схеме можно пойти как очным, так и заочным путём – т. е. согласование по электронной почте. Но на практике получается, что заочный путь более трудоёмкий и длительный.
А что потом?
После прохождения Архитектурного комитета решение уходит на согласование в информационную безопасность, далее передаётся в оценку на инвестиционный комитет. Важно понимать, что Департамент информационной безопасности согласовывает инициативу, а не само решение.
На этом этапе работа корпоративного архитектора прерывается до момента, когда в работу её берёт солюшн архитектор. И далее корпоративный архитектор выступает в роли эксперта/консультанта, так как солюшн архитектору могут понадобиться разъяснения по утверждённой схеме. При глубокой проработке на данном этапе может выявиться необходимость её изменения. В этом случае солюшн архитектор создаёт задачу для корпоративного архитектора на согласование изменений концепт-дизайна.
Существуют две точки контроля соответствия АР. Первая – когда уже выделен бюджет, команда реализации готовит детальную архитектуру, которую проверяет корпоративный архитектор. Вторая – когда инициатива реализована, её лидер передаёт корпоративному архитектору полную документацию того, что именно было передано в реализацию. Он сравнивает корпоративную архитектуру с тем, что было на концепт-дизайне. В случае расхождений корпоративный архитектор анализирует их причины. В некоторых случаях (изменение бизнес-требований, внешней среды и пр.) корректируется концептуальная архитектурная, а в каких-то случаях изменения необъективные, и тогда архитектор отстаивает свою первоначальную позицию.
Что в итоге
ИТ-архитектура по своей важности ничем не отличается от классической архитектуры. Мы – Х5 Group – слишком большая компания, чтобы жить без правил. Слишком высока цена ошибки в нашем случае. Поэтому согласование архитектуры – ответственный период проработки любого архитектурного решения. С учётом общей стратегии важна целостность ландшафта, а не лоскутное полотно.
На наш взгляд, за годы работы мы сформировали чёткие и эффективные правила согласования архитектурного решения внутри компании. И они продолжают развиваться, адаптируясь под потребности бизнеса, рынка и времени.
Комментарии (20)
Grigory_Otrepyev
11.04.2024 16:43я работаю менеджером направления концептуального проектирования инициатив в дирекции по архитектуре Х5 Tech.
.. два раза в неделю, длится два часа. Она носит рекомендательный характер. Во встрече одновременно участвуют 30-45 архитекторовИли каждый из них говорит по 2-3 минуты, или 90% людей там не нужны,а процесс развился в классическую бюрократию
Varvara1810 Автор
11.04.2024 16:43Вовсе нет) нет такой задачи, чтобы в обязательном порядке каждый говорил. Архитектор представляет свое решение, а дальше высказываются/задают вопросы/предлагают альтернативные пути только те, кому есть, что сказать. Для тех, кто не выступает или не участвует в обсуждениях – это возможность принять информацию и не допускать в своих решениях недоработанных кейсов.
atues
11.04.2024 16:43+1У меня был печальный 2-х летний опыт работы корпоративным архитектором. Срок, конечно, небольшой, но мне хватило.
Первое, что меня неимоверно напрягало - совещания. Два часа в день - это, считай, никаких совещаний и не было. Обычно три-четыре по часу/полтора/два. Т.е. полдня минимум. Если на совещании присутствуют представители бизнеса - то все совсем печально. При всем уважении к ним как к заказчикам, общаться с ними непросто. Они мыслят своими категориями, постоянно сбиваются на посторонние (и важные с их точки зрения) темы; разговор все время уходит в сторону. А архитектору надо все это потом осознать, сложить в голове и перевести на язык, понятный аналитикам и разработчикам.
Второе: очень редко удается собрать все заинтересованные стороны - кто-то в отпуске, кто-то на другой встрече, кто-то в командировке, кто-то занят срочной работой, кто-то с бодуна, кто-то с женой поцапался и ему не до того. Приходится встречаться и обсуждать "по кускам". Вроде с одним договорился, но после встречаешься с другими людьми и оказывается, что нет - все не так. В результате на руках ворох порой противоречивых требований, которые надо между собой увязать, нарисовать и согласовать. Апофеоз наступает когда кто-то увольняется и на его место приходит новый человек. И понеслось все сначала.
Третье - проектов никогда не бывает один; их, как правило, 4-5-6. Разной степени сложности, запущенности, срочности (впрочем, с точки зрения любого заказчика только его проект, действительно, важный и сложный, а остальные - так, баловство). Вертишься между ними как (простите) сопля по сковородке. Не мудрено что-то забыть, перепутать. Работать приходится урывками между встречами. Чтобы хоть что-то оставалось, вел записи. Исписал три больших тетради - реально не раз выручало.
Четвертое - уже в сторону корпоративных архитекторов. Я заметил, что подавляющее большинство из них не имеют адекватного практического опыта системного анализа и разработки. Представление - да, опыта - увы. Может быть, мне не повезло - спорить не стану. Более того, может корпоративным архитекторам это и не нужно? Я этого так и не понял, но когда после разработки пробуешь себя в архитектуре - это сильно удивляет.
Пятое - я заметил, что корпоративные архитекторы любят потрещать о высоких материях, инструментах проектирования, методиках. Добро бы, если бы это находило свое воплощение, но нет - отвели душу и вернулись в свое болотце.
Короче, я мучался-мучался и сбежал обратно - в разработку. Все вышеизложенное - сугубо IMHO. Если кого обидел - простите великодушно.
Varvara1810 Автор
11.04.2024 16:43Уверена, что никто не обиделся) И большое спасибо за Ваш комментарий. Еще раз показали, что работа корпоративного архитектора гораздо шире, чем может показаться. Более того, она часто выходит за рамки просто архитектуры, она еще и про объяснить, перевести на архитектурный язык, найти общий знаменатель и много чего еще.
dyadyaSerezha
11.04.2024 16:43А вот аналогии с обычными архитекторами вы зря написали. Мы ж тут не градостроители)
И кстати, что-то новости невеселые про Х5 приходят... Не в архитекторах ли дело?)
mishamota
11.04.2024 16:43На этом этапе работа корпоративного архитектора прерывается до момента, когда в работу её берёт солюшн архитектор. И далее корпоративный архитектор выступает в роли эксперта/консультанта, так как солюшн архитектору могут понадобиться разъяснения по утверждённой схеме. При глубокой проработке на данном этапе может выявиться необходимость её изменения. В этом случае солюшн архитектор создаёт задачу для корпоративного архитектора на согласование изменений концепт-дизайна.
команда реализации готовит детальную архитектуру, которую проверяет корпоративный архитектор. Вторая – когда инициатива реализована, её лидер передаёт корпоративному архитектору полную документацию того, что именно было передано в реализацию. Он сравнивает корпоративную архитектуру с тем, что было на концепт-дизайне. В случае расхождений корпоративный архитектор анализирует их причины.
Описанное деление ответственности между архитекторами "по слоям" приводит к тому, что ответственного за решение нет.
Классика.
"К пуговицам претензии есть?" https://www.youtube.com/watch?v=w8NfqKlYKl0
Batalmv
Можно только позавидовать людям, которые могут себе позволить иметь только архитекторов и собираться ДВА раза в неделю на ДВА часа :)
Ну и далее ... не знаю, выглядит честно говоря эпично
--------------
Плюс непонятно, зачем собираться и что там решать.
Условно, имея такую "банду" описать все возможные типовые решения можно за условные полгода. Вот реально, на всех уровнях. Дальше просто применять и все.
Ну к примеру, вы приняли, что используете "кубик" для деплоя и определенные стек для, к примеру пользовательских приложений. Ну расписали делали. Сетка, безопасность, скейлинг, мониторинг, ... Все. DevOps взял это в конкретном проекте и по готовому шаблому запихнул. На третий проект базовая инфраструктура залетать должна по надатию двух кнопок.
Базы - тоже самое. Расписали в зависимости от уровня критичности и еще чего-то как ее "растягивать" на серверные площадки, что у вас есть, как настроить безопасность, мультитенанси и еще что придумаете
Так и со всем остальным, тем более в нашем время большая ччасть инфраструктуры реально сделать как сервис.
Бизнес домены. Ну тут понятно, надо отслеживать функции и их маппинг на системы, связи между системами. Ну описали, как и кто с чем интегрируется. Как защищать, как обеспечивать транзакционность и разпределенные транзакции, требования к доке
Но это все такая банда может закрыть за полгода. Единственная причина, дальше эту ораву можно сократить раз в 5 :), поэтому наверное не пишут :)
-----------------
Далее ... солюшен. Банальный чек лист + проверка полноты помогут куда больше, чем какие-то совещания. Вот я недавно запилил описание на 70 страниц. Как его валидировать без чек листа? Вычитывать все буквы и задавать комментарии? НУ тоже можно, условно один написал - второй проверил. Смысл толпе читать, есть условно на вход пришло 50 (точнее 49) только нефункциональных требований (а в реальности 100+, просто пришлось ради экономии вписать основные)?
---------------
Я б в такую организация хотел на пенсию попасть. Уже рвать себе .опу и внедрять не надо, можно на совещания походить и накопленные мысли за до фига лет излагать :)
alexanek
Не могу повысить карму. Но комментарий выше в точку. Уважаю за опыт. Таких хочу в компании.
Grigory_Otrepyev
как мне нравятся комментаторы, с 4 комментариями с 13 ноября 2017 , причем три из них в этом году.
yukoshkina
Комментарий в стиле "Взять все и поделить". Во-первых, кубики, бдшечки, деплой - это не про EA. Они принимают решения на другом уровне.
Во-вторых, любопытно было бы в реальности (не в теории) увидеть организацию, которая бы взяла и построила идеальный ландшафт за полгода. 1 - осознала все потребности, 2 - выделила бюджет, 3 - предсказала будущее, чтобы сразу предусмотреть риски всех масштабов.
Теоретики такие теоретики)))
Batalmv
А что по вашему EA? Я вам расскажу
Business capability map - как основа понимая, чего делает организация и какими сервисами ИТ это покрывается
Инфа об as-is по слоям, иначе о чем вы хотите решения принимать и процессы его поддержания в актуальном состоянии
Технологические стандарты (это все, о чем вы отозвались пренебрежительно "кубики, бдшечки, деплой")
Практики solution architecture - гайдлайны, чек-листы, шаблоны, процессные документы
То, о чем пишете вы - относится ка ИТ-стратегии, которая как раз описывает это описывает. Но иметь банду на 35-40 человек писать ИТ стратегию - это даже не перебор, это классический случай:
---------------------------
Но как все это написано - открой страшный секрет, столько народу точно не надо. На организацию условно на 10+к людей и 200+ систем разной степени устаревания, , которая за год может делать 40-50 проектов вполне достаточно 3-4 человек в EA, и то - это жирно и не напряжно
Да и чтобы написать, столько народу не требуется. Из опыта, всеобемлющую ИТ-стратегию с большой долей бизнес стратегии для банка из ТОП-3 крупной страны делает команда человек на 10, из которых в проекте на 100% работает дай бог половина. При этом будет все, что я написал и даже немножко (даже на до фига) больше. Дальше с этим всем отлично живет "банда" человек на 5, и то - лично я бы половину выгнал, либо отправил внедрять в "поля"
yukoshkina
На организацию условно на 10+к людей и 200+ систем разной степени устаревания, , которая за год может делать 40-50 проектов вполне достаточно 3-4 человек в EA, и то - это жирно и не напряжно
+-+-+
В организациях описываемого вами масштаба и с предлагаемой интенсивностью изменений, очевидно, не нужна выделенная команда EA. Потому что это не про Enterprise.
Batalmv
А можно пример организации сильно большего масштаба?
Просто стало интересно, можем вы имеет в виду условный Гугль?
--------------
К примеру, в профайле автора указано следующее:
3500+ специалистов по ИТ и большим данным
10.0 Пб объем хранения кластера больших данных
46 цифровых продукта и 109 проекта в работе
368 информационные системы в эксплуатации
1400 физических серверов
-----------------
Как вы понимаете, разница не на порядок. Тем более как считать :) Т.е. что считать системой или продуктом. Ну и надо понимать, что большой ритейл - это не так много ИТ по капотом, при всем желании.
Зашел посмотрел на сайт. Ничего космического там нет, стандартный набор плюс-минус
У них получается на 109 проектов только EA 40 человек
Сервера - вполне возможно, у них куча локальных серверных, отсяда и такое количество
yukoshkina
Ну и надо понимать, что большой ритейл - это не так много ИТ по капотом, при всем желании.Я поздравляю вас, вы в 21-м веке. Сейчас ИТ под капотом у всех, кто хочет и может себе позволить автоматизировать бизнес-процессы.
На какой сайт вы зашли и что вы там хотели увидеть, я не очень поняла. Но даю подсказку, чтобы оценить гипотетические возможности автоматизации в корпорации, нужно хотя бы примерно представлять BCM.
Batalmv
Я знаю что такое business capability map, и даже имею практический опыт в ее составлении :)
На сайт компании, которая указана у вас в профиле ;)
Про ИТ под капотом - есть разница, если клиент купил полбатона и кефир, и для этого надо поставить кассиру терминал, сервер с бэком для торгового зала и модуль "склад", и если вы делаете к примеру простой звонок ;) Там все будет сложнее на порядок
Но суть не в размере, а в том, используете вы стандартизированные решения иди нет. Есди да, то размер это просто чуток другие нефункциональные требования и все. Если нет - то я вас могу поздравить с тем, что EA не делает свою работу
Varvara1810 Автор
Добрый вечер, подход, который Вы описываете, хороший и понятный, но, на мой взгляд, он работает или в маленьких организациях, или в отдельной обособленной бизнес-единице. Мы уже работаем в других масштабах, на сегодняшний день наш процесс полностью себя оправдывает. Повторюсь, на АрхРевью не принимаются решения, а коллеги обмениваются опытом, «подсвечивают» варианты решения с разных ракурсов, которые могли быть упущены.У нас около 150 архитектора разных направлений, 30-45 приходят на встречу – это не один и тот же состав, зависит от повестки встречи. И подключаются те архитекторы, которым интересны заявленные решения. Будем ждать ваше резюме, когда будете готовы делиться своим опытом с нами:)
Batalmv
Я писал выше
К примеру, в профайле автора указано следующее:
3500+ специалистов по ИТ и большим данным
10.0 Пб объем хранения кластера больших данных
46 цифровых продукта и 109 проекта в работе
368 информационные системы в эксплуатации
1400 физических серверов
Получается у вас 100+ проектов, на которых пасется 150+ архитекторов. По моему опыту, проект, где нужен больше чем один solution архитектор - это что-то типа внедрения SAP (модулей 5), или биллинга в телекоме. Или миграции кор-банкинга банка на что-то новое и непонятное. Я могу предположить, что это просто такой стиль наименования. Архитектор Java, Big data архитектор, архитектор безопасности.... тогда да, можно набрать 150 человек :)
Но то такое, нравится "быть" большими - я ж не могу запретить :)
-----------------------
Кстати, а МТС больше вас или меньше?
Batalmv
Самое веселое, что я поддался на обсуждение размера, хотя это не важно. Поэтому я дополнительно решил вам ответить по другому, как архитектор ответить
Поясню. К примеру у вас действительно 50 продуктов. Вау, круто. Экстенсивный путь говорит, что конечно. Столько продуктом, столько систем. Конечно нам надо по два архитектора на проект. Но это не так. И причем именно на уровне EA. Как раз solution более-менее пропорциональны количеству проектов, но мы про EA.
Что должен делать EA, чтобы их не было 40 и все проще жилось? Все просто. На помощь приходит замечательное словосочетание: reference architecture. Смысл крайне прост. Мы создаем архитектуру без функциональных требований. Но знаем, что у нас есть много end-users, им надо веб-интерфейс, возможно нативные мобильные приложения. Под "капотом" очевидно серверное прилодение, база, и там еще много чего. Задача EA выработать такую reference architecture. Она пишется относительно просто. Вы рисуете квадратики, их соединяете и далее методично под каждый квадратик определяете возможный технологический стек: язык программирования, допустимые/рекомендуемые фреймворки, механизмы обеспечения HA/DR, способ деплоя, и т.д. Для связей, они же интерфейсы, они же интеграции определяются допустимые протоколы, соглашения о форматах, и т.д. Сбоку описываются "поддерживающие" функции, логи, мониторинг, аудит и т.д. Это тоже квадратики и под каждый квадратик есть детальное описание. Что взять, как растянуть в "кластер", как не пролюбить данные, как накрутить безопасность.
Такая reference architecture закрывает сразу ВСЕ клиентские приложения. Все. Представляете, даже те, что еще не написаны :)
Аналогично. У вас много данных. Отлично. Рисуете свой data lake, первичные данные, data pipeline, на чем все это крутится и т.д.
Где-то ниже это все живет на железе, своем, арендованном, в облаке или микс. И там тоже свои детализации.
Вот задача EA. И самое приятное - размер не важет, так как если у вас 10 стеков под клиентские приложения - значит какого-то EA, либо группу надо гнать пинком под зад. Конечно бывают покупные решения, они часто имеют свои пасочки, но времена суровных деплоев "дорогих" решений со своим стеком уже в прошлом. Мир поменялся и упростился в каком-то смысле благодаря тому, что даже дорогие платформы пререшли на общий стек хотя бы для DevOps.
И, что интересно? как раз на такой набор референсных архитектур + инфрастурктура + рекомендации по портфелю приложений + план проектов на три года вперед + ... как раз достаточно команды человек на 10 на полгода. Хотите очень-очень детально. Ок, год.
Ключ в том, что задача EA не кричать, что нас 40, а всего 150 - що неоспоримо говорит о проблемах, а наоборот. Стандартизация должна упрощать решения.
dyadyaSerezha
За до фига денег излагать, вы имели ввиду. И я вас понимаю. :)