воскресенье, 28 апреля 2019 г.

Мощь ArchiMate в связях

Поступил вопрос:
"И вот такой сижу читаю
Автомобильные компоненты для цеха сборки шасси
Читаю отношение , моделирует доступ работы к объекту деятельности или данным , вот не совсем понятно , что тут имеется ввиду , примеры простые есть ?)
То какие там написаны вообще не понятно )))
И что значит структурная категория , сколько категорий бывает и какие виды и почему ?)"

Мой ответ:
Alexander Turkhanov, [28.04.19 16:37]
Категории бывают либо структурные, которые описывают из чего состоит, из чего построена система, и динамические, которые показывают как она работает, как действует.

Alexander Turkhanov, [28.04.19 16:39]
Динамических отношений всего 2 типа - отношения запуска, которые показывают причинно-следственную связь. Например, пришла заявка от клиента и менеджер по продажам начал отрабатывать лид. Событие "Пришла заявка от клиента" связано отношением запуска с практикой "Отработка лида".
Alexander Turkhanov, [28.04.19 16:41]
И отношения передачи. Например, бензонасос передает топливо в двигатель. Или двигатель передает крутящий момент на оси. Или менеджер по продажам передает информацию по товарам и ценам клиенту.
Как работает означает либо причину и следствие либо передачу информации, материала, энергии, людей.

Alexander Turkhanov, [28.04.19 16:43]
Структурные отношения. Часть-целое, отношение состава. Рука - часть тела. Отдел - часть организации. Параграф контракта - часть договора продажи. Бухать - часть функционала отдела продаж. Обрабатывать косяки пользователей - часть функционала программного обеспечения.
Alexander Turkhanov, [28.04.19 16:48]
Отношение назначения. Означает совпадение двух объектов, о которых можно думать отдельно. Допустим, у нас есть вакансия менеджера отдела оптовых продаж. Мы о ней думаем отдельно, пишем к ней требования, составляем профиль должности, делаем маркетинг вакансии и ведем вакансию по воронке найма. И есть кандидаты, конкретные люди. Мы о них тоже думаем отдельно. На каждого заводим запись или даже дело, собеседуем, прогоняем через тесты, проверки, медкомиссию, делаем им предложения. В какой-то момент подходящий кандидат соглашается на вакансию и занимает ее. С этого момента вакансия заполнена, а должность и человек есть по сути одно и то же. Вася Пупкин занимает должность менеджера оптовых продаж. Мы можем называть его Вася Пупкин, можем называть "менеджер оптовых продаж", мы все равно указываем на конкретный объект.
Alexander Turkhanov, [28.04.19 16:50]
Аналогично можем думать про покупку автомобиля. Есть функция "индивидуальная перевозка людей и грузов по автомобильным дорогам" и есть куча вариантов автомобилей, которые мы можем купить. В какой-то момент покупаем конкретный автомобиль и у нас совпадает функция и автомобиль. Функция исполняется конкретным автомобилем, хотя мы можем думать о ней абстрактно "автомобиль должен возить 7 человек и 5 мешков картошки с дачи".
Alexander Turkhanov, [28.04.19 16:51]
Точно также можем думать про выбор CRM. Вначале думаем про то, что должен делать CRM, а потом в какой-то момент покупаем лицензию на использование конкретного экземпляра и у нас совпадает функция и конструкция.
Alexander Turkhanov, [28.04.19 16:58]
Отношение реализации показывает уровни абстракции. Откуда стрелка идет - это более низкий уровень абстракции, куда идет - более высокий уровень абстракции.
Например, есть конкретное яблоко и есть яблоки вообще. Конкретное яблоко реализует яблоки вообще. Яблоки вообще реализуют фрукты вообще.
Отношения реализации обычно используются для связывания аппаратного обеспечения с программным, а программного с деятельностью. Например, есть конкретный сервер, на котором работает конкретная CRM с конкретной базой данных. Сервер и база данных реализуют программу и данные по клиентам. А программа и данные по клиентам реализуют деятельность по привлечению клиентам и информацию по клиентам. Деятельность и информация куда более абстрактная, чем сервер с базой данных, в нем больше неопределенности в состоянии клиента, в работе с ним.
Alexander Turkhanov, [28.04.19 17:00]
Отношение использования. Разделяет структурные части системы, элементы конструкции, системные уровни, позволяет абстрагироваться от деталей реализации.
Например, сервис Убер позволяет абстрагироваться от того, как конкретно добираться до места. Ты просто говоришь, что хочешь куда-то доехать.
Alexander Turkhanov, [28.04.19 18:04]
Отношения использования могут быть между модулями на одном системном уровне. Например, эскалатор в метро обслуживает линию движения поездов, он должен перевозить не сильно больше и не сильно меньше пассажиров, чем способна перевезти линия.
И они могут быть на разных системных уровнях, например, Яндекс.Метро как часть смартфона, подсистема смартфона, обслуживает пассажира метро со смартфоном, надсистему Яндекс.Метро.
Отношения использования используются для обозначения вертикальных и горизонтальных границ систем и модулей систем.

Alexander Turkhanov, [28.04.19 18:12]
Отношения доступа. Показывает, что какой-то активный элемент (ответственный, роль, программа или оборудование) что-то записывает в пассивный объект (информационный объект, документ, базу данных) или считывает из пассивного объекта.
С помощью отношений доступа детально описывается связь между активными элементами. Например, CRM записывает данные о клиенте, которые затем считывает система аналитики. Отдел продаж записывает данные по сделке в реестр сделок, который потом считывает отдел финконтроля для контроля оплат.
Можно считать, что пассивные объекты - это такие места, папки, каталоги и файлы, куда заносится информация, а отношение доступа показывает кто записывает эту информацию, а кто ей пользуется.

Alexander Turkhanov, [28.04.19 18:22]
Отношение специализации. Показывает категории. Например, есть холодильники вообще, а есть холодильники Стинол. Холодильники Стинол являются специализацией холодильников вообще.
Отношения состава, реализации и специализации можно объединить в группу классификаторов. Классификаторы можно построить тремя способами:
1) Разделив на части - отношения состава и объединения. Ученик является частью класса, работник является частью организации, колеса являются частью машины, программная функция является частью всего функционала программы, запись о работнике является частью реестра.
2) Разделив по уровням абстракции. Ученик является человеком, а человек является живым существом, точно так же, как рыбы и звери. Накладная является документом первичного учета, документ первичного учета является документом, документ является рабочим продуктом, рабочий продукт является вещью, точно так же, как камень или дом является вещью.
3) Разделив на классы или типы. Человека можно отнести к разумным, живым, теплокровным, млекопитающим. Автомобиль можно отнести к механизмам, транспортным средствам, движимому имуществу, собственности, вещам, подлежащим государственной регистрации, производственным изделиям.

Alexander Turkhanov, [28.04.19 18:23]
Таким образом, ArchiMate позволяет описать состав и работу системы и классифицировать функциональные и конструктивные элементы системы так, как удобно для работы.

Медитация по рабочим вопросам с 9 до 10. Не беспокоить!

Слово «медитация» происходит от латинского meditatio, точнее от глагола meditari, который в разных контекстах означает «обдумывать», «мысленно созерцать», «вырабатывать идеи».

В Ветхом Завете хага (на иврите: הגה) означает не только вздыхать или шептать, но и размышлять, умственно созерцать. Когда Тора была переведена на греческий язык, слово хага было переведено как melete. В латинской Библии слово хага / melete было переведено как meditatio. Использование термина meditatio применительно к одной из частей поэтапного процесса мысленного созерцания впервые встречается у монаха Гиго II в XII веке.

Медитативные методы основаны на управлении функциями психики с помощью концентрации внимания (пассивная медитация) или воли (активная медитация).

Источник: Википедия

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

Для чего нужна медитация по рабочим вопросам?


1. Спокойствие. Если у вас есть схема понимания мира, то у вас есть схема действий. Есть схема действий, вы работаете по ней, а не мечетесь от одной проблемы к другой.
2. Уверенность. Если у вас есть схема понимания мира, то  вы можете сверять фактические результаты действий со своими планами. Вы знаете, как работает ваша схема, где она менее точна, где более. Значит, вы понимаете, где надо воспринимать критику и корректировать действия, а где надо аргументировано отстаивать свою точку зрения.
3. Влияние. Если у вас есть схема понимания мира, то вы можете показать ее другим. Люди любят порядок и всегда готовы следовать за тем, кто за хаосом видит цель и говорит, что надо сделать, чтобы прийти к этой цели. Схема позволяет каждому объяснить его вклад в общее дело, а люди любят делать значимый вклад в большое дело. Схема позволяет быть понятным, вы можете объяснить свои действия, а люди любят предсказуемость лидеров. Предсказуемость порождает доверие, вы знаете, что можно ожидать от человека. Сложно доверять тем, чьих действий ты не понимаешь. Способность видеть цель и путь, объяснять людям их вклад и пользоваться доверием усиливают наше влияние на людей.
Только глубокие размышления о бизнесе приводят к его полному пониманию. 
Только полное понимание позволяет быстро и безошибочно действовать в критической обстановке. 
Только те, кто быстро действует в критической обстановке, успешно проходят кризис за кризисом. 
Только те, кто успешно проходят кризис за кризисом, могут расти на расчищенной кризисом площадке не с нуля. 
Только те, кто растет не с нуля, вырастают большими.
Самый большой дуб вырос не из самого большого желудя. Просто рядом не было других больших дубов, его не погрызли зайцы, его не срубили люди, его не сломал ураган. Но дуб ничего не может сделать со своей судьбой, люди - могут. Надо только как следует подумать.

четверг, 25 апреля 2019 г.

MVP курса по цифровым двойникам организации

Проект создается в сотрудничестве с Михаилом Софоновым.


Контрольные вопросы к ролику "Как обосновать проектные инвестиции руководству с помощью системных эффектов".

1.1 Руководитель цеха сборки шасси сократил время такта с 2:25 до 2:15 минут:секунд. При этом увеличился выпуск полусборок шасси всего цеха за смену.
А) Это будет иметь системный эффект на все производство, т.к. сменное задание цеха сборки шасси будет выполняться быстрее.
Б) Это не будет иметь системного эффекта, потому что узким местом является цех окраски со временем такта 3:50 и операции цеха сборки шасси ускорять бессмысленно.
В) Это вообще не оптимизация потому что сократить персонал от такой оптимизации не получится.
Г) Любое ускорение - это хорошо, когда-нибудь пригодится. Например, если поставки опоздают и надо будет нагонять график.

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

1.3 Директор завода предлагает между кузовным цехом и цехом окраски поставить сортировочный центр, чтобы заказные комплектации шли в приоритете и попадали на отгрузку раньше типовых комплектаций без конкретных заказчиков. На месте начальника кузовного цеха, которому надо организовать такую сортировку вы:
А) Проголосую за, ведь это мнение директора.
Б) Проголосую за, в цехе окраски длинные очереди и для заказов с высокой стоимостью задержки надо применять приоритезацию.
В) Проголосую против, пусть выделяют отдельное подразделение.
Г) Проголосую против, такая сортировка только собьет производственный ритм и повысит процент брака.
Д) Воздержусь, т.к. ценность такого решения сомнительна, но и серьезных доводов против тоже нет.

1.4 Начальник отдела по закупкам и логистике на совещании сказал, что после проектов улучшений на производстве его отдел не справляется с возросшим объемом производства и это стало причиной падения выпуска на этой неделе. Какой вариант системного решения вы считаете предпочтительным?
А) Нужны внутренние склады комплектующих, они позволят создать буферы поставок.
Б) Нужно строить дополнительные конвейеры поставки ресурсов на производстве, чтобы уменьшить плечо поставок при внутренней логистике.
В) Нужно лучше приоритезировать заявки на снабжение, задержка поставок комплектующих на рабочие станции, которые работают с высокой загрузкой, недопустима.
Г) Это проблемы начальника отдела закупок и логистики, а не мои. Пусть сам разбирается.

Контрольные вопросы к ролику "ОРМ методология, SysML и ArchiMate".
2.1 Директор завода сказал, что нанял консультантов по MBSE, которые будут ставить практику основанного на моделях управления жизненным циклом продукции. Для вас это означает:
А) Очередное буллшит-бинго. Ничего по факту не изменится.
Б) Регламенты и стандарты предприятия будут вестись в составе единой модели управления заводом. Частные экземпляры документов (регламентов, должностных и рабочих инструкций) будут порождаться по запросу, с учетом всех изменений и отображений нестыковок, коллизий с другими документами и единым списком терминов.
В) Болезненный и длительный переход инженерного проектирования в PDM либо PLM-систему. Возможно, неудачный.
2.2 На совещании по запуску этого проекта по MBSE один из участников совещания спросил консультанта, а в чем разница между моделями ИТ-ландшафта, органиграммой и схемой бизнес-процессов и "этой вашей системной моделью жизненного цикла"? Что скорее всего ответил консультант?
А) Ни в чем, системная модель жизненного цикла - это ровно то же самое, что ИТ-ландшафт, органиграмма и схема бизнес-процессов, просто созданная в одном пакете моделирования.
Б) Содержание этой модели и впрямь повторяет ИТ-ландшафт, органиграмму и схему бизнес-процессов, но во-первых эти модели связаны в единое целое, во вторых, они подчинены одной метамодели и могут быть обработаны скриптами, т.к. созданы в одном программном пакете и находятся в едином хранилище под контролем версий.
2.3 Совещание идет дальше и тут один из ваших молодых инженеров спрашивает, а почему консультанты предлагают использовать OPM, а не SysML, ведь SysML как раз и предназначен для моделирования систем. Консультанты привели несколько аргументов в пользу ОРМ. Какой аргумент консультантов показался вам наиболее убедительным?
А) Моделирование жизненного цикла будет наиболее удачным, если заниматься им будет как можно больше человек. OPM гораздо проще SysML, в нем 1 вид диаграммы, а не 9, 20 символов, а не 120, а спецификация в 10 раз короче. Кроме того, OPM позволяет записывать модели в текстовом виде, а не рисовать только диаграммы, что гораздо быстрее.
Б) OPM предназначен для систем автоматизации производства, а вам как раз надо производство автоматизировать, у вас идет цифровизация.
В) Для моделирования в SysML надо будет купить довольно дорогой моделлер и программу тренингов. С моделированием в OPM в бесплатном моделлере Archi вы справитесь сами, по нему есть много бесплатных материалов.
Г) Стандарт по объекто-процессуальной методологии есть на русском в официальном заверенном ФАТР-М варианте, спецификация SysML не переведена.
Контрольные вопросы к ролику "Реверс-инжиниринг функциональной модели предприятия".
3.1 Вы обсуждаете модель, которая описывает динамику отгрузки машин из цеха сборки шасси в цех кузовной сварки. На этой модели два типа элементов - практики и объекты. На ваш взгляд это:
А) Функциональная модель, потому что она описывает поведение завода.
Б) Структурная модель, потому что она описывает конструкцию и состав завода.
3.2 Вы представляете цех сборки шасси и обсуждаете межцеховой буфер полуготовой продукции с цехом кузовной сварки. Вы достигли соглашения по размеру этого буфера и теперь вам надо изменить модель жизненного цикла завода. В какую часть вы внесете изменения?
А) В атрибуты практики
Б) Подписью на стрелках
В) В атрибуты стрелки
Г) В атрибуты объекта

Д) В атрибуты интерфейса
Е) В атрибуты стрелки
3.3 Вы проводите обследование работы кузовного цеха и подходите на станцию сварки капота. Видите там поддон, на котором написано "Карбоновые капоты", он пустой. Мастер говорит вам, что эта модель давно уже не выпускается. Вам надо смоделировать эту рабочую станцию. Самым лучшим действием для вас будет:
А) Проверить реестр конфигураций модельного ряда, если эта опция все еще есть и не удалена, то карбоновый капот надо поставить как возможный вход практики установки капота.
Б) Уточнить информацию у отдела производственного планирования, не ошибается ли мастер.
В) Не ставить карбоновые капоты как возможный вход практики установки капотов.
Г) Просто проигнорировать, что капоты бывают карбоновые, они в любом случае ставятся.
3.4 Вы изучаете диаграмму, которую вам прислали консультанты, и замечаете, в объект "Шасси в сборе" одна стрелочка входит от практики сборки шасси, а другая стрелочка выходит на практику сварки кузова и монтажа шасси на кузов. Вы наводите курсор на стрелочки, и понимаете, что практика сборки шасси записывает в объект шасси в сборе какую-то информацию, а практика сварки кузова считывает информацию из объекта шасси в сборе.
Вы задаете консультанту вопрос, что это означает. Какой ответ вы получаете?
А) Это модель реального мира. Объект - это такой список, в котором по строкам записаны все экземпляры автомобилей, которые передавались между этими практиками. А по столбцам атрибуты объекта шасси в сборе. Каждый раз, когда собирается очередной экземпляр шасси, в этот список делается запись о нем. Когда практика сварки кузова забирает экземпляр шасси, чтобы смонтировать его на кузов, она считывает из этого списка очередную запись.
Б) Это модель реального мира. Объект показывает состояние технологического передела целевой системы автомобиля. Шасси в сборе является частью автомобиля, которая передается между практиками сборки шасси и сварки кузова. Стрелочки показывают направление движения материалов.
Контрольные вопросы к видео "Моделирование типов и экземпляров в ArchiMate"
4.1 Вы изучаете модель, которую прислали консультанты, и видите, что в ней есть элемент, который не связан отношениями с другими элементами на диаграмме. Что лучше всего сделать?
А) Несвязанные элементы модели бесполезны, вся идея моделирования заключается в том, что в мире все со всем связано, а модель должна показывать самые важные связи. Консультанты ошиблись, надо вернуть им модель на доработку.
Б) Несвязанные элементы бесполезны, но возможно, что этот элемент связан с другими элементами в других описаниях, надо зайти в окне "Свойства" во вкладку "Анализ" и проверить существующие связи. После этого задать консультантам вопрос, зачем они поместили этот элемент на диаграмму, в чем была идея.
В) Не связан и не связан, я тоже рисую слайды из кубиков и блоков без стрелочек между ними. Самое главное - что в голове и рассказываешь, а не картинки.
4.2 Вы заходите в модель и хотите добавить атрибут для объекта "Готовый автомобиль в сборе". Выпадает целый большой список атрибутов. Чем будете руководствоваться при выборе нужного атрибута?
А) Своим опытом. Обычно я знаю, какие свойства мне нужны для объектов, за свою жизнь я сделал множество различных табличек Excel.
Б) Я подумаю, какие отчеты мне нужны, какие решения я буду принимать и какая информация мне нужна для принятия этих решений. Исходя из этого и выберу атрибуты или даже добавлю новые.
В) Обзвоню всех, кто принимает решения по готовым автомобилям, уточню, какая информация им нужна и какие решения они принимают. Исходя из этого добавлю все необходимые атрибуты, а не только те, которые нужны мне.
======================
Правильные ответы.

1.1 Б) 1.2 Б) 1.3 Б) 1.4 А) 2.1 Б) 2.2 Б) 2.3 А) 3.1 А) 3.2 Д) 3.3 А) 3.4 А) 4.1 Б) 4.2 В)

вторник, 23 апреля 2019 г.

Гуманитариям здесь место. Как работодатели Кремниевой долины разводят гуманитариев на 100-часовую рабочую неделю


Сколько надо денег для счастья? Около 75,000 долларов.
http://content.time.com/time/magazine/article/0,9171,2019628,00.html
Есть, правда, и другой анализ, который говорит, что счастливых людей почти нет, потому что для счастья надо 100 млн., но при этом описывается семья очень далекая от семей таких миллионеров.
http://www.townandcountrymag.com/society/money-and-power/a13528013/how-much-money-you-need-to-be-happy/

Остановимся на 75,000 долларах, около 250,000 рублей на руки в месяц. Похоже на правду, реально больше для комфортной жизни не нужно. Сколько получают разработчики Кремниевой долины? От 130 до 200+ долларов, в 2-3 раза выше порога счастья.

Сколько зарабатывает СЕО в Кремниевой долине? В 20-200 раз больше рядовых сотрудников:
https://www.bizjournals.com/sanjose/news/2018/12/13/tech-median-pay-ceo-ratios-splunk-goog-ea.html
 
Теперь держим все это в уме и критически рассмотрим основной тезис статьи Forbes:
"В 2015 году американский Forbes выпустил статью с провокационным заголовком «Технарям тут не место: как гуманитарии захватывают Кремниевую долину». Специалисты с дипломами психологов, философов, филологов и маркетологов тогда начинали всерьез конкурировать за высокие должности в технологических корпорациях и стартапах с инженерами и математиками. Именно гуманитарии все чаще помогали правильно упаковывать и продавать продукт таких компаний, доносить до пользователей ценность и принципы бизнеса."

Я бы сформулировал основной тезис по-другому.
"HR Кремниевой долины не могут найти инженеров на топовые позиции. Приходится довольствоваться гуманитариями. Наступит ли конец эпохе громадных зарплат СЕО?"
Есть два типа инженеров - те, кто основал успешный стартап и те, кто в нем работает. Те, кто основал стартап, получили свои миллионы и десятки миллионов при выходе и обычно богаче менеджеров, которых нанимают. Это закон жизни, собственники обычно богаче менеджеров, особенно в конкурентной экономике. И вот тут есть хитрый мыслительный трюк, к которому прибегают авторы статьи. Они говорят, что приходит историк или выпускник либерал артс на позицию СЕО и начинает рулить организацией. И это называется "гуманитарии захватывают Кремниевую долину". Давайте посмотрим на факты.
Инженер-основатель создал продукт и вывел его на рынок. Получил инвестиции несколько раз, расширил рынок, получил с бизнеса поток денег, достаточный для того, чтобы кормить разработчиков и продажников, а потом и COO+CEO с суммарной зарплатой от 3,0 млн. Это все сделал инженер. Если инженер не заработал бы этих денег, то МВА с либерал артс бы к нему не пришел. Они не работают за идею, в отличие от инженеров.
К этому моменту в компании работает кучу народа и инженер-основатель настроил процессы и ИТ-системы для поддержки этой работы. Сделал оргдизайн и создал ИТ-ландшафт. Либерал артс и историк не способен это сделать.
Инженер-основатель вместе со своими продажниками договорился о ключевых партнерствах и сотрудничестве. Иначе откуда деньги и продукт?

Итого - выпускник либерал артс приходит в бизнес, который создал инженер, работает с людьми, которых нанял инженер, по контрактам, которые подписал инженер, с инвесторами и советом директоров, с которыми выбрал работать инженер, продает продукт, который создал инженер, в ИТ-системах и по управленческой отчетности, которую создал инженер. Все вместе это называется "гуманитарии захватывают Кремниевую долину". Есть некая ирония, не правда ли?

Разберем этот тезис с другой стороны. В основном тезисе статьи Forbs есть пресуппозиция "раньше СЕО в Кремниевой долине чаще были инженерами". Если бы доля инженеров в топ-менеджменте не менялась за последние годы, то зачем же было тогда писать про "захват"? Захват рынка - это вытеснение конкурентов. Захват должностей гуманитариями - это вытеснение инженеров. Все логично.

Это не захват, это добровольная отдача топовых позиций инженерами гуманитариям. И за этим стоит обычный расчет. ОК, ты зарабатываешь 150,000 и этот заработок стабильный, ему ничего не угрожает, мир становится все более технологичным, спрос на инженеров растет 20 лет и будет расти дальше. Уровень загрузки отделов разработки 98% доказывает этот тезис с легкостью. R&D был и остается узким звеном современного бизнеса. Компьютер заболтать и уговорить работать нельзя, надо знать, как он работает. До какого возраста можно работать инженером? Я буду консервативным, пусть до 70. Пусть ничего серьезного в здравоохранении и продлении жизни за 50 лет не произойдет. Инженеру с опытом 30 лет, впереди 40 лет доходов 200,000. Ожидаемый совокупный доход 8 млн. Средний срок СЕО на должности - пусть 3 года, с зарплатой 2,5 млн. и выходным пособием пусть 10 млн. Сравнимые деньги, но это постоянные командировки, стресс, 100-часовая рабочая неделя и токсичное окружение. А потом ты опять либерал артс и идешь кататься на серфе и писать мемуары. Потому что инженеры придумали цифрового СЕО, который бьет живых СЕО в 90 случаях из 100, а большего и не надо, дальше работает статистика и капитал.

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

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

Ну, удачи, пацаны. Берегите здоровье, оно вам понадобится.

понедельник, 22 апреля 2019 г.

Работа с человеческим фактором при реинжиниринге предприятия


Юрий основал компанию в начале 90-х, она быстро росла и стала успешной. Юрий нанял кучу специалистов по продажам, закупкам, логистике, маркетингу и ИТ-шников. Появилась специализация, регламенты, оргструктура и зоны ответственности. Все шло нормально пока не начинались кризисы. В кризис все вокруг менялось так быстро, что старые методы управления переставали работать и Юрий дни и ночи напролет проводил в компании, раздавал указания, потому что процессы спокойного времени просто не давали нужного результата. После кризиса 2008 года Юрий нанял консультанта по оргдизайну и тот ему объяснил, что любая подстройка организации под изменившиеся внешние условия требует устраивать общение всех лиц, принимающих решения в своей области со всеми другими ЛПРами. Понятно, что до маразма не доходим и с уборщицами сбытовую политику компании не обсуждаем, но все равно общения во врем реорганизации будет много. Консультант это сформулировал как принцип: "Сложность системы управления должна по мощности соответствовать управляемой организации. Мы, говорил, он, не можем поставить движок от Опеля на Мерседес, и не можем посадить тебе людей, которые только в ларьке торговали".
И Юрий стал перестраивать организацию, стал устраивать общение всех со всеми. Оказалось, что никто перестраиваться не хочет, всем и так нормально. Зарплату платят, премии есть, подчиненных становится все больше. Юрий опять вызвал консультанта и тот ему объяснил, что это работает так называемый эффект "функциональных шахт", когда все делают свое дело, и их не волнуют чужие проблемы, своих хватает. На вопрос Юрия как же выгнать людей из этих шахт, консультант ему ответил, что надо:
  1. Напугать.
  2. Показать, куда надо бежать.
  3. Получить согласие бежать вместе.
Другими словами, чтобы перестроить организацию надо:
  1. Рассчитать системные эффекты сохранения текущей ситуации, показать, что всем будет плохо.
  2. Показать организационно-техническое решение и план его развития, например, ту же дорожную карту.
  3. Создать ролевую модель взаимодействия, которая позволит выполнить этот план развития предлагаемого решения. И уговорить всех ЛПРов на эту новую схему взаимодействия, то есть на реорганизацию.

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

Все стало слишком сложно, и Юрий опять пригласил консультанта. В этот раз консультант пришел не один, а с двумя помощниками. Был длинный обстоятельный разговор, в результате которого консультанты выдали три рекомендации:
  1. Нужно ввести мониторинг отчетности. Надо создать панель показателей, по которой можно будет отследить не выполнение функций, как это сейчас, и не только обращать внимание на финансовые показатели, как Юрий привык. Панель показателей должна измерять бизнес-модель организации, качество клиентских сервисов, и простраивать причинно-следственную связь от уровня клиентского сервиса к ключевым процессам, от которых этот уровень сервиса зависит. Консультанты сказали, что таких процессов в компании Юрия всего три, панель будет небольшой.
  2. Нужно описать ролевую модель взаимодействия в явном виде и требовать от начальников исполнять свои обязанности строго по ролям, которые на них назначены. В первую очередь это важно при подготовке и проведении совещаний, именно совещания были общей больной точкой. Для описания ролевой модели взаимодействия консультанты предложили создать модель бизнес-архитектуры предприятия и связать ее с картами ИТ-ландшафта, которые недавно создал новый ИТ-директор.
  3. Нужно ввести управление знаниями, выделять ключевые знания людей о том, как работает бизнес, и записывать их в базу знаний. Только это должны быть не регламенты и даже не вики, консультанты сказали, что все это не работает. Они порекомендовали создать связанную модель бизнес-архитектуры предприятия с графовой базой данных neo4j, в которой-то и вести все знания о том, как работает бизнес. И даже показали работающий вариант. Все оказалось совсем не сложно и не страшно, с этим явно бы справились и текущие подчиненные https://neo4j.com/use-cases/knowledge-graph/
     
     

Все было понятно  звучало просто, но пока все вместе не заработало, прошла куча времени. Но дела наладились, Юрий опять стал ходить в отпуск, мрачность и суровые шутки ушли, и он опять стал встречаться с немногими друзьями, которые еще остались в Москве. Кризис коснулся многих, дотянулся самыми разными путями. И на салфетке в ирландском баре он описал всю концепцию:
"Оперативная обстановка должна быть на карте, коллективное обсуждение ведется только по этой карте".
  1. Построить карту территории бизнеса, учесть в ней бизнес-модель.
  2. Использовать карту для управления коллективным обсуждением, обновлять карту по мере поступления новых данных.
  3. Должностные инструкции и поручения оформлять как чек-листы, делить участки карты с подчиненными.

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

четверг, 18 апреля 2019 г.

Голдратт и цифровые двойники организации

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


Исходник модели ArchiMate. Инструкции по установке русифицированного моделлера Archi здесь.

понедельник, 15 апреля 2019 г.

Если вы хотите больше пользы от департамента ИТ, его надо вывести из подчинения финансовому директору


Считает Грегор Хохпе, технический директор по облачным вычислениям в Google. Грегор написал книгу "37 вещей, которые знает один архитектор о цифровой трансформации", в которой описал свои находки за время работы старшим архитектором в страховой компании Allianz с годовой выручкой 130 млрд. Евро, это в 7 раз больше, чем весь рынок страхования России, по данным KPMG https://assets.kpmg/content/dam/kpmg/ru/pdf/2018/07/ru-ru-insurance-survey-2018.pdf. Грегор работал разработчиком в Google и закончил Стэнфорд по специальностям Computer Science и инженерный менеджмент (MSEM). Его профиль https://www.linkedin.com/in/ghohpe/ 

"Обычно ИТ заканчивается на офисе ИТ-директора (CIO, chief information officer). Этот человек распоряжается всем бюджетом ИТ и большинство людей в ИТ в конце концов подчиняются ИТ директору. Это довольно сложная работа. Куча людей шутят, что CIO расшифровывается как career is over, карьера закончена. Это не смешная шутка, потому что это очень сложная работа, особенно сейчас. Вам надо снижать издержки и внедрять инновации". 


Расшифровка выступления.

Спасибо, что пришли послушать мой 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-х, которая понятна руководству. Руководство поймет такую стратегию. Но вам еще надо, чтобы исполнители поверили в такой план развития. И для этого вам надо, чтобы этот план развития отражал те штуки, которые у вас есть.
Говорят, что архитектор больше похож на садовника. Отлично, метафора садовника. В саду растут сорняки и вам надо их выпалывать, потому что они растут быстрее полезных растений. И я приведу еще один простой и понятный пример того, что такое стратегия.
Что такое план развития и как правильно гармонизировать. И в этом случае ситуация, которая описана на левой части диаграммы, была большой проблемой для ИТ, потому что приложения были сложными для изменения. Приложения ограничивали возможность экспериментов наверху, где бизнес как раз и хотел гибкости в части продуктовых линеек и бизнес-моделей. А приложение не могло обеспечить этой гибкости. С другой стороны, внизу приложение было крайне разнообразным, оно работало на всех видах аппаратного обеспечения и мейнфреймах, Linux, Windows, я действительно имею в виду, что там было все что угодно. Так что это был худший случай, когда внизу у вас разнообразие, которое вы оплачиваете, и эта инфраструктура ничего не дает вам в плане вариативности бизнес-модели. Вы не можете продать полис страхования, потому что поддержка бизнеса и вовлечение клиента находится на разных серверах.
Так что правильной стратегией гармонизации была гармонизация внизу. Убрать разнообразие инфраструктуры, перевести все на Linux, поместить в контейнер, автоматизировать развертывание и функционирование и резко уменьшить платформу. Джеймс Люис только что рассказал о роли платформ. Вам не нужна гармонизация, вам нужна возможность гибко экспериментировать с бизнес-моделью, не так ли?
Было бы глупо гармонизировать все сверху донизу, потому что разнообразие наверху — это ровно та штука, которая двигает бизнес. Поэтому ваше корпоративное управление ИТ должно четко понимать, где надо затянуть винты потуже, а где их ослабить и это очень важный момент в практике архитектуры предприятия. А то вы получите ситуацию, когда во всех частях организации появятся люди, которые будут гармонизировать все подряд, так как кто-то когда-то им сказал, что гармонизация — это хорошо, потому что она экономит деньги. Но гармонизация — это одновременно плохо, потому что она убивает бизнес. Если вы проведете гармонизацию там, где она не нужна, то вы сделаете ситуацию хуже. Все это кажется очень простым, но проблема в том, что ваш план может быть отличным, но реальность будет отличаться от плана. И с этим ничего нельзя поделать. Знаете, у нас есть поговорка в Германии, что если реальность не соответствует планам, то это проблема реальности, а не планов. Вы столько времени потратили на составление планов, они не могут быть плохими по определению.
К сожалению, с реальностью очень сложно спорить, она может быть очень упрямой, вы ее не переспорите. И тут опять нет никакой магии, вам нужна корректировка курса. И для того, чтобы корректировать курс, вам нужна гибкость, вам нужна способность направлять развитие.
Но кроме того, вам нужна еще и четкая цель, потому что если у вас нет цели, и вы можете рулить, вы будете ходить кругами. Поэтому идея иметь гибкость на уровне организации хороша только в том случае, когда у вас есть четкая цель. И на этом пути вы обнаружите кучу вещей, которые вам не понравятся, но лучше их обнаружить, чем не обнаружить. И это приводит нас к концу рассуждений про гармонизацию. Практика архитектуры предприятия нужна не только для того, чтобы создать модель архитектуры, но и для того, чтобы создать компетенции по выявлению архитектуры предприятия и разработке моделей архитектуры в вашей организации.
У вас никогда не будет достаточно людей с достаточным набором навыков, вам надо выращивать таланты внутри организации.
Так что у вас, с одной стороны, есть стимул, чтобы осваивать распределенную практику архитектуры предприятия, а с другой стороны, так и надо делать, это правильный способ. И ваша роль как архитектора предприятия заключается в том, чтобы провести людей по этому пути. Это не игра "кто первый заберется наверх", это игра "кто первый забрался, тянет остальных". И это просветительская функция, функция тренера, инструктора на должности архитектора предприятия. И про это важно не забывать, потому что именно это подпитывает цикл, вам понадобится помощь остальных архитекторов. Вам нужна их поддержка, без нее вы потеряете базис. Линда хорошо про это говорила ранее "у меня такие классные идеи, мне не нужна помощь остальных", но такой настрой — это кратчайший путь в никуда.
Вот такая цепочка создания ценности.
И есть три вещи, которые должен делать архитектор предприятия, чтобы эта цепочка создания ценности заработала:
- Связи
- Абстракции
- Принятие решений

И чтобы объяснить суть работы архитектора предприятия, я покажу мое любимое определение этого термина. 

Это очень простое определение и теперь, посмотрев на эти уравнения, я думаю, все понимают суть работы архитектора. Это формула Блэка-Шоулза для оценки стоимости опционов, за которую выдали Нобелевскую премию. 
Когда вы разговариваете с бизнесом и объясняете, в чем суть работы архитектора, то большинство людей в бизнес-подразделениях легко поймут эту аналогию, особенно в финансовых организациях. Вы просто говорите им, что вы продаете опционы, так? Что дает практика архитектуры? Она дает гибкость, она дает возможность менять свои решения в будущем. И это опционы. 
Собираюсь я переместить приложения в облако или не собираюсь этого делать? Нужен мне такой опцион или нет? Надо ли мне иметь возможность динамически масштабировать приложение или это не нужно? Я могу продать такие опционы, они называются архитектура без состояний и масштабируемая архитектура. Эти опционы стоят денег, точно также, как и опционы на финансовых рынках и эта формула вычисляет стоимость такого опциона. За этот опцион надо заплатить, потому что он позволяет отказываться от своих решений в будущем и это имеет ценность. Я не знаю точно, что мне понадобится, поэтому я покупаю опцион, он дает мне возможность пойти в будущем как налево, так и направо, что имеет для меня ценность. Можно построить деревья решений и легко посчитать стоимость таких решений и стоимость опционов. И это основная штука, которую делает практика архитектуры предприятия и ключевая дискуссия, которая происходит между архитектором предприятия и бизнесом, заключается в следующем. Вот список опционов, которые могут оказаться для вас полезными. Давайте обсудим, какие из этих опционов стоит купить и почему. И дальше надо сделать еще одну вещь, которая на самом деле показана на этой формуле. Эта вещь заключается в том, что в меняющейся среде стоимость опциона увеличивается. Это легко представить себе. Если вы знаете абсолютно точно, что произойдет, например, вы разрабатываете приложение, которыми будут пользоваться 10 человек и это всегда будут 10 человек, то опцион на то, чтобы сделать это приложение масштабируемым, ничего не стоит. А вот если вы делаете Интернет-приложение, у которого сегодня 10 пользователей, а завтра 10 миллионов пользователей, то опцион на масштабирование будет очень ценным. 
Мы сейчас живем в очень изменчивом мире, в котором меняется окружение в бизнесе, меняются технологии, поэтому стоимость опционов увеличивается. И именно так стоит объяснять бизнесу, почему надо вкладывать больше ресурсов в разработку архитектуры предприятия. Потому что стоимость опционов, в которые они вкладывают деньги, и которые вы как архитектор предприятия продаете, увеличивается. И люди из бизнеса поймут эту логику. 
Три вещи, которые делает архитектор. 
Связи. Есть одна простая истина, которую я вам сейчас открою. Никому нет никакого дела до архитектуры. 
Неожиданное заявление с моей стороны, не правда ли? Архитектор говорит, что никому нет никакого дела до архитектуры. От этого знания становится грустно, не так ли? Старший архитектор говорит, что никому нет никакого дела до архитектуры. Потому что заказчики не видят вашей архитектуры. Ваши заказчики видят, как ваша система себя ведет. Быстро ли она работает? Работает ли она 24/7 или она все время ломается? Способны ли вы быстро ее дорабатывать? Если вы посмотрите на левую и на правую системы, то они состоят из одинаковых кусков А, В, С, Д. В чем же между ними разница? 

Разница между этими системами в том, что они по-разному соединены. Связи между этими кусками разные. И если я спрошу любого архитектора, одинаковые ли свойства у этих двух систем, то он сразу выдаст мне минимум 10 различий между этими вариантами. У варианта, представленного слева, проще делать замены, но задержки могут быть больше, если один компонент выходит из строя, то вся система перестает работать, а у системы справа путь сигнала короче, но связность решения больше, сложнее производить замены и т.д. и т.п. Эта те штуки, которые мы делаем как архитекторы. Эти два варианта находятся на противоположных концах спектра возможных решений несмотря на то, что они состоят из одинаковых элементов. Как я это обычно объясняю с помощью простой метафоры . Пусть у нас есть ингредиенты - А, Б, С, Д. Помидоры, мука, тесто, сыр, колбаса, оливковое масло. В случае с софтом это база данных, сервер, сеть, фаерволл, но есть один тонкий момент.

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

Архитектор должен быть хорошим поваром, а что значит быть хорошим поваром? Быть хорошим поваром означает уметь правильно использовать ингредиенты. Если вы пойдете на рынок и купите хорошие помидоры, то это еще не значит, что вы вкусно покушаете. То же самое в ИТ, приобретение хороших ингредиентов — это хорошее начало, но приготовить вкусную еду, сделать хорошую архитектуру означает правильно все связать. Хорошая архитектуры живет в правильных связях. 

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

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

Связи играют основную роль и связи живут в разных измерениях - между слоями, между системами и организационные связи. 

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

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

И модели являются самыми важными инструментами для архитекторов, мы принимаем по ним решения, потому что реальность слишком сложная. Тут надо понимать очень важную вещь - модель не является реальностью. Она и не должна быть реальностью, потому что суть модели в том, чтобы упрощать реальность так, чтобы можно было отвечать на какой-то вопрос и принять решение. Но, с другой стороны, это означает, что для того, чтобы найти правильную модель, вам надо понять, на какой вопрос вы отвечаете. Поэтому вот вам классический пример с 4 различными картами. Они очень разные, они отображают одну и ту же систему - планету Землю. Но они выглядят очень по-разному. И причина, по которой они так по-разному выглядят заключается в том, что они отвечают на разные вопросы. Как мне пойти в пеший поход из пункта А в пункт Б или как мне проехать на машине отсюда и туда? Разные вопросы. 
Это означает, что когда вы делаете модель архитектуры предприятия, то вам надо понять, на какой вопрос вы отвечаете, чтобы сделать хорошую модель. Или какое решение вы принимаете. Поэтому, когда кто-нибудь просит вас показать архитектуру, то совершенно закономерным уточнением с вашей стороны будет: "На какой вопрос вы ищете ответ? Какое решение вы принимаете?" Вы не должны разрабатывать диаграммы просто так, потому что такие виды диаграмм существуют. Разработка модели архитектуры должна лежать на твердом основании вопросов, на которые вы отвечаете и решений, которые вам надо принять. И можно перевернуть это в другую сторону. Если кто-то показывает вам диаграмму архитектуры, то правильно будет спросить: "Какое решение помогает принять эта диаграмма?" Если вас спросят: "В смысле?" То вы сможете ответить: "Ну как, это же модель реальности, модель нужна для того, чтобы помочь мне принять решение. Если вы показываете мне какую-то модель, то вы разрабатывали ее для поддержки принятия какого-то решения. Какое решение помогает принять эта модель?" И если он не сможет вам ничего ответить, то возможно, эта модель не так уж и полезна. Это пример архитектурной модели. 
Так выглядят модели, которые создают различные инструменты разработки моделей архитектуры предприятия. Как вы видите, в этой диаграмме множество разных соединений. В этой модели вы можете увидеть соединения между практиками бизнеса и техническими решениями. И это основной функционал моделлеров архитектуры предприятия. Это очень полезная штука и это тот функционал, про который люди часто забывают при разработке моделей архитектуры, потому что инструменты разработки архитектуры часто очень сложные. Мы еще поговорим об этом. Дело ведь не в том, какие модели вы создадите в этом инструменте, дело в том, какую информацию вы сможете получить из инструмента, в чем заключается его польза. Инструмент должен помогать принимать вам решения. Если он не помогает вам принимать решения, то создание моделей архитектуры предприятия в этом инструменте — это простая потеря времени и денег.

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

И есть классическая история про индийских кобр во времена колониальной Англии. Это называется эффектом кобры. В то время было много кобр, и эти кобры не были особо дружелюбными созданиями. Британцы подумали: "Как бы нам от них избавиться?" И они объявили награду за поимку кобр. Мы будем платить за каждую убитую кобру и тогда всех кобр переловят и у нас больше не будет этой проблемы. Что произошло на самом деле? Люди просто стали разводить и убивать кобр. Потому что проще разводить кобр у себя на заднем дворе, чем ловить их в джунглях. И когда индусы стали просить слишком много наград за кобр, британцы перестали за них платить. И что сделали индусы? Правильно, они отпустили ненужных им кобр на свободу. Что получили британцы? Они получили еще больше кобр, чем их было до того и потратили на это кучу денег. Такими вещами занимается теория систем, системное мышление. И создание организационных систем сталкивается с точно такими же проблемами.
Когда вы рассуждаете о связях, то очень важно понимать такого рода эффекты кобры. Вам может казаться, что вознаграждать за какие-то действия правильно и хорошо, пока не столкнетесь с эффектами кобры. Это очень важный аспект работы архитектора предприятия.
Решения.
И последний пункт, про который я уже говорил, это про то, как архитекторы предприятия принимают решения. И я часто иллюстрирую этот аспект с помощью такой картинки домика. Является ли такая картинка домика это архитектурой? И в классическом определении архитектуры, эта картинка описывает архитектуру. Классическое определение архитектуры говорит, что архитектура — это элементы состав, структура, ограничения и то, как они соединены все вместе. И картинка домика полностью подходит под это определение. На ней показаны окна, двери, крыша, все на своих местах. Так что картинка подходит под классическое определение архитектуры. Но на мой взгляд эта картинка не проходит проверку по следующему параметру. По параметру решений. Эта картинка не показывает никаких принятых решений. У меня есть хороший вопрос для проверки. И этот вопрос не: "Является ли это архитектурным описанием или нет?" Вот этот вопрос - заплатили бы вы за такой дизайн своему архитектору? И ответ скорее всего что нет, не заплатили бы. В этом дизайне нет никаких решений. Это стандартный рисунок. 
И у меня есть другой вариант похожего рисунка, такой же домик с покатой крышей. Причина, по которой крыша такая острая заключается в том, что дом расположен в холодном климате, в котором выпадает много снега. И снег попадает на крышу, скапливается там и может просто проломить крышу, сломать балки. И поэтому крыша очень покатая, чтобы снег съезжал вниз. То есть тут принято решение и по поводу этого дизайна я могу сказать, что здесь показана архитектура. И за такой дизайн вы готовы заплатить своему архитектору. Если вернуться обратно к ИТ, то основной проблемой при принятии решений по поводу ИТ-систем является то, что люди просто теряются в сложности этих систем. И им нужна дисциплина принятия решений. Принимать решения не так уж и сложно. У вас есть варианты, опционы, вам надо выбрать один вариант, выбрать опцион, у вас есть четкое понимание того, какие варианты, какие опционы для вас предпочтительны. Вы знаете, что вы хотите автоматизировать, что должно быть в облаке, что должно работать на открытом ПО, у вас есть принципы, есть стратегия, вы понимаете, что вы выбираете, что для вас является наилучшим вариантом. Проблема в том, что за всей сложностью систем люди про это забывают. И вам надо возвращаться к основам и принимать обоснованные решения и следовать дисциплине принятия решений. И тут важно понимать, что решение, в котором нет выбора между улучшением одного параметра за счет ухудшения другого, не является истинным решением. Оно не очень-то и полезно. И такое часто встречается в ИТ, когда люди выбирают между чем-то осмысленным и чем-то абсолютно дурацким с помощью скоринговых таблиц. И они смотрят на баллы, которые набрал каждый вариант, и говорят: "О, смотрите, это решение намного лучше, у него больше баллов". Это бесполезное решение. В полезном решении вы обмениваете одни характеристики на другие характеристики. Мы можем сделать крышу покатой, чтобы снег скатывался с крыши вниз, но в этом случае мы должны сделать выбор. Вы не сможете найти икеевскую мебель, которая бы поместилась у вас на чердачном этаже. Потому что на чердаке не будет стен, там будет покатая крыша. В этом решении есть выбор. Если вы не делаете выбор одних характеристик в пользу других, то скорее всего, ваше решение не очень-то и хорошее. И если у вашего решения есть отрицательные последствия, то вам нужна стратегия, чтобы уменьшить эти отрицательные последствия. И это ваша обязанность как архитектора сказать, что да, мы понимаем, что если мы переходим на гибридные облака, мы увеличиваем сложность и вот что мы делаем по этому поводу.

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

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

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

https://www.enterpriseintegrationpatterns.com
https://leanpub.com/37things