Революция в мире программного обеспечения уже началась. Пытаясь примирить сложность современных прикладных систем и настоятельные требования, предъявляемые бизнесом к скорости и качеству их создания, внедрения и внесения в них изменений, поставщики вынуждены изменять архитектуру своих решений, выделяя отдельные программные слои, которые получили название прикладных платформ.
Марина Аншина
Заместитель председателя правления
Фонда ФОСТАС,
директор департамента
ПО компании «Ай Эс Джи»
В
области ИТ существуют свои вечные вопросы, которые из года в год задают себе
и коллегам члены ИТ-сообщества. И один из них такой: «Покупать ли готовое или
разрабатывать свое?». Довольно часто ответы на вечные вопросы сменяют друг друга
с пугающей последовательностью. Если в 80-е годы мы всё разрабатывали сами,
то где-то в 90-х возможность покупать готовое ПО казалась решением многих проблем:
не надо писать техническое задание, тестировать и т. д. Однако вскоре поняли,
что с приобретенной готовой системой, даже самой замечательной и грамотно выбранной,
с хорошими консультантами, далеко не всё получается так, как хотелось. Но ИТ,
как и многое другое, развиваются по спирали, и на новом витке старый ответ основывается
на новых доводах — новых стандартах, технологиях и опыте. Вот и сейчас в вопросе
«покупаем готовое или разрабатываем свое» мы переходим на новый уровень. Можно
сказать, что традиционная дилемма теперь звучит следующим образом: «Покупать
ли ширпотреб или приобретать готовое базовое ПО, из которого можно быстро и
качественно получить индивидуальное решение?».
Недостатки готового тиражного ПО
Если еще совсем недавно крупнейшие игроки рынка ПО обещали предложить такой набор программных компонентов, из которого любое предприятие могло бы выбрать компоненты, покрывающие все его потребности, то сейчас стало понятно, что:
- разнообразие стоящих перед различными компаниями задач столь велико, что
не позволяет продолжать унификацию программных систем;
- гибкость программных решений приобретает все большее значение, между тем
как унифицированные решения практически не бывают гибкими;
- настройка бизнес-процессов компаний на бизнес-процессы, заложенные в готовом
программном решении, затратна, дорогостояща и редко заканчивается успехом;
- потребности бизнеса все чаще вынуждают предприятия отстаивать индивидуальность
своих программных решений;
- готовые решения позволяют предприятию создать «кусочную автоматизацию», но не позволяют построить полноценную архитектуру программных систем.
На
мой взгляд, самый сложный вопрос — как построить такое программное обеспечение,
которое можно было бы менять параллельно с изменениями в компании? В моей практике
был такой случай. Мы разрабатывали корпоративную систему узкой функциональности,
нам было выдано очень грамотное техническое задание на ста страницах, составленное
квалифицированными консультантами (результат более чем 40-часовых обсуждений
с заказчиком), и специалисты заказчика тоже были очень грамотны. Но когда через
два месяца работы мы представили свою систему, оказалось, что работать с нею
нельзя. Хотя мы всё сделали строго по ТЗ и формально заказчик не мог не принять
нашу работу, реальные процессы были уже совершенно другими. Всего за два месяца,
прошедшие с момента составления ТЗ, работа настолько изменилась, что к ее ИТ-поддержке
предъявлялись совсем иные требования.
Заказчики все больше ощущают необходимость в гибком и масштабируемом ПО и ждут от поставщиков таких корпоративных информационных систем, которые могли бы достаточно быстро подстраиваться под их изменяющиеся требования. В результате назрела революционная ситуация, когда пользователи уже не хотят жить с неподвижными окостеневшими ИТ, а поставщики ещё не могут предложить им ничего другого.
Прикладная платформа
Революция в мире программного обеспечения уже началась. От трехуровневой распределенной архитектуры мы потихоньку переходим к так называемым прикладным платформенным архитектурам. В ИТ утверждается новое понятие — прикладная платформа. Что же это такое? Хочу напомнить, что прикладная платформа не является открытием последних лет. В модели OSI, которая всем известна, понятие «платформа» активно используется. Мало того, там присутствует несколько типов платформ, в том числе и прикладная, определяемая как иерархия функциональных блоков сеансового, представительского и прикладного уровня, то есть трех верхних уровней модели OSI.
Но я позволю себе сформулировать свое, может быть излишне общее, определение. Когда чуть ниже я буду говорить о типах прикладных платформ, вам станет ясно, почему мне пришлось дать именно такую формулировку. Прикладная платформа — это программное обеспечение, предназначенное для проектирования, разработки, выполнения и модернизации программных компонентов, автоматизирующих деятельность различных конкретных предприятий. Иными словами, прикладная платформа — это то, из чего мы можем собрать программную систему «под себя». Причем с помощью прикладных платформ мы можем создавать такие системы, которые потом сможем изменять в соответствии с переменами в нашем бизнесе. Прикладная платформа неразрывно связана со всем жизненным циклом построенного на ней ПО (в том смысле, что без нее ПО не может эксплуатироваться) и обычно сама состоит из разнообразных взаимосвязанных компонентов. Основные отличия таких прикладных платформ от настраиваемых программных систем заключаются в следующем.
- Прикладная платформа позволяет предприятию создать ПО «под себя», а настраиваемая
система позволяет только выбрать один из нескольких предопределенных вариантов.
Конкретные параметры у каждого предприятия свои, и когда мы говорим о готовом
приложении, то по сути дела настройка на них — это выбор варианта. Если речь
идет о внедрении крупной корпоративной системы, то предприятию обязательно
приходится подстраивать под неё свои бизнес-процессы. Конечно, каждая уважающая
себя тиражируемая система имеет API, на котором можно разрабатывать дополнительные
компоненты. Мне даже известны случаи, когда на таком API переписывалось более
50% функционала системы. Но здесь уже можно говорить о настраиваемой системе,
которая выступает именно как прикладная платформа, однако почему-то стыдливо
об этом умалчивает. Кроме того, в этом случае заказчик вынужден платить за
готовое решение, хотя практически приобретает платформу.
- Прикладная платформа предполагает широкие возможности по развитию созданного на ее основе ПО. Она позволяет добавлять программные компоненты, переписывать и развивать их. Это обеспечивает эффективную структуру совокупной стоимости владения, когда на первом этапе мы можем ограничиться относительно небольшими затратами на закупку собственно прикладной платформы, разработку и внедрение ядра системы, а потом — развивать базовое решение. Если же компания внедрила готовое монолитное решение, то проводить изменения и перестраивать параметры крайне трудно.
Преимуществ у такого подхода много. Прикладная платформа позволяет, с одной стороны, существенно сократить сроки разработки ПО, а с другой — повысить его индивидуальность, соответствие потребностям компании, ее стратегическим и оперативным задачам, запросам сотрудников и других заинтересованных лиц. Кроме того, она позволяет увеличить гибкость ПО и часто берет на себя отдельные сервисы — технические, общие для многих программных систем, такие как обеспечение безопасности, поддержка транзакционной целостности, обработка событий, управление сообщениями, и прикладные, определяемые конкретной функциональной областью предлагаемой платформы.
Кстати, необходимо отметить, что прикладные платформы все чаще разрабатываются для отдельных функциональных областей, например для управления ресурсами предприятия, телекоммуникационных процессов стандарта eTOM или поддержки клиентов. Обычно они включают в себя также средства мониторинга программных компонентов и управления их выполнением. Это особенно существенно с учетом непрерывного усложнения программных приложений, свою лепту в которое вносит добавление в корпоративную архитектуру слоя прикладных платформ.
Таким образом, все более популярной становится новая идеология создания программных систем: покупаем полуфабрикат (прикладную платформу), на основании которого проектируем и собираем собственное программное решение, а в дальнейшем по мере необходимости развиваем и расширяем его. Все это сильно отличается от ситуации, когда решаются краткосрочные задачи с наименьшей затратой усилий или покупается готовый дорогостоящий продукт, очень тяжело внедряется, а потом все нововведения обязательно проверяются на возможность их поддержки во внедренной системе.
Типы и характеристики прикладных
платформ
Прикладные платформы можно разделить на два вида: технические и функциональные. Первые в простейшем варианте представляют собой развитые средства разработки (например, на Java, и тогда сюда же следует отнести виртуальную машину Java, необходимую для выполнения разработанных программ). Подобные платформы годятся для создания прикладного решения в любой функциональной области, на них можно построить что угодно. В некотором смысле это просто развитые средства разработки. Вторые обычно включают функциональные компоненты, автоматизирующие отдельные функции бизнес-процессов в определенной предметной области. В этой области функциональная платформа предлагает программные компоненты, которые можно использовать в программном решении с простейшими настройками.
В свою очередь, технические прикладные платформы можно разделить на несколько типов:
- по поддерживаемым ОС и программным языкам;
- по возможностям расширения и добавления новых компонентов.
Функциональные прикладные платформы также можно разделить на несколько типов:
- по охватываемой функциональной области (чем уже область, тем более «готовые»
программные компоненты могут в нее входить и, значит, тем проще создание ПО
на такой платформе);
- по объему и качеству предоставляемых сервисов, технических и функциональных;
- по уровню предоставляемых средств построения ПО (от высокоуровневого моделирования до написания кода на языке программирования).
В качестве основных специфических характеристик прикладных платформ обоих типов надо назвать следующие:
- зрелость платформы (насколько быстро и просто можно разработать на ее основе
готовое ПО);
- функциональные границы (какого типа ПО можно на ее основе создавать);
- простота (насколько быстро и просто можно ее освоить).
Уже сформировались стандарты прикладных платформ. В качестве наиболее популярного стандарта необходимо назвать Java 2 Platform Enterprise Edition — стандарт, объединяющий J2EE Application Server, J2SE и средства разработки и построения программных систем в стандарте J2EE и Web-сервисов.
Другим стандартом, к которому часто обращаются разработчики прикладных платформ технического вида, является технология CORBA, в частности протокол IIOP и объектные сервисы. Прикладные платформы функционального вида все чаще строятся на основе стандартов бизнес-процессов, относящихся к области BPM (Business Process Management). К наиболее популярным стандартам этого типа относятся BPEL (Business Process Execution Language), BPML (Business Process Modelling Language) и BPMN (Business Process Management Notation). В списке стандартов, лежащих в основе прикладных платформ, необходимо упомянуть также SOA как идеологическую основу построения многих прикладных платформ.
Основными игроками рынка универсальных прикладных платформ, а именно платформ, не привязанных к отдельной функциональной области, являются IBM (Web Sphere), BEA (Web Logic), Oracle (Application Server). К числу других следует отнести Cordys, InterSystems, Novell, SAP и Sun Microsystems (данные взяты из отчетов Gartner Group). В отдельных функциональных областях имеются свои игроки: например, SAP является лидером в области прикладных платформ для управления ресурсами предприятия. Кроме того, можно назвать Oracle и Microsoft. Однако надо сказать, что в целом рынок прикладных платформ все еще довольно беден, и при выборе конкретного решения предприятие оказывается перед лицом существенных рисков и проблем.
При этом выбрать прикладную платформу оказывается еще труднее, чем определиться с тиражируемым программным решением. Дело в том, что здесь появляется еще одна степень свободы, связанная со специфическими свойствами прикладных платформ, описанными выше, и прежде всего с их зрелостью.
Прогноз развития моделей создания
прикладных систем
Рост популярности прикладных платформ вовсе не означает, что все программное обеспечение будет строиться на их основе. Заказные или собственные разработки, о полной и окончательной гибели которых уже не раз говорили, вовсе не собираются уходить со сцены. Существуют определенные, обычно узкоспециальные задачи, которые выгоднее и рациональнее разрабатывать на языках программирования, получая мобильные, легко обслуживаемые модули. Настраиваемые программные системы также весьма привлекательны, конечно, в тех случаях, когда точно соответствуют потребностям предприятия, причём не только на момент внедрения, но и на некоторый период времени, в течение которого хотя бы окупятся затраченные на них средства.
Мне хотелось бы остановиться на развитии моделей создания прикладных систем (см. таблицу). Я выделила несколько наиболее популярных и перспективных вариантов. Думаю, что прикладные платформы будут активно развиваться и завоевывать рынок. Индивидуальная разработка, как я уже отмечала, также никуда не исчезнет. Однако нельзя забывать, что для разработки бизнес-приложений собственными силами компания должна обладать очень высокой культурой в области информационных технологий.
| Тип ПО | Индивидуальная разработка с использованием библиотек классов различных типов | Автоматическая генерация кода на основе построенных моделей | Низкоуровневая платформа, сервер приложений с основными "системными" сервисами* | Функциональная прикладная платформа с набором готовых прикладных сервисов и инструментами прикладного конструирования -- сборки, конфигурирования, описания процессов, а также пользовательских интерфейсов | Функциональная прикладная платформа с набором готовых модулей и шаблонов пользовательских интерфейсов, позволяющая собрать программное решение без программирования | Тиражируемое программное решение с настройками |
| Тип приложений | Отдельные узкоспециализированные функции, приложения реального времени, драйверы устройств | Некритические приложения; по мере развития и совершенствования инструментов автоматической генерации расширение области использования | Критические для бизнеса приложения | Интеграционные решения, Web-приложения, порталы, системы типа workflow | Корпоративные приложения, сочетающие как стандартные (например, выполнение требований законодательства), так и уникальные бизнес-процессы | Стандартный функционал (Web-сайты, системы дистанционного обучения, бухгалтерия, налогообложение) |
| Бизнес-требования к ПО | Реализация специальных требований и уникальной функциональности | Время важнее качества | Необходимо высокое качество системных функций, устойчивая и надежная работа приложения | Уникальность и сложность объекта автоматизации | Сложный и большой функционал при ограниченном времени на создание и внедрение системы | Простота использования и поддержки, скорость внедрения |
| ТСО | Высокая | Высокая | Средняя | Средняя | Средняя | Низкая |
| Тип компаний | Разработчики прикладных программных систем | Мелкие компании – разработчики, выходящие на рынок; подразделения ИТ с высокой квалификацией | Крупные и средние | Крупные и средние | Крупные и средние | Средние и малые |
| Уровень развития ИТ в компании | Высокая культура разработки | Высокий | Высокий | Очень высокий | Средний | Низкий |
| Перспективы | Область использования будет постепенно сужаться, но не исчезнет | Будет активно использоваться для нестандартных задач | Станет основной для высокотехнологичных малых и средних компаний с уникальными бизнес-задачами | Станет основной для развитых средних и крупных компаний | Станет основной для средних и крупных компаний, не имеющих сильных ИТ-подразделений | Станет основной для мелких компаний или компаний с низким уровнем ИТ |
Следующая модель создания прикладных систем — автоматическая генерация кода на основе построенных решений. В России и на Украине к идее автоматической генерации кода относятся очень прохладно, однако в других странах мира у нее есть много приверженцев. Такая модель несомненно имеет право на существование в силу высокой скорости и удешевления процесса разработки, и она будет развиваться дальше, особенно для тех задач, где не требуется очень высокое качество программного кода. А ведь ситуации, когда время важнее качества, встречаются нередко.
Третья модель — низкоуровневая или техническая платформа. Она уже сейчас широко применяется для создания критически важных для бизнеса приложений, например, биллинговых систем. Думаю, что для такой модели уровень развития ИТ в компании должен быть также достаточно высок, поскольку ее поддержка предполагает высокую квалификацию персонала. На мой взгляд, в ближайшие два-три года эта модель будет основой для большей части программных систем. Однако в дальнейшем она уступит позиции двум следующим моделям.
Четвертая модель — функциональная платформа с набором готовых прикладных сервисов и инструментарием прикладной разработки. Часть приложений уже сегодня делается на таких платформах, например многие популярные системы документооборота. Думаю, что в недалеком будущем на таких платформах будут разрабатываться различные корпоративные системы. Уровень ИТ в компании для этой модели также должен быть высоким, потому что создание программного решения на такой платформе обычно сопровождается разработкой дополнительных специфических компонентов.
Пятая модель — функциональная прикладная платформа с набором готовых модулей и шаблонов пользовательских интерфейсов, позволяющая собрать программное решение без программирования, — на мой взгляд, в будущем станет основной моделью для создания приложений в средних и крупных компаниях, не имеющих своих сильных ИТ-подразделений.
Наконец, последняя, шестая модель — тиражируемая программная система — также никуда не исчезнет. Такие системы будут использоваться мелкими и средними компаниями для относительно быстрой автоматизации отдельных стандартных задач. Однако к ним будут предъявляться строгие требования по гибкости и интеграционным возможностям.
В заключение необходимо отметить, что грамотная архитектура слоя программных приложений должна представлять собой гармоничное сочетание трёх основных типов программных решений: настраиваемых тиражируемых программных систем, прикладных платформ и разработанного под конкретные задачи ПО. Методика построения подобной архитектуры может быть, например, следующей. Из задач, стоящих перед ИТ, выделяются те, которые покрываются готовым ПО и при этом в ближайшие годы не потребуют существенных изменений. Из остальных задач выделяются крупные функциональные «подвижные» части, для которых наилучшим образом подходят прикладные платформы. Оставшиеся отдельные задачи реализуются на выбранных платформах, а если это неэффективно, то путем разработки в программных кодах.
Не стоит вести споры о том, какой путь лучше — заказная разработка, готовое тиражируемое решение или нечто промежуточное. Корпоративная архитектура современного предприятия объединяет различные подходы, а современные стандарты и технологии умеют сочетать разные программные решения для построения единой прикладной среды предприятия.
