Самая серьезная проблема для компании заключается сегодня не в изучении чего-то нового, а в адекватных действиях на основе уже имеющейся информации. Ее накоплено так много, а принимать решения нужно так быстро, что впору говорить о пересмотре технологий работы с хранилищами данных, которые изначально создавались как средства неторопливого оффлайнового анализа. Несмотря на прогресс в ИТ-области, реализовать большие хранилища пока удается лишь крупным компаниям, да и то с переменным успехом. Каким, централизованным или децентрализованным, должно быть такое хранилище? Что дает параллельная обработка? Какие специализированные решения уже созданы? ИТ-менеджеры хотят получить ответы на эти и другие вопросы — требуется голос пророка.
В платежной системе следует оценивать риски непосредственно в момент обслуживания клиента, а телекоммуникационной компании для выявления недобросовестных абонентов необходимо в режиме, близком к реальному времени, просматривать миллионы ретроспективных записей. В этом выпуске журнала мы аккумулировали мнения и взгляды на архитектуры хранилищ, обеспечивающих оперативную оценку текущих тенденций и бизнес-ситуаций. Как отмечают наши авторы, с лавинами данных позволяет справляться организация распределенного хранения, параллельной обработки и виртуализации. В таком случае бизнес начинает рассматривать ИТ-системы не как источник дополнительных обязанностей на сотрудников, а как кладезь новых возможностей.
Параллелизм проникает повсюду, «встраивается» почти во все хранилища данных. Однако при любом изменении парадигмы пользователи не сразу понимают суть нововведений, и сейчас они еще не очень хорошо представляют, что же такое параллельная обработка применительно к хранилищам. В одной из статей этого выпуска журнала описывается архитектура хранилища, разработчики которой распараллелили абсолютно все, от ввода SQL-предложений до деталей их выполнения. Фундаментальная идея состояла в том, чтобы снабдить каждый компонент аппаратно-программной системы множеством «близнецов». Не зная заранее, где появятся «узкие места», разработчики заранее устранили причины заторов, что обеспечило гибкость и контроль над производительностью — критически важными факторами современных крупномасштабных систем, предназначенных для поддержки принятия решений. Стоимость таких систем достаточно высока, но сокращение времени обработки данных всерьез «играет» против цены.
Стоимость ежегодной поддержки централизованного хранилища составляет примерно пятую часть его первоначальной цены, причем в таком решении не учитываются многочисленные распределенные источники информации. Наши авторы осторожно говорят об уходе с основной сцены централизованных, статичных хранилищ данных — таких же динозавров, как мэйнфреймы. Правда, по их мнению, те и другие не исчезнут совсем. Централизованные хранилища позволяют решать специфические задачи «отложенного» анализа, но их неспособность сохранять актуальные данные критична при создании оперативных систем. В них сложно размещать данные, и не менее трудно извлекать из них нужные сведения. По утверждениям аналитиков, более 80% крупных компаний имеют классические хранилища, но до 90% их данных не востребованы. Высокая стоимость, сложность и недостаточный уровень использования ресурсов — именно по этим причинам, предсказывают некоторые пророки, централизованные хранилища уступят место параллельным системам с распределенным интеллектом.
Мы продолжаем серию публикаций, посвященных особенностям применения CMMI. Судя по редакционному портфелю, который постоянно пополняется статьями на эту тему, она становится все более актуальной. Правда, наличие у производителя множества сертификатов вовсе не подразумевает выпуска качественного программного обеспечения. Принимая решения о сертификации, разработчик балансирует на грани между надеждами и истинной мотивацией. Конечно, подготовка к получению дипломов CMMI позволяет лучше понять, что делает компания, и понять, как делать еще лучше. Однако иногда за CMMI берутся компании-разработчики, попросту не умеющие создавать хорошее ПО. Например, во многих офшорных азиатских компаниях выстроен процесс разработки, но их сертификация по CMMI порой лишь закрепляет доминирование процесса над технологией. Такие разработчики подобны строителям, укладывающим асфальт поверх коровьей тропы: новая дорога кажется несколько лучшей, но, по сути, остается все той же тропой.
В компьютинге сейчас происходит смена парадигмы: коммуникационная модель отступает под натиском еще не получившей официального названия модели, характеризуемой доминированием слабых связей, ориентацией на сервисы и процессы. Только в движении можно услышать голос пророка, призывающего, в частности, не увлекаться процессом. Касается ли это построения хранилищ или разработки программ, процесс остается всего лишь процессом.
