Охота за сокровищами

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

Золотая обманка?

Проблема вот в чем: вы полагаете, что обладаете потенциальной «дойной коровой» (воплощенной в созданном вами частном ПО), и держите его близко к сердцу, как последний козырный туз, боясь, что если вы его отпустите, его немедленно украдут. Однако реалии современной экономики таковы, что извлечь живые деньги из интеллектуальной собственности становится все труднее. На то есть свои причины.

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

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

Поставки коммерческого ПО — это нечто большее, чем просто создание продукта и последующая его продажа. Помимо этого, необходимо обеспечить его поддержку, а также потратить немалые деньги на сопровождение и документирование. Хорошо известно, что большая часть доходов от ПО получается от его сопровождения, а не от разработки.

Следуйте за деньгами

В конечном счете продажа внутреннего решения экономически нецелесообразна. И все больше компаний начинают понимать, что стоимость собственно ПО неуклонно падает. В настоящее время наиболее востребованы общедоступные технологии и программы с открытым кодом — XML и Java. Деньги делаются на интеграции этих инструментов в состав программных сред или на простом содействии применению этих технологий. Никто не получает прибыль, продавая саму технологию: XML — это спецификация, доступная всем для ознакомления и использования, а язык Java, равно как Java-компиляторы и библиотеки, можно свободно загрузить для использования с Web-сайта корпорации Sun Microsystems.

Да что говорить — даже Microsoft медленно, но верно присоединяется к этому движению. Известно, что большинство людей вполне удовлетворены текстовым процессором из состава Office 97 и им вовсе не нужна модернизация этого пакета программ. Все труднее «продавать» мысль о том, что обновление принесет существенное улучшение. Поэтому Microsoft пытается приспособиться к сервисной модели, разрабатывая концепцию .NET, Web-службы которой также созданы на базе свободных и готовых стандартов — таких, как протокол SOAP (Simple Object Access Protocol) и спецификация UDDI (Universal Description, Discovery and Integration). В действительности Microsoft также запустила программу Shared Source («общий исходный код»), по условиям которой фактически позволяет избранным партнерам изучать и использовать свой собственный код для их особых нужд. Это все еще не настоящий открытый исходный код, так как Microsoft владеет им и запрещает его модификацию. Но даже этот маленький шаг на пути к раскрытию исходного кода намного больше того, на что Microsoft была готова пойти четыре года назад. И это еще одно доказательство того, что ценность программного обеспечения — не в самом коде.

Мысль проста: в течение долгого времени компании рассматривали свои внутренние программные «шедевры» как ценную интеллектуальную собственность, стоимость которой может только расти. Однако многие из них осознали, что любая интеллектуальная собственность обладает максимальной стоимостью в момент своего создания, а затем ее ценность медленно снижается. Сохранение внутрикорпоративного интеллектуального ПО в секрете не обеспечивает никаких выгод компании. Жесткий контроль зачастую даже препятствует разработке действительно высококачественного ПО, потому что компании оказываются недоступны преимущества внешних ресурсов и независимого анализа.

Ценность программного обеспечения

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

Во-вторых, измените акценты при разработке корпоративных приложений, делая ударение на интеграции и сопровождение готовых компонентов, а не на создание решения «с нуля». Проекты внутренней разработки ПО должны ориентироваться не на прямую прибыль, а на экономию средств. Таким образом, реальная ценность заключается в нахождении способов сокращения затрат. В терминах программного обеспечения сокращение затрат — это поиск путей облегчения интеграции и поддержки имеющегося ПО, а не попытки создать уникальный продукт и сохранить его как интеллектуальную собственность.

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

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

Поскольку ценность ПО резко падает вскоре после создания, то, подвергая свой проект и компанию влиянию внешних сил в виде сообщества разработчиков, вы немногим рискуете в длительной перспективе. Вы поймете, что ценность проектов разработки корпоративного ПО заключается не в самом ПО, а в том, как оно объединяет все части вашей компании, обеспечивая их поддержку. Оценивать проект следует по тому, как эффективно используются его результаты и выполняются поставленные задачи. Идеи об увеличении прибыли от проекта путем продаж или «консервирования» ПО — это атавизмы экономики старой школы. А если так, то почему бы и не открыть исходный код?

Майкл Дж. Хадсон (Michael J. Hudson) — инженер по созданию инфраструктур в Blueprint Technologies (МакЛин, шт. Виргиния), компьютерной компании, специализирующейся на создании программных архитектур. Его работа заключается в создании корпоративных архитектурных решений, в частности, для таких клиентов, как NASA. С ним можно связаться по e-mail: mhudson@blueprinttech.com.