Вторая проблема заключается в том, что когда люди говорят об архитекторе предприятия, то на ум приходит Архитектор Матрицы.
Человек настолько умный, что он все знает и все решает. Конечно, это представление точно так же ущербно, как и первая позиция, потому что такого человека не существует. Никто не может знать все и принимать решения за всех. Да и в фильме это не человек, а компьютерная программа. Так что эта аналогия неверна. Почему такое нереалистичное представление так распространено? Потому что очень удобно иметь того, кто решит все твои проблемы и примет все важные решения. Принимать решения, вообще говоря, непросто. Обязательно что-то пойдет не так и вы примете неверное решение. И если есть какой-то человек, который принимает такие решение, то это не ваша проблема, это проблема этого человека.
И еще раз, практика архитектуры предприятия работает совсем не так. Поэтому давайте проговорим еще раз, что такое практика архитектуры предприятия и в чем заключается роль архитектора предприятия. А потом поговорим немного о том, как должна выглядеть правильная работа архитектора предприятия. Как на самом деле должна работать эта штука. Наиболее важным моментом я считаю понимание того, как архитектура предприятия связана с ИТ архитектурой. По большей части, когда говорят про архитекторов, то имеют в виду архитекторов ПО, архитекторов инфраструктуры, архитекторов облачных решений и т.д.
На стороне ИТ столько разных видов архитекторов, и поэтому довольно удивительно понимать, что на стороне бизнеса вы редко встретите архитектора. И это подозрительно, потому что большая часть ИТ существует ровно для того, чтобы поддерживать деятельность, ведение бизнеса. Вы можете спросить, а где все те люди, которые задают целевое видение бизнеса? Ведь целевое видение бизнеса во многом определяет то, какими должны быть целевые ИТ решения.
И вы обнаружите, что в последнее время стало чуть больше народа, который занимается практикой бизнес-архитектуры, которая формализует бизнес-решения примерно так же, как практика ИТ-архитектуры формализует ИТ-решения. Но по большей части бизнес-архитекторами являются руководители бизнес-подразделений, вы найдете их среди операционных директоров, вице-президентов, руководителей департаментов. В их должности обычно нет слова "архитектор", но если вы всмотритесь в то, чем они занимаются и как они мыслят о своей работе, как они проектируют бизнес-подразделения, дивизионы, продуктовые линейки, то вы обнаружите, что они ведут себя точно так же, как архитекторы из ИТ.
И вот ИТ-архитекторы и бизнес-архитекторы должны работать совместно и это является главной задачей архитектора предприятия. В роли архитектора предприятия я должен удостовериться, что ИТ-архитектура соответствует бизнес-архитектуре, потому что все крутые навороты, которые мы сделали в ИТ, будут не нужны, если они не поддерживают операционную деятельность компании. И тогда разработка контейнера 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-х, которая понятна руководству. Руководство поймет такую стратегию. Но вам еще надо, чтобы исполнители поверили в такой план развития. И для этого вам надо, чтобы этот план развития отражал те штуки, которые у вас есть.
Говорят, что архитектор больше похож на садовника. Отлично, метафора садовника. В саду растут сорняки и вам надо их выпалывать, потому что они растут быстрее полезных растений. И я приведу еще один простой и понятный пример того, что такое стратегия.
Что такое план развития и как правильно гармонизировать. И в этом случае ситуация, которая описана на левой части диаграммы, была большой проблемой для ИТ, потому что приложения были сложными для изменения. Приложения ограничивали возможность экспериментов наверху, где бизнес как раз и хотел гибкости в части продуктовых линеек и бизнес-моделей. А приложение не могло обеспечить этой гибкости. С другой стороны, внизу приложение было крайне разнообразным, оно работало на всех видах аппаратного обеспечения и мейнфреймах, Linux, Windows, я действительно имею в виду, что там было все что угодно. Так что это был худший случай, когда внизу у вас разнообразие, которое вы оплачиваете, и эта инфраструктура ничего не дает вам в плане вариативности бизнес-модели. Вы не можете продать полис страхования, потому что поддержка бизнеса и вовлечение клиента находится на разных серверах.
Так что правильной стратегией гармонизации была гармонизация внизу. Убрать разнообразие инфраструктуры, перевести все на Linux, поместить в контейнер, автоматизировать развертывание и функционирование и резко уменьшить платформу. Джеймс Люис только что рассказал о роли платформ. Вам не нужна гармонизация, вам нужна возможность гибко экспериментировать с бизнес-моделью, не так ли?
Было бы глупо гармонизировать все сверху донизу, потому что разнообразие наверху — это ровно та штука, которая двигает бизнес. Поэтому ваше корпоративное управление ИТ должно четко понимать, где надо затянуть винты потуже, а где их ослабить и это очень важный момент в практике архитектуры предприятия. А то вы получите ситуацию, когда во всех частях организации появятся люди, которые будут гармонизировать все подряд, так как кто-то когда-то им сказал, что гармонизация — это хорошо, потому что она экономит деньги. Но гармонизация — это одновременно плохо, потому что она убивает бизнес. Если вы проведете гармонизацию там, где она не нужна, то вы сделаете ситуацию хуже. Все это кажется очень простым, но проблема в том, что ваш план может быть отличным, но реальность будет отличаться от плана. И с этим ничего нельзя поделать. Знаете, у нас есть поговорка в Германии, что если реальность не соответствует планам, то это проблема реальности, а не планов. Вы столько времени потратили на составление планов, они не могут быть плохими по определению.
К сожалению, с реальностью очень сложно спорить, она может быть очень упрямой, вы ее не переспорите. И тут опять нет никакой магии, вам нужна корректировка курса. И для того, чтобы корректировать курс, вам нужна гибкость, вам нужна способность направлять развитие.
Но кроме того, вам нужна еще и четкая цель, потому что если у вас нет цели, и вы можете рулить, вы будете ходить кругами. Поэтому идея иметь гибкость на уровне организации хороша только в том случае, когда у вас есть четкая цель. И на этом пути вы обнаружите кучу вещей, которые вам не понравятся, но лучше их обнаружить, чем не обнаружить. И это приводит нас к концу рассуждений про гармонизацию. Практика архитектуры предприятия нужна не только для того, чтобы создать модель архитектуры, но и для того, чтобы создать компетенции по выявлению архитектуры предприятия и разработке моделей архитектуры в вашей организации.
У вас никогда не будет достаточно людей с достаточным набором навыков, вам надо выращивать таланты внутри организации.
Так что у вас, с одной стороны, есть стимул, чтобы осваивать распределенную практику архитектуры предприятия, а с другой стороны, так и надо делать, это правильный способ. И ваша роль как архитектора предприятия заключается в том, чтобы провести людей по этому пути. Это не игра "кто первый заберется наверх", это игра "кто первый забрался, тянет остальных". И это просветительская функция, функция тренера, инструктора на должности архитектора предприятия. И про это важно не забывать, потому что именно это подпитывает цикл, вам понадобится помощь остальных архитекторов. Вам нужна их поддержка, без нее вы потеряете базис. Линда хорошо про это говорила ранее "у меня такие классные идеи, мне не нужна помощь остальных", но такой настрой — это кратчайший путь в никуда.
Вот такая цепочка создания ценности.
И есть три вещи, которые должен делать архитектор предприятия, чтобы эта цепочка создания ценности заработала:
- Связи
- Абстракции
- Принятие решений
И чтобы объяснить суть работы архитектора предприятия, я покажу мое любимое определение этого термина.
Это очень простое определение и теперь, посмотрев на эти уравнения, я думаю, все понимают суть работы архитектора. Это формула Блэка-Шоулза для оценки стоимости опционов, за которую выдали Нобелевскую премию.
Когда вы разговариваете с бизнесом и объясняете, в чем суть работы архитектора, то большинство людей в бизнес-подразделениях легко поймут эту аналогию, особенно в финансовых организациях. Вы просто говорите им, что вы продаете опционы, так? Что дает практика архитектуры? Она дает гибкость, она дает возможность менять свои решения в будущем. И это опционы.
Собираюсь я переместить приложения в облако или не собираюсь этого делать? Нужен мне такой опцион или нет? Надо ли мне иметь возможность динамически масштабировать приложение или это не нужно? Я могу продать такие опционы, они называются архитектура без состояний и масштабируемая архитектура. Эти опционы стоят денег, точно также, как и опционы на финансовых рынках и эта формула вычисляет стоимость такого опциона. За этот опцион надо заплатить, потому что он позволяет отказываться от своих решений в будущем и это имеет ценность. Я не знаю точно, что мне понадобится, поэтому я покупаю опцион, он дает мне возможность пойти в будущем как налево, так и направо, что имеет для меня ценность. Можно построить деревья решений и легко посчитать стоимость таких решений и стоимость опционов. И это основная штука, которую делает практика архитектуры предприятия и ключевая дискуссия, которая происходит между архитектором предприятия и бизнесом, заключается в следующем. Вот список опционов, которые могут оказаться для вас полезными. Давайте обсудим, какие из этих опционов стоит купить и почему. И дальше надо сделать еще одну вещь, которая на самом деле показана на этой формуле. Эта вещь заключается в том, что в меняющейся среде стоимость опциона увеличивается. Это легко представить себе. Если вы знаете абсолютно точно, что произойдет, например, вы разрабатываете приложение, которыми будут пользоваться 10 человек и это всегда будут 10 человек, то опцион на то, чтобы сделать это приложение масштабируемым, ничего не стоит. А вот если вы делаете Интернет-приложение, у которого сегодня 10 пользователей, а завтра 10 миллионов пользователей, то опцион на масштабирование будет очень ценным.
Мы сейчас живем в очень изменчивом мире, в котором меняется окружение в бизнесе, меняются технологии, поэтому стоимость опционов увеличивается. И именно так стоит объяснять бизнесу, почему надо вкладывать больше ресурсов в разработку архитектуры предприятия. Потому что стоимость опционов, в которые они вкладывают деньги, и которые вы как архитектор предприятия продаете, увеличивается. И люди из бизнеса поймут эту логику.
Три вещи, которые делает архитектор.
Связи. Есть одна простая истина, которую я вам сейчас открою. Никому нет никакого дела до архитектуры.
Неожиданное заявление с моей стороны, не правда ли? Архитектор говорит, что никому нет никакого дела до архитектуры. От этого знания становится грустно, не так ли? Старший архитектор говорит, что никому нет никакого дела до архитектуры. Потому что заказчики не видят вашей архитектуры. Ваши заказчики видят, как ваша система себя ведет. Быстро ли она работает? Работает ли она 24/7 или она все время ломается? Способны ли вы быстро ее дорабатывать? Если вы посмотрите на левую и на правую системы, то они состоят из одинаковых кусков А, В, С, Д. В чем же между ними разница?
Разница между этими системами в том, что они по-разному соединены. Связи между этими кусками разные. И если я спрошу любого архитектора, одинаковые ли свойства у этих двух систем, то он сразу выдаст мне минимум 10 различий между этими вариантами. У варианта, представленного слева, проще делать замены, но задержки могут быть больше, если один компонент выходит из строя, то вся система перестает работать, а у системы справа путь сигнала короче, но связность решения больше, сложнее производить замены и т.д. и т.п. Эта те штуки, которые мы делаем как архитекторы. Эти два варианта находятся на противоположных концах спектра возможных решений несмотря на то, что они состоят из одинаковых элементов. Как я это обычно объясняю с помощью простой метафоры . Пусть у нас есть ингредиенты - А, Б, С, Д. Помидоры, мука, тесто, сыр, колбаса, оливковое масло. В случае с софтом это база данных, сервер, сеть, фаерволл, но есть один тонкий момент.
Из этих ингредиентов можно приготовить очень разные блюда. Можно приготовить прекрасную пиццу или приготовить ужасный сэндвич. В этом и заключается сила связей.
Архитектор должен быть хорошим поваром, а что значит быть хорошим поваром? Быть хорошим поваром означает уметь правильно использовать ингредиенты. Если вы пойдете на рынок и купите хорошие помидоры, то это еще не значит, что вы вкусно покушаете. То же самое в ИТ, приобретение хороших ингредиентов — это хорошее начало, но приготовить вкусную еду, сделать хорошую архитектуру означает правильно все связать. Хорошая архитектуры живет в правильных связях.
И тут я напомню хорошую фразу о том, что если кто-то показывает мне модель архитектуры предприятия, в которой нет линий, в которой есть только блоки, то я сразу говорю, что это не модель архитектуры. Потому что поведение системы, то, что важно для заказчиков, для пользователей, определяется связями. И если кто-то показывает мне модель, в которой нет этих связей, то я отвечаю, что такая модель для меня бесполезна.
Люди считают, что так говорить не очень-то и вежливо, но я искренне так считаю. Если у вас на картинке нет связей, то эта картинка скорее всего бесполезна. Вот интересный факт про связи - они существуют в разных измерениях. Первый вид связей - это связи между слоями. Вам надо связать инфраструктуру, данные, приложения, процессы, стратегию. И с точки зрения архитектора очень важно правильно связать между собой эти слои. Инфраструктура, данные и приложения должны поддерживать процессы и стратегию. И это как раз и есть цепочка создания ценности, о которой мы столько говорили. И еще есть связи между системами. Как у вас устроена интеграция. Изолированы они или у вас микросервисы, где там облака, SaaS, PaaS и это очень сильно определяет на то, как ведут себя эти системы. И, наконец, если мы оставим на минутку мир инженерных решений и перейдем в мир организационных структур, то есть еще связи между функциями организации. И все эти вещи очень сильно влияют на архитектуру, потому что если вам надо два месяца согласовывать перенос данных на сервер, то переезд приложения в облако вам не поможет. Вы все равно будете ждать 2 месяца своего одобрения.
Связи играют основную роль и связи живут в разных измерениях - между слоями, между системами и организационные связи.
Вторая важная для архитектора вещь — это способность абстрагироваться. Помните смешную картинку, в которой связи между множеством систем переплетены между собой как спагетти? Это реальность, она бесполезна для принятия решений.
Реальность слишком сложна, чтобы принимать по ней информированные решения. Вам нужна модель, чтобы принимать информированные решения.
И модели являются самыми важными инструментами для архитекторов, мы принимаем по ним решения, потому что реальность слишком сложная. Тут надо понимать очень важную вещь - модель не является реальностью. Она и не должна быть реальностью, потому что суть модели в том, чтобы упрощать реальность так, чтобы можно было отвечать на какой-то вопрос и принять решение. Но, с другой стороны, это означает, что для того, чтобы найти правильную модель, вам надо понять, на какой вопрос вы отвечаете. Поэтому вот вам классический пример с 4 различными картами. Они очень разные, они отображают одну и ту же систему - планету Землю. Но они выглядят очень по-разному. И причина, по которой они так по-разному выглядят заключается в том, что они отвечают на разные вопросы. Как мне пойти в пеший поход из пункта А в пункт Б или как мне проехать на машине отсюда и туда? Разные вопросы.
Это означает, что когда вы делаете модель архитектуры предприятия, то вам надо понять, на какой вопрос вы отвечаете, чтобы сделать хорошую модель. Или какое решение вы принимаете. Поэтому, когда кто-нибудь просит вас показать архитектуру, то совершенно закономерным уточнением с вашей стороны будет: "На какой вопрос вы ищете ответ? Какое решение вы принимаете?" Вы не должны разрабатывать диаграммы просто так, потому что такие виды диаграмм существуют. Разработка модели архитектуры должна лежать на твердом основании вопросов, на которые вы отвечаете и решений, которые вам надо принять. И можно перевернуть это в другую сторону. Если кто-то показывает вам диаграмму архитектуры, то правильно будет спросить: "Какое решение помогает принять эта диаграмма?" Если вас спросят: "В смысле?" То вы сможете ответить: "Ну как, это же модель реальности, модель нужна для того, чтобы помочь мне принять решение. Если вы показываете мне какую-то модель, то вы разрабатывали ее для поддержки принятия какого-то решения. Какое решение помогает принять эта модель?" И если он не сможет вам ничего ответить, то возможно, эта модель не так уж и полезна. Это пример архитектурной модели.
Так выглядят модели, которые создают различные инструменты разработки моделей архитектуры предприятия. Как вы видите, в этой диаграмме множество разных соединений. В этой модели вы можете увидеть соединения между практиками бизнеса и техническими решениями. И это основной функционал моделлеров архитектуры предприятия. Это очень полезная штука и это тот функционал, про который люди часто забывают при разработке моделей архитектуры, потому что инструменты разработки архитектуры часто очень сложные. Мы еще поговорим об этом. Дело ведь не в том, какие модели вы создадите в этом инструменте, дело в том, какую информацию вы сможете получить из инструмента, в чем заключается его польза. Инструмент должен помогать принимать вам решения. Если он не помогает вам принимать решения, то создание моделей архитектуры предприятия в этом инструменте — это простая потеря времени и денег.
Последний важный пункт при работе с абстракциями заключается в том, что вы должны понять, как все эти штуки работают вместе. Как функционирует система.
И есть классическая история про индийских кобр во времена колониальной Англии. Это называется эффектом кобры. В то время было много кобр, и эти кобры не были особо дружелюбными созданиями. Британцы подумали: "Как бы нам от них избавиться?" И они объявили награду за поимку кобр. Мы будем платить за каждую убитую кобру и тогда всех кобр переловят и у нас больше не будет этой проблемы. Что произошло на самом деле? Люди просто стали разводить и убивать кобр. Потому что проще разводить кобр у себя на заднем дворе, чем ловить их в джунглях. И когда индусы стали просить слишком много наград за кобр, британцы перестали за них платить. И что сделали индусы? Правильно, они отпустили ненужных им кобр на свободу. Что получили британцы? Они получили еще больше кобр, чем их было до того и потратили на это кучу денег. Такими вещами занимается теория систем, системное мышление. И создание организационных систем сталкивается с точно такими же проблемами.
Когда вы рассуждаете о связях, то очень важно понимать такого рода эффекты кобры. Вам может казаться, что вознаграждать за какие-то действия правильно и хорошо, пока не столкнетесь с эффектами кобры. Это очень важный аспект работы архитектора предприятия.
Решения.
И последний пункт, про который я уже говорил, это про то, как архитекторы предприятия принимают решения. И я часто иллюстрирую этот аспект с помощью такой картинки домика. Является ли такая картинка домика это архитектурой? И в классическом определении архитектуры, эта картинка описывает архитектуру. Классическое определение архитектуры говорит, что архитектура — это элементы состав, структура, ограничения и то, как они соединены все вместе. И картинка домика полностью подходит под это определение. На ней показаны окна, двери, крыша, все на своих местах. Так что картинка подходит под классическое определение архитектуры. Но на мой взгляд эта картинка не проходит проверку по следующему параметру. По параметру решений. Эта картинка не показывает никаких принятых решений. У меня есть хороший вопрос для проверки. И этот вопрос не: "Является ли это архитектурным описанием или нет?" Вот этот вопрос - заплатили бы вы за такой дизайн своему архитектору? И ответ скорее всего что нет, не заплатили бы. В этом дизайне нет никаких решений. Это стандартный рисунок.
И у меня есть другой вариант похожего рисунка, такой же домик с покатой крышей. Причина, по которой крыша такая острая заключается в том, что дом расположен в холодном климате, в котором выпадает много снега. И снег попадает на крышу, скапливается там и может просто проломить крышу, сломать балки. И поэтому крыша очень покатая, чтобы снег съезжал вниз. То есть тут принято решение и по поводу этого дизайна я могу сказать, что здесь показана архитектура. И за такой дизайн вы готовы заплатить своему архитектору. Если вернуться обратно к ИТ, то основной проблемой при принятии решений по поводу ИТ-систем является то, что люди просто теряются в сложности этих систем. И им нужна дисциплина принятия решений. Принимать решения не так уж и сложно. У вас есть варианты, опционы, вам надо выбрать один вариант, выбрать опцион, у вас есть четкое понимание того, какие варианты, какие опционы для вас предпочтительны. Вы знаете, что вы хотите автоматизировать, что должно быть в облаке, что должно работать на открытом ПО, у вас есть принципы, есть стратегия, вы понимаете, что вы выбираете, что для вас является наилучшим вариантом. Проблема в том, что за всей сложностью систем люди про это забывают. И вам надо возвращаться к основам и принимать обоснованные решения и следовать дисциплине принятия решений. И тут важно понимать, что решение, в котором нет выбора между улучшением одного параметра за счет ухудшения другого, не является истинным решением. Оно не очень-то и полезно. И такое часто встречается в ИТ, когда люди выбирают между чем-то осмысленным и чем-то абсолютно дурацким с помощью скоринговых таблиц. И они смотрят на баллы, которые набрал каждый вариант, и говорят: "О, смотрите, это решение намного лучше, у него больше баллов". Это бесполезное решение. В полезном решении вы обмениваете одни характеристики на другие характеристики. Мы можем сделать крышу покатой, чтобы снег скатывался с крыши вниз, но в этом случае мы должны сделать выбор. Вы не сможете найти икеевскую мебель, которая бы поместилась у вас на чердачном этаже. Потому что на чердаке не будет стен, там будет покатая крыша. В этом решении есть выбор. Если вы не делаете выбор одних характеристик в пользу других, то скорее всего, ваше решение не очень-то и хорошее. И если у вашего решения есть отрицательные последствия, то вам нужна стратегия, чтобы уменьшить эти отрицательные последствия. И это ваша обязанность как архитектора сказать, что да, мы понимаем, что если мы переходим на гибридные облака, мы увеличиваем сложность и вот что мы делаем по этому поводу.
И мы переходим к заключительной части моего выступления. Все те пункты, о которых я говорил, выглядят достаточно логичными. Есть 8 шагов цепочки создания ценности, у нас есть ключевые ингредиенты, вам надо учитывать связи, вам надо работать с абстракциями, вам надо принимать решения, но проблема заключается в том, что ситуация никогда не является такой простой и логичной. Потому что в реальности это огромное море неопределенности. И я думаю, что в этом море неопределенности теряется множество архитекторов предприятия, они просто теряют ориентиры. У них правильные намерения, но из-за того, что все так неопределённо, они просто не понимают, с чего начать. Поэтому принцип "разделяй и властвуй" является, пожалуй, самым важным принципом, которым вы должны руководствоваться в своей работе архитектора предприятия. Потому что именно этот принцип и позволяет им не закрываться в своей башне из слоновой кости. Но если у вас нет измеримых результатов, то вы никогда не покинете свою башню из слоновой кости. Потому что в башне из слоновой кости мир кажется прекрасным и красивым, но вы не приносите никакой пользы для бизнеса и это очень-очень плохая вещь.
Архитектура предприятия — это не какая-то черная магия. Большая часть этой практики приходит из здравого смысла. Это понимание отношений между вещами, это расстановка приоритетов, это понимание того, как объединяются бизнес и ИТ, это последовательное и дисциплинированное принятие решений, с учетом общих принципов и стратегии. Главное тут не потеряться в сложности предметной области или в сложности инструментов и методов. Вы должны помнить, что инструмент вам нужен для того, чтобы достичь какой-то цели, инструмент не является целью сам по себе. Возможно, для кого-то это будет самым важным советом за сегодня.
Если вы вспомните, о чем я сегодня говорил, вы поймете, что я рассматривал ситуация с разных точек зрения. С точки зрения основателя компании, консультанта, с точки зрения разработчика, архитектора, и хороший архитектор всегда комбинирует различные точки зрения, чтобы получить полезные модели. И я думаю, что быть хорошим архитектором означает уметь занимать различные точки зрения, понимать аспекты организации бизнеса, технические моменты, понимать бизнес. Чем больше точек зрения вы понимаете, тем лучше вы можете делать работу архитектора предприятия, тем лучше вы "склеиваете" работу разных подразделений в согласованную деятельность. И спрос на таких людей крайне высокий, потому что их просто мало. И если вы сможете делать все то, о чем я говорил, и выдавать конкретный результат, то компании будут с руками вас отрывать. Это блог и книга про роль архитектора в цифровой трансформации организации.
https://www.enterpriseintegrationpatterns.com
https://leanpub.com/37things
Alexander Turkhanov, [28.04.19 16:41]
Как работает означает либо причину и следствие либо передачу информации, материала, энергии, людей.
Alexander Turkhanov, [28.04.19 16:48]
Alexander Turkhanov, [28.04.19 16:50]
Alexander Turkhanov, [28.04.19 16:51]
Alexander Turkhanov, [28.04.19 16:58]
Отношения реализации обычно используются для связывания аппаратного обеспечения с программным, а программного с деятельностью. Например, есть конкретный сервер, на котором работает конкретная CRM с конкретной базой данных. Сервер и база данных реализуют программу и данные по клиентам. А программа и данные по клиентам реализуют деятельность по привлечению клиентам и информацию по клиентам. Деятельность и информация куда более абстрактная, чем сервер с базой данных, в нем больше неопределенности в состоянии клиента, в работе с ним.
Alexander Turkhanov, [28.04.19 17:00]
Alexander Turkhanov, [28.04.19 18:04]
И они могут быть на разных системных уровнях, например, Яндекс.Метро как часть смартфона, подсистема смартфона, обслуживает пассажира метро со смартфоном, надсистему Яндекс.Метро.
Отношения использования используются для обозначения вертикальных и горизонтальных границ систем и модулей систем.
С помощью отношений доступа детально описывается связь между активными элементами. Например, CRM записывает данные о клиенте, которые затем считывает система аналитики. Отдел продаж записывает данные по сделке в реестр сделок, который потом считывает отдел финконтроля для контроля оплат.
Можно считать, что пассивные объекты - это такие места, папки, каталоги и файлы, куда заносится информация, а отношение доступа показывает кто записывает эту информацию, а кто ей пользуется.
Отношения состава, реализации и специализации можно объединить в группу классификаторов. Классификаторы можно построить тремя способами:
