Вторая половина шахматной доски

chess masterТот энтузиазм, с которым компьютерное сообщество обсуждает сейчас тему Big Data, свидетельствует о том, что они сами не ведают, что творят. Футуролог Рэймонд Курцвейл, известный книжками по технологической сингулярности (гипотетический момент, по прошествии которого, технический прогресс станет настолько быстрым и сложным, что окажется недоступным пониманию см. википедию ) ввел в обиход термин вторая половина шахматной доски. Как известно, изобретатель шахмат попросил в качестве награды положить на первую клетку доски одно зерно, на вторую – два, на третью четыре и т.д. Общее количество зерен на шахматной доске составит 2 в 64 степени без 1, а это очень и очень много. Однако, количество зерен, которые следует разместить на первых клетках шахматной доски, не кажется таким большим. Даже на 32 клетке будет всего 2 гигабайта зерен. Это примерно сто тонн риса. Это полтора современных железнодорожных вагона, предназначенных для перевозки зерна.  Термин вторая половина шахматной доски  сейчас активно используется в экономике и управлении, например в книжке “Race Against The Machine” By Erik Brynjolfsson and Andrew McAfee.

Но оставим в стороне стратегию и футурологию и вернемся к технологиям работы с информацией. Для того чтоб запутаться в данных не нужно пересекать отметку в пентабайт. Достаточно месячного объема писем в вашем почтовом ящике. Многие евангелисты корпоративных социальных сетей, технологий Enterprise 2.0 рассказывают о том, что эти инструменты, в первую очередь, необходимы для работы с персоналом. Я уверен в том, что это большое лукавство. Для успеха в работе с персоналом нужны инструменты материальной и нематериальной мотивации и сильные менеджеры среднего звена. А вот инструменты Enterprise 2.0 нужны для работы с информацией, организации взаимодействия между сотрудниками в ходе рабочих процессов и управления знаниями. А вот в управлении информацией HR, равно как и большинство других функций современной компании разбираются не очень хорошо.

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

Еще Фредерик Брукс в 1975 году, в 9-ой главе книги «Мифический человеко-месяц» сказал:

Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowchart; it’ll be obvious.

Покажите мне свои блок-схемы и спрячьте свои таблицы – и я останусь одураченным. Покажите мне свои таблицы, и мне, скорее всего, не понадобятся блок-схемы, они будут очевидными.

А автор «Собора и Базара» Эрик Реймонд в 97-м выразился еще проще

Smart data structures and dumb code works a lot better than the other way around.

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

Технологии организации данных эволюционировали вслед за ростом объема данных.

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

На первом уровне появилась реляционная модель данных. Обратите внимание, Эдгар Кодд писал в первую очередь о данных, а не об их структурах. Именно конкретные данные определяют вторую и третью нормальные формы. Скорее всего, Кодд считал, что с базами данных будет работать человек и по мере накопления данных такой человек вполне сможет изменять структуру реляционной базы данных. Но, как известно, со структурами данных работает программист и в этом проблема архитектуры реляционных баз данных. Рано или поздно сбор данных в реляционной базе приводит к существенному росту количества таблиц и полей.  Включается эффект «второй половины шахматной доски» пользователи перестают понимать, как им работать с данными, программисты – как дальше развивать такую систему. Большинство «технических дискуссий» в современных организациях как раз об этом. Отсутствие функции архитектора данных в подразделении или организации ухудшают карму балов на сто.

business objects

Следующая ступень развития это объектно-ориентированный подход. Неайтишники на эту ступеньку, как правило, уже не доходят. Огромное количество материалов про ООП рассказывают об объединении данных и функций, но мало кто обращает внимание на организацию данных. Отношение наследования, существенно упростившее организацию данных, появляется именно здесь. В объектно-ориентированной системе меньше коллекций; вместо двухсот таблиц пятьдесятов классов. Кстати на дня обнаружил интересный косяк в нашей CMDB. Дублирован признак того, что приложение находится в эксплуатации. На одной закладке это поле «унаследовано» от базового класса конфигурационная единица, а на другой введено отдельное поле, принимающее значение true в случае наличия распоряжения о вводе в эксплуатацию. Какой-то архитектор однажды сглупил, а масса экспертов и руководителей отрабатывают теперь карму в продолжительных дискуссиях о том, сколько и каких систем у нас в эксплуатации. Эта ситуация не характерная только для ITSM. В учетных системах такое творится сплошь и рядом.

Третье поколение организации данных – это семантический веб (semantic web, linked data). Что это такое не понимает даже большинство айтишников. Но, возможно, развитие NoSQL баз данных, таких как MongoDB, научит их механически делать правильные вещи. Идея та же самая, что при переходе от реляционных моделей данных к объектно-ориентированным. Мы хотим сократить количество коллекций(типов или классов данных). Т.е. чтоб физическое представление данных  одной экранной формы у нас не хранилось в двух десятках связанных таблиц, лежало в одной коллекции. Это повышает характеристики информационной системы (производительность, время отклика), позволяет масштабировать системы (распределять данные по разным узлам инфраструктуры) и что менее очевидно, но не менее важно упрощает структуру данных. Для того чтоб это стало возможным пришлось отказаться от строгой типизации данных. Эта идея – стопроцентная заслуга web технологий. Вспомните википедию: есть страница, однозначно идентифицируемая посредством URL, ну и хорошо. В ходе своего жизненного цикла страница обогащается связями с другими объектами, попадает в различные категории, приобретает все новые и новые ключевые значения (например, для страны это может быть численность населения, тип климата, размер территории, столица… ). Идея вики не в красивых картинках, а подходе к жизненному циклу информационного объекта. Безусловно, можно считать, что википедия это в первую очередь пример коллективного творчества, но посмотрел бы я на результаты такого творчества, если бы этому коллективу предоставили жесткую структуру данных с обязательными для заполнения полями.

В завершении хочу поделиться вчерашним твитом Кита Свенсона, безусловного лидера темы adaptive case management:

Define #SOA? Simple: “instead of distributing the function to where the data is, we distribute the data to where the function is”

Похожие сообщения:

Вторая половина шахматной доски: 5 комментариев

  1. Про данные, но не про их целесообразность и содержание.
    Предлагаю впику BigData ввести термин SmallAmmountOfNecesaryAndSufficientData – Small Data! Или про то, что “многие данные, многие печали”, “много данных – мало толку”

  2. Все равно все методики работы с BigData направлены на уменьшение объема анализируемых данных (сегментация, агрегация, выделение общих тенденций и пр). Так что работать “на первой половине шахматной доске” все равно приходится.

    .

  3. >>”instead of distributing the function to where the data is, we distribute the data to where the function is”

    Ну да. Приносим ботинки в починку, а не наоборот – до тех пор, пока это применимо (например, пока у нас не BigData). Определение содержит в себе и ограничение применения SOA – становится ясно, что подход SOA тоже не универсален.

    Объектный подход (которому сто лет в обед), при котором инкапсулируются и данные и методы, кажется более универсальным – при вырожденных данных это только функции, при вырожденных функциях это только структуры данных.

    Видимо, проблема именно в том, чтобы упростить инструментарий для объектного подхода до уровня непрограммирующих юзеров, а то они свои потребности на объектно-ориентированных языках выражать никак не хотят и не будут, а ждать при очередном изменении бизнес-процесса пока программеры их срочно обслужат – оно им тоже не надо. Пришлось понизить уровень абстракции (и сузить область применения) и придумать SOA – пользоваться сервисами как-то проще научить всех.

    1. Объектный подход всем хорош, но есть один маленький нюанс. В ходе своего жизненного цикла объект не может поменять свой класс. В современном мире это как-то, я бы сказал, не политкорректно 🙂

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *