TI como Mecanismo Adaptativo

Mecanismos adaptativos permitem que os indivíduos possuam uma capacidade de resposta ao meio de acordo com mudanças ambientais e comportamentais, ajustando-se assim para a sobrevivência. No cenário empresarial, um exemplo de mecanismo adaptativo é a capacidade da empresa em inovar ou criar novos processos de negócios reutilizando seus ativos de software.

Para ter esta capacidade, os componentes de software devem ser projetados para o reuso. Não menos importante é a catalogação e a divulgação desses componentes no ambiente corporativo. Muitas empresas não enxergam a área de TI como mecanismo de adaptação e perdem flexibilidade e agilidade em mudanças estratégicas.

Como a TI pode se transformar em um mecanismo adaptativo?

Alguns cenários que são comuns em muitas empresas e organizações:

Pode-se agrupar os cenários em três grandes blocos:

• Migração - que compreende os cenários C01 e C02;
• Integração - que compreende os cenários C03, C04 e C05;
• Evolução - que compreende os cenários C07 e C08.

Neste exemplo hipotético, todos os cenários ocorrem na mesma empresa.

Analisando pela perspectiva da gestão de um projeto, são destacadas as dependências e as prioridades. É natural que a migração seja escolhida como prioridade. Porém a empresa não pode parar até que tudo seja migrado. Então o que é prioridade e quem depende de quem? É impossível determinar uma dependência linear entre os blocos, pois são coparticipantes. Mas podemos determinar prioridades dentro da intersecção dos blocos:

Mas, por que são coparticipantes e por que as prioridades foram definidas assim? O objetivo é atender às necessidades do cliente. No exemplo, a meta principal é a expansão do negócio em 200% (C06). Para atingir este objetivo, é necessário novas parcerias comerciais (C03), novos canais de venda (C04) e produtos inovadores (C07). Mas o legado não suporta mais usuários; está obsoleto (C01). O risco é alto.

É importante identificar o que é necessário para atender a parcerias comercias, além das características dos novos produtos e o que será exposto prioritariamente nos novos canais de venda. Que parte do negócio ou produto será foco destas parcerias? A resposta identificará que módulo do legado será prioridade na migração.

Os módulos não operam de forma isolada; existe uma dependência mútua com o que foi migrado e o legado, que utilizam regras e dados. Então estas serão as primeiras fronteiras de integração a serem tratadas.

Com o módulo prioritário migrado, as integrações com parceiros e canais de vendas já podem ser realizadas.

Para atender em tempo ao cenário C07, uma alternativa é procurar no mercado uma solução no modeloSaaS que atenda as expectativas da equipe de marketing e que permita alguma forma de integração. No exemplo, os novos produtos não são suportados pelo sistema de informação disponível. Então este modelo será escolhido para suprir essa necessidade em tempo de mercado. Nesse caso seria um risco de negócio aguardar o desenvolvimento de uma nova solução.

Modularização

A modularização é uma parte importante da arquitetura e possui alto grau de complexidade. Definir um módulo não é só analisar uma divisão lógica do negócio e dividir seu software em pedaços. Existem dependências técnicas, políticas e de negócio (umas fortes e outras mais fracas). A complexidade da solução tecnológica, formas de comunicação e a forma de distribuição dependem da modularização.

Há casos em que a forma com que o software foi modularizado inviabiliza o atendimento de alguns atributos de qualidade (como eficiência, portabilidade e até confiabilidade). Um exemplo disso é colocar no mesmo módulo processos de backoffice que são pesados com uma quantidade de transações elevadas junto com funcionalidades que são disponíveis a clientes. Se não houve um correto desenho modular, fica complexo a segregação das funcionalidades para minimizar futuros problemas de desempenho e confiabilidade.

Com uma visão modular da solução é possível dimensionar e distribuir de forma mais ágil os componentes de software que são mais consumidos em um momento específico do negócio. Em período de declaração de imposto de renda, por exemplo, o módulo de informe de rendimento será mais acessado e não deverá interferir em outros processos.

Antes de migrar, integrar ou construir é importante modularizar.

Atendendo aos atributos de qualidade

Voltando ao cenário hipotético, é possível identificar quatro fronteiras principais do sistema migrado: com o legado, com o SaaS, com os parceiros e com os novos canais de venda. Estes são pontos críticos pois destacam o risco de indisponibilidade da integração com sistemas externos. É importante ficar atento ao atendimento dos principais atributos de qualidade (confiabilidade, eficiência e portabilidade), para mitigar os riscos de integração e se manter adaptável a outras soluções.

Analisando os requisitos, as fronteiras serão classificadas como fronteiras internas e externas. As fronteiras internas correspondem a integrações do legado e SaaS; as externas correspondem as integração com os parceiros e canais de venda. Neste cenário, o legado está obsoleto e não suporta mais usuários. É necessário dar confiabilidade à migração e a suas integrações.

Uma solução para que o legado continue em pleno funcionamento e com o mesmo número de requisições é adotar uma estratégia assíncrona. A maioria das transações relativa às integrações poderá rodar em momentos em que o legado não está sendo muito utilizado. Para garantir a confiabilidade e a recuperabilidade das transações assíncronas, o controle transacional pode ser por compensação.

A virtualização dos servidores ampliam a elasticidade da solução, permitindo a flexibilização do dimensionamento dos recursos e da distribuição dos componentes em momentos específicos do negócio.

Outro ponto é a definição da interface entre as fronteiras. Com interfaces bem definidas o sistema se torna Adaptável.

Existem muitos detalhes a serem resolvidos em relação aos atributos de qualidade.

Infraestrutura SOA

Para tentar atender uma série de requisitos já citados, podemos adotar uma infraestrutrua SOA (Arquitetura Orientada a Serviços).

Do ponto de vista de estrutura conceitual temos:

1. Para atender as fronteiras internas e externas, neste caso foi escolhido umEnterprise Service Bus (ESB) como middleware de integração. Por definição o ESB deve fornecer suporte aos principais atributos de qualidade que é necessário, no que diz respeito a integração. Além de ser um ponto único de integração e monitoramento.
2. É preciso flexibilizar a manutenção de regras de negócio, para não correr o risco de multas (C08): um motor de regras de negócio neste cenário é uma opção porque existe uma grande quantidade de regras e a aplicação de um padrão Strategy, por exemplo, tornaria o código muito extenso e difícil de gerenciar.
3. Para possibilitar o negócio mudar sua estratégia quando bem entender: A adoção de uma metodologia BPM e uma solução BPMS (motor de processo).

Conclusões

Este artigo dá uma visão ampla e conceitual do modelo adaptativo. Se diz adaptativo pela capacidade de se compor, de forma escalável e sustentável, soluções, componentes e regras. Quanto mais maduro, maiores serão as possibilidades de soluções.