Digital Book. Книга вторая
Шрифт:
Считайте это законом Благирева. Как бы вы не старались, на 100 % вам не удастся оцифровать компанию, т. е. заменить всех людей, или отказаться от бумаги, перестроить все процессы (например бухгалтерию и тд). У каждой компании, есть свой технологический предел, то есть те технологии, которые она сможет использовать, потянуть и не забросить.
Вот если вы не Яндекс, то вы все равно что-то купите, это нормально, например у вас будут использоваться всякие инструменты типа ВРМ, роботизации и т.д. Есть одна очень интересная компания, называется она South Korea Telecom или просто SK Telecom. Ее очень любили приводить в пример в одной замечательной большой российской компании. Так в 2015 году они выделили отдельное подразделение, которое должно было заниматься только инновациями – SK Planet. За 2 года оно показало выручку в 2 млрд долларов, но со старым SK Telecom ничего не произошло. Таких примеров много, поэтому если вы изначально не строите цифровую компанию,
1. Способность внедрить все технологии, которые свойственны этой категории компаний
2. Наличие денег и ресурсов, чтобы это сделать
3. Наличие компетенций для управления этими технологиями.
4. Время в течении, которого вы сможете управлять технологией.
Действительно большинство компаний, если посмотреть с ИТ точки зрения напоминают кладбища технологий, которые кто-то пытался внедрить, у него не получалось и он бросал. Как – то раз я спросил одного своего знакомого, почему он меняет каждые 3 года работу в сфере BI (Business Intelligence) и работы с данными. Его ответ оказался интересным, “Слава, потому что через 3 года, управлять данными становится для меня очень сложным, что я не знаю, что с этим дальше делать”. Вот он технологический предел, его предел это 3 года. В итоге он запускал технологию и переходил в другую среду. Хотя так еще бывает часто из-за политики. Сама технология она аполитичная, это скорее механика. Поэтому программисты и инженеры не очень любят играть в политику и очень любят математику, потому что она точная и дает двусмысленного трактования. Но если в организации правит политика, то любая технология станет жертвой и пополнит количество трупов на корпоративном кладбище. Как-то лет 10 назад, работая в большом красном банке у меня стояла задача сделать сделать автоматический расчет CIR (Cost Income – отношение прибыли к расходам) по клиенту. Тот самый, о котором я писал раньше. Так вот когда я его проектировал, то изучал хранилище данных и случайно наткнулся на таблицы и процедуры, которые считали похожие показатели. Быстро изучив, я понял, что они вообще никем не используются, более того их расчет выключен и не работает. Открыв программный код расчета витрины показателей, я удивился, потому что он был правильным. Все операции по клиенту загружались в определенные таблицы, дальше на основании комбинации номеров бухгалтерских счетов и регулярных выражений (это формальный язык для работы со строками текста) и функции RegexpLike в informatica, я быстро воссоздал работающую схему. Да она считала только 30 клиентских операций (из 124 которые мне нужны были), но я наше основу. Дальше я попросил ребят из своего отдела, дополнить этот описанный механизм, ребята дополнили, потом оптимизировали и он заработал. Очень прикольно заработал. Жалко только заказчик этого функционала после его запуска, сказал, что он ему не нужен. Так после воскрешения он снова вернулся на кладбище:). Даже было немного грустно, и тупо. А самое смешное, что руководитель организации даже не подозревал в то время, что у него есть такой крутой функционал. Поэтому прежде, чем внедрять новую технологию сходите на свое кладбище, побудьте Индиана Джонсом или Ларой Крофт. Откройте могилы похороненных проектов, там могут оказаться очень крутые артефакты. Я понимаю, что звучит это странно, но в кино обычно всегда самые крутые штуки, волшебные посохи, мечи кладенцы находили в каких-нибудь могилах. Тут такой же принцип. Я помню, как нашел в одной большой телеком компании, в DPI платформу в гараже, CMS платформу, которая оказалась в лидерах в квадрате Garnter’a.
С другой стороны, большинство Enterprise архитекторов (это те люди, которые определяют какой набор технологий должен присутствовать в компании), просто под копирку пытаются копировать различные рекомендации. Вы, наверное, удивитесь, но фактически каждый тип компании в мире, уже был проанализирован, расписан, и создан список технологий, которые нужно ставить для каждого такого типа. Так появились модели BIAN (Banking Industry Architecture Network – ODA (Open Digital Architecture, Открытая Цифровая Архитектура от Telecom Forum,), или ODF (OPen Digital Framework для раскрытия потенциала 5G, от того же Telecom Forum’a)
https://www.bian.org
https://www.tmforum.org/oda/
Их очень много. Для каждой индустрии, есть свой blueprint (чертеж в переводе означает), который поможет вам понять, что в рамках вашей индустрии в мире принято. Конечно все эти чертежи, нужны для того, чтобы разобраться в том, какие технологии придумали умные люди для вашей предметной области и начать с ними работать. Главная цель их, это сократить время на внедрение ваших идей и получение результата. Будь то, производство товара или услуги, до тестирования идей. Поэтому не нужно ничего придумывать, просто берите, что то что придумали до вас и адаптируйте под себя. Вот, например карта технологий, которую я когда-то сделал для своих студентов, здесь я попытался, расписать все виды технологий, которые могут быть в компании. Назову ее B-Map, от Blagirev карта:). Если что это шутка:).
Итак, давайте подведем итог:
1. Каждая технология состоит из технологий попроще, как пасхальное яйцо.
2. Все технологии в общем сводятся к тому, чтобы давать команды машине
3. Команда – это набор сигналов 0 и 1, которые в физике достигаются через управление напряжением
4. Машина это набор транзисторов,
5. Каждая технология рассчитана на определенную аудиторию пользователей
6. Обычный программист, может разработать любую технологию самостоятельно, вопрос только в количестве часов и качестве результата.
7. Большие цифровые гиганты автоматизируют ИТ процессы, и на этом же уровне автоматизируют бизнес-процессы. У них нет никаких BPM систем и прочего.
8. Есть компании, которые никогда не смогут стать технологичными, у них свой путь и нужно это понимать, поэтому у них будет свой ассортимент технологий. Это нормально. Нет никаких Enterprise паттернов и шаблонов, как должна выглядеть архитектура предприятия.
Правила разработки (Code Convention)
Я решил оставить на десерт очень интересную тему, как “Правила разработки” или его еще называют “Соглашением разработки”. Смотрите, если вы хотите создавать очень большие программы, например написать какую-нибудь платформу, то вам потребуется обеспечить, чтобы ваши команды разработки (внутренние и внешние) понимали результат действий друг друга и то, что они будут писать. Чужой код напоминает книгу, написанную на другом языке или диалекте. Даже если вы будете знать язык программирования, то для того, чтобы осознать смысл всех алгоритмов и конструкций, которые описаны в коде, вам потребуется их расшифровать и изучить. Так обычно происходит, если исследователь пытается прочесть книгу на древнем мертвом языке. Он, например знает, что означают символы, но не знает фонетически, как правильно произнести и начинает гадать методом тыка. Любой программный код, это набор команд, которыми вы описываете сценарий задания машине, что ей сделать, посчитать или сложить, что вывести на экран, куда сохранить результат вычисления и т.д. Для каждого вычисления вам нужна переменная, которая будет связана с этим результатом или параметром, который будет использоваться для вычисления. Например, у вас считается кредитный рейтинг платежеспособности по разным возрастным группам и одним из параметров вы возьмете параметр “возраст”. Допустим мы назовем его “a”. Но не в каждом языке программирования машина поймет, что такое a и какие значение оно сможет принимать, поэтому нужно задать определение более четкое. Например,
Часто многие языки начинаются вот с похожих конструкций begin end, которые означают начало и конец выполнения программы. a: integer означает, что параметр a будет иметь тип integer, этот тип во многих языках означает “целое положительное число”. Вообще задумайтесь, как много общего во многих языках программирования, как и в обычных языках. Так, например тип integer или int практически во всех есть. Он обусловлен не тем, что одни и те же люди создавали языки, а тем что такой тип “органически необходим всем”. То есть он как золотое сечение, который всегда будет, потому что алгоритмы на этой планете требуют этот тип для работы. Есть, например другой тип float. Это тоже числовой тип, но с плавающей точкой, т. е. это дробное число. Ну так вот вернемся к “а”. Вам понятно, что “a”, это age или возраст? Конечно нет. А если вы например передадите вашу программу другому программисту исследователю, то поймет ли он что такое a? нуу… если вы ему не скажете, или не дадите инструкцию или не укажите комментарий прямо в коде, то точно нет. Получается сторонам нужен некий свод правил, чтобы можно было передавать друг другу информацию описанную в виде программного кода. Ну и обеспечить преемственность для будущих поколений. Я немного пишу тут как археолог и историк, но так оно и есть. Чтобы ваш код прошел через поколения, должны быть правила его прочтения. Наша современная письменность прошла через поколения, потому что был алфавит, орфография, грамматика и фонетика, которые кто-то придумал. Это все некие правила. Они и называются Code Conventions (Код конвешионс). Если провести параллель, между алфавитом и обычными языками, то фактически это алфавит и правила его использования – орфография и грамматика. Вы тут сейчас такие, наверное, скажете, “воу воу полегче парень! Ведь в языке программирования, это вроде все есть”. Не совсем так. Этого там нет, машине можно скормить все что угодно, она понимает только 0 и 1 и поэтому живет в бинарном измерении, а мы другом измерении. Даже если в языке есть минимальный набор правил написания кода, который называется синтаксис, то нужно помнить. что задача синтаксиса совершенно другая чем обеспечить преемственность программного кода. Задача синтаксиса всего ли обеспечить конвертацию вашего программного кода в машинный язык.
За свою практику я столкнулся с интересным фактом в отношении code conventions (для простоты я буду называть их Правилами). Так вот не в каждой развитой с точки зрения ИТ организации были Правила. Если эти наблюдения, как – то обобщить, то можно сказать, что Правила мне встречались где-то в среднем в 20–30 % внутри организации и в 1 из 5 организаций в целом. При этом среди эти организаций были большие ИТ бюджеты, солидные ИТ руководители, но не было сформировано ИТ культуры и никакого намека на Правила. Это странно. Иногда мне приходилось лоббировать или требовать создания Правил в том числе и со стороны Заказчика. Обычно слышишь много клевых аргументов, почему разработчики не хотят делать программный код по Правилам, они ведь художники:). Самые классные это – “Это первый и последний раз!”, “Мне срочно нужно вывести доработку на бой иначе все сломается”, “я один кто поддерживает эту систему и мне все понятно. не вижу смысла”, ну или “это все для хипстеров. Бессмысленная трата времени”. Но Правила, это основа ИТ культуры, иначе вы будете в заложниках у вашего разработчика, а еще его знание просто потеряются с годами, и никто не сможет понять, а как же проходит те или иные вычисления. Есть программы, в которых тысячи строчек года, если все строки кода будут одинаковыми, все переменные будут просто называться – a, b, c, d и тд, то такой код невозможно будет расшифровать или потребуется очень много. Например, взять шумерские таблички им почти 5000 лет. Вот табличка с письмом царю Лагашу: