В 2006 году среди подписчиков Dr. Dobb’s Journal проводился опрос с целью выяснить, какие практические методы управления данными применяются в отрасли ИТ. Почти 62% из 1176 респондентов тогда отметили, что их компании сталкиваются с проблемами при работе с производственными данными, а 18% указали, что в их компаниях даже нет стратегии решения этих проблем. Треть участников опроса признали, что вся стратегия сводится к тому, чтобы «не сделать еще хуже».
Практически все респонденты посчитали, что данные являются корпоративным активом, но только 40% подтвердили, что у них имеется тест проверки корректности данных. На вопрос о том, сколько времени займет переименование столбца в производственной базе данных, только 25% ответили, что эта задача может быть решена за один день, у 7% это займет больше трех месяцев, а 8% респондентов заявили, что это слишком рискованная задача, чтобы вообще за нее браться.
Эти результаты указывают на серьезные различия между культурой, господствующей в сообществе специалистов по управлению данными, и культурой сообщества сторонников «скорой» (agile) разработки, во главу угла ставящих качество. Согласно наблюдениям Data Warehouse Institute, одни только проблемы, связанные с качеством данных, ежегодно обходятся американским компаниям в 600 млн долл. Традиционные подходы к управлению данными не оправдали возложенных на них надежд, так и не обеспечив высокое качество данных в организации. Результаты опроса — еще одно свидетельство того, что такие подходы к управлению данными неэффективны, а эволюционные методы скорой разработки оказываются более предпочтительными.
Данные — это лишь один из множества аспектов, учитываемых при выполнении приложения, и я уверен, что сообщество управления данными значительно отстает от сообщества программного обеспечения в том, что касается повышения эффективности используемых ими методов. Как правило, методы скорой разработки включают в себя поэтапную апробацию, что вместе с ранним тестированием позволяет добиться более высокого качества. Я показал, что методы контроля качества, используемые при «скорой» разработке, применимы и при создании баз данных [1]. Так почему же о них ничего не слышно в сообществе разработчиков баз данных?
История разногласий
Тот факт, что специалисты по данным не спешат внедрять эволюционные методы или методы «скорой» разработки — это следствие известного технического диссонанса между объектно-ориентированной технологией и технологией реляционных баз данных. Такое разногласие вызвано различными теоретическими основами этих двух технологий — программного инжиниринга и математики. Вопреки приводимым аргументам, ни одна из технологий не превосходит другую — они просто различны, и иногда крайне сложно использовать их вместе.
Первое расхождение
Как же так получилось? На рис. 1 показано, что объектная технология впервые появилась в конце 1960-х годов, а бизнес-сообщество приняло ее в конце 1980-х — начале 1990-х годов. Это и стало первой точкой расхождения между двумя сообществами. До этого момента они во многом опирались на одни и те же принципы и стратегии. Нельзя сказать, что это было хорошо но, по крайней мере, они оставались в достаточной степени согласованными друг с другом.
Объектная революция привела к разногласиям, которые существуют до сих пор. И, как и в случае с большинством технологических революций, появление объектной технологии сопровождала обычная шумиха под лозунгами о том, что наконец-то, найдено универсальное средство — «все есть объект, и объектная технология — единственное, что вам когда-нибудь потребуется». Время расставило все по своим местам, но один из лозунгов нанес ощутимый вред, а именно: идея о том, что чисто объектный подход, поддержанный объектной основой, быстро сведет на нет использование реляционных технологий. Более того, результаты серьезных научных исследований, проведенных в конце 1980-х — начале 1990-х годов, действительно показали, что не следовало использовать структурные объекты для языков объектной реализации, таких как C++ или Smalltalk, или объектных моделей для языков структурной реализации, таких как Cobol или Basic. Все это вынудило многих в объектном сообществе утверждать, что объекты и реляционные базы данных не должны использоваться вместе.
В то же время сообщество специалистов по данным следовало стратегиям, которые изолировали его от происходящих изменений. Специалисты по моделированию данных уже играли важную роль в мире мэйнфреймов, причем и в двухуровневом клиент-серверном мире их деятельность имела в равной степени критическое значение. Разработка в обоих мирах велась одинаково: специалисты по данным разрабатывали схемы данных, а разработчики приложений писали свой программный код. Между этими двумя задачами на концептуальном уровне практически не было ничего общего. Более того, чем дальше, тем яснее казалось, что объектные базы никогда не выйдут за рамки узкой, нишевой технологии, а реляционные фактически превратились в стандарт для хранения информации. Поэтому, с точки зрения специалистов по данным, в их мире практически ничего не изменилось — даже несмотря на то, что их взаимодействие с разработчиками становилось все более и более напряженным.
Второе расхождение
Однако, когда речь коснулась процесса, между двумя сообществами проявилось четкое различие. В 1990-е годы при разработке большей части нового программного обеспечения предпочитали использовать объектную и компонентную технологии и следовать инновационным процессам в духе спиральной модели разработки, описанной Барри Боэмом [2]. По большей части сообщество специалистов по данным отдавало предпочтение тому, что называют проверенными приемами, в то время как разработчики начали экспериментировать в поисках способов раздвинуть границы процесса создания программного обеспечения. Какое-то время рост производительности в сообществе разработчиков оказался значительно ниже, чем предполагалось, несмотря на обещания, успешный опыт ряда проектов и наличие унифицированных языков моделирования.
Тогда в 2001 году руководителей из объектного сообщества обсудили, что именно при создании систем оправдывает себя на практике, в противоположность тому, что, как они говорили, должно работать в теории. Они действительно договорились о ценностях и принципах, которые затем опубликовали в Agile Manifesto. Так возникло второе расхождение.
Эволюционная разработка имела определенные достоинства, но вести ее в тесном сотрудничестве членов коллектива разработчиков и с жестким контролем качества оказалось еще лучше. Философия и методики «скорой» разработки действительно позволили добиться роста производительности, который обещало первое расхождение. Группы «скорой» разработки теперь достигали измеримо более высоких темпов успеха, чем группы, придерживающиеся традиционных методов создания приложений, и специалисты, занимающиеся проектами хранения данных, — 72% против 62,8% и 62,6% соответственно.
Таким образом, пропасть между специалистами по данным и разработчиками становилась все шире. К изумлению первых, методики объектного моделирования, в частности касающиеся Unified Modeling Language (UML), оказались значительно надежнее, чем методики моделирования данных и, безусловно, представляют собой суперинструментарий для моделирования данных [3]. Объектный подход вытеснил подход данных, поскольку он охватывает значительно более широкий круг вопросов, относящихся к разработке, поддержке и функционированию систем. Фактически концептуальное дублирование было настолько значительным, что многие специалисты по данным ошибочно полагали, что диаграммы классов были просто моделями данных, в которые добавлены операции. Но сложность моделирования поведения требует большего, чем одни только диаграммы классов; отсюда и изобилие моделей, описанных с помощью UML. Более того, из-за сложности современных систем становится понятно, что сосредоточенность только на данных слишком сужает стратегию.
Как устранить культурные разногласия
Культурные разногласия проявляются в трудностях, с которыми сталкиваются разработчики объектов и специалисты по данным, когда им приходится работать вместе. Это также проявляется и в приводящих к конфликту политиках в двух сообществах, который сказывается как внутри организаций ИТ, так и в самой отрасли ИТ. Например, как показали результаты опроса, посвященного управлению данными и проведенного в июле 2006 года, 66% респондентов подтверждают, что группы разработчиков иногда действуют в обход групп управления данными (рис. 2). В какой-то мере проблема, по-видимому, связана с разработчиками, поскольку 8% из них не знают о том, что такие группы по данным вообще существуют. К счастью, обучение и эффективное управление разработкой могут исправить эту ситуацию.
Нежелание групп разработки эффективно взаимодействовать и даже вообще работать с группами по управлению данными усугубляет и без того весьма серьезные проблемы с качеством данных, имеющиеся в современных организациях. Группы разработки не могут эффективно применять знания, навыки и опыт специалистов по данным и поэтому совершают распространенные ошибки, например создают новые источники данных, вместо того чтобы использовать уже существующие. В результате появляется не соответствующая стандарту архитектура баз данных, которая не удовлетворяет корпоративным конвенциям именования данных и работы с метаданными. Это мешает и работе группы по управлению данными, поскольку они не знают, как использовать новые стратегии разработки, предлагаемые сообществом «скорой» разработки, такие как регрессивное тестирование, рефакторинг и непрерывная интеграция. Поэтому группа упускает из виду конкретные, ориентированные на качество методики эволюционной разработки [1].
Преодолеть культурные различия значительно труднее, чем технические. Прежде всего каждый должен сознавать, что проблема существует. Разработчики и специалисты по данным имеют разные навыки, опыт, идеологию и предпочтительные методы работы. Вместо того чтобы искать пути для совместной работы, которые позволили бы обернуть на пользу эти различия, многие отделы ИТ предпочитают создавать коммуникационные и политические барьеры между двумя группами. В IBM, например, имеется служба совершенствования программных процессов, получившая название Measured Capability Improvement Framework (MCIF) и поддерживающая две основные функции: первоначальная оценка состояния и последующая постоянная «самопроверка». Самопроверка MCIF позволяет более эффективно отслеживать все улучшения в конце каждой итерации [4]. Важная часть оценки состояния заключается в том, чтобы выявить,что именно тормозит прогресс в организации, и, используя эти знания, повысить эффективность работы отдела ИТ. Как показывает опыт, культурные различия, такие как разногласия между специалистами по данным и разработчиками, преодолеть сложнее всего. Но сделать это необходимо.
Политические империи, созданные на традиционных подходах, в конечном итоге должны пасть. Универсальных решений нет. Разные проекты требуют разных подходов к разработке, но ими следует должным образом управлять. Проект, посвященный хранению данных, отличается от проекта по созданию Web-сайта. Группа из трех человек будет работать не так, как группа из 30 или 300 специалистов. Группа, все члены которой находятся вместе, действует иначе, чем распределенная команда. Недостаточно того, чтобы была права только группа данных или группа разработки — они должны быть правы вместе.
Кроме того, необходимо видеть всю архитектуру в целом. Слишком многим разработчикам приложений приходится разбираться в основах технологии данных. И опять-таки, слишком много специалистов по данным вынуждены разбираться в архитектурных концепциях, выходящих за узкие рамки мира данных. Мы должны обучать разработчиков работе с данными, а специалистам по данным давать навыки разработки.
Стратегии, направленные на преодоление трудностей по воссоединению этих двух сообществ, уже реализуются. Например, список рассылки для специалистов по «скорой» разработке баз данных (agiledatabases@yahoogroups.com) предоставляет возможность обмена мнениями между специалистами по данным и разработчиками для того, чтобы они могли эффективно взаимодействовать. Ежегодная конференция Software Development Best Practices Conference активно предлагает специалистам по данным изложить свои взгляды и научиться передовым методам разработки. Такие инструментальные средства, как Optim и Rational Data Architect компании IBM, помогают сократить пропасть за счет совершенствования традиционный функциональности разработки баз данных с помощью стратегий, предлагаемых сообществом «скорой» разработки.
***
Предстоит еще сделать немало. Во-первых, необходимо отказаться от некоторых ошибочных представлений, касающихся методов «скорой» разработки баз данных. На практике, если вы готовы мыслить вне традиционных рамок, изменение существующей схемы реляционной базы данных происходит достаточно просто, даже в тех случаях, когда к базе данных обращаются сотни производственных систем. Во-вторых, превалирующая культура данных должна стать более ориентированной на качество. Необходимо принять конкретные методики поддержки качества, такие как разработка с тестированием и рефакторинг, и меньше следовать традиционным бюрократическим методикам. В-третьих, сообщество разработки должно больше разбираться в вопросах, касающихся данных, и, что важнее, в корпоративных вопросах в целом. Многие разработчики не имеют представления о проблемах с качеством данных, которые они же и создают, когда предлагают еще одну производственную базу данных или когда оказываются не в состоянии эффективно использовать возможности реляционных бах данных, поскольку применяют оболочку, инкапсулирующую базу данных.
Наконец, каждый должен понимать, что есть эволюционная разработка. Она становится нормой, а не исключением, и методы «скорой» разработки уже доказали свою эффективность в повседневной практике. Нет никаких причин, мешающих специалистам по данным тоже применять методы эволюционной или даже «скорой» разработки. Мир программного обеспечения изменился. То же самое может произойти и с миром данных.
-
S. Ambler, “Test-Driven Database Development,” IEEE Software, vol. 24, no. 3, 2007.
-
B.W. Boehm, “A Spiral Model of Software Development and Enhancement,” Computer, vol. 21, no. 5, 1988.
-
R.J. Muller, Database Design for Smarties: Using UML for Data Modeling, Morgan Kaufmann, 1999.
-
N.L. Kerth, Project Retrospectives: A Handbook for Team Reviews, Dorset House, 2001.
Скотт Амблер (scott_ambler@ca.ibm.com) — менеджер по «скорой» разработке компании IBM Software Group.
Scott Ambler, When IT Gets Cultural: Data Management and Agile Development, IEEE IT Pro, November/December, 2008. IEEE Computer Society, 2008. All rights reserved. Reprinted with permission.
