Будущее "Галактики" — на платформе Microsoft .NET
Геннадий Гацко,
первый вице-президент корпорации "Галактика",
руководитель управления разработки
Опыт показывает, что эффективность использования управленческих систем и ИТ на предприятиях наряду с функциональными возможностями применяемых систем весьма сильно зависит от их архитектурных особенностей. Они влияют на основные факторы и составляющие процесса эксплуатации (сказываясь также на общей стоимости владения): сопровождение (в частности, устранение ошибок и обновление версий), адаптацию к специфике предприятия и динамичным условиям бизнеса, возможность функционального расширения (доработок), в том числе силами самой компании или сторонних разработчиков, включение в системы сторонних компонентов, расширяющих круг решаемых прикладных задач, интеграцию с другими системами (в том числе специализированными, например, САПР, АСУТП).
Корпорация "Галактика" (http://www.galaktika.ru)
работает над развитием архитектуры систем для управления предприятием в двух
направлениях. Первое — это улучшение существующих решений, развитие системы
в рамках имеющейся архитектуры (эволюционный путь). Второе направление — разработка
системы в новой архитектуре, которая должна дать новый импульс бизнесу, обеспечить
качественный скачок (революционный путь).
Двигаться по первому пути необходимо, хотя бы потому, что систему в существующей архитектуре использует множество клиентов, включая крупные корпорации. И они в настоящее время, как правило, не заинтересованы в переходе с продукта в нынешней архитектуре ("Галактика") на продукт в принципиально новой архитектуре ("Галантис"), поскольку это недешевый проект. Поэтому мы намерены развивать функционал и совершенствовать имеющуюся архитектуру столько, сколько это будет необходимо нашим клиентам. Пока, кроме находящейся в промышленной эксплуатации версии 5.8 системы "Галактика", к этому направлению относятся версии 7.1 и 8.0.
Второе направление связано с тем, что корпорация считает необходимым обеспечить своим пользователям конкурентные преимущества в будущем. Информационные системы, способные обеспечить такие преимущества, должны, на наш взгляд, обладать целым комплексом свойств, включая распределенность, многоплатформность, широкую поддержку общепринятых стандартов, возможность взаимодействия с другими системами (данными) при невысокой общей стоимости владения (TCO). Эти свойства более полно, эффективно и с меньшими затратами реализуются в условиях универсализации и стандартизации платформ, на которых базируются ИС, — именно этот процесс сейчас активно идет в мировой ИТ-индустрии. В долгосрочной перспективе выбор той или иной универсальной платформы становится вопросом времени (или готовности разработчика).
Основные вехи развития продуктов "Галактики" по обоим направлениям перечислены в таблице, а ниже мы рассмотрим их подробно.
Основные вехи развития продуктов "Галактики"
| Продукт и версия | Особенности | Архитектура | Состояние продукта |
| Галактика 5.8 | Галактика-Финансы. Комплекс решений по управлению финансами предприятия | Существующая | Коммерческий продукт |
| Галактика 7.1 | Галактика-Производство. Комплекс решений для управления производством (MRP II) |
Существующая | Коммерческий продукт |
| Галактика 8.0 | Эффективность. Открытость. Качество. Развитие существующей архитектуры с целью повышения открытости, расширения аутсорсинга, повышения эффективности использования и сопровождения |
Существующая | разработке (проект "Эффективность. Открытость. Качество) |
| Галантис 1.0 | Продукт нового поколения. Система со свойствами бизнес-конструктора, реализована петля управления и WorkFlow, есть инструментарий для адаптации и развития |
Новая, на платформе .NET | разработке (проект "Галантис) |
Эволюция "Галактики"
Поговорим более подробно о существующей архитектуре и версиях системы "Галактика". В ее основе лежит собственное средство разработки "Атлантис", написанное на C++ и Delphi. Включает компиляторы с собственного языка 4GL — VIP, собственную среду исполнения бизнес-логики и визуальной части. Продукт поддерживает быструю разработку (RAD), интегрирован с COM. "Атлантис" обеспечивает независимость прикладного кода от выбранной СУБД (Pervasive SQL, Microsoft SQL, Oracle), т. е. один и тот же прикладной код без изменений работает со всеми указанными СУБД.
С использованием "Атлантиса" разработаны текущая коммерческая версия системы "Галактика" 5.8 и готовящаяся к выходу версия 7.1. В данных продуктах получили дальнейшее развитие средства управления финансами (бюджетирование, оперативный финансовый менеджмент, финансовый анализ), входящие в версию "Галактика-Финансы" (5.8). Улучшены (на основе предложений пользователей) корпоративные свойства системы (управление корпоративными ресурсами, консолидация учетной информации), решения для управления персоналом, капитальным строительством, взаимоотношениями с клиентами и договорными отношениями.
Версия 7.1 представляет собой полный комплекс решений по управлению производством, в который вошли следующие модули:
"Управление заказами" — оформление заявок на производство продукции
(выполнение работ, услуг), формирование портфеля заказов, а на его основе —
планов сбыта (поставок) готовой продукции, подготовка данных для формирования
связанных планов в сопряженных модулях.
"Планирование производства" — формирование плана производства продукции,
расчет потребностей в материалах и полуфабрикатах, формирование заказов службе
МТО, планирование загрузки производственных мощностей с учетом ограничений по
ресурсам оборудования и персоналу. Разработка альтернативных планов, расчет
стоимости их реализации, сравнение и выбор оптимального плана.
"Материально-техническое обеспечение" — оформление заявок на обеспечение
плана производства, включение в портфель закупок, формирование и контроль исполнения
плана снабжения, графиков закупок.
"Спецификации продуктов" — ведение материальных норм для продукции с
использованием производственных и конструкторских спецификаций (для машиностроения).
Описание технологии изготовления с помощью маршрутных карт, нормирование времени
и расхода материалов, использования оборудования и оснастки, по технологическим
операциям.
"Учет в производстве" — ведение первичных документов оперативного учета,
включая лимитно-заборные карты, накладные на передачу материальных ценностей,
акты на списание, на оказание цеховых услуг. Автоматизированное формирование
документов по бизнес-схемам, в соответствии с реальным документооборотом предприятия.
Консолидация данных в сменных производственных отчетах, контроль производства
с точностью до конкретной партии продукции, сырья или стадии техпроцесса.
"Контроллинг" — управленческий учет, включая формирование фактического
производственного баланса, расчет плановых и учет фактических затрат на производство,
калькулирование себестоимости продукции по различным схемам (absorption costing,
direct costing и т. д.). Выявление наиболее затратных статей для соответствующих
управляющих воздействий.
Функционал перечисленных компонентов и реализуемые с их помощью бизнес-схемы соответствуют стандарту MRP II. В сочетании с имеющимися решениями для управления финансами, персоналом, логистикой можно говорить о реализации в системе базовой концепции ERP. Широкие возможности настройки в сочетании с большим набором типовых алгоритмов и шаблонов документов позволяют эффективно применять систему в различных отраслях и на предприятиях с разным типом производства.
Однако вопросы развития архитектуры для компании не менее важны, чем расширение функциональных свойств и набора решаемых прикладных задач. Сейчас в "Галактике" выполняется проект "Эффективность. Открытость. Качество" (его название подчеркивает стратегическую цель разработки). В рамках проекта продолжается активное развитие "Атлантиса" (сейчас тестируется его 5-я версия), ведется разработка версии 8.0 системы "Галактика".
Основная особенность версии 8.0 — развитие в первую очередь общесистемных (нефункциональных)
свойств продукта. Ключевые результаты, которые планируется достичь:
- полная реализация трехуровневой архитектуры;
- завершение перехода к объектным технологиям;
- реализация компонентной модели с поддержкой независимой разработки и сопровождения
компонентов;· - реализация "тонкого клиента".
Цель такого развития — сделать работу пользователей с системой более эффективной, в частности, за счет оперативных доработок и расширения функционала непосредственно "на местах", т. е. силами самого клиента или работающего с ним партнера, за счет интеграции с другими программными продуктами, при повышении надежности и других показателей качества.
Одновременно с разработками ведется работа с партнерами "Галактики" (презентации новых решений, обучение, сертификация партнеров-разработчиков) с тем, чтобы к моменту выхода версии 8.0 они были готовы ее использовать. Это лишний раз подтверждает намерение компании продолжать работы в рамках существующей архитектуры до тех пор, пока это востребовано нашими клиентами.
К новой архитектуре
Когда возможности старой платформы будут исчерпаны, задумываться о переходе на новую окажется уже поздно (особенно, если "широкие массы" к тому времени уже испытают и оценят преимущества нового). Решения, привлекательные для потребителей, должны быть уже наготове. Если при этом не ориентироваться на самые современные разработки, возникает риск оказаться на обочине…
Выбор новой платформы — очень непростой и ответственный момент. Когда в работу над программным продуктом вовлечены сотни людей, число клиентов измеряется тысячами, лицензий — десятками тысяч, это становится ключевым вопросом развития бизнеса. Решение требует объективного и всестороннего анализа, с учетом интересов и клиентов, и партнеров, и самой корпорации.
Анализ различных вариантов у нас начался летом 2000 г., знакомство с Microsoft .NET — в сентябре. Напомним, что в августе 2000 г. уже был общедоступен Technology Preview (альфа-версия Framework SDK, включающая работоспособные примеры и концептуальные описания платформы .NET).
По мере знакомства отпали варианты построения новой системы, ограниченные рамками спецификации COM. Появление .NET переводит COM в разряд пройденных этапов. Вероятно, с помощью более проработанных и освоенных на текущий момент решений COM можно вести разработки программных продуктов более быстрыми темпами. Но их результаты окажутся морально устаревшими, когда широкий круг потребителей реально ощутит преимущества платформы .NET. При этом перенос прикладных решений из одной архитектуры в другую будет весьма сложной задачей.
Чтобы пояснить этот тезис, придется сделать небольшой экскурс в историю развития компонентных технологий.
Появление библиотек DLL обеспечило физическую независимость компонентов от языка разработки — стало достаточно указать точку входа и соглашение о вызове. Но речь шла только о вызове функций. Понятие объекта отсутствовало.
Технология СОМ, сохраняя ту же возможность и физическое представление (DLL), обеспечила возможность установить на этапе исполнения динамическую связь и взаимодействие по интерфейсам между объектами (ко-классами). Связывание происходит по индексам и глобальным идентификаторам (GIUD).
Концепция .NET, кроме спецификации взаимодействия, специфицирует и среду исполнения, что обеспечивает физическую независимость компонентов от аппаратной платформы. Динамическое связывание компонентов, классов и их функций происходит по имени с верификацией по публичным ключам (Public keys), причем за счет компиляции во время исполнения (JIT) это не приводит к проигрышу по быстродействию по сравнению с COM.
Можно сказать, что есть всего два концептуальных отличия .NET от COM — виртуализация и расширяемость метаданных. Но эти различия столь же принципиальны, как и различия между технологиями DLL и COM, и требуют такого же пересмотра архитектуры приложения.
Метаданные
Уже в технологии COM введено понятие метаданных компонента, позволяющих декларативно описывать способ взаимодействия с ним. И именно благодаря им появилась возможность разработки на основе COM технологий, подобных DCOM, ActiveX, ActiveDocument и т. д.
Но главное отличие в том, что метаданные СОМ нерасширяемы, т. е. оперируют только заранее предусмотренными понятиями (как правило, уровня системы), в то время как в .NET можно создавать собственные (прикладные) слои метаданных на уровне компонентной модели. Расширяемость метаданных позволяет создавать высокоуровневые инструменты и технологии работы с компонентами, например, оперирующие в терминах бизнес-логики.
Виртуализация
COM — это всего лишь двоичный (бинарный) стандарт (спецификация) взаимодействия компонентов плюс некоторый набор стандартных интерфейсов. СОМ оперирует терминами "смещение в таблице виртуальных функций", "стандарт вызова" и никак не специфицирует среду исполнения — для него в качестве среды исполнения выступает непосредственно процессор компьютера.
В результате компонент COM, физически реализованный в виде DLL, не будет переносим между разными типами процессоров. Данное ограничение в принципе невозможно преодолеть без полной эмуляции соответствующего процессора. Один и тот же COM-компонент не сможет работать одновременно на RISC-процессоре и X86, а тем более на 32- и 64-разрядных процессорах. Оптимизация для определенного типа процессора возлагается на сам компонент, технология же COM не предоставляет возможности разработать универсальные механизмы оптимизации.
.NET, напротив, вводит понятие виртуальной машины исполнения, которая берет на себя вопросы оптимизации исполнения компонента. Можно привести такой пример: на одной из конференций Microsoft продемонстрировала программу, которая на платформе .NET исполнялась в 10 раз быстрее, чем если бы логически ту же программу написать на языке С++ и скомпилировать в native-код.
Многоплатформность
Фактически выше мы затронули один из аспектов многоплатформности. Поскольку это широкое понятие, выделим в нем несколько уровней.
Независимость от архитектуры процессора. Как заявляет Microsoft, .NET
присутствует во всех версиях ее 64-разрядных операционных систем, причем весь
managed-код исполняется и взаимодействует совершенно прозрачно между 32- и 64-разрядными
системами.
Независимость от операционной системы. Как спецификация, .NET (в отличие
от COM) не завязана на Windows, а построена на открытых стандартах. Таким образом,
вполне можно ожидать, что появятся реализации платформы .NET для других ОС,
причем необязательно от Microsoft. Когда? Это уже вопрос потребности и маркетинга.
Как только продукты на базе .NET станут широко распространенными, поддержка
.NET станет конкурентным преимуществом операционной системы — как это случилось
с эмуляцией Win32 на Linux (см., например, http://wine.codeweavers.com), хотя
эта задача на несколько порядков сложнее, чем реализация CLR, и в полной мере
не решается по причине как технических, так и лицензионных ограничений. Первые
примеры поддержки .NET в Linux и других клонах UNIX, уже сейчас доступны по
адресам http://www.go-mono.com, http://www.dotgnu.org.
Независимость от СУБД — эта тема обсуждается ниже.
Подчеркнем, что важна принципиальная возможность многоплатформности — и .NET как спецификация, в отличие от СОМ, ее предоставляет. Конкретные же свойства могут появляться по мере потребности.
.NET или Java?
Сейчас существуют только две платформы, которые в полной мере можно отнести к актуальным и универсальным: Java (точнее, J2EE + CORBA) и .NET. Окончательный выбор мы в компании "Галактика" сделали в начале 2001 г. Перечислим основные моменты, склонившие чашу весов в пользу .NET.
Более широкие или более доступные возможности .NET по сравнению с комбинацией
J2EE + CORBA. Это вполне закономерно, потому что более "свежее" решение обычно
учитывает недостатки предыдущего. Нужно отметить, что мы изучили целый комплекс
технических вопросов (см. статью А. Володько, начальника отдела ядра системы
корпорации "Галактика", "Remoting.NET, или Удаленное взаимодействие объектов
есть" в "BYTE/Россия" № 4'2002).
Единое интегрированное решение при ориентации на .NET. Казалось бы,
при этом мы "завязываемся" на одного поставщика, а альтернативный вариант дает
большую свободу выбора. Однако необходимость использования CORBA также подразумевает
привязанность к конкретной компании из числа разработчиков данной платформы,
но без гарантии получить от нее все необходимое. Кроме того, работа с несколькими
поставщиками не гарантирует полной совместимости их продуктов.
Стабильность разработчика платформы. Факторы, с учетом которых здесь
стоит отдать предпочтение Microsoft, общеизвестны.
Затраты клиентов. CORBA подразумевает, что пользователям придется покупать
дорогостоящие серверы приложений, что существенно повышает для него общую стоимость
владения программным продуктом. В то же время платформа .NET поставляется бесплатно,
в перспективе — вместе с операционной системой.
Большие возможности аутсорсинга в .NET (эта оценка сделана нами в первую
очередь для российского рынка, с учетом перспективы). Мы полагаем, что для широкого
распространения аутсорсинга определяющую роль играют "основательность" поставщика
платформы, ее стоимость, доступность, универсальность и широкое распространение,
а также совместимость между продуктами различных производителей (разными версиями
компонентов). По большинству этих параметров .NET превосходит Enterprise JavaBeans.
Уже сейчас существует рынок компонентов для .NET, несмотря на то, что коммерческий
релиз .NET появился только в начале года; расширяется также инструментарий и
набор языков программирования. Интересно, что даже Borland включает поддержку
.NET Framework в очередную версию Delphi Studio.
Упрощение обеспечения многоплатформности (интероперабельности) по СУБД.
Наш опыт показал, что выбор СУБД — реальная задача клиентов, особенно крупных
(корпоративных). Что касается .NET, никаких ограничений по использованию СУБД
здесь не предусмотрено. С точки зрения доступа к БД для .NET нет никакой разницы
между Microsoft SQL, Oracle, DB2 и СУБД других производителей. Достаточно OLE
DB-провайдера к конкретной СУБД или ADO+ адаптера (они уже имеются для всех
наиболее распространенных СУБД). Аналогичная ситуация и в Java (низкий уровень)
— там используется JDBC и требуется соответствующий драйвер.
Но проблема состоит в том, как при разработке прикладных систем добиться реальной независимости слоя бизнес-логики от СУБД. Это требует создания собственного уровня преобразования запросов, генерации и изменения БД и способа работы с данными. Хотя в EJB имеются уже готовые подобные решения, они нас не устраивают ни по стоимости, ни по функциональности и совместимости. По нашей оценке, в .NET разработать этот уровень проще.
В проекте "Галантис", который сейчас развивает компания "Галактика", данный уровень уже разработан. На первом этапе мы создали драйвер для Microsoft SQL, но наличие специального слоя позволит без особых затрат разработать драйверы для других СУБД, не меняя прикладного кода. Мы не используем никаких специфических возможностей Microsoft SQL, которые могли бы закрыть эту возможность.
Основная цель проекта "Галантис" — разработка ERP-систем на универсальной платформе .NET, с использованием ее концептуальных особенностей и преимуществ. Это продукт нового поколения, имеющий свойства бизнес-конструктора, с реализацией петли управления и WorkFlow, с инструментарием для адаптации и развития. В ходе проекта мы уже в течение года взаимодействуем с Microsoft в статусе Early Adopter.
Все-таки .NET!
Итак, мы выбрали платформу .NET. Попробуем перечислить ее составные части,
важные с точки зрения разработчика:
- новые концептуальные решения (виртуализация и расширяемые метаданные);
- поддержка общепринятых стандартов (например, XML, Web-сервисы);
- набор технологий (ADO+, ASP.NET, WinForms, CodeDOM, Component model, Reflection,
Security, Remoting, Interoperability и т. д.), компонентов и реализующих их
библиотек; - средства разработки и утилиты (Visual Studio.NET, Microsoft Application
Center Test), интегрированные с платформой исполнения; - набор продуктов для различного круга задач (Microsoft SQL Server, Microsoft
Office, Exchange Server и т. д.); · - среда исполнения (CLR).
Сюда же нельзя не отнести технологическую и маркетинговую поддержку Microsoft, которая помогает ускорить реализацию и повысить эффективность решений — немаловажный фактор при выполнении проектов.
Таким образом, говоря о .NET, бессмысленно говорить об одной только среде исполнения (CLR), которую обеспечивает установка .NET Framework. Мы говорим о комплексной интегрированной среде проектирования, разработки, развертывания и сопровождения программных продуктов.
Для разработчика начинать переход на .NET имеет смысл уже сейчас, потому что
сделать это в сжатые сроки при возникновении конкретной потребности невозможно.
Большинство преимуществ .NET достигается только при полной переработке архитектуры
приложения. Вот неполный перечень тенденций развития индустрии ПО, которые и
должна обеспечить .NET:
- поддержка 64-разрядных процессоров и ОС, взаимодействие 32- и 64-разрядных
приложений. Независимость прикладного программного кода и компонентов от архитектуры
процессора; - распределенные приложения, интеграция, взаимодействие разных версий;
- аутсорсинг (использование сторонних компонентов, распределение разработки
различных частей и уровней системы между производителями); - Интернет-свойства системы, аренда приложений.
В цитируемых в прессе аналитических материалах Gartner Group утверждается,
что перед корпоративными пользователями не стоит вопрос, переходить или не переходить
на .NET. Вопрос стоит так — когда? (См. например, ".NET уже на подходе", "BYTE/Россия"
№ 12'2001). Мы вполне согласны с такой формулировкой и полагаем, что ответ
может звучать так: "Когда появятся системы с необходимой функциональностью"
(естественно, при условии, что они будут обладать достаточной для эксплуатации
надежностью).
Что касается другой цитируемой оценки, согласно которой "критически важные приложения" появятся через два-три года, то она требует пояснений. Если критически важным приложением считать полнофункциональную корпоративную ERP-систему, то она действительно вряд ли появится за более короткий срок. Необходимо время, чтобы построить ее в полном соответствии с идеологией .NET, ибо только так могут быть эффективно задействованы возможности новой платформы. Однако продукт с меньшей функциональностью можно создать и за более короткие сроки. Мы пошли по этому пути, рассматривая выходящий в 2003 г. "Галантис" как основу для последующего создания корпоративных систем.
Интересно отметить, что наша практика вполне соотносится с рекомендациями Gartner
по внедрению .NET. Так, аналитики рекомендуют начинать с создания приложения-прототипа.
Мы изначально запланировали и уже подготовили подобное приложение — Web-аналог
существующей корпоративной системы "Проблемы и решения" (см. врезку). Опытная
эксплуатация этого решения в офисах "Галактики", которая начата в сентябре этого
года, поможет определить потребность в доработке нового инструментария и технологических
процессов и провести их заблаговременно перед выпуском коммерческих продуктов.
Полагаем, что можно говорить о первом продукте на платформе .NET в пределах
СНГ (во всяком случае, сообщения о других продуктах нам в прессе не встречались).
Система ПИРСистема "Проблемы и решения" (ПИР) — продукт класса bug-tracking system, Сейчас система развернута в семи основных офисах корпорации. Благодаря |