Методы совершенствования прикладных бизнес-систем весьма разнообразны, и среди них есть такие, которые на отечественных предприятиях пока используются не слишком активно.

Тема развития ключевых систем поддержки бизнес-процессов может быть разбита по крайней мере на несколько более детальных направлений, но в общей постановке она безусловно является одной из важнейших для ИТ-директора. Поэтому задумывая тему номера, посвященную такого рода вопросам, мы решили пойти, что называется, от обратного, полагая, что имеющиеся сейчас на отечественном рынке методы развития транзакционных систем поддержки основных бизнес-процессов (а именно их мы прежде всего будем иметь в виду в данном случае) легко можно подразделить в соответствии с элементарным принципом: используемые часто и используемые редко. По нашему мнению разговор о совершенствовании основных бизнес-систем на российском рынке следует сосредоточить вокруг перспектив и возможностей перехода с одной прикладной системы на другую — более мощную. Если такой вариант по каким-либо причинам предприятию не подходит или резерв в отношении функциональности самого продукта уже достигнут, есть возможность развить ИТ-поддержку за счет внедрения новых модулей имеющейся системы — можно заняться собственной разработкой недостающих функций или поручить это стороннему разработчику.

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

Неклассические примеры

С нашей точки зрения к разряду не совсем традиционных способов развития бизнес-систем относится ситуация, которая описана в интервью, посвященном истории автоматизации ювелирной группы «Адамас». Несмотря на то что речь здесь во многом идет об отраслевых проблемах, и к тому же может показаться, что статья посвящена довольно традиционным моментам совершенствования технологий автоматизации, нам представляется, что это не совсем так. Несомненно, очень интенсивное совершенствование прикладных систем в настоящее время ведётся не путем замены «старой» системы на более мощную, не за счет разработки и внедрения новых функциональных модулей, наконец, не наращиванием мощности аппаратно-программной инфраструктуры (хотя последнее, как и в любой компании, безусловно имеет место). В данном случае мы и вправду говорим о создании новой версии прикладной системы, но отнюдь не о наращивании функций, а скорее наоборот — о передаче заметной их части другим внедряемым на предприятии продуктам. Именно на попытках вписать новую версию в существующий и планируемый к развитию прикладной ландшафт, а также на вопросах смены технологической платформы собственно и будет сконцентрирован процесс разработки.

Второе, пока нетрадиционное с нашей точки зрения направление совершенствования прикладных систем связано со следующей ситуацией. Имея в арсенале целый набор традиционных, в целом эффективных и очень неплохо отработанных на практике способов апгрейда приложений, имеющего целью повышение их функциональности и производительности, заказчики и по сей день затрудняются ответить на некоторые вроде бы даже не самые сложные вопросы. Если у нас действительно проблема с производительностью, то является ли обязательной закупка нового оборудования (более производительного с точки зрения вычислений и ввода-вывода данных), или все-таки можно изыскать некоторые резервы по повышению быстродействия работы конкретных бизнес-систем в конкретной конфигурации и в конкретном инфраструктурном ландшафте? Если система не предусматривает работу в режиме Web-интерфейса, который остро востребован в случае географического расширения бизнеса, означает ли это, что мы должны сменить ее на другую? Если у нас медленно выполняется бизнес-процесс, то можем ли мы локализовать проблему? А локализовав ее, имеем ли право утверждать, что проблема в недостаточной квалификации определенной группы пользователей, или же имеются вполне определенные резервы в отношении технических возможностей доступа? На подобные вопросы без специального инструмента (опять-таки автоматизации) ответить очень сложно, даже если информационный ландшафт предприятия не слишком сложен. Направлению, которое помогает справиться с подобными задачами, посвящено интервью с ИТ-директором Магнитогорского металлургического комбината (ММК) Дмитрием Капланом (стр. 46).

Через APM — на новый уровень

В случае ММК речь идет об инструментах класса Application Performance Management (APM) — средствах управления производительностью приложений, позволяющих более эффективно использовать имеющееся оборудование и программные комплексы. Поскольку подобные системы сегодня не слишком популярны в России (гораздо шире они приняты на американском рынке), скажем о них несколько слов. А заодно и о смежных инфраструктурных решениях, так или иначе направленных на улучшение работы прикладных программных продуктов, эксплуатируемых в компании и развиваемых исключительно благодаря существованию последних. Занимаются подобными системами, например, такие компании, как Quest Software, Precise, CA, Citrix, F5, Embarcadero, EMC, Riverbed Technology. Наверное, многие читатели согласятся, что данные производители либо практически неизвестны в нашей стране, либо если и из­вестны (и порой даже очень широко), то в силу присутст­вия в их линейке совершенно других продуктов.

Начнем с некоторых тезисов, высказываемых представителями Магнитогорского металлургического комбината. В нашей собственной интерпретации вкратце они таковы. Крупное (именно крупное, что очень важно) предприятие рано или поздно приходит к некому порогу в отношении традиционных способов улучшения производительности (а в общем случае и иных «системных» характеристик, например доступности) прикладных систем по целому ряду причин. А классическая схема аппаратного апгрейда при этом из-за проявляющейся с ростом сложности систем нелинейной зависимости «стоимость апгрейда — процент увеличения производительности» становится все более неэффективной. Система i3, внедренная на ММК, призвана обойти указанную проблему, о чем довольно подробно рассказано в интервью. Однако вместе с этим ее использование раскрывает еще целый ряд довольно любопытных и по всей видимости абсолютно новых для российского рынка моментов.

Во-первых, интеллектуальный мониторинг производительности, сопряженный со средствами анализа сложившейся ситуации, заставляет рассматривать по меньшей мере два пути «лечения» обнаруженных проблем. Можно сделать выбор в пользу программной модернизации того или иного компонента программного обеспечения или сделать аппаратный апгрейд; при этом существует также возможность комбинированного подхода. А это значит, что системы APM (и в интервью эта мысль звучит явным образом) имеют прямое отношение к инструментарию управления разработкой внутри организации. Средства APM, как утверждается в статье, не заменяют профессиональных инструментов разработчика, а скорее дополняют их, позволяя ясно видеть задачу программной доработки в конкретной ситуации наличия различных прикладных и инфраструктурных систем и даже предлагать высокоуровневые решения в области создания ПО (например, альтернативные варианты SQL-кода).

Во-вторых, интересной особенностью эксплуатации APM на ММК является то, что она кроме всего прочего служит рычагом повышения эффективности управления ИТ-процессами и работы с показателями уровня сервиса (SLA). А коль скоро это так, то системы APM удачно дополняют функции известных систем управления ИТ-инфраструктурой и ИТ-процессами, многие из которых уже широко применяются в том числе и в российской практике.

Данный момент представляется важным еще и по той причине, что инструменты эти на российском рынке постепенно начинают применяться для все более высокоуровневых задач. Это видно как по некоторому изменению акцентов в продуктовых предложениях, так и по повышению культуры применения подобных систем самими пользователями. Переход от простого мониторинга функционирования инфраструктуры к проактивному, о чем мы, кстати, неоднократно рассказывали на страницах нашего издания, служит по сути первым шагом на этом пути. Более «продвинутой» ситуацией является применение средств класса Business Service Management (BSM), о чем мы также рассказывали в журнале (IE, №20/2006, стр. 20). Здесь от мониторинга инфраструктуры мы переходим к возможности привязки тех или иных характеристик ее функционирования к параметрам выполнения бизнес-процессов. И это уже гораздо ближе подводит нас к возможностям того класса систем, о котором мы говорим сейчас. Именно это, думается, имеют в виду специалисты ММК, когда говорят о некотором пересечении функций систем i3 и CA Unicenter, используемых на комбинате.

Из всего сказанного напрашивается, как нам кажется, важный вывод. Состоит он в том, что более широкое распространение систем Application Performance Management по крайней мере на крупных российских предприятиях может не только стать новым для отечественного рынка направлением совершенствования работы прикладных систем, но и стимулировать более качественное применение традиционных способов, о которых мы говорили в начале. Ведь логично допустить, что за традиционные методы совершенствования прикладных систем могут (каждый со своей стороны) отвечать ИТ-аналитики компании, подразделения, ответственные за разработку ИТ-систем, а также специалисты в области программной и аппаратной инфраструктуры. А если это так, то, думается, из сказанного выше ясно, что инструменты класса APM в определенной мере еще и состыковывают между собой все традиционные направления развития бизнес-систем.

На самом деле системы, подобные той, что используется на ММК, на рынке существуют, но создаётся такое впечатление, что четкой классификации самих категорий инфраструктурного ПО, направленного исключительно на повышение различных характеристик работы прикладных систем, не существует. И соответственно многие их функции пересекаются. Все эти системы так или иначе связывают работу прикладных систем и инфраструктуры, а некоторые из них включают в свой пул еще и средства программной инженерии. Почти всё подобное ПО на российском рынке также пока не слишком популярно, хотя соответствующие предложения вроде бы и есть. Существуют также продукты Application Мanagement, объединяющие в себе, пожалуй, самый широкий и наименее стандартизированный набор функций. Именно поэтому конфигурация входящих в продукты этой категории составных решений может быть весьма различной. Такие продукты есть, например, у компаний Quest Software и EMC. Может быть, в отдельную категорию следовало бы выделить инструменты класса Application Delivery, позволяющие максимально задействовать все имеющиеся у поставщика возможности, чтобы за счет различных схем оптимизации системных и прикладных протоколов ускорить доставку прикладного функционала систем к конечному потребителю. Кстати, всё это может быть реализовано как программными, так и аппаратными средствами, и подобные решения есть, скажем, у компаний Citrix, F5 или Riverbed Technology. Об одном небольшом, но вместе с тем весьма показательном в контексте нашего разговора проекте внедрения решений Riverbed Technology мы рассказали в рамках данного выпуска (стр. 45).

После всего сказанного вернемся к проекту в «Адамасе», отметив, что описанное развитие информационной под­держки по принципу соединения нескольких систем и информационных ресурсов для решения единой задачи управления ассортиментом так или иначе делает ландшафт прикладных ИТ-систем более разнообразным и сложным. Всё это в будущем может поставить вопрос о применении систем класса Application Management или же о создании соответствующей разработки. Ведь для платформы Java, на которую планируют перейти в «Адамасе», помимо множества программных интерфейсов есть и такой.