It платформы для бизнеса что такое

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

Есть компании, которым необходим промежуточный вариант: отдельная ИТ-инфраструктура и виртуальная среда для разработки собственных приложений. Для этих целей существует сервисная модель — PaaS (Platform as a Service). В этом материале мы расскажем об услуге «Платформа как сервис», разберем ее преимущества и недостатки и выделим задачи, для которых она подходит.

Что такое PaaS

Platform as a Service (PaaS) — это сервис, в рамках которого бизнес получает ИТ-инфраструктуру с готовыми ВМ на которых уже есть ОС и платформенное ПО, например, для разработки или базы данных. С помощью PaaS специалисты могут создавать, развертывать и тестировать собственные веб-приложения и программное обеспечение на виртуальной платформе облачного провайдера.

ПЛАТФОРМЫ ДЛЯ ПРОДВИЖЕНИЯ БИЗНЕСА

Преимущества PaaS

Благодаря PaaS ИТ-специалисты компаний могут пользоваться инструментами разработки, обслуживание которых берет на себя облачный провайдер. Панель управления ITGLOBAL.COM

Готовность к работе

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

Поддержка разных языков программирования

Платформа поддерживает различные языки программирования (Python, С++, Java и т.д.) и инструменты для оркестрации контейнеров (Kubernetes, Docker).

Легкая масштабируемость

Ресурсы в PaaS можно быстро наращивать для сложных и тяжеловесных проектов. Например, разработка интернет-магазина или одновременное тестирование нескольких веб-приложений. После ресурсы можно быстро и легко уменьшить.

Отсутствие капитальных затрат

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

Круглосуточная техподдержка

Облачные провайдеры круглосуточно администрируют платформу и консультируют клиентов по техническим вопросам.

Решение для распределенных команд

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

Недостатки PaaS

• PaaS не такая гибкая и управляемая модель облачных вычислений, как IaaS (Инфраструктура как услуга).
• Возможности разработки ограничены функционалом конкретного облачного провайдера.
• Данные уязвимы, так как передаются по общедоступным каналам связи. Поэтому дата-центр облачного провайдера должен иметь все три сертификата Tier III.
• Скорость доступа к данным и приложениям ниже, чем в локальных системах.

Для каких задач подойдет PaaS

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

Цифровая платформа для бизнеса | Работаю на себя

• Среда разработки. Готовые инструменты для разработки позволяют бизнесу пройти весь путь создания веб-приложений: от сборки и тестирования до развертывания и обновления.
• Облачное хранилище. На платформе можно организовать облачное хранилище, которое будет хранить, обрабатывать и защищать данные любых объемов и любого типа.
• In-Memory вычисления. In-Memory платформы (SAP HANA и Oracle Database In-Memory) предназначены для быстрой работы аналитических и транзакционных приложений.
• Хостинг приложений. Услуга облачного хостинга платформ SAP HANA и SAP Hybris помогает бизнесу расширить набор SAP-решений и оптимизировать затраты на них.
• PaaS в гибридном облаке. Подойдет разработчикам, которые работают с исходным кодом в своем хранилище. Приложение создается локально, загружается на PaaS-платформу и эксплуатируется на инфраструктуре облачного провайдера.

Итог

Хотя рынок PaaS в России развит не так сильно, как в западном мире, Platform as a Service остается оптимальным вариантом для компаний, которые разрабатывают собственное ПО, планируют перейти в облако, но не хотят тратить свои ресурсы на подготовку и настройку платформы. Если бизнесу понадобиться больше гибкости, производительности и индивидуальных настроек, то можно всегда перейти на другую сервисную модель — IaaS (Инфраструктура как услуга).

Источник: itglobal.com

Платформа для организации производства Информационных систем. Часть 1

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

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

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

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

Но эта тема получила новый импульс после ухода с рынка РФ части игроков.

Обсуждению концепции организации производства ИТ-продуктов и посвящена данная статья.

II Платформа для организации производства ИТ‑Продуктов

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

1. Определение цифровой платформы

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

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

У платформы принято выделять 3 аспекта применимости:

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

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

2. Модель платформы организации производства ИС

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

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

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

В следствии того, для автоматизации подобного рода деятельности можно выделить, как минимум 2 макро-сервиса:

1. «Учет требований к ИТ-Продукту»;
2. «Организация производства ИТ-Продукта»;

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

III Сервис управления требованиями к ИТ-Продукту

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

Опыт разработки показывает, что при любом итерационном подходе реализации продукта (Scrum, RUP, MSF и т.д.) удобнее управляться не с отдельными задачами, а с метриками, группирующими работы в некую продуктовую функциональность. В RUP — это Прецеденты, в Agile методиках – это Feature (полезность) или Store (совокупность возможностей) и прочие. Обусловлено это спецификой самого процесса, когда невозможно протестировать или продемонстрировать отдельную выполненную задачу (алгоритм, часть кода и т.д.), но можно анализировать результат группы работ, воплотившей в конечной сборке: функциональную возможность взаимодействия пользователя с ИС.

1. Представление ИТ-Продукта в виде Требований

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

Исходя из вышесказанного, не взирая на зрелость и формат представления Требований командой проектирования, в сервис «Организация производства Продукта» они должны попадать в виде описания возможностей ИТ-Продукта или его компонентов, или условий их функционирования. В следствии того Требования должны различаться типом, определяющим способы их реализации. Тип может принимать значения: 1) «Продукт»; 2) Компонент; 3) «Возможность»; 4) «Условие применения»; 5) «Поведение»; 6) «Алгоритм»; 7) «Визуальное представление» и прочее. Например:

2. Способы представления Требований к ИТ-Продукту

Часто удобно выводить контекст разрабатываемого продукта вокруг набора визуальных прототипов форм. Это естественно и легко воспринимается большинством заинтересованных лиц. Например, требование:

1.3.2. Представление формы версии Требования — Визуальное представление

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

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

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

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

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

3. Моделирование жизненного цикла Требования

Для того, чтобы отслеживать прогресс воплощения Требования в целевой Информационной системе, сформированное Требование должно поступать в сервис «Организация производства ИТ-Продукта», в виде контекста задачи на его реализацию. В сервисе производства будут организованы работы претворяющие Требование в функциональность ИТ-продукта, фиксироваться их результат, а в ответ возвращаться текущая стадия его Жизненного цикла (далее ЖЦ). Так мы сможем в самом сервисе Учета требований, наблюдать за степенью его готовности в целевом Продукте см. Рис 3.

В связи с этим у Требования должен фиксироваться статус, определяющий текущий этап его обработки и степень готовности в текущей версии ИТ-продукта. Например, «Создано», «В разработке», «Реализовано», «Аннулировано», «Замещено» см. Рис.2.

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

4. Сложная организация Требований для линеек продукта

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

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

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

Но эту тему мы разовьем в следующей части, где детально рассмотрим сервисы, поддерживающие организацию процесса реализации Требований в ИТ-продукте см. Часть 2

• инфраструктура
• производство
• проектирование систем
• проектирование взаимодействия
• организация работы
• организация процессов
• организация труда

• Анализ и проектирование систем
• Управление разработкой
• Управление проектами
• Управление продуктом

Источник: habr.com

Компания «Консалтинг по управлению ИТ»

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

Разработка ИТ-стратегии создания цифровой платформы бизнеса уместна:

• для крупных и средних компаний всех отраслей;
• до цифровой трансформации бизнес-процессов (или как ее первый этап).

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

ИТ-стратегия создания цифровой платформы бизнеса является одной из типовых тематик (вариантов содержания) ИТ-стратегии. Все рассмотренные на этом сайте тематики ИТ-стратегий представлены на странице «Типовые тематики ИТ-стратегий».

Структура ИТ-стратегии создания цифровой платформы бизнеса

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

В ИТ-стратегии создания цифровой платформы бизнеса целесообразно рассмотреть все разделы ИТ-стратегии, ну или хотя бы разделы, выделенные в таблице:

Обозначения: «√»: входит в вариант; «+-»: частично входит

Разработка ИТ-стратегии создания цифровой платформы бизнеса

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

12 основных ошибок при разработке ИТ-стратегии.
Типовые варианты разработки ИТ-стратегии

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

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

Более подробно тема полной ИТ-стратегии рассматривается здесь.

Источник: www.info-strategy.ru