9 sinais de aviso de que a arquitetura de TI necessita de cuidados

9 sinais de aviso de que a arquitetura de TI necessita de cuidados

Uma sólida arquitetura de TI mantém a estratégia tecnológica de sua empresa funcionando. Mas são muitos os indicadores de que ela pode estar próxima do colapso.

É provável que em algum momento alguém tenha passado muito tempo planejando a arquitetura de TI da sua organização antes de entregar o grande plano a outra pessoa para construí-la e depois para outra pessoa mantê-la à medida que seu ambiente de computação aumentasse inevitavelmente. 

E, as chances também são, em algum lugar ao longo da linha, de melhores intenções desbotadas em face da conveniência, política departamental e má gestão geral, corroendo o que antes era uma estratégia coerente de gerenciamento de arquitetura em uma série contínua de decisões independentes, caso-por-base sobre cada componente técnico.

Como você sabe se sua organização se desviou do caminho?

Aqui estão nove sinais de alerta de que uma arquitetura de TI ruim tomou conta da sua organização.

1 - Re-digitação manual
A redigitação manual pode não ser o maior custo que as empresas pagam devido à arquitetura ruim, mas é certamente a mais óbvia. Contratar seres humanos para servir como o mecanismo da interface que conecta aplicativos incompatíveis não é apenas caro; é desumano.

Impacto arquitetural: erros de codificação resultam em dados inconsistentes.

Impacto direto nos negócios: A reinserção manual elimina os recursos de negócios da atividade de criação de valor.

2 - Coleção de soluções pontuais
Todos querem o seu trabalho apoiado por uma solução “best of breed”. Entretanto, basta definir  “seu trabalho” de forma muito restrita para que todos tenham que visitar muitos aplicativos para realizar seu trabalho.

Enquanto isso, a menos que a TI gaste muito tempo criando interfaces para conectar todas essas soluções pontuais, você estará de volta à recodificação.

Impacto arquitetural: as soluções pontuais geram a necessidade de interfaces de sistema e o número de plataformas que devem ser suportadas. Coleções de soluções pontuais também criam frequentemente a necessidade de redigitação manual.

Impacto direto nos negócios: as coleções de soluções pontuais diminuem os processos de negócios e aumentam os custos de treinamento - além de questões de recriação de chaves.

3- Aplicações redundantes
Cada aplicativo de negócios resolve problemas de negócios. Resolver problemas de negócios é bom, então resolvê-los mais de uma vez deve ser ainda melhor, certo? Não!

E ainda que muitas empresas mantenham muitas aplicações redundantes, seja porque se sobrepõem, porque suportam algumas áreas exclusivas, ou porque cresceram através de fusões e aquisições, elas não são recomendáveis. O dinheiro gasto para suportar toda essa redundância é puro desperdício.

Impacto arquitetural: os aplicativos redundantes exigem a necessidade de interfaces de sistema e um grande número de plataformas que devem ser suportadas.

Impacto direto nos negócios: os aplicativos redundantes eliminam os recursos de TI da atividade de criação de valor e desperdiçam dinheiro em licenças de software que não oferecem nova funcionalidade para os negócios - e geralmente criam a necessidade de reinserção manual.

4 - Dados redundantes
Muitas vezes, diferentes aplicativos precisam da mesma informação para realizar seus trabalhos. Você tem duas opções: apontá-las para o mesmo banco de dados subjacente, o que nem sempre é possível, ou sincronizar seus bancos de dados separados, o que geralmente é bastante confuso.

Ah! Há sempre essa opção de re-digitação manual ....

Impacto arquitetural: as unidades de dados redundantes precisam da interface do sistema e geralmente criam necessidade de reinserção manual.

Impacto direto nos negócios: Manter a sincronização de dados entre vários bancos de dados é difícil, levando a esforços desperdiçados em atividades de reconciliação, obtendo respostas erradas dependendo de qual banco de dados é consultado.

5 - Muitas interfaces
Quando você tem dados redundantes e decide mantê-los sincronizados, é necessário criar uma interface. Mesmo que você não o faça, muitas vezes você precisa alimentar um sistema com resultados de outro sistema.

Quanto mais sistemas e bancos de dados você tiver, mais interfaces você criará. É melhor do que não tê-los, mas à medida que se acumulam, sua arquitetura se torna cada vez mais frágil e você gasta mais e mais tempo gerenciando as interfaces em vez de criar novas funcionalidades.

Impacto arquitetural: quanto mais interfaces você tiver, mais frágil será seu sistema e mais difícil será manter esse sistema.

Impacto direto nos negócios: a interface de criação após a interface elimina os recursos de TI da atividade de criação de valor.

6 - Integração faux-elegante
Então você decide resolver o seu dilema de interface com um sistema de integração de aplicativos empresarial elegante, ou um barramento de serviços, ou alguma outra forma de middleware mais metadados que mantém tudo limpo.

E seus desenvolvedores imaginam duas coisas: (1) o que seu novo sistema legal faz é facilitar ainda mais a solução dos problemas fáceis; e (2) não resolve os problemas difíceis. E em vez de discutir com você, eles reconstroem a mesma teia de aranha das interfaces, mas escondem dentro do sistema EAI, para que você não saiba.

Impacto arquitetônico: A integração do falso-elegante é tão frágil e difícil de manter quanto o excesso de interface.

Impacto direto nos negócios: A integração do falso-elegante ainda drena os recursos de TI da atividade de criação de valor - e também é cara.

7 - Kludges e soluções alternativas
Talvez você estivesse competindo com um desenvolvedor externo que menosprezou um projeto. Talvez o patrocinador de negócios tenha insistido em um prazo muito curto. Ou talvez construir uma solução tenha arruinado o caso de negócios do projeto.

Seja qual for o motivo, você acorda um dia para descobrir que muitos de seus sistemas são mantidos juntos com Band-Aids, goma de mascar e fita adesiva.

Se você tiver sorte, ninguém vai notar antes da sua aposentadoria.

Impacto arquitetônico: os Kludges resolvem problemas imediatos criando sistemas frágeis.

Impacto direto nos negócios: Seu custo de manutenção aumenta com cada solução desnecessária, assim como o tempo de inatividade, o custo do treinamento da equipe e a complexidade de cada projeto subsequente.

8 - Tecnologia obsoleta
É missão crítica! Satisfaz a necessidade do negócio perfeitamente! O que você quer dizer com gastar dinheiro para mantê-la?

Quando você tem sistemas baseados em uma versão do Visual Basic que a Microsoft não suporta há uma década, que não pode ler e gravar de qualquer versão do SQL Server que não tenha pelo menos sete anos de idade, e só roda em versões do Windows que já não têm drivers para nenhuma das impressoras que você use - sim, você tem que gastar dinheiro para mantê-los operacionais.

Impacto arquitetônico: Quanto mais obsoleta a tecnologia, mais difícil é manter e interagir com novos sistemas e equipamentos.

Impacto direto nos negócios: A tecnologia obsoleta leva a um aumento no custo de manutenção, ao mesmo tempo em que aumenta sua incapacidade de adaptar os sistemas aos novos e dinâmicos requisitos de negócios.

9 - White papers
Você vê um monte de sinais de aviso. Você organiza um grupo de gerenciamento de arquitetura técnica corporativa. Você contrata um especialista ou dois. E sua produtividade é enorme.

Enorme, isto é, se você mede a produtividade em termos do número de white papers que eles publicam. Mudou como o trabalho é feito em TI?

Impacto arquitetônico: Nenhum. Todo mundo ignora o grupo de arquitetura.

Impacto direto nos negócios: O custo de desperdício de salários, papel e toner - e ainda mais cinismo empregado sobre mais uma moda de gerenciamento.

Por Bob Lewis, para a CIO/EUA

Compartilhe: