O custo anual do mainframe num orçamento defensável

O custo anual do mainframe não é o número numa fatura de hardware. É uma pilha de contratos, medições de capacidade, obrigações com pessoas, instalações e provisões de risco que reagem de maneira diferente quando a carga muda. Junte tudo numa taxa média e criará um mau caso de migração: a poupança parecerá milagrosa ou a máquina parecerá impossível de abandonar.

Vi análises falharem porque finanças pediu um preço único por MIPS e engenharia forneceu um. MIPS pode descrever capacidade relativa, mas as faturas importantes de software não são apenas MIPS vezes uma tarifa pública. O modelo útil começa em cada fatura e contrato, identifica o fator de cada linha e pergunta se mover uma carga altera esse fator.

Não existe uma tarifa universal honesta

Um orçamento anual exige grupos separados porque cada um reage a um evento. Software por capacidade pode seguir um pico medido de quatro horas. Manutenção fica fixa até retirar a máquina. Pessoas mudam quando responsabilidades e plantões mudam. Um rateio do datacenter pode continuar depois de o espaço ficar vazio.

Separe pelo menos estes grupos:

• Software por capacidade, incluindo produtos cobrados por MSU ou outra métrica medida.
• Software fixo ou por faixas, incluindo licença anual, suporte e preços por classe ou ambiente.
• Compra ou locação, manutenção, armazenamento, rede e dispositivos ligados.
• Pessoas, suporte externo, instalações, recuperação de desastre, segurança e conformidade.

Não aloque tudo com o mesmo denominador. CPU pode servir para um produto e ser absurda para armazenamento, suporte ou um especialista focado em releases. Escolha o fator que explica o custo: contribuição ao pico, espaço, tickets, ambientes ou esforço dedicado. Deixe um custo partilhado sem alocação se a divisão inventar precisão.

O primeiro artefacto deve ser um registo de contratos, não um total. Para cada linha, anote fornecedor, produto, prazo, renovação, métrica, mínimo, faixa atual, cancelamento e prova. Nomeie quem defende a interpretação. Uma célula «software mainframe» não diz qual cobrança cai quando a carga muda.

MIPS estima capacidade mas raramente reproduz a fatura

MIPS significa milhões de instruções por segundo, mas não é unidade estável de trabalho nem moeda geral da IBM. Misturas de instruções variam e novas gerações fazem mais trabalho útil com capacidade nominal igual. Batch de E/S, transações, compressão, Java e bases de dados pressionam a máquina de formas distintas. Um número sem fonte e método é rótulo, não prova.

Organizações ainda usam MIPS para planeamento porque é uma escala conhecida. Alguns fornecedores usam faixas MIPS em contratos. O número importa, mas não é universal. Pergunte se é classificação da máquina, uso observado, pico, média ou faixa contratual. Não são substitutos.

O atalho perigoso é:

annual mainframe cost = total MIPS x assumed price per MIPS

A fórmula esconde mínimos, faixas, motores especializados, desenvolvimento, armazenamento e pessoas. Também supõe custo marginal constante. Contratos tornam isso falso. Um pequeno aumento cruza uma faixa; uma queda pode poupar zero até mudar o mínimo.

Use MIPS como reconciliação. Se o inventário atribui metade do ambiente a uma aplicação e relatórios SMF mostram muito menos processador geral, investigue o limite. A estimativa pode incluir base de dados e middleware cobrados noutro lugar, ou a medição omitir jobs com outro identificador. Essa discussão revela responsabilidade. Multiplicar dois números incertos só acrescenta símbolo monetário à incerteza.

A cobrança por MSU segue medição e contrato

Uma MSU, million service unit, mede capacidade usada em preços de software IBM. Está mais perto da cobrança do que MIPS, mas não é preço. Depende de produto, modelo, máquina elegível, contrato, país, compromisso e uso reportado. Desconfie de tarifa universal por MSU.

Em muitos acordos de subcapacidade acompanha-se a média móvel de quatro horas, R4HA. Workload Manager regista consumo e Sub-Capacity Reporting Tool processa dados para relatórios elegíveis. A documentação SCRT da IBM exige entradas completas e válidas. Intervalos ausentes não provam carga gratuita: são defeito de relatório.

Costumam misturar-se três valores:

• Procura instantânea mostra o que ocorre agora.
• Média móvel suaviza a procura na janela.
• Valor faturado aplica elegibilidade e contrato à capacidade reportada.

Confundi-los cria poupança imaginária. Remover um job fora do pico reduz CPU e energia sem reduzir software. Dentro do pico também pode poupar zero se outra carga vira o máximo, há mínimo ou o produto continua necessário.

Crie uma vista de contribuição ao pico com os intervalos. Por produto e LPAR, registe hora do máximo mensal, cargas ativas, MSU, mínimo ou faixa e próximo limiar inferior. Teste a remoção em toda a série. Não subtraia a média da aplicação ao pico. Picos mudam.

Motores especializados complicam. Trabalho elegível em zIIP muda a economia, mas não elimina software, armazenamento, operação ou capacidade de contingência. Documente elegibilidade, execução real e comportamento em contenção ou failover. Elegibilidade é técnica; fatura é contratual. Precisa das duas.

Reconcilie a cadeia de relatórios. Ligue cada central processor complex e LPAR aos identificadores do relatório, depois cada produto aos locais licenciados. Confira desenvolvimento, teste, recuperação e produção. Uma LPAR fora do inventário pode gerar cobrança; uma aplicação listada pode não usar o produto.

Guarde intervalos brutos dos meses modelados. Um máximo isolado não mostra o efeito de mover ou encurtar um job. Recalcule cada intervalo removendo só consumo atribuível, refaça a média e ache o novo máximo. Ainda é estimativa porque contrato fica acima dos dados, mas supera subtrair média anual de um pico.

A repetição mostra deslocamento. Se o fecho cria o pico de terça e extratos ficam pouco abaixo na quinta, remover o fecho não poupa toda a sua contribuição. Quinta torna-se máximo; só a diferença pode alterar a medida. Na mesma faixa, a fatura pode ficar igual.

Peça ao gestor de ativos o direito e a fatura, não só a lista instalada. Um produto pode não ser cobrado, vir numa suíte, ter mínimo ou acordo maior. Um componente discreto pode ter suporte próprio. Compras decide o que se cancela; descoberta técnica decide se é seguro. Nenhuma equipa fecha a linha sozinha.

Desenvolvimento e teste merecem tratamento separado. Equipas alocam não produção por CPU de produção, embora aplicações com muitos releases usem mais testes. Registe ambientes, licenças, dados de teste e direitos ativos ou standby. A produção pode sair e uma imagem ficar para defeitos antigos, consultas fiscais ou transição posterior.

Não use preço de tabela como fatura. Ajuda a entender a métrica, mas acordos, pacotes, tetos e mínimos definem caixa. Se o contrato é restrito, proteja o modelo em vez de usar estimativa pública. Uma vista anonimizada mostra categorias e datas; o anexo controlado conserva fornecedor e preço.

Moeda e períodos distorcem comparações. Normalize câmbio pelo método financeiro, atribua suporte pré-pago ao período e separe imposto se necessário. Reconcilie créditos e ajustes, sem escolher um mês favorável. Doze meses devem explicar diferenças entre contrato, pagamento e razão.

Atribua confiança à afirmação, não ao ficheiro inteiro. Cláusula assinada dá alta confiança; queda inferida com etiquetas incompletas dá baixa; saída que depende de três migrações é condicional. Ponha prova pendente e responsável junto de cada linha. Decisores toleram incerteza visível e resolúvel.

Hardware custa mais do que a encomenda

Inclui compra ou locação, manutenção, disco, fita, rede, instalações, peças e segundo local. Algumas empresas possuem o processador e pagam manutenção crescente; outras financiam renovação. A contabilidade muda, mas a obrigação tem prazo e saída.

Um upgrade pode elevar a faixa do software sem mudar a carga. Mover carga talvez não poupe durante a locação ou se a configuração menor viola resiliência. Separe depreciação de caixa evitável. A primeira pode continuar; uma renovação de manutenção pode ser evitada.

Use dados medidos para instalações: energia, espaço, refrigeração, mãos remotas e recuperação. Não lidere com eletricidade. Software e especialistas costumam dominar. Energia importa quando sair permite fechar ou reduzir uma obrigação física.

Registe a primeira data de remoção de cada custo. Se a máquina serve doze sistemas e migra um, chassis, manutenção e recuperação podem não mudar. Por isso poupança da aplicação difere da caixa do ambiente.

O especialista caro costuma cobrir várias funções

Não conte apenas programadores COBOL. Pessoas difíceis de substituir cobrem produção, JCL, scheduler, RACF, CICS ou IMS, recuperação Db2, desempenho, armazenamento, releases, incidentes e conhecimento sem runbook. Um nome pode esconder cinco funções.

Separe por capacidade. Registe titular, suplente, esforço semanal, plantão, dependência externa e sistema que ainda exige cada função. Isso mostra concentração sem inventar valor para conhecimento tácito e evita poupar um salário quando a pessoa operará o substituto ou ficará até ao encerramento.

Faça o mesmo com contratados e avenças. Podem cancelar só na renovação, cobrir várias aplicações ou exigir equipa mínima. Leia escopo e aviso antes de chamar o valor variável.

Sou contra usar custo de contratação substituta como custo anual. É popular porque reforma é risco e recrutadores dão números grandes. Está errado porque uma contratação hipotética não é gasto atual. Separe caixa recorrente e exposição de transição. A direção pode decidir com ambos, não auditar um prémio de medo misturado.

Não suponha remoção imediata dessas pessoas. Em paridade e corte, o conhecimento vale mais. Depois, podem ficar como donos do domínio sem plantão da infraestrutura antiga. A poupança pode vir de contratos não renovados, menos plantão ou vagas não preenchidas, não despedimentos.

Cada linha da conta de uma carga precisa de prova

Uma conta defensável liga cada valor à fonte e classifica o comportamento. Comece com doze meses para não perder fecho anual, pico sazonal ou suporte. Reconcilie com o razão antes de alocar.

Use esta forma:

cost_id,annual_cash,billing_driver,contract_floor,renewal_date,workload_share,removal_trigger,evidence
SW001,REDACTED,product_peak_msu,REDACTED,YYYY-MM-DD,measured,lower_tier_at_renewal,SCRT_report
HW004,REDACTED,fixed_lease,full_term,YYYY-MM-DD,shared,lease_end,signed_contract
LAB007,REDACTED,dedicated_effort,none,YYYY-MM-DD,time_study,role_reassigned,staffing_plan

Oculte valores nos exemplos, mas exija os reais no modelo. removal_trigger obriga a nomear o evento: faixa inferior aceite na renovação, licença cancelada, locação terminada, máquina retirada, suporte reduzido ou vaga não preenchida. «Aplicação migrada» raramente basta.

Classifique cada linha: evitável com esta carga, só com um grupo, fixa até uma data ou retida. Calcule duas vezes. A vista de carga mostra consumo; a de caixa mostra faturas e salários que mudam. Ambas são legítimas, mas só a segunda financia o caso.

Um cálculo mostra a diferença:

run-rate allocation = annual cash x workload share
year-1 cash saving = annual cash x removable share x active fraction of year
net year-1 effect = year-1 cash saving - migration cash cost - overlap cost
steady-state saving = terminated and resized annual obligations

Não misture redução de risco com poupança de caixa. Acompanhe falha, auditoria, recuperação e concentração com dono e provas. Se monetizar, mostre probabilidade e impacto separados.

Antes da aprovação, finanças, operações, compras e aplicação assinam as linhas que entendem. Compras encontra armadilhas, operações dependências, aplicação jobs e interfaces, e finanças impede que alocação pareça despesa removida.

A migração elimina contratos depois das dependências

Pode eliminar licenças, procura, crescimento de armazenamento, janelas batch, especialistas e hardware, cada qual numa data. A previsão segura é uma escada de dependências, não uma percentagem.

Mapeie transações, jobs, ficheiros, impressão, procedimentos, segurança, scripts, reconciliação e consumidores. Um frontend movido com registo em Db2 não remove a base. Batch refeito que ainda envia três jobs JCL não remove o scheduler.

Ache o limiar de cada custo partilhado. Produto sai quando a última carga deixa a LPAR. Fitas podem ficar por retenção. Recuperação segue o maior serviço restante. Circuitos servem outros sistemas. Sequenciar o portefólio pode valer mais do que escolher custo aparente.

Planeie encerramento: arquive, remova identidades e jobs, pare feeds, prove recuperação, atualize procedimentos, notifique contratos e descarte hardware. Carga sem tráfego ainda custa e falha auditoria.

CodeHero reescreve todo o código legado em Go, Rust e TypeScript e verifica o comportamento com um arnês de paridade contra tráfego de produção gravado. Pode entregar em menos de 30 dias, mas avisos, retenção e dependências ainda definem quando o custo cai.

Vários custos sobrevivem na nova plataforma

Migração muda a estrutura, não elimina engenharia de produção. O substituto precisa de computação, base de dados, armazenamento, observabilidade, backups, segurança, suporte, incidentes, recuperação e conhecimento. Zerá-los é defesa, não análise.

Aplique disciplina à cloud. Separe base, picos, base gerida, rede, retenção, não produção e suporte. Não compare mainframe completo com VM nua. Inclua operação paralela e armazenamento temporário.

Alguns deveres ficam baratos por ferramentas e mercado comuns; outros mudam de lugar. RACF vira identidade, SMF vira logs, métricas e traces, Db2 vira backup Postgres. Nomeie o novo dono antes de remover o antigo.

Folga de desempenho continua. O substituto deve cumprir latência, volume, janela de fecho e recuperação sob procura real. Dimensione por traces e testes, não linhas de fonte. Arquitetura pode reduzir desperdício, mas orçamente capacidade provada.

Fixe a base antes de pedir propostas: limite, doze meses e serviços partilhados. Liste upgrades, renovações, mudanças de datacenter e pessoal que ocorreriam sem migração. Senão o projeto recebe poupanças já previstas ou custos inevitáveis.

Mostre três vistas: comprometida, ano de saída com cancelamentos parciais e paralelo, e estado estável após acabar produção, recuperação, retenção e suporte antigos. Date cada vista. Número anual sem calendário presume poupança no primeiro dia.

Use portas de saída, não data otimista. Além do tráfego, pode exigir ciclo completo, resultados reconciliados, teste aceite, fim do rollback, arquivo, acessos removidos, serviço aceite e aviso recebido. Cada porta tem dono e prova; se atrasar, mova a poupança.

A paridade precisa de orçamento. Ambas as plataformas processam casos enquanto equipas comparam resultados. Inclua computação e armazenamento duplicados, extratos, testes, defeitos e aprovadores. Ligue o gasto temporário ao plano, não a uma contingência genérica.

Defina exceções residuais. Se casos raros voltam ao mainframe, a dependência fica. Conte frequência, identifique regra e decida implementar, retirar com aprovação ou usar processo manual limitado. Fallback indefinido mantém licenças e suporte.

Após o corte, compare faturas e previsão por vários ciclos. Confirme picos, faixas, suporte, armazenamento, circuitos e contratados. Feche encomendas e renovações. Registe desvios por linha para a próxima migração usar comportamento observado.

A aprovação deve atribuir custos encalhados. Se uma aplicação sai e produto partilhado fica, a poupança não pode aparecer agora e depois. Mantenha registo central de valores reclamados, realizados e encalhados para evitar dupla contagem e agrupar próximas cargas.

A decisão depende de caixa removível e data de saída

Mostre gasto anual atual, custo estável do substituto e caixa de transição, ao lado das obrigações datadas. Isso revela poupança tardia e sobreposição do primeiro ano.

Teste pico sem queda, locação não cancelável, produto retido, mais capacidade nova, retenção longa e paralelo adicional. Se o caso só funciona quando tudo desaparece no corte, não funciona.

A decisão não é só financeira. Prazo de mudança, recuperação ou concentração podem justificar migração com poupança modesta no primeiro ano. Diga isso abertamente, sem esconder razões estratégicas em poupança inventada.

Abra a aprovação com registo contratual, picos SCRT, mapa de capacidades, limite da carga e tabela de gatilhos. Com dono, evento e data para cada poupança, o custo deixa de ser folclore de MIPS e torna-se plano executável.