что такое системный ландшафт
Построение информационных ландшафтов с использованием сервисных шин
Основная проблематика интеграционных ландшафтов
В современном мире бизнес-приложения практически не могут существовать без интеграции с другими приложениями. Посредством интеграции мы можем как осуществлять простейший обмен данными, так и строить сложные композитные приложения.
Однако накопленный парк приложений в силу своих архитектурных, платформенных и «возрастных» отличий имеет массу проблем интеграционного уровня.
К основным проблемам подобного типа можно отнести:
• Различные интеграционные механизмы приложений
• Несовпадающие, либо частично пересекающиеся форматы данных, избыточность передачи данных
• Отсутствие единой точки управления
• Сложности с масштабированием интеграционной схемы
• Необходимость модификации приложений-подписчиков.
A. Различные интеграционные механизмы
Большинство приложений при проектировании получают тот или иной интеграционный интерфейс. Однако каждый вендор имеет свое понимание роли приложения в интеграционной схеме. И чаще всего он видит своё приложение в центре интеграционного ландшафта (особенно этим грешат поставщики финансовых систем). Исходя из этого видения и строится архитектура интеграционной части приложения. Но так как приложения разрабатываются в различные временные отрезки, то они получают обычно те интеграционные технологии, которые доминируют в данный период. А из-за «эгоцентричной» архитектуры чаще всего закладывается одна или две из наиболее популярных технологий. В результате мы имеем набор «приложений-эгоистов», ожидающих, что вся интеграция будет строиться по заложенной в них интеграционной модели.
B. Несовпадающие форматы данных
Проблема имеет те же корни, что и рассмотренная выше. Каждое приложение помещает себя в центр интеграционного ландшафта и планирует играть по своим правилам. Приложение описывает форматы и состав данных, опираясь на свою модель данных и алгоритмических базисов. Чаще всего передаваемые данные стараются привести к полной идентичности с внутренней моделью данных приложения, чтобы избежать накладных расходов на изменение форматов. В результате мы имеем ситуацию, когда данные либо частично, либо полностью не совпадают по форматам, вплоть до разных форматов носителей. Довольно часто, при простых схемах интеграции, это приводит к необходимости многократной отправки одних и тех же данных в различных форматах.
C. Отсутствие единой точки управления
Отсутствие единой точки управления – одна из краеугольных проблем при построении интеграционных ландшафтов. Когда каждое приложение пытается управлять интеграцией со своей точки зрения, ситуация довольно быстро становится слабоуправляемой. Требуется планирование комплекса мероприятий, иногда даже не связанных друг с другом, для мониторинга и обслуживания. Возникают очаговые центры компетенции, связанные с конкретным приложением. Однако, следует отметить, что частично проблема может быть решена засчет комплексного подхода к полной автоматизации предприятия – единая платформа, единые протоколы, единые форматы, сквозная документация. Но, несмотря на прозрачность и конечность методов, в реальности такое встречается очень редко.
D. Сложности с масштабированием интеграционной схемы
Проблемы, связанные с централизованным управлением, плавно перерастают в проблемы масштабирования интеграционной схемы. Для планирования масштабирования надо воедино связать информацию: кто, когда, в каком объеме и составе передает и ожидает данные, какие форматы использует и протоколы поддерживает. В таких условиях изменение формата даже одного из пакетов информации может приводить к повышенным трудозатратам и простоям.
E. Необходимость модификации приложений-подписчиков
Для обеспечения загрузки и выгрузки данных зачастую требуется модификация приложения-подписчика. Это приводит к необходимости постоянной модификации приложений при масштабировании интеграционного ландшафта, простоям приложения в период внесения изменений, повышению вычислительной нагрузки на приложение для обеспечения интеграции; требует наличия специалистов по каждой платформе, на которой реализованы приложения-подписчики. Также это затрудняет саму модификацию систем-подписчиков, так как при планировании модификаций проектной командой приложения ей требуется учитывать и планировать необходимые доработки по интеграционной модели. При этом проектной команде либо придется самой погрузиться в архитектуру интеграционных связей, либо дополнительно привлекать специалиста, обладающего этими знаниями.
Основные подходы к построению интеграционных ландшафтов
Не секрет, что современные продукты класса ESB (Enterprise Service Bus) нацелены именно на комплексное решение перечисленных проблем интеграционных ландшафтов.
Несмотря на различные подходы и компонентную базу, все они исповедуют следующие базовые принципы:
• Стандартизация форматов
• Обеспечение подключения систем-подписчиков в единую сеть посредством библиотеки коннекторов
• Гарантированность доставки сообщений
• Перенос правил обработки и маршрутизации на глобальный уровень
• Единые механизмы протоколирования и мониторинга
• Развитые средства масштабирования.
Следуя этим принципам, для построения интеграции обычно выполняют более или менее стандартный набор работ. На первом этапе выполняются аналитическая проработка и стандартизация структур передаваемых данных. Могут быть использованы следующие подходы: подход, при котором все данные от систем-источников приводятся к единым структурам, или подход, при котором данные приводятся к структурам систем-подписчиков перед доставкой. Довольно часто используется смешанный подход к структурам данных. Первый вариант позволяет сразу при получении привести передаваемые данные к стандарту и использовать эти данные в дальнейшем (например, для динамической маршрутизации данных на основании их содержимого). При необходимости формируются шаблоны информационных пакетов. Еще одним плюсом этого подхода является то, что в этом случае все участники интеграционного процесса одинаково понимают структуру данных периметра интеграции.
Второй подход позволяет сократить накладные расходы на преобразование данных и выполнять его при получении только для систем-подписчиков, которые в этом нуждаются. При смешанной схеме преобразование либо разделяется по типам данных, либо выполняется всегда на всех точках маршрута доставки данных. Делается это для упрощения последующего сопровождения интеграционного ландшафта. Так как мы знаем планируемую структуру данных и можем четко отслеживать её инструментами мониторинга и автоматической валидации.
После определения форматов и структур данных производят формирование процессов движения информации. Различают «маршрутную» и «потоковую» схемы доставки данных. Они довольно похожи между собой, но имеют и некоторые различия.
Эта схема предполагает, что система-отправитель не должна знать о потребителях данных. В свою очередь, системы-потребители не должны зависеть от поставщика данных. Они просто получают данные, на которые они подписаны, по факту их возникновения в сети. Это позволяет строить слабосвязанные схемы с возможностью буферизации и агрегации данных. Также эта схема отличается тем, что механизмы получения, обработки и загрузки данных выделены в отдельный процесс и не связаны напрямую с процедурой маршрутизации.
Для реализации этой схемы необходимо определить:
• Типы данных и методы их извлечения
• Список получателей и условия поставки данных этого типа до обозначенных получателей
• Список маршрутов
• Набор процедур трансформации.
Важно понимать, что для каждого объекта выполняются действия, связанные только с этим объектом. То есть, для системы-источника мы определяем, какие типы данных он будет отдавать, и каким образом мы их будем извлекать; определяется механизм трансформации полученных данных (если требуется). Для системы-подписчика, в свою очередь, также определяются типы данных, которые он будет принимать, механизмы загрузки и схемы предварительной трансформации (если требуется). В маршрутах описываются условия доставки различных типов данных до каждой системы-подписчика. Такой подход позволяет легко масштабировать интеграционную схему под любые возникающие изменения.
К недостаткам этой схемы можно отнести снижение сквозной прозрачности истории прохождения данных. Этот недостаток в системах чаще всего решается инструментальными средствами мониторинга.
При этом подходе специалист по интеграции описывает полные потоки прохождения данных. Системы-источники и системы-приемники жестко связаны между собой в рамках потока.
Для полного описания потока требуется определить следующие объекты и механизмы:
• Список доступных систем-источников
• Методы подключения к системам-источникам
• Методы извлечения данных для каждой системы-источника
• Методы трансформации данных
• Методы расщепления и сложения данных
• Список систем-подписчиков
• Методы подключения к системам-подписчикам
• Методы передачи данных для каждой системы-подписчика.
Чаще всего используется подход, когда один поток оперирует каким-то одним типом данных. Однако важно понимать, что классическая модель потоков не обязана оперировать одним типом данных. Проектирование таких систем ведется через определение списка потоков, структурирование информации внутри каждого потока. Далее определяются точки возникновения информации, список получателей и необходимые для них трансформации.
Важно понимать, что каждое описание потока требует заново формировать вышеописанный список объектов и механизмов.
Недостатками этой модели являются:
• Потенциальная возможность частичного пересечения по данным в различных потоках;
• Потоки, оперирующие несколькими типами данных, усложняют понимание полной схемы и требуют схем управления данных внутри потоков (потоки в потоках). Сложность растет с ростом уровня вложенности потоков;
• Для каждого потока требуется описание всех процедур извлечения, трансформации, подключения и т.д., даже если схожие процедуры используются в соседних потоках. Возрастает сложность изменения масштаба интеграционной модели.
При любом подходе важной составляющей интеграционной модели являются схемы трансформации данных. Различаются только места, в которых описываются эти схемы. В первом случае схемы трансформации описываются относительно систем – выход системы-источника, вход системы-подписчика – и представляют собой единую процедуру обработки данных для этого источника. Во втором случае схема трансформации описывается внутри потока данных и может быть разбита на несколько независимых участков. Хочется обратить внимание, что в отличие от интеграционных моделей типа «точка-точка», процедура трансформации позволяет довольно сильно снизить нагрузку на прикладное приложение. Практически, использование ESB со схемами трансформации избавляет клиентское приложение от всей нетипичной нагрузки по обеспечению обмена. Решается одна из типовых проблем – необходимость доработки системы-подписчика.
Схемы трансформации обычно обладают следующей функциональностью:
• Изменение форматов передаваемых данных
• Изменение структуры передаваемых данных
• Обогащение данными
• Обеднение данных в целях уменьшения объема
• Разделение информационных пакетов на несколько
• Слияние нескольких информационных пакетов в один
• Валидация данных прикладными бизнес-правилами.
Также разработка схем трансформации позволяет существенно снизить объемы передаваемых данных. Это достигается за счет того, что выгрузка данных осуществляется однократно, атомарно и только в необходимом объеме. При этом инициатором выгрузки является либо событие по изменению данных, либо запрос данных от схемы трансформации в объеме, необходимом для выполнения обогащения данных.
Все действия по извлечению данных, трансформации и загрузке протоколируются и записываются в журналы различных форматов. Наиболее частым подходом является выделение отдельного сервера под хранение таких журналов. Это позволяет подключать специализированные системы мониторинга для возможности оперативного получения данных в человекочитаемом виде.
Хранение журналов разделяется на оперативное и архивное. Для оперативного хранения зачастую используются циклически перезаписываемые лог-файлы, которые по мере заполнения сбрасываются в архивное хранилище.
Отдельно протоколируются состояние объектов ESB и счетчики производительности оборудования. Это позволяет строить полную оперативную картину прохождения данных и текущего состояния системы в целом. Наиболее продвинутые решения имеют в своем составе средства проактивной диагностики состояния сети. Эта диагностика позволяет заблаговременно информировать сотрудников, выполняющих обслуживание интеграционной сети, о возможности возникновения проблемы, чтобы устранять потенциальные угрозы.
В результате мы имеем четкую и прозрачную модель данных, управляемую из единой точки и обеспеченную различными средствами централизованного мониторинга.
***
Построение информационного ландшафта позволяет решить многие проблемы, которые присутствуют при точечных интеграциях, но требует вдумчивого подхода к проектированию и выбору решения. Следует оценить плюсы и минусы реализуемых подходов и выбрать продукт, максимально обеспечивающий покрытие будущего ландшафта коннекторами, блоками трансформации, имеющий развитые системы мониторинга и проактивной диагностики. Затем выбрать подходы к проектированию схем передачи данных, оценить какой из подходов наиболее предпочтителен в вашем случае. На выходе мы получим стабильную, масштабируемую интеграционную модель с полным и централизованным управлением процессом.
sidadm
записки SAP Basis консультанта
Полезное
понедельник, 2 октября 2017 г.
Почему SAP рекомендует 3-х системный ландшафт?
Вот вы говорите: «Ландшафт, ландшафт. » А что такое ландшафт?
Давайте остановимся на этом понятии поподробнее.
Итак, в посте «Копирование манданта SAP системы» я приводил структуру данных SAP системы (рис. 1).
Помимо манданта, в системе есть общие для всех мандантов данные: манданто-независимые настройки и репозитарий SAP системы. Репозитарий это прежде всего ABAP-программы (reports, функциональные модули, экраны и т.п.). К репозитарию так же относится и ABAP-словарь, про который я писал в посте «Транзакция SE14 : утилита базы данных».
Ландшафт, как я уже упоминал ранее, это объединение нескольких систем одного назначения/версии для настройки/обеспечения контроля качества/поддержки того или иного решения компании SAP. Например, SAP ERP 6.0 EHP7 (кстати, самая распространенная версия по опросам) или SAP SRM 7.0 EHP3.
Здесь ситуация лучше: программисты разрабатывают программы в отдельной системе и, по мере готовности, переносят их в продуктивную систему. Программисты отделены от пользователей и не мешают их работе. Но, на самом деле, ситуация далека от идеальной. Такой ландшафт не может обеспечить хороший уровень контроля качества настроек и разработок системы. Тут проблемы возникают с тестированием решений. Где проводить тестирование? На стороне системы разработки? Тогда встает вопрос с безопасностью (основные данные предприятия в системе, где работают консультанты и разработчики) и с обновлением данных. Про тестирование на стороне системы промышленной эксплуатации вообще говорить не приходится. Даже если выделить отдельный мандант в этой системе, репозитарий общий и дампы при переносе никуда не денутся.
Но основная проблема на самом деле в другом: в переносе изменений. Никто не может гарантировать, что транспортный запрос содержит все необходимые компоненты с изменениями и импортируется в систему промышленной эксплуатации без ошибок. В таком ландшафте это никто не проверял.
 |
| Рис. 4. Трёх системный SAP ландшафт. |
За промежуточные некорректные версии объектов, которые содержатся в такой очереди, можно не переживать. При импорте очереди запросов, автоматически активируются только последние версии каждого объекта.
А чтобы было меньше дампов у пользователей при переносе, осуществлять его лучше во время минимальной активности в системе. Вечер пятницы вроде бы идеально подходит, но иногда чреват незапланированной работой в выходные. 🙂 Поэтому лучше вечер четверга.
Стоит еще отметить: систем в ландшафте может быть больше. Например, 2 тестовые системы, с разным срезом продуктивных данных. 2 продуктивные системы, которые поддерживаются одной парой разработка-тест.
Так же и мандантов внутри систем может быть больше. В системе разработки часто, кроме манданта для настройки и разработки (который в идеале не содержит основных данных), создают мандант первичного тестирования. В нём есть небольшой объем данных для первичного теста. Так же часто можно увидеть мандант-песочницу, в котором консультанты могут «побаловаться» с настройками. Главное, чтобы все изменения (мусор, песок) в этом манданте не включались в транспортные запросы и никуда не импортировались.
В тестовой системе часто создают отдельный мандант для обучения сотрудников. Так как для реальных примеров во время обучения нужен объем данных, а в продуктивной системе обучать новых людей нельзя по очевидным причинам.
В продуктивной системе могут быть несколько промышленных мандантов для работы отдельных предприятий в рамках одной системы.
Но самое главное, что я хотел сказать, это то, что для качественной разработки и поддержки нужны минимум 3 отдельные системы.
Референсная архитектура управления ИТ
В области управления ИТ целый ряд стандартов и лучших практик традиционно используется компаниями в качестве ориентира: ITIL, MOF, TOGAF, PMBoK, BABOK, RUP и т. д. Однако специалистам всегда хотелось собрать все эти вещи воедино, чтобы получить общую картину управления ИТ. В 2014 году была выпущена первая публичная версия IT4IT — открытого стандарта и референсной архитектуры управления ИТ. IT4IT издан от имени The Open Group — уважаемой в области ИТ организации, которая является владельцем многочисленных стандартов, например TOGAF в части архитектуры или Single UNIX Specification. Соавторами IT4IT стали крупные международные компании: Shell, Hewlett Packard, Achmea, Accenture, AT&T, PWC, ING, Университет Южной Флориды, Nestle, Barclays, Procter & Gamble, NBC, Disney и др.
Предпосылки появления IT4IT
В течение последних 20 лет многие крупные компании занимались совершенствованием управления ИТ. Было развернуто много систем автоматизации в этой области, разработаны и внедрены в повседневную деятельность процессы управления.
Однако и процессный, и системный ландшафт управления ИТ зачастую представляли собой «лоскутное одеяло». Различные стандарты и лучшие практики, такие как ITIL, COBIT, PMBoK, TOGAF и др., хотя и совершенствовались с целью взаимного соответствия, все же не воспринимались как единое целое. С системами автоматизации еще хуже — интеграция систем даже одного вендора не всегда была простой задачей, а уж если предстоит интегрировать смежные решения от разных производителей, нужны существенные вложения времени, денег и сил. В этой ситуации ряд крупных компаний организовали IT4IT-консорциум, в рамках которого и был разработан открытый стандарт управления ИТ — IT4IT и одноименная референсная архитектура управления ИТ.
Принципиальный подход
В основу IT4IT легло понятие цепочки ценности (value chain), описанное Майклом Портером в его книге «Конкурентное преимущество». Вся деятельность ИТ-организации была разделена на четыре основных потока создания ценности (value stream) и пять вспомогательных видов деятельности. Четыре потока создания ценности объединены и детализированы в виде референсной архитектуры управления ИТ.
При этом впервые большое внимание уделено данным и артефактам, которыми оперируют блоки деятельности ИТ (круги на иллюстрации, связанные линиями). Ведь именно разрывы в передаваемых данных зачастуюслужат причиной неэффективного сопряжения процессов и систем автоматизации управления ИТ. Такая проработка сделана как на уровне архитектуры в целом (см. иллюстрацию), так и более подробно на уровне каждого потока создания ценности.
При этом IT4IT не отменяет существующие стандарты и своды лучших практик (ITIL, TOGAF, PMBoK и т. д.), а скорее выступает «надстройкой», позволяющей соединить их вместе, и является не сводом рекомендаций, а предписывающим стандартом. Важным является и то, что IT4IT — полностью открытый стандарт. С более подробной информацией о нем можно ознакомиться на сайте opengroup.org/IT4IT.
Участие Hewlett Packard Enterprise в работах по IT4IT
Компания Hewlett Packard Enterprise принимала участие в разработке IT4IT с самого начала и, по сути, являлась единственным производителем программного обеспечения, вовлеченным в этот проект.
Сейчас есть четкое наложение программных продуктов HPE на референсную архитектуру IT4IT. Команды разработчиков программного обеспечения HPE опираются на IT4IT, чтобы обеспечить стандартную интеграцию между продуктами.
Кроме того, консалтинговые подразделения Hewlett Packard Enterprise имеют в своем портфеле набор услуг по оценке и планированию развития процессного и системного ландшафта управления ИТ в соответствии с IT4IT. Очень многие компании успешно используют системы автоматизации и процессы управления, но порой из-за отсутствия недостающего звена тот или иной поток создания ценности не может проявить весь свой потенциал. Экспертный взгляд на конкретное ИТ- подразделение с точки зрения IT4IT позволяет выявить эти разрывы, спланировать и выполнить работы по реализации недостающих компонентов.
IT4IT можно использовать для оценки текущего состояния и планирования гармоничного развития управления ИТ — как в части процессов, так и в части автоматизации.
У любой компании, присутствующей в интернете, есть свой IT-ландшафт. Как сделать его более эффективным?
Product Manager B2B tools в «СберМаркете»
Понятие «IT-ландшафт» появилось среди производственных компаний. Но теперь все больше высокотехнологичных бизнесов делятся, как они выстраивают свои многослойные информационные системы.
Тимофей Попов, Product Manager B2B tools в «СберМаркете», на основе своего семилетнего опыта преобразований IT-ландшафта объясняет, что собой представляют такие системы и как с ними работать.
Что такое IT-ландшафт
IT-ландшафт или IT-архитектура — это совокупность информационных систем, сервисов, услуг и продуктов, которыми компания пользуется, чтобы поддержать или улучшить свою жизнедеятельность: на производстве, в коммуникации, аналитике, учете — или получить доход.
Сейчас у любой компании, которая использует интернет для ведения бизнеса, есть свой IT-ландшафт. У небольших фирм он может быть максимально простым: состоять из одного лендинга с десятью товарами и онлайн-кассой, собираться по частям из предложений на рынке. Так быстрее и дешевле.
Но также IT-ландшафт может представлять собой целый комплекс продвинутых инструментов для управления финансами, человеческими ресурсами, продажами, маркетинговыми активностями, техподдержкой, сбором данных. Такой сложный ландшафт можно найти, к примеру, у крупных маркетплейсов и онлайн-банков. Некоторые из гигантов даже продают свои технические наработки.
На число компонентов IT-ландшафта влияет то, какой принцип использует компания для его построения: монолита или микросервисов. В первом случае все компоненты ландшафта запускаются и работают одновременно. Во втором компоненты запускаются отдельно, по требованию пользователя, но связаны между собой. Тренд на микросервисную архитектуру стал устойчивым: в 2020 году в среднем компании использовали 137 уникальных микросервисов, и это на 30% больше, чем в 2018-м.
У IT-ландшафта есть несколько классификаций:
Каждая из этих классификаций используется в зависимости от характера задачи, которая стоит перед специалистами.
Что отличает правильно выстроенный IT-ландшафт
Важно помнить, что работа над улучшением ландшафта — работа постоянная. Весь ландшафт целиком не обновляется. Всегда будут приоритетные изменения. Ведь устанавливая обновление операционной системы на свой телефон, мы при этом не обновляем само устройство.
Его «железо» остается тем же. Но через какое-то время, к примеру, через два года может понадобиться и замена деталей. Однако, если телефон можно просто сменить, сделать то же самое с системой, на которой «живет» бизнес, без его приостановки нереально.
Как выстраивать IT-ландшафт
Работу по выстраиванию IT-ландшафта курирует CTO (Chief technical officer), в чем ему помогают, в том числе, системный аналитик или продуктовый менеджер. Выбор ответственного зависит от устройства компании. Однако не менее важно, чтобы команда, которой предстоит этим заниматься, понимала, зачем она меняет ту или иную часть системы.
Кратко алгоритм работы с IT-ландшафтом выглядит следующим образом:
Для составления продуктовых методологий можно взять CJM и Canvas, архитектуру предприятия Джона Захмана, Business Process Model and Notation (BPMN) и UML-диаграммы. В моделировании хранилищ данных, связей, источников помогут ER-диаграммы, data flow digram (DFD). Для наглядного представления всего IT-ландшафта стоит использовать ARIS, Visio, Miro, MindMap. В последнем можно сделать верхнеуровневые карты.
Приведу пример из своей практики. Когда я работал в McDonald’s, нам предстояло внедрить систему онлайн-платежей. Чтобы она появилась и исправно работала, нам было нужно настроить внутренние хранилища данных и сервисы (ЦО и рестораны) так, чтобы они получали и обрабатывали транзакции и информацию о заказах из мобильного приложения.
Также нам предстояло доработать системы финансового учета и отчетности, чтобы она учитывала онлайн-платежи. И все это — с нуля, потому что предыдущий IT-ландшафт был нацелен на поддержку бизнеса только в офлайне. Для его обновления понадобилось и дополнительное оборудование, и перенастройка программ, и работа по их интеграции между собой. Зато у компании появился масштабируемый фундамент для обработки транзакций и заказов по digital-каналам.