Про роль техлида

Для кого эта статья?

В основном статья для технических лидеров команд разработчиков ПО и тех, кто стремится ими стать. И, конечно, для остальных, кого заинтересовала тема.  Для тех, кому интересно мнение относительно роли технического лидера, и для тех, кто готов делиться собственными соображениями на этот счет.

Что будет обсуждаться далее? В основном, это будут мысли на тему роли технического лидера, важных моментов в его работе, а также совсем немного про архитектуру и модульность.

techlead

Совсем немного о себе

Более 15 лет в разработке ПО. Опыт работы как в продуктовых компаниях, так и в аутсорсинговых, как в иностранных компаниях, так и в российских. Различные роли, включая технического лидера и архитектора.

Кто такой техлид

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

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

Попробуем определить, что вы, как технический лидер, должны делать.

  • Вы принимаете технические решения. Направляете, инициируете обсуждения при необходимости, разрешаете технические конфликты, контролируете. Ищите разные способы получения информации — метрики, отзывы или что-то еще, что приносит видимую пользу. Однако, нередко менеджмент требует от вас другого вида ответственности — за результат, сделанный за предсказуемое время, причем качественный результат. Часто принято считать, что вся команда несет ответственность за результат. Мы можем так говорить, но если за вами последнее слово в решении технических вопросов, вы можете сильнее других влиять на проект, беря таким образом на себя бОльшую ответственность. Также важно упомянуть, что отказ участвовать в решении какой-то проблемы или делегирование решения другому не избавит вас от ответственности, т.к. тоже является решением. Часть вопросов может быть ответственностью архитекторов или других заинтересованных лиц — об этом нужно знать и привлекать их при необходимости. Также не бойтесь спрашивать советы у коллег — это может помочь принять более правильное решение.
  • Вы управляете ожиданиями. Будьте предсказуемыми для своего менеджмента и заказчика. Знаете, что через 2 недели закончится итерация (спринт, проект), а вы с вероятностью 80% не успеете сделать одну из запланированных задач — соберите необходимую информацию о причинах и способах решения проблемы и обсудите с заинтересованными лицами, пока еще может быть время что-то решить. Оставите это на сюрприз в конце итерации — можете получить какой-нибудь неприятный сюрприз в ответ.
  • Вы в теме. Не проводя ревью кода и не участвуя в разработке, очень легко потерять контакт с реальностью, когда ваши слова (документы, письма и пр) говорят об одном, а код — совершенно о другом.
  • Вы уважаете коллег. Кто-то может назвать это спорным, но мне бы хотелось оставить это здесь. Если не будете уважать вы, то не будут уважать и вас, сегодня или завтра. Вероятно, не всегда вы сможете увидеть взаимность, но вы хотя бы пытаетесь, что делает вас уж точно не хуже.
  • Вы постоянно учитесь. Сфера ИТ настолько быстро развивается, что технологии, популярные всего 3-5 лет назад, могут быть устаревшими (неэффективными, не поддерживаемыми) сегодня. Выделяет на это время ваш работодатель или нет, это нужно и вам, и ему — найдите решение (у вас же 24 часа в сутках, а еще и выходные бывают — шутка). Работая долго с одним набором технологий, вы, вероятно, улучшаете свои навыки в них, но расширение кругозора позволяет видеть больше альтернатив и принимать более эффективные решения. Изучайте не только вглубь, но и вширь.

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

Процессы

Большинство сегодня знает, что такое процесс, а также использует или хотя бы слышал о гибких методологиях. Зачем нам нужен процесс? Например, для того, чтобы сделать команду более эффективной и/или предсказуемой. Сложно предсказывать сроки сдачи проекта? Разные разработчики случайно и независимо друг от друга берут одну и ту же задачу, о чем еще и узнают только через неделю? Временами закапываются в проблемах, решение которых уже известны кому-то еще из команды? Ответив утвердительно на один из этих или подобных вопросов, следует задуматься об улучшении вашего процесса. И в этом должны быть заинтересованы все. Технический лидер также, сколь бы крутым он ни был в техническом плане, в случае неудачи проекта может не дождаться похвалы (если только в этом не был коварный план изначально).

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

Борьба со сложностью

Мы обычно считаем архитектурой высокоуровневую структуру системы. Прорабатывать ее заранее, в процессе работы, или вовсе не думать о ней — нужно решать вам. Если с системой будет работать кто-то еще, может оказаться полезным иметь актуальный документ, ее описывающий. С другой стороны, если система мала и исходный код достаточно прост для понимания, дополнительный документ может быть никому не нужен и вы зря потратите время на его создание и поддержание. Зачем мы обычно рисуем высокоуровневые схемы систем или алгоритмов — вероятно, для условного упрощения системы с целью изучения неких основных моментов. От упрощенной схемы значительно проще переходить к изучению схем более детальных и непосредственно исходного кода. Плюс понимания архитектуры командой — знание контекста — условий, в которых будет выполняться разрабатываемый код. В некоторых случаях это может также помочь в продаже системы — некоторые покупатели будут больше доверять продукту, архитектура которого понятна или хотя бы не скрыта. Но если говорить в общем, это наш способ борьбы с увеличивающейся сложностью системы. Невзирая на количество новых килострочек кода, мы хотим обеспечивать необходимый уровень  качества, поддерживаемости, расширяемости и масштабируемости.

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

Модульность

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

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

Чем же может помочь разделение на модули?

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

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

Один способ разбиения двигает нас в сторону слоистой архитектуры. Бывает разное количество слоев, с разными смыслами, но общая идея в том, что каждый слой работает только со слоем, находящимся непосредственно под ним. Например, есть слои доступа к данным, бизнес логики и представления. Слой представления будет использовать только слой бизнес логики, но не доступа к данным. Бизнес логика — только доступ к данным, но не представления. А слой доступа к данным никаких других слоев использовать не будет. Таким образом получаем 3 модуля, с некими внешними интерфейсами и зависимостями. Это вертикальное разделение.

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

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

Заключение

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

Роман Левченко, Tech Lead, Return on Intelligence, Нижний Новгород

IMaterialize add-on

Компонент предназначен для материализации сущностей в обход стандартного метода, встроенного в Entity Framework.

Преимущества этого метода состоят в 40%-ном приросте производительности на одиночных запросах, и возможности сгруппировать несколько запросов в один round-trip до сервера, что также дает прирост производительности в условиях сетей с высокими задержками.

Cкачать

Владимир Репин, разработчик, Return on Intelligence, Нижний Новгород

Студенческий проект: что удалось сделать за три месяца работы с SAP HANA

Николай Грушин, руководитель студенческого проекта Виртуальной лаборатории ROI, делится своими впечатлениями.

Наша компания  (Return on Intelligence, ROI) уже много лет работает со студентами, в том числе проводя летние практики и помогая реализовать первые в их жизни ИТ-проекты. В этом году совместно с  кафедрой вычислительной техники факультета КТИ Санкт-Петербургского Государственного Электротехнического Университета (ЛЭТИ) мы запустили Виртуальную лабораторию — новое направление нашей университетской программы.
В рамках лаборатории  магистры  1-го года обучения реализуют проекты по разработке  в 4-х областях:

  • Java
  • .Net
  • Мобильные приложения
  • Математические методы прогнозного анализа (Big Data).

ROI обеспечивает программное обеспечение для разработки и выделяет инженеров-наставников для успешной работы студентов. Лаборатория работает непрерывно, обеспечивая конвейер  проектов, имитирующих ИТ-стартапы. В феврале 2015 года стартовали первые проекты в рамках Виртуальной лаборатории, а уже 14 мая прошла защита студенческих проектов.

Я руководил одной группой, которая работала над темой: Нахождение основных внешних и внутренних факторов, влияющих на количество проектов в организации методами математической статистики на основе исторических данных.
Используемые технологии: SAP HANA + R.  

SAPHana

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

Целью проекта было найти внешние и внутренние факторы, максимально влияющие на количество проектов в компании. Для анализа были взяты данные из внутренних и внешних систем компании. Сами данные cодержали факты как явно влияющие на количество проектов (например, количество предварительных договоренностей с клиентами и контрактов на стадии согласования), так и явно не влияющие (например, температурные колебания в регионе).
Архитектурой были выбраны средства, которые используются в реальных продуктовых средах для такого рода задач: SAP HANA и R. Ребятам было необходимо не только разобраться с тем, как работают эти системы, научиться работать с внутренним языком и методологиями работы, но и суметь настроить их для совместной работы.
Именно настройка систем вызвала наибольшие затруднения у студентов. Вот что написал один из участников проекта, Дмитрий: «Ужасные танцы с бубном вокруг SAP HANA. Все по-настоящему, не на учебный проект». Основные сложности были в настройке среды разработки, которая в то же время является и системой управления сервисом. Для студентов, знакомых только со «стандартными» «компиляторными» студиями разработки ПО, такими как Visual Studio, Eclipse, работа и настройка среды в Hana Studio (которая тоже работает на базе Eclipse) вызвала ряд  затруднений. Основные сложности возникли  в переключении между перспективами для разных задач, настройке и разграничении прав доступа (некоторые задачи можно решить, только используя пользователей со специальными правами).

Документация по HANA. В этом пункте у нас были как «плюсы», так и «минусы». Документация очень подробная и полностью обновляется к каждой новой версии HANA, и это замечательно! Но изучать ее надо целиком, что, учитывая объем информации, требует очень много времени. И чтобы найти ответ на конкретный специализированный вопрос, приходится пролистывать весь документ. Было бы здорово иметь еще комплект сжатых подсказок по разделам. По итогам работы с инструментами разработки студенты создали документ «Руководство по развертыванию HANA и R», призванный помочь другим студенческим командам на старте проектов с аналогичным инструментарием.
Динамичность развития HANA оставила двоякое впечатление. Радует, что продукт постоянно развивается, в нем быстро исправляются ошибки, неизбежные при разработке. Но базовая инструкция к продукту не всегда успевает за сменой версий. В процессе работы наша студенческая команда столкнулась с рядом проблем:

  • совместимость R-сервера с программно-аппаратным окружением. Не все версии продукта корректно работали с сервером;
  • необходимость ручного переноса данных из исходных источников в HANA из-за нестабильной работы внутреннего инструмента для загрузки данных. Мы пользовались учебной версией с ограниченным уровнем доступа, из-за этого приходилось использовать ряд дополнительных сервисов, что немного снизило итоговую скорость обработки данных, являющуюся конкурентным преимуществом HANA.

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

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

Подводя итоги, я готов сформулировать свои впечатления от работы студентов / junior-специалистов с SAP HANA:

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

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

Николай Грушин, BI/DB Technical Lead, Return On Intelligence

Построение системы отчетности на базе SAP HANA

Введение

В статье показан опыт использования платформы SAP HANA для оптимизации системы создания отчетности крупной строительной компании. Проект реализован специалистами Return on Intelligence (ROI) — бизнес-партнера SAP. ROI – международная компания по оказанию услуг в области высоких технологий. Мы предоставляем консалтинг по технологическим решениям, системную интеграцию и коммерческую разработку программных решений. Наши решения предоставляют максимальный рост, конкурентные преимущества, увеличение прибыли и снижение сложности бизнес-процессов.

За 15 лет нашими клиентами стали более 200 международных компаний, работающих в сфере страхования, финансовых услуг, здравоохранения, телекоммуникаций и государственном секторе.

Компания объединяет более 800 профессионалов, работающих в центрах разработки в Санкт-Петербурге, Нижнем Новгороде, Риге и Днепропетровске. Штаб квартира Return on Intelligence расположена в США.

Return on Intelligence работает в сотрудничестве с SAP, что подтверждено наличием статусов SAP PartnerEdge Partner, VAR-реселлер и Consulting Services Partner. Как член партнерской программы SAP PartnerEdge  (моделирование, разработка, продажа, внедрение, обслуживание и поддержка решений SAP) компания Return on Intelligence, Inc. (ROI) участвует в разработке решений, позволяющих клиентам приобретать и удерживать значительное конкурентное преимущество в своей отрасли. Использование лучших практик, отраслевых моделей, методов, инструментов, технологий и фреймворков дает возможность клиентам ROI переосмыслить и улучшить свой способ ведения бизнеса.

Ориентация SAP на технологии, отрасли и регионы полностью согласуется с нашими навыками, приоритетами и сильными сторонами.

  • Мы являемся глобальным партнером по внедрению страховых решений SAP Camilion, SAP Claims и FS-CD
  • Наша компания является глобальным экспертом в области страхования
  • Мы являемся специалистами, поддерживающими консультативную аналитику в страховании (BOBJ и HANA)
  • У нас есть высококвалифицированные разработчики программного обеспечения, поставляющие услуги по разработке продукта непосредственно для SAP

1. Платформа SAP HANA: техническая информация – краткий обзор

SAP HANA является современной in-memory платформой для работы аналитических и транзакционных приложений в реальном времени. SAP HANA позволяет организациям анализировать бизнес-операции, использующие большой объем разнообразных детализированных данных. Первые внедрения приложений SAP на базе SAP HANA показали, что время реакции системы при работе бизнес-пользователей составляет доли секунды, что открывает новые возможности для бизнеса.

SAP HANA полностью использует все преимущества самых современных аппаратных технологий, сочетая хранение данных по столбцам, массово-параллельную обработку (MPP) и вычисления  по технологии “in memory”  благодаря оптимизированной структуре программного обеспечения.

Программный комплекс SAP HANA представляет собой гибкий, многоцелевой и независимый от источника данных программный комплекс на базе технологии “In-memory”, который объединяет программные компоненты SAP, оптимизированные для аппаратных средств ведущих мировых вендоров – партнеров SAP – Cisco, Dell, IBM, HP,Fujitsu и Hitachi Data Systems.

Благодаря сочетанию технологий оперативного анализа данных и оперативной обработки транзакций в единой СУБД SAP HANA позволяет создать целостную инфраструктуру для обработки корпоративных данных, получаемых из транзакционных систем, систем бизнес-анализа, поддержки принятия решений и планирования. Аналитические приложения реального времени и оперативные приложения реального времени, включая планирование, могут выполняться совместно с другими операциями.

2. Бизнес – проблема

Заказчик решения — крупная строительная компания с чистым доходом более $70 млн в год. Компания существует на рынке более 100 лет и предоставляет услуги в разных секторах экономики. Основные направления работы: инфраструктурные работы, энергетика и добывающая отрасль. За свою многолетнюю историю компания построила большую сеть клиентов и поставщиков. Как следствие активной деятельности, внутри компании появилось большое количество разнородных информационных систем, которые перестали выполнять свою основную задачу — ускорять и упрощать работу сотрудников компании. В ходе реструктуризации IT инфраструктуры было принято решение создать централизованную отчетную систему. На момент интеграции у заказчика уже имелись другие продукты SAP: ERP, CRM, SRM, BW и вполне логично, что при выборе решения выбор остановился на технологическом стеке SAP продуктов.
Существующая инфраструктура оказалась сложной и характеризовалась следующим:
1. отсутствие мастер данных
2. 4 отдельные системы отчетности без единой точки входа
3. более 600 различных отчетов, с перекрывающимися областями и неконсистентными данными
4. низкая производительность
5. нарастающая сложность и стоимость поддержки

3. Технологии и архитектура

Основные бизнес процессы и система отчетности, в общем, единообразны в большинстве компаний, в частности, если в качестве системы управления процессами и взаимодействия с партнёрами используется решение от SAP.

Для решения задач хранения, переноса, подготовки и представления данных были выбраны следующие продукты:
1) SAP HANA
2) SAP Business Object (BObj) Data Services как средство ETL и инструмент контроля качества данных
3) SAP BObj Rapid Marts в качестве слоя метаданных для стандартных отчетов
4) SAP BObj BI 4.1 как основной инструмент визуализации.

Untitled-1

Первостепенной задачей было построение основного хранилища данных (Data Warehouse) в котором должны храниться мастер данные организации качества, целостности данных и реконселяция — проверка правильности/консистентности переноса. Стоит отметить, что SAP HANA использовалась для создания хранилища мастер данных только для информации, которая разным причинам не хранится в ERP и BW, например данные получаемые из систем компаний партнёров, которые не имеют прямого отношения к операционной деятельности организации, но интересны с точки зрения аналитики.. Таким образом, все необходимые данные можно было получить из двух источников: SAP HANA и SAP BW (SAP BW бы настороен на использование SAP HANA в качестве внутреннего хранилища).
Все данные были перенесены, консолидированы и проверены, время создавать модели метаданных понятные и удобные для применения специалистам бизнеса.
Отражением бизнес модели, говорящей с пользователями бизнес языком, являются юниверсы. Для ускорения интеграции большая часть юниверсов для системы отчетности поставлялась через SAP Rapid Marts. Rapid Marts автоматически генерирует юниверсы для стандартных процессов и отчетов, на основе конфигураций и данных SAP систем. Для данных, которые выгружались в HANA из 3-х систем, юниверсы строились вручную через SAP BObj Information Design Tool. IDT это специальный инструмент от SAP, который позволяет в удобном графическом интерфейсе создать необходимые связи между данными необходимыми для отчетности, а так же выделить и переобозначить в понятные выражения поля таблиц хранилища.

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

4. Результаты и преимущества

После 8 месяцев разработки появились результаты в виде оптимизированных процессов, консистентного хранилища данных, а так же средств для принятия решений в виде красивых графиков, интерактивных отчетов и информационных панелей. В качестве систем визуализации были выбраны BObj BI Web Intelligence и Dashboard Designer с возможностями создания интерактивных отчетов и дашбордов различной сложности и имеющими все необходимые инструменты, такие как детализация, консолидация, создание параметризированных срезов.
В итоге было построено около 400 отчетных форм в различных представлениях с возможностью доступа через корпоративный портал, систему отчетности с дополнительными преимуществами самостоятельной параметризации, а также появился новый способ доступа к отчетной системе через мобильные устройства.

Мое впечатление от подхода и использования компонентов в ходе реализации в большей степени положительно.

1. HANA отлично интегрируется со всеми используемыми компонентами SAP
2. Отсутствие дополнительного ETL процесса для построения многомерной модели. В HANA он был реализован логически и выполнялся практически мгновенно благодаря её архитектуре, что сводило латентность данных к нулю. А так же не создавало новых данных.
3. На платформе HANA были построены аналитические модели (Analytical views), которые позволяли использовать данные в системе отчетности напрямую, почти без изменения модели метаданных.
4. Все необходимые для отчетности данные доступны в SAP BObj и легко связываются.
5. «Тяжелые» расчеты были перенесены из BI платформы на SAP HANA, которая выполняет такие расчеты в несколько раз быстрее.
6. Фильтрация является одной из основных операций при построении отчетов, на SAP HANA работает намного быстрее, ввиду колоночного хранения данных.

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

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

Дополнительную информацию по использованным технологиях и программах можно найти на следующих ресурсах:

SAP Partner Portal

SAP HANA portal

SAP BusinessObjects

SAP BW

SAP Data Sevices

SAP Developer Center

Николай Грушин, BI/DB Technical Lead, Return On Intelligence

Наши разработки. Владимир Репин.

dbВсе проекты нашей компании так или иначе связаны с базами данных. Во многих из них в качестве основного средства доступа используется Entity Framework. Преимуществ у этого средства много, среди них основые это скорость разработки и более красивый, переиспользуемый и поддерживаемый код. Это достигается за счет того, что код работающий с данными и запросы к базе пишутся на одном и том же языке, в отличие от ADO.Net, где приходилось бы «склеивать» строки для того, чтобы произвести запрос на языке SQL. Но есть у этого подхода и недостатки.  Цена удобной и быстрой разработки оказалась весьма высока. Производительность операций вставки, обновления и удаления данных оставляет желать лучшего. Причина такой производительности кроется в том, что все эти операции EF производит поодиночке. Т.е. если нам нужно вставить 100 записей в базу, то EF пошлет 100 запросов на вставку. Кроме этого, в одном из проектов была обнаружена одна неприятная ошибка. EF, при работе с Oracle, в Clob/Xml поля не позволяет вставлять строки более 2000 символов.
Для решения проблемы производительности и был создан компонент, который я назвал “Context Items”. Он создавался как часть комплексного решения, разрабатываемого для того, чтобы скомпенсировать недостатки Entity Framework-a, но для публикации я решил выделить Context Items как отдельный компонент, т.к. другая, более высокоуровневая часть еще не готова к тому, чтобы увидеть свет.

Компонент предоставляет следующие операции:

  1. Bulk Insert (MS Sql): в таблицы, не имеющие Identity в качестве первичного ключа возможно осуществить вставку методом Bulk Insert, который поддерживается базой данных Ms Sql Server. В случае с Identity нет способа надежно получить назад ключи, сгенерированные базой при вставке с помощью Bulk Insert, поэтому для таблиц имеющих такие ключи используется группировка нескольких обычных Insert-запросов в один запрос. Это работает существенно медленнее, чем Bulk Insert, но все же быстрее, чем через EF.
  2. Sequenced Bulk Insert (MS Sql): альтернативой Identity обычно служит Guid, это решает проблему вставки, но создает другую проблему – в силу большей длины ключа операции Join начинают работать медленнее, кроме этого Guid непоследователен, и поэтому Clustered индексы не приносят своих преимуществ. Как решение данной проблемы начиная с MS Sql Server 2012 есть возможность использовать Sequence для создания первичных ключей. Это позволяет использовать целочисленные последовательные ключи, что позволяет использовать Clustered индексы, аналогично Identity, и одновременно позволяет использовать Bulk Insert для вставки. Компонент поддерживает только ацикличные Sequence с инкрементом 1.
  3. Bulk Update (MS Sql): самой по себе в базе данных такой операции не существует, ее воплощает в себе компонент Context Items, последовательно выполняя следующие 4 операции:
    a)    Создается временная таблица, имеющая тот же набор полей, что и целевая таблица
    b)    Производится Bulk Insert данных во временную таблицу
    c)    Выполняется Join-Update операция, которая переносит данные из записей временной таблицы в записи целевой таблицы, имеющие совпадающие первичные ключи.
    d)    Временная таблица удаляется
    По причине того, что операция не атомарная, ее желательно исполнять в транзакции.
  4. Bulk Delete (MS Sql): также как и Bulk Update, эта операция происходит в 4 шага:
    a)    Cоздается временная таблица имеющая набор полей совпадающий с первичным ключом целевой таблицы
    b)    Производится Bulk Insert во временную таблицу первичных ключей для записей, которые надо удалить
    c)    Выполняется Join-Delete операция
    d)    Временная таблица удаляется
  5. Материализация: встроенная материализация в Entity Framework также работает не очень быстро, в силу того, что сущности нужно провести через механизм отслеживания изменений (Change Tracking), и еще каких то внутренних особенностей EF. Поэтому в Context Items так же добавлена возможность материализовать EF запрос непосредственно через ADO.Net. Кроме этого, эта операция исследовалась в сравнении с другими решениями, в частности достаточно известные micro-ORM Dapper. Context Items выполняет эту операцию примерно на 40% быстрее, чем EF и на 3-5% быстрее, чем Dapper.
  6. Array-bound Insert, Update and Delete (Oracle): Bulk Insert компонент, реализованный в ODP.Net не принимает во внимание ни триггеры ни constraint-ы, ни даже первичные ключи. Поэтому для вставки непосредственно в таблицу он не годится. Конечно всегда остается возможность использовать временную таблицу, но я решил использовать метод, которые рекомендуется самим разработчиком Oracle. Метод называется array-binding. Вкратце – запрос, посылаемый в базу, выглядит так, как будто мы вставляем одну запись, но в качестве параметров мы передаем не набор полей, а набор массивов полей, и таким образом вставляем, обновляем либо удаляем массив записей, а не одну запись.

Компонент Context Items поддерживает EF версии 5.0.0 – 6.1.3, а также базы данных Oracle и MS Sql Server.

Компонент опубликован на nuget.org, с идентификатором contextitems.
Подробнее об установке и использовании можно прочитать в репозитории на GitHub.com: https://github.com/repinvv/ContextItems

Владимир Репин, разработчик, Return on Intelligence, Нижний Новгород