Digital Book. Книга вторая

4. Могу ли я использовать самостоятельно для себя разработанную программу на базе СРО?

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

5. Нужно ли мне платить за СРО

Обычно они бесплатные, есть платная версия enterprice поддержки. То есть, если вы хотите поддержку, то покупаете ее, потому что в лицензии СРО есть приписка обычно, что производитель ПО не несет никакой ответственности за результат обработки и работы ПО. Такой вот принцип распространения технологии – “Бери, что хочешь, но на свой страх и риск”:).

Тема использования лицензии стала очень популярна с 2017 года. Даже GitHub ведущий онлайн – сервис в мире по хранению кода (это то место где все разработчики хранят код) разместил в своем интерфейсе привязку к тому, какую лицензию использует проект. Без лицензии вы должны понять, ни одно ПО не может распространяться, иначе оно будет ничейным без автора и тд, и некому будет выставить претензию, если что. Обычно лицензия хранится в файлике license.txt.

Ключевые различия open-source лицензий:

Что такое лицензия copyleft и copyright. Эти выражения можно часто встретить.

Copyright – переводится дословно “право на копирование и воспроизведение” в английском праве. Его символ – это русская или английская буква “С”. Здесь возникают такие вещи, как интеллектуальные права на собственность, т. н. Intellectual Property (или сокращенно IP). Все что связано с лицензией, работе с приложениями и программами, это все работа с IP. Лицензия тут один из инструментов работы с ней. Когда вы видите такой значок, значит этот объект IP защищен необходимыми правами и его просто так нельзя использовать, копировать и воспроизводить. Соответственно термин “copyleft” (читает как копилефт), является зеркальным отражением выражения copyright, которая означает, что можно делать все что угодно. То есть, когда говорят, что лицензия копилефтная, то ты ничем не ограничен и можешь делать все что тебе захочется. В части opensource, или свободно распространяемого ПО не все оказалось copyleft’тным. Поэтому если вы планируете использовать какое-то стороннюю программу у себя в цифровизации, я вам рекомендую самостоятельно изучить ее лицензию. Если это одна из тех лицензий, которые перечислены, то можете ее не читать, ее ограничения кратко перечислены выше. Так или иначе, в каждой лицензии есть своя плата и это нормально. Часто общая стоимость платы лицензии за несколько лет, может превышать стоимость внедрения самого приложения или же может превышать стоимость собственной разработки. Конечно, тут палка о двух концах, заниматься собственной разработкой или нет. Есть адепты только принципа “Я все разработаю сам”, будь то офисная программа или какой-нибудь маркетинговый инструмент. В этом проблема, ведь часто такая затея со временем превращается в спортивное программирование (это такой термин, который означает, что разработка различных алгоритмов на время, которые не имеют практической ценности, да такая вот фигня:), и в этом случае, вы станете заложником вашего спортивного программиста или спортивного ит директора. И беда в том, что это сложно будет понять, ведь для этого нужно понимать, что он делает и зачем. Но теперь у вас есть в руках эта книга заклинаний:). Так вот давайте разберем собственную разработку.

Собственная разработка. За и против

В принципе написать можно все что угодно. Если смотреть на нашу пирамиду, то фактически все известные системы и технологии, например офис, игра “Wolfenstein 3D” или какой-нибудь текстовый редактор были написаны на языках высокого уровня. Когда они появились, мир пошел по пути абстракции, то есть пытаться абстрагироваться от сложной логики машинного уровня, до каких-то простых вещей. Это дало рывок, и все начали писать свои программы, мир захватила лихорадка собственной разработки. На этом начинает строительство наша пирамида технологий. Каждый язык высокого уровня, обладает своими правилами, синтаксисом, инструментами и возможностям. Если посмотреть статистику за 2020 репозитория GIT, это то место, где хранят свой код 90 % всех разработчиков (по – моему мнению). То статистика, следующая:

Но людям оказалось этого мало. Почему? ну, потому что несмотря на то, что языки вроде как высокого уровня и вроде как должны быть понятны людям, оказалось, что не все могут ими пользоваться, потому что они тоже оказались очень сложными для понимания. И вслед за ними придумали еще более абстрактный уровень языка, – DSL (Domain Specific Language), т. е. это язык программирования близкий к человеческому. Иными словами, вам необязательно знать все правила языка, чтобы на нем писать, причем даже вы можете не знать вообще язык, но сможете его прочитать, просто зная соответствующий человеческий язык. Примером такого языка может быть SQL язык для работы с данными. С помощью этого языка нельзя написать программу, но можно написать процедуру для работы с данными, почему он DSL? Ну например о чем этот запрос SELECT PRODUCT_NAME, PERIOD FROM SALES?.. ну если у вас с английским норм, то вы переведете, как “Выбери мне название продукта, период из продаж”, по сути это выборка продаж продукта и периода из таблички продаж. Давайте еще раз попробуем, что написано на картинке?

Это выборка всех клиентов. идите? вам не нужно знать программирование, чтобы в этом разобраться. Язык SQL считается языком бизнес-аналитиков, обычно с помощью него строят всякие отчеты, работают с данными и т.д. Если вам интересно его поизучать, то вот вам классный ресурс, где можно это сделать совершенно бесплатно и там же попрограммировать. Кстати картинка взята оттуда:).

https://www.w3schools.com/sql/

Другим популярным языком, на котором пишется 99 % всех интерфейсов программ и приложений является Java Script, скриптовый язык, который ничего не имеет общего с языком программирования Java, кроме названия. С чем он работает? если SQL работает с данными и таблицами, и всяким объектами данных, то JavaScript работает с очень интересными объектами, которые мы видим почти каждый день – это объекты нашего браузера. Той самой программы, через которую вы ходите в Интернет. Сейчас это все очень логично и интуитивно, но поверьте, лет 20 назад, зайти в интернет и что-то там найти было довольно сложно, поэтому Google и появился. Нужно было всегда знать точное название сайта, когда вбивал его в строку поиска. Это сейчас быстро и понятно, а раньше это была какая-то магия. Ты открывал браузер и не понимал, чего делать дальше:). Сидел и тупил, если не знал, ни одного сайта. Представьте. Поэтому тогда популярные имена сайтов стоили очень дорого, потому что их любой мог запомнить. Так вот вернемся к браузеру (да именно так и называется Chrome, Safari и другие программы, без которых вы не можете жить). Когда вы нажимаете кнопку “Открыть страницу”, то вся страница запускается частями:

1. Сначала ваш браузер запрашивает код страницы (HTML код) у сервера (это тот компьютер, на котором лежит страница)

2. Сервер отправляет этот код вашему браузеру

3. Браузер его запускает (фактически там указаны инструкции, как нарисовать сайт)

4. И браузер начинает рисовать сайт (процесс рисовки называется рендеринг (render), сначала он:

1. Строит все объекты, которые есть на страницы (называются DOM объекты, от слова Document Object Model). Любая кнопка, баннер – это объект и у него есть свойства и с ним можно чего-нибудь делать. Прикольно да?

2. Потом загружает стили для каждого объекта. Стиль, это набор правил, как правильно нарисовать объект – какого цвета, шрифта и т.д. Все стили находятся в таком документе, который называется CSS (Cascading Style Sheet – каскадная таблица стилей, ей Богу не понимаю, зачем так сложно назвали, могли бы проще, например таблица стилей Татьяна)

3. После этого, для отрисовки страницы начинают загружаться недостающие картинки, видео, файлы, все это называется ресурсы.

Соответственно с каждым этим пунктом работает Java Script. Например можно создать кнопку, которая будет что-нибудь делать, или сделать несколько полей для ввода информации и т.д. На примере ниже, простейший пример на javascript, который вы можете немного понять, даже не зная программирование.

Слева написано, что в теле (body) сайта, есть кнопка (button), которая при событии кликнуть по ней (onClick) получает из текущего документа страница, дату и время. Конечно, это немного сложнее чем SQL, но это точно легче чем Си или Java или ассемблер. Программированием на таком языке занимаются front-end программисты (если переводить, то разработчики интерфейсов). Если вы попросите их разработать всю программу целиком, то они не смогут, потому что работа с базой данных это другой диалект, это как испанца попросить поговорить на китайском, поэтому вам нужен будет еще человек, кто знает SQL, знает Java, чтобы все вместе написать. Итого минимум 2 человека, на то чтобы написать какую-нибудь простую веб-программу, то есть ту программу, которую не нужно будет устанавливать и в которую можно будет заходить откуда угодно.

ПРИНЦИП 1: “СОБСТВЕННАЯ РАЗРАБОТКА, НУЖНО МНОГО РАЗНЫХ СПЕЦИАЛИСТОВ

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

ПРИНЦИП 2: “ЗА 1 РАЗРАБОТЧИКА, 2-Х ТЕСТИРОВЩИКОВ И 1ГО АНАЛИТИКА ДАЮТ”

Чтобы ваш разработчик мог что-то писать, надо ему поставить задачу. И обычно это делают аналитики. В части нашего примера с Java Script они разбирают, какие объекты на сайте есть, какие у них свойства, какие они принимают состояния, какие должны быть пользовательские сценарии и т.д. Но и это еще не все, чтобы разработчик работал, его результат кто-то должен протестировать. Есть такой принцип Maker-Checker – Один делает – другой проверяет, чтобы исключить ошибки. Так и тут, конечно, это все выливается в количество людей. Т. е. если вы решили нанять 2 разработчиков, то вам придется еще и 4х тестировщиков взять и 2х аналитиков взять.

Но сперва надо всегда понимать, чем они будут заниматься, ведь купить готовую программу проще, чем содержать штат программистов. Иногда просто хочется заниматься бизнесом и не думать, как же правильно разместить кнопку. Фактически все готовые программы, которыми мы пользуемся когда – то были написаны такими же командами разработки, как продукт на продажу. Только их было гораздо больше, чем 8. Например на Microsoft Office было потрачено миллионы часов разработки. Таких программ, много и все их можно найти на самом верхнем уровне пирамиды, где будет уровень обычных пользователей. Т. е. точно не требующих никаких навыков программирования. Например, Яндекс такси, facebook, whatsapp, photoshop, мы можем ими пользоваться и нам для этого не нужны навыки программирования. Хотя тот же фотошоп требует уже навыков дизайнера.

ПРИНЦИП 3: “ЕСЛИ ПОКУПАЕТЕ ТЕХНОЛОГИЮ, ТО ВАМ ДЛЯ НЕЕ НУЖЕН СВОЙ ПОЛЬЗОВАТЕЛЬ”

У каждой технологии свой пользователь. Например, у платформы роботизации blueprism (это один из лидеров в части роботизации процессов) это будет бизнес аналитик с навыками программирования, т. н. бизнес-технолог. А чтобы работать в операционной системе UNIX, вам нужен Devops инженер или системный администратор (по старинке), кто в ней разбирается.

Каждый слой такой пирамиды основывается на предыдущих слоях, и представляет собой уровень абстракции. Как видите, на определенном уровне появляются базы данных, на каком-то уровне появляются операционные системы и т.д. Чистый программист работает на уровнях до высоких языков программирования. Дальше уже появляются различные фреймворки разработки, появляются такие люди, как DevOps инженеры, которые управляют ИТ системами с помощью других ИТ систем, таких как kubernetes, Amazon, Openshift и т.д. Обычный пользователь живет на самом верху, пользуясь обычными приложениями, например Яндекс такси или оффис. Надо понимать, что каждый такой уровень съедает часть ресурсов машины / времени на перевод команды в формат, команды, который работает на нижнем уровне. Например, Яндекс такси, это работа с базой данных и работа программы на языках Си и Пайтон, которые в свою очередь конвертируются в машинный код. Чем больше уровней абстракции, тем более ресурсоемкая пирамида получится, ведь каждый уровень будет потреблять какую – то часть ресурсов, с другой стороны, вы получите независимость одного уровня от другого. Есть даже отдельный уровень интеграции и управления процессами, где живут такие инструменты, как ВРМ, шина данных, роботизация процессов и т.д. Все эти инструменты дают готовую среду, которая ускоряет процесс разработки и цифровизации процессов. Любая технология требует ресурс, как цветок своего горшка. Если вы решили посадить у себя оранжерею, то придется разориться на кашпо и землю. Конечно, есть компании, кто все старается отдать на аутсорс, вообще всю ИТ функцию, но обычно они плохо заканчивают.

ПРИНЦИП 4: “ВСЕ КОМПАНИИ, КТО ОТДАЛ НА АУТСОРС ИТ ФУНКЦИЮ ПЛОХО КОНЧИЛИ”

Кароче, вот это догма). Аксиома. Если у вас нет амбиций или вы не хотите расширяться, а хотите сохранить свой свечной заводик то отдавайте все на аутсорс, но помните, что со временем это все станет большой проблемой, в том числе и потому, кому будет принадлежать IP (Интеллектуальная собственность).

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

Как видите, здесь очень мало всяких ВРМ систем нет. Даже скриптовые языки практически не используются, только голое программирование. Поэтому в Яндексе нужны программисты C и Python, а обычным бизнес-аналитикам и программистам на ВРМ там практически делать нечего. Такая суровая реальность, если вы посмотрите фильмы про Google и другие компании, то увидите, что в основном там работают программисты, и программисты и. эээ еще раз программисты. Нет конечно там есть всякие инженеры, аналитики, продуктологи, но их меньшинство. Никаких тебе бизнес технологов и т.д. Понятно почему, потому что активом такой цифровой компании являются ее инструменты и системы, и именно в них вкладываются ресурсы и капитализируют их. Такая вот утопия программистов:). Конечно, Яндекс тут съэкономил на других компетенциях, но подойдет ли такая модель другим компаниям?.. все очень индивидуально. При этом что делать всем остальным? ну либо учить программирование, либо идти в обычные компании, в которых есть большой legacy бизнес, который никуда не денется. Почему не денется? ну, потому что “обычные компании никогда не смогут уйти в цифру на 100 %”.

ПРИНЦИП 5: “ДАЖЕ СОБСТВЕННАЯ РАЗРАБОТКА НЕ ПОМОЖЕТ ВАМ НА 100 % ЦИФРОВИЗИРОВАТЬ КОМПАНИЮ. У КАЖДОЙ КОМПАНИИ ЕСТЬ СВОЙ ТЕХНОЛОГИЧЕСКИЙ ПРЕДЕЛ”

Считайте это законом Благирева. Как бы вы не старались, на 100 % вам не удастся оцифровать компанию, т. е. заменить всех людей, или отказаться от бумаги, перестроить все процессы (например бухгалтерию и тд). У каждой компании, есть свой технологический предел, то есть те технологии, которые она сможет использовать, потянуть и не забросить.

ПРИНЦИП 6: “ВАМ ВСЕ РАВНО ПРИДЕТСЯ ЧТО-ТО КУПИТЬ”

Вот если вы не Яндекс, то вы все равно что-то купите, это нормально, например у вас будут использоваться всякие инструменты типа ВРМ, роботизации и т.д. Есть одна очень интересная компания, называется она 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 и какие значение оно сможет принимать, поэтому нужно задать определение более четкое. Например,