Облачный опыт: как мы переводили KPI Suite на платформу Azure

в 11:10, , рубрики: .net, #isvcloudstory, azure, kpi suite, Microsoft Azure, Блог компании Microsoft, Облачные вычисления, облачные сервисы

Мы рады поделиться с вами очередной статьей из серии статей от наших партнеров независимых разработчиков ПО. В этот раз свою историю успеха перевода решения на облачные рельсы рассказывает Мгер Парунакян, руководитель компании «KPI Lab». Все истории успеха вы можете найти по ссылке #isvcloudstory — Владимир Юнев

Платформа KPI Suite начала набирать популярность благодаря своей универсальности, удобства использования, популярного языка программирования C#. На платформе можно создавать различные системы оценки, по различным методикам, реализовать возможности форматного сбора данных вручную, экспертных оценок.

Облачный опыт: как мы переводили KPI Suite на платформу Azure - 1

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

Изыскания начались в 2010 году. За основу были взяты

  • СУБД: MS SQL сервер
  • ОС: Windows
  • Клиентское приложение: Silverlight
  • Язык: C# + дополнительное собственное API
  • Веб сервер: IIS
  • .NET Framework

MS SQL был выбран из соображений непритязательности в администрировании, доступности по цене и распространенности. Доступны также девелоперские версии, которые можно использовать при разработке.

Silverlight на момент начала был более удобен, чем HTML5. И было принято решение начать на Silverlight и далее сделать миграцию на стабильную версию HTML5.

За ОС взяли Windows платформу, также из-за распространенности.

Язык выбирали так, чтобы будущие пользователи не затруднялись в поиске специалистов. Чем больше специалистов на рынке, тем безопаснее брать ПО. C# оказался хорошим выбором с нашей точки зрения. Тем более .NET

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

Решения можно создавать различные. К ним относятся методики по оценке компании, департаментов, эффективности сотрудников, сбалансированная система показателей, форматные сборы данных и т.д.

Система состоит из 4 основных элементов и пары вспомогательных

Основные:

  • Структуры данных
  • Дашбоарды
  • Интеграция
  • Библиотеки изображений и документов

Вспомогательные:

  • Управление задачами и поручениями
  • Скрипты
  • Календарь
  • Администрирование и поддержка
  • Библиотека метаданных

Структуры данных

Это тип элемента системе, в котором содержатся наши данные. См. рис. 1

Облачный опыт: как мы переводили KPI Suite на платформу Azure - 2

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

  • Рассчитываемые
  • Интегрированные с источниками
  • Для ручного ввода

Облачный опыт: как мы переводили KPI Suite на платформу Azure - 3

В рассчитываемых ячейках можно пользоваться языком C#. API разработчика предоставляется вместе с пакетом лицензий. Также должны быть определены иерархии, такие как, к примеру, календарь. Он определит значение в ячейках за определенный период. Примером использования может быть расчет годового значения показателей суммируя ежемесячные.

В каждом элементе также могут быть определены:

  • Свойства – статические параметры (список изменяемый)
  • Минидашбоарды – внешний вид, используемый для разных дашбоардов
  • Присоединенные задачи, мероприятия. События из календаря

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

Облачный опыт: как мы переводили KPI Suite на платформу Azure - 4

Показатели могут бать как количественные, так и качественные, с весами и без. Система дает полные права разработчику самому определять политику построения данных.

Элемент используется не только для вывода данных, но и для ввода.

Изменения данных можно производить несколькими способами:

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

Дашбоарды данных

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

Облачный опыт: как мы переводили KPI Suite на платформу Azure - 5

Они бывают:

  • для элементов
  • для структур данных
  • отдельные

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

Как писалось ранее, палитра элементов разнообразна, начиная от диаграмм, заканчивая полями ввода данных, фильтров.

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

Также можно перемещаться между дашбоардами и экспортировать их в разные форматы файлов.

Библиотеки данных

Библиотеки бывают 2 типов

  • документы – необходимы для хранения документов в системе, присоединения документов к показателям за период (к примеру подписанные приказы и т.д.), присоединения к мероприятиям
  • изображения – необходимы для придания эстетичности нашим дашбоардам

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

Интеграция данных

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

Разработан механизм, который дает возможность присоединиться к внешней таблице, считать данные, произвести сопоставление (matching) данных из таблицы с нашими метаданными и получить непосредственно данные в нашу систему. Задание можно запускать по расписанию.

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

Практика Azure

Первое, что мы начали проверять возможность подключения группы доступности. Достаточно интересный механизм обеспечения работоспособности системы. Т.е. заводится группы. В ней находится несколько виртуальных машин. Есть главная, остальные на подхвате. Если первый сервер перестает отвечать, второй поднимается и работает вместо первого. Не отвечать сервер может по разным причинам, к примеру обновление системы, которое производится самой Azure.

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

С точки зрения затрат, намного интереснее иметь несколько небольших машин, чем одну супервиртуалку, так как нагрузка, в течение рабочего дня, высокая, а вне – низкая. Стоимость же супервиртуалки будет высокая все 24 часа, а в случае небольших машин – они будут отключаться и не тратить средства.

Развитие

На семинаре (workshop) Microsoft в августе, посвященному Azure, было принято решение о разработке Microsoft Outlook Add-on. Об этом готовится новая статья.

Об авторе

Парунакян Мгер СамвеловичОблачный опыт: как мы переводили KPI Suite на платформу Azure - 6
Руководитель компании «KPI Lab»

Опыт на должности руководителя организации более 12 лет, основная специализация – общее руководство компанией, отделом продаж, управление проектами, ведение переговоров; создание новых направлений деятельности, разработка партнерской сети; ведение проектов от первой презентации до закрытия работ.

  • 15 лет, построение комплексных систем оценки деятельности
  • 14 лет, управление разработками ПО
  • 3 года, проектирование b2b систем
  • Более 5 лет работы в иностранных компаниях на руководящих должностях

Автор: Microsoft

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js