Na postagem anterior desta série, nós olhamos para o planejamento e análise da mudança na empresa através da ligação do ciclo de vida de elementos como aplicativos e projetos. Mas, como você decide o que fazer com, por exemplo, seu panorama de aplicativos? Quais aplicativos precisam ser melhorados, mudados de plataforma, atualizados funcionalmente, ou simplesmente eliminados?

A abordagem comum para isto é o gerenciamento do portfólio de aplicativos, o que nós temos descrito em diversas outras postagens. Aqui, gostaríamos de focar nas análises analíticas que estão por trás de gráficos como o mostrado abaixo, com os tradicionais eixos de valor técnico e de negócio, o tamanho das bolhas indicando custos, e suas cores indicando o risco. Este tipo de gráfico é geralmente usado para decidir o futuro dos aplicativos e, neste exemplo, vemos quatro opções: Tolerar (Azul), Investir (vermelho), Migrar (Amarelo), e Eliminar (Verde) (também conhecido como análise TIME. Isto é bastante grosseiro, e você poderia querer usar um conjunto de opções diferentes e mais detalhadas, mas para esta postagem focaremos em como calcular estes valores para o valor de negócio, valor técnico,e risco, no Enterprise Studio.

Naturalmente, existem muitos fatores que você pode querer considerar para definir o destino do seu aplicativo, de forma que o exemplo abaixo é apenas isto - um exemplo - mas é, de qualquer forma, realístico o suficiente, já que é baseado em uma situação real de um de nossos clientes.

Como você pode ver abaixo, várias das métricas que nós usamos para avaliar o valor de negócio, o valor técnico, e o risco, são calculados a partir da estrutura da nossa arquitetura. Isto mostra, realmente, a força de usar modelos como a base para nossas análises, algo que você jamais será capaz de fazer usando simples planilhas ou outras ferramentas de desenho para fazer o cálculo.

Vamos começar como valor de negócio. Na tela abaixo, vemos como a métrica de valor de negócio á construída como uma média ponderada de várias sub-métricas:

• Importância estratégica, determinada pelo cálculo da contribuição de um aplicativo para os resultados de negócio, através dos processos de negócio que ele suporta, as capacidades que ele habilita, e as metas que são satisfeitas por isto. Isto pode ser feito de várias formas, desde avaliações de alto nível que apenas determinam se um aplicativo tem qualquer influência em um resultado, até cálculos bastante refinados que pesam as prioridades das metas e atributos de força nos relacionamentos. Isto pode ser calculado usando a linguagem de scripting embutida do Enterprise Studio. 
• Importância para os usuários, que, por si só, é uma média ponderada do número de usuários efetivos (aqueles que usam o aplicativo em uma base diária), e os potenciais usuários (aqueles que podem usá-lo, mas não dependem dele, e que recebem um peso bem menor, naturalmente). Estes números são importados de uma fonte externa (neste caso, um aplicativo de Gerenciamento de Serviços de TI (ITSM-IT Service Management), e normalizados para uma faixa de 0 a 10.
• Criticidade para o negócio, determinada pela contagem e normalização do número de processos críticos de negócio que são suportados pelo aplicativo, onde processo crítico de negócio, em si, é uma outra métrica, aplicada aos processos de negócio na arquitetura. Esta métrica é calculada através de um script, caminhando pela estrutura do modelo para encontrar todos os processos direta ou indiretamente suportados por um aplicativo, e tomando o maior valor da métrica criticidade.
• Importância para outros aplicativos, também uma métrica baseada em script, calculada com base no número de relacionamentos de saída (os relacionamentos ArchiMate de acionamento, fluxo e servidão, além dos relacionamentos de acesso de gravação para dados lidos por outros aplicativos).
• Nível de conformidade regulatória de um aplicativo, determinado pela contagem do número de violações conhecidas das regulações aplicáveis, normalizado para uma escala de 0 a 10. Esta métrica requer uma avaliação manual por parte dos responsáveis pela conformidade.
• Nível de conformidade de SLA do aplicativo é a porcentagem do tempo em que ele está dentro dos limites de desempenho esperados (e.g., 99,9%). Assim como o número de usuários, isto é baseado na informação coletada pelo aplicativo de ITSM. Ele fornece um valor percentual que também é normalizado para uma escala de 0 a 10.

O valor técnico de um aplicativo é determinado de forma semelhante. O aspecto mais importante do valor técnico é a qualidade técnica de um aplicativo. Isto é determinado através das várias 'qualidades' conhecidas a partir de padrões, tais como o padrão ISO/IEC 25010 para a qualidade de software. Algumas delas serão baseadas em medidas operacionais do panorama de aplicativos. Por exemplo, a estabilidade de um aplicativo pode ser baseada no número e severidade de incidentes, controlados através de uma solução de help desk; sua manutenibilidade pode ser medida com base no esforço relativo por mudança, e assim por diante.

Outras métricas de valor técnico são baseadas na estrutura da arquitetura e podem ser calculadas usando scripts. A complexidade (externa) de um aplicativo, por exemplo, pode ser determinada pelo número de relacionamentos de entrada e de saída dos aplicativos. Além disso, outras métricas podem requerer uma opinião especializada, por exemplo, a adequação do aplicativo à arquitetura. a maturidade da tecnologia utilizada, ou a qualidade de sua documentação. Qualidade de dados é outra métrica importante, a qual requer avaliação externa. Por fim, métricas como usabilidade podem ser avaliadas através de uma pesquisa com os usuários.

Análises automatizadas de qualidade de código de software são realizadas por especialistas como a CAST, um de nossos parceiros. As saídas de tais análises podem ser importadas no Enterprise Studio, e usadas no seu gerenciamento de portfólio e do ciclo de vida de aplicativos.

Outra métrica altamente relevante para avaliar aplicativos é seu risco de tecnologia, indicado através das cores das bolhas no gráfico acima. Isto agrega vários riscos, como:

• Risco do término do suporte: o risco de um aplicativo ou elemento da tecnologia perder o suporte do fornecedor. Quão menor o tempo de vida restante, maior o risco. Este tipo de dado é, tipicamente, fornecido por fontes externas, como a Technopedia.
• Risco de competência: a disponibilidade futura de pessoal com os requisitos de conhecimento e competência técnica para manter um aplicativo
• Risco de dependência: o valor do pior caso de fim de suporte em toda a tecnologia na qual o aplicativo depende. Se um aplicativo em si ainda é suportado pelo seu vendedor, mas requer, por exemplo, o Windows XP para funcionar, isto constitui um risco de dependência.

Além destas métricas, para decidir o destino de um aplicativo você geralmente usa também atributos como o tamanho (mostrado pelo tamanho da bolha, no exemplo acima), idade e custo. Este último, custo, será abordado na próxima postagem desta série, que lida com as análises financeiras. Fique ligado!