В условиях, когда Интернет-компаниям требуется все больше приложений, поставщики решений и системные интеграторы обращаются к объектно-ориентированному программированию и компонентным средствам разработки. Они отмечают, что возможность повторного использования кода и доступа к хранилищам программных компонентов помогает разрабатывать приложения для вертикальных рынков и выполнять заказы намного быстрее.
Интернет-компаниям требуется гибкое ПО — часто приложения надо перестраивать и корректировать «на ходу», утверждает Джейсон Блумберг, аналитик компании IDC. «Темпы работ, как правило, ускоряются, а качество выполнения по-прежнему имеет большое значение», — отметил он. При этом ускорение темпов разработки увеличивает вероятность появления ошибок в программах, что может привести к падению акций компании, а в случае крупного «прокола» — полному ее краху. «Сейчас выпуск продукции низкого качества представляет собой большую угрозу для бизнеса поставщика, чем раньше», — считает Блумберг.
Это способствует росту спроса на компонентное ПО, в частности на продукты, построенные на компонентах COM, Enterprise JavaBeans (EJB) и CORBA. По прогнозу IDC, объем рынка программных компонентов достигнет к 2003 г. 30 млрд. долл., что вчетверо больше 7,2 млрд. долл. в 1998 г. Согласно оценке Giga Information Group, один лишь рынок EJB к 2003 г. должен составить 2 млрд. долл. против 200 млн. долл. в прошлом году.
Поставщики решений широко используют подобные технологии для построения приложений и целых архитектур, адаптированных к потребностям бизнеса заказчиков. Так, C-bridge Internet Solutions строит свою стратегию разработки ПО на объектных возможностях Java, что позволяет ей создавать готовые решения за 16—20 недель, сообщил директор по технологиям Рон Бодкин. C-bridge называет свои программные разработки iSolutions. Они включают многократно используемые службы, бизнес-объекты, механизмы доступа к данным, средства интеграции и представления. «Все это реализовано в виде отдельных модулей, которые могут повторно использоваться в различных приложениях, а также легко расширяться и модифицироваться для поддержки широкого спектра сценариев, — пояснил Бодкин. — Цель в том, чтобы сделать программные платформы iSolutions эквивалентом «продуктов» и позиционировать C-bridge как поставщика бизнес-услуг». Согласно утверждению главного управляющего C-bridge Джозефа Беллини, «если пакеты iSolutions приобретут статус продукта, C-bridge сможет внедрять новые системы электронного документооборота за 6–10 недель вместо прежних 16–20».
Идея использования не просто фрагментов кода, а заранее сконфигурированных программных структур и модулей находит все более широкое признание в отрасли. Многократно используя модели и архитектуры, разработчики во многих случаях получают возможность произвести «сборку» приложений более эффективно, утверждает Брайан Лайонс, председатель правления компании Number Six Software. «Разработчик больше не строит системы «с нуля» с помощью компилятора и редактора, — продолжает Лайонс. — Он начинает с архитектуры и подбирает столько готовых структур и компонентов, сколько требуется использовать в каждом конкретном проекте».
В ситуации, когда поставщики решений переходят на объектно-ориентированные средства разработки ПО, возникла потребность упростить доступ к непрерывно растущему числу программных компонентов и структур, а также управление ими. Это вызвало к жизни идею репозитория, или библиотеки компонентов и структур для прикладных решений. Две компании уже начали осуществление программы по вводу таких репозиториев в эксплуатацию.
Фирма IntellectMarket, создавшая торговую площадку для компонентов, представила систему управления репозиторием программных компонентов под названием IntellectMachine. Основными ее элементами являются Component Capsule, система описания компонентов на базе XML, а также Component Relationship Model, система поиска, которая не только находит нужные разработчикам компоненты, но и рекомендует дополнительные. Кроме того, IntellectMarket создала систему классификации для библиотеки компонентов IntellectMachine, получившая название ICNsys.net. Она присваивает каждому компоненту в репозитории учетный номер International Capsule Number (ICN). «Эта система в чем-то сходна с Napster’ом, — пояснил главный управляющий IntellectMarket Крис Ламела. — Она предназначена для создания всемирной библиотеки не из сотен тысяч, а из десятков миллионов программных компонентов, которые будут у каждого программиста под рукой».
IntellectMarket подала заявку на патент по базовой технологии, которая легла в основу IntellectMachine, сообщил Ламела, добавив, что компания ведет переговоры с рядом потенциальных партнеров о создании консорциума по сопровождению системы ICNsys.net.
Другая торговая площадка компонентов, Flashline.com, также представила недавно свое решение. Система Flashline Component Manager 2 Enterprise Edition (CMEE) включает в себя репозиторий со средствами поиска, шаблон обеспечения соответствия стандартам и систему отчетности, сообщил Чарлз Стэк, главный управляющий этой компании.
Созданием собственного глобального репозитория компонентных моделей занимается также Arthur Andersen — одна из фирм «большой пятерки».
Однако лидером в области организации торговых площадок компонентов является компания ComponentSource, которая одной из первых занялась подобным бизнесом. Сейчас в ее архиве насчитывается около 5400 компонентов. «Это значительно больше, чем в библиотеках IntellectMarket или Flashline.com, где счет компонентов пока идет на сотни», — с гордостью отметил Сэм Паттерсон, главный управляющий компании ComponentSource. А вот организацию бизнеса у конкурентов Паттерсон ставит под сомнение: по данным самих компаний, маржа у IntellectMarket составляет 12,5%, а у Flashline.com — около 20%, что, по мнению управляющего ComponentSource, «просто неприемлемо для онлайновых рынков». Правда, прибыльность своей компании Сэм Паттерсон оглашать не намерен.
Другие поставщики решений также отмечают, что компонентная разработка связана с рядом проблем, особенно в плане окупаемости. «Использование готовых компонентов действительно сокращает время внедрения, но это не помогает нам понять, как окупить стоимость разработки и сопровождения компонентов», — говорит Мун Так Яп, директор Arthur Andersen.
Джон Раймер, президент Upstream Consulting, считает, что оптимальный уровень окупаемости для программных модулей, учитывая производительность, повторное использование, экономию времени и затрат, должен быть около 80%, однако типичный модуль способен дать лишь 40%. «Сорок процентов окупаемости — это проигрыш. Однако очень трудно спроектировать и построить модули, которые способны дать вдвое больше, — заявил Раймер. — Поэтому построение подобного бизнеса пока что представляется трудно осуществимым».
