Дивизион данни. 2013 година. Ретроспектива

През 2013 година IBS, които тогава, изглежда, създаваха Департамент по данни, помолиха ме да направя такъв брейндамп (изключително на база опита на взаимодействие с корпоративни нефтогазови клиенти) относно проблемната област на Големите Данни, а и на Данните изобщо. Ето, аз попаднах на него след 7 години и се стори забавно. Някои неща са очевидни. Някои не са съвсем верни, но… минаха 7 години.

Писах на английски и ето, реших да го преведа на български. Изведнъж нещо актуално ли е и сега? (Ще преведа булетите, а таблиците ще оставя на английски от мързел. Зеленото е добро, червеното е опасно, синьото — мечта).

Минималните коментари от "днес" ще бъдат оформени с курсив, за да е ясно и различимо.

И така, ДАННИ! Нуждаем се от данни…

Департаментът по Данни – това е Департамент на Кръвта, защото данните могат да се сравнят, например, с кръвта, която тече по вените и артериите на бизнес организма. Въпреки че кръвта е една – организми са различни и затова продуктизацията е много затруднена, но също така представлява и възможност за развитие.

Има хора, на които данните направо им се набиват в очите – това е Ние.
И има хора, които за съжаление не виждат данните в упор. Това, отново за съжаление, са нашите Клиенти!

И така, бизнес постулати…

1. Продаваме на бизнеса, а не ИТ (да ми простят всички IT специалисти), защото решаваме световни проблеми, а и искаме повече пари.
2. Всички бизнес проблеми са концентрирани около тематични индустриални вертикали и ще изискват адекватна специализация..
3. Опити за доказване стоността на "данните" или, което е още по-трудно, стойността на "управлението на данните" за бизнеса – това са вечни страдания и болка. Всъщност, това е като да кажеш на човек, който се чувства добре, и да му кажеш: “Човече, сега ще лекуваме кръвта ти, а, човече, това е скъпо!”
4. Мечтата ми е в рамките на SaaS модела да продавам "извличане на данни" и "анализ" на малкия и средния бизнес, които се навъдиха в 123 облачни услуги с готини интерфейси: управление на проекти, помощен център, счетоводство, CRM, заплати, отчет на времето, маркетинг, … името му, и се затрупаха с данни. Youcalc и Successfactors (вероятно вече не съществуват) е добре!
5. Търсете хора, които обичат да се занимават “crunch” с данни. Те са редки и странни (като гадатели на кафе), но ключови за бизнеса. Поетът, например, може да разбира много добре от корелации.
6. Инженери нужни! Нужни, за да преобразуват проблемите, които Cruncher-ите извадиха от данните в решения. А успехът или неуспехът на решенията зависи напълно от тях.
7. Развитие открит код проектите представляват огромна стойност и дават възможност да се 'събират' сложни решения практически 'от нулата'.
8. Но… не бива да се забравя, че Hadoop е библиотека, а Lucene също е библиотека, а разстоянието между библиотеката и индустриалния продукт е значително!
9. Изградените решения ще трябва да бъдат значително адаптирани, защото модулността и интегрируемостта са ключови моменти.
10. Аджайл (Боже господи) — ключова техника при взаимодействието с клиента и проверката на хипотези, които ще бъдат много.
11. Аутсорсването на всякакво кодиране и UI е особено допустимо и необходимо. Цялата бизнес аналитика и спецификации на бекенда трябва да се оставят вътре и да се разглеждат като ключова компетенция.
12. Хората, взимащи решения от бизнеса, трябва да бъдат постоянно 'информирани' за необходимостта от правилна работа с данните и постоянния търсене на нови начини за тяхното анализиране. Комбинацията от технически и бизнес компетенции на нашите служители ще помогне за повишаване на статуса на цялата организация.
13. Интернет — това е безкраен източник на вдъхновение (тогава котките не бяха толкова много) относно подходите към корпоративното управление на данни, въпреки че задачите и мащабът значително се различават.

Технологичните постулати…

1. Съществува огромен потенциал за развитие в оптимизирането на начина, по който данните се показват на хората. Може да се нарече 'айфонизация'.
2. Въпреки че BI доставчиците твърдят, че пряко предоставят аналитика на крайни потребители, (и те наистина се движат в тази посока) – пробив все още не е настъпил. Хората просто не разбират добре многомерните данни.
3. Потребителският интерфейс, представляващ по-или-малко сложни слабо структурирани данни в фасетизиран вид – също така представя безкрайно количество проблеми. Извод: колкото по-плоско (flatter) – толкова по-добре.
4. Платформата, изградена на база автоматично извличане на данни от източници (които не винаги са предназначени за такова извличане), е в значителна зависимост от източниците, устойчивостта на конекторите и инфраструктурата. В неспособността да се осигури резултат, платформата (вестителят) винаги ще бъде обвинена. Доверие – капитал от такъв тип платформи. Капитал, който е труден за изкарване и лесен за загуба.
5. От гледна точка на бизнеса няма никаква разлика между анализа на Големи Данные и Просто Данные. Често зад простите като 2х2 числа стоят възможности за милиони долари. Добър пример – данните за изтичане на срока на служба на елементи от инфраструктурата на Норвегия. Когато всички дати на бъдещите капитални ремонти на цялото оборудване са били позиционирани на една ос и установили, че след N години ни очаква истински шельфов Армагеддон — един много заможен човек стана от стола си, учтиво се поклони и напусна стаята с думите: „Извинявайте, имам малко време, трябва да подготвя флота…“
6. Excel, а по същество ясното и точно таблично представяне на данни притежава огромна сила и голямо бъдеще. Вярвам в красивите таблици (и до ден днешен) и това е всичко!
7. Главният акцент на цялата тази «аналитика» е автоматизацията на вземането на решения. Там са най-значимите възможности, но и най-високите рискове, затова възможностите са значителни, затова и рисковете, затова и възможностите, затова и рисковете… 🙂 Управлението на пробивите, например…
8. Ако «интегрируемостта» е ключовата функция, то данните де факто трябва да бъдат представени под формата на услуга. REST управлява, но не бива да се забравя за оптимизацията производителност, която често в момента се жертва за сметка на интегрируемостта, тъй като изчислителната мощност продължава да нараства.
9. Мастър данни – това е нещо, което трябва да се локализира, извлече, стандартизира, преди да се адресират конкретни бизнес въпроси. Мастър данни — малки, а проблемите с тях — големи! Както казват братята по семантика – 50% от световните проблеми произтичат от факта, че хората наричат едни и същи неща с различни имена, а останалите 50% от това, че наричат различни неща с едно име.
10. Всякаква инкапсулация на ниво съхранение ограничава откритостта на решението и води до SILO-фикация. Добре е, ако сте голям доставчик, в противен случай – несигурно. (Тук не става дума, разбира се, за блочни нива и не за AWS S3, който вече беше на 6 години тогава, а за файлове).
11. Релационно моделиране на данни вече не ни е приятел. RDF и ключ-стойност – страхотно! Видяхме магически трансформации на релационни бази с модели от 2000 таблици в 15 таблици, и никой от потребителите не е загубил нищо.
12. Интернет функционира, защото има URL като единствен начин на адресиране. Значението на URL или по-точно URI за информационните ресурси на предприятието трудно може да се подценява.
13. Text mining и NLP са популярни. В интернет. Но и в корпоративния сектор може да се постигнат огромни успехи, извличайки структурирани данни от неструктурирани корпоративни данни.
14. Синергия между структурирани данни и информация, извлечена от неструктурирани данни, т.е. файлове – аналитичен Клондайк.
15. При извличане на данни – не забравяйте за правата и авторските права.
16. Компания, занимаваща се с извличане на данни, трябва да формира департамент на хакерите, в добрия смисъл на думата. Вдъхновено от тежката битка с защитните системи на Жълтите Страници срещу търсачките.
17. Преди да започнете работа с данни – те трябва да «видите» в цялото им изобилие. Това е трудно за обяснение. В ума ми идват таблици. За някого графични представяния, но всеки график всъщност е интерпретация. Или иначе казано… «вижте»!
18. Повтаряйки в въпроса за «достоверността» на потребителите на фронтенда. Достоверност към конекторите/процесите за генериране на данни, доверие към самите данни, доверие към взетите решения.

Източник: habr.com