SAP Business Technology Platform (SAP BTP)

A SAP descreve o SAP BTP como uma única oferta que reúne vários portfólios de tecnologia. Na prática, uma equipe de SAP S/4HANA o encontra por meio de um punhado de serviços:

• Desenvolvimento de aplicações: runtimes para código customizado, SAP Business Application Studio, o SAP Cloud Application Programming Model (CAP) e o SAP BTP ABAP environment.
• Automação e low-code: a família SAP Build, incluindo o SAP Build Process Automation e o SAP Build Work Zone.
• Integração: SAP Integration Suite, além dos serviços de conectividade e de destinations que alcançam sistemas on-premise por meio do SAP Cloud Connector.
• Dados e analytics: SAP HANA Cloud e os serviços de analytics construídos sobre ele.
• IA: SAP AI Core e seu generative AI hub, para incorporar modelos de IA em aplicações.

Cada serviço tem o próprio entitlement, a própria administração e o próprio ciclo de vida. O SAP BTP é, portanto, um catálogo de serviços de plataforma que compartilham contas, identidade e faturamento, e não uma aplicação única.

Todo landscape do SAP BTP segue o mesmo modelo de contas:

1. Uma global account representa o contrato com a SAP e guarda os entitlements que o cliente comprou.
2. Directories agrupam opcionalmente os subaccounts, por exemplo por unidade de negócio ou por projeto.
3. Os subaccounts são onde o trabalho acontece. Cada subaccount fica em uma região e recebe uma parte dos entitlements como quota.
4. Dentro de um subaccount, os administradores habilitam ambientes: Cloud Foundry para aplicações poliglotas, Kyma para workloads baseadas em Kubernetes e o ambiente ABAP para desenvolvimento ABAP Cloud.
5. Os serviços são consumidos como instâncias dentro de um ambiente ou como assinaturas de aplicações SaaS, como o SAP Build Work Zone.

Desenvolvimento, teste e produção costumam ser subaccounts separados, e os transportes entre eles podem passar pelo SAP Cloud Transport Management. O modelo de contas do SAP BTP é primeiro uma decisão de governança e só depois uma configuração técnica.

• Serviços que conhecem o SAP: destinations, SAP Cloud Connector e serviços de identidade são construídos para alcançar o SAP S/4HANA e outros sistemas SAP, inclusive on-premise.
• Ciclo de vida desacoplado: extensões side-by-side rodam com runtime e ciclo de releases próprios, então um upgrade do SAP S/4HANA não obriga a reimplantar todas as extensões.
• Suporte ao clean core: a SAP posiciona o SAP BTP como o lugar padrão para extensões que não devem viver dentro do core do ERP.
• Uma plataforma, vários perfis de competência: desenvolvedores pro-code, especialistas em integração e criadores low-code trabalham sobre o mesmo modelo de contas e a mesma configuração de identidade.
• Serviços centrais compartilhados: um site de launchpad, uma caixa de entrada de tarefas ou um fluxo de integração podem atender vários sistemas SAP e não SAP ao mesmo tempo.

Para extensões que precisam ficar fora do ciclo de upgrade do SAP S/4HANA, o SAP BTP é a plataforma que as próprias orientações de extensibilidade da SAP indicam.

• Uma plataforma, não uma solução. O SAP BTP fornece runtimes e serviços. Qual extensão construir, e quem é o responsável por ela após o go-live, é decidido fora da plataforma.
• A lógica dos documentos fica no core. Precificação, lançamentos, aprovações de documentos do SAP S/4HANA e seus status permanecem no SAP S/4HANA. Uma extensão no SAP BTP chama essa lógica por meio de APIs; não assume o lugar dela.
• Cada serviço é um produto próprio. Cada serviço traz a própria administração, roles, monitoramento e limites. Um landscape com muitos serviços precisa de uma operação de plataforma de que muitas equipes de ERP não precisavam antes.
• O custo acompanha o uso. Em contratos baseados em consumo, cada instância e cada usuário consomem créditos, então a transparência de custos exige monitoramento ativo.
• A integração é projetada, não dada. Um caso de negócio que envolve vários serviços e sistemas só é tão visível quanto a integração e o monitoramento construídos ao redor dele.

Esses limites são o preço da flexibilidade: o SAP BTP amplia o que pode ser construído em torno do SAP S/4HANA sem tornar essas construções autogovernadas.

Um critério de decisão prático é o acoplamento entre a extensão e a transação do SAP S/4HANA:

Um erro comum é abrir subaccounts projeto a projeto sem um desenho de landscape, o que depois bloqueia destinations, identidade e transportes compartilhados. O SAP BTP compensa quando o modelo de contas é planejado antes da primeira extensão.

O lado do SAP BTP é o mesmo para todas as opções de implantação. O que muda é a conexão com o ERP:

• On-premise e Private Edition: o SAP Cloud Connector abre um túnel controlado da rede do cliente até o subaccount, e as destinations apontam através dele para o sistema SAP S/4HANA.
• Public Edition: o SAP S/4HANA Cloud expõe APIs liberadas por meio de communication arrangements, e as destinations no SAP BTP as chamam pela internet.
• Identidade: o SAP Cloud Identity Services é uma forma comum de reconhecer o mesmo usuário no SAP BTP e no back-end; a configuração de confiança difere conforme a opção de implantação.

Os serviços da plataforma não mudam com a opção de implantação do ERP; muda apenas a configuração de conectividade e de confiança entre o SAP BTP e o SAP S/4HANA.