Comparar responsabilidades antes de comparar produtos

Compare o mesmo resultado

A escolha da ferramenta de prototipagem não tem de determinar o modelo operacional de produção. As pessoas podem explorar ideias com ferramentas adequadas ao seu trabalho. A organização continua a precisar de uma forma suportada de proteger, instalar, manter e operar os resultados úteis.

Um assistente de programação, uma plataforma interna e uma fábrica de software podem resolver partes diferentes do problema. Comparar os preços das subscrições sem definir o âmbito pode conduzir a uma decisão enganadora.

Comece por um resultado exigido: entregar e operar um serviço interno sob os requisitos de dados, segurança e fiabilidade da empresa. Depois, identifique o trabalho necessário ao longo do ciclo de vida. Inclua o trabalho após a primeira demonstração bem-sucedida.

Para um serviço fictício de contratos, a organização precisa de requisitos aprovados, acesso dos colaboradores, registos privados, lançamentos verificados, resposta a incidentes e atualizações contínuas. Uma ferramenta que gera um endpoint responde apenas a parte desta lista.

Descreva três modelos operacionais plausíveis

Com um assistente de programação, os programadores usam IA dentro de um sistema de engenharia existente. A organização fornece os processos envolventes, as integrações, as capacidades da plataforma e a recolha de evidências. Isto pode adequar-se a uma organização com serviços partilhados maduros.

Com um sistema de entrega integrado internamente, a organização integra agentes, contexto, verificações, deployment e feedback operacional. Ganha controlo sobre a conceção e também assume a responsabilidade pelo produto de integração, pelo seu suporte e pelas suas atualizações.

Com uma fábrica de software adquirida, um fornecedor disponibiliza um fluxo de trabalho ligado e mais abrangente. Verifique o âmbito real e as integrações suportadas. A organização continua a precisar de decisões de produto e de uma divisão explícita de responsabilidades.

Estes são modelos de comparação, não categorias universais de produtos. Um fornecedor ou plataforma interna específica pode combinar capacidades de forma diferente.

Verifique o caminho do protótipo até ao serviço em operação

Use o mesmo cenário concreto para cada opção. Para o protótipo bancário, comece com transações sintéticas e sem permissões reais. Peça à equipa ou ao fornecedor que demonstre estas capacidades antes de ampliar o acesso:

1. Avaliar o protótipo e identificar código que precisa de alterações ou substituição.
2. Fazer deployment na infraestrutura exigida, incluindo as suas próprias contas cloud quando a política o exige.
3. Verificar as permissões da aplicação, o tratamento de segredos e os fluxos de dados do desenvolvimento e da execução.
4. Produzir evidências face aos requisitos aplicáveis e registar a decisão de lançamento.
5. Monitorizar o serviço, corrigir vulnerabilidades, testar a recuperação e responder a incidentes.

Colocar o código na sua conta é uma parte deste trabalho. Verifique quem pode administrar o ambiente e onde os serviços externos recebem dados. Ajuste os controlos às suas obrigações; o local do deployment, por si só, não demonstra conformidade.

Para conhecer os limites declarados por um fornecedor, compare a descrição de responsabilidade partilhada da Taiga com o seu mapa. Este material pertence ao editor deste site. Verifique o acordo e a configuração aplicáveis antes de ativar a Taiga.

Separe executar, verificar e decidir

Para cada atividade, registe quem a executa, quem verifica o resultado e quem aceita a consequência. Uma parte pode assumir várias funções, mas uma função sem responsável é uma lacuna.

Os serviços cloud também dividem a responsabilidade entre fornecedor e cliente. A divisão exata depende do serviço. Use isto como motivo para pedir um mapa preciso, não para presumir que todos os produtos geridos têm os mesmos limites. Responsabilidade partilhada da AWS.

Procure lacunas e trabalho duplicado

Suponha que o fornecedor gera um pipeline enquanto a equipa da plataforma já mantém o processo aprovado de deployment. Decida se o fornecedor deve usar esse processo. Dois pipelines mantidos independentemente podem criar controlos incompatíveis e custos desnecessários.

Por outro lado, um fornecedor pode presumir que o cliente tem uma equipa de incidentes, enquanto o cliente presume que a operação está incluída. Resolva essa lacuna antes de os utilizadores dependerem do serviço.

As orientações da CNCF sobre plataformas permitem combinar capacidades internas e geridas. A pergunta relevante é se a experiência resultante satisfaz as necessidades dos utilizadores com responsabilidade clara. Orientações da CNCF.

Use o mapa na decisão comercial

Anexe o mapa de responsabilidades às notas da avaliação e clarifique-o no acordo aplicável. Calcule o custo do trabalho que permanece na organização. Inclua o custo de manter as ligações entre componentes.

Um fornecedor mais abrangente pode ser valioso quando elimina trabalho de integração e preserva evidências ao longo do ciclo de vida. Uma abordagem interna pode ser valiosa quando requisitos específicos justificam manter essa responsabilidade. Decida com base no resultado exigido e no âmbito verificado.