[SOA # 5] - Processos

Da mesma forma que SOA não requer nenhuma nova tecnologia, o mesmo vale quando tratamos de processos ou metodologias para gestão de programas e projetos. A corporação pode e deve reaproveitar os processos existentes, principalmente as práticas com benefícios comprovados.

Mas algumas mudanças podem ser necessárias, visando atender principalmente os meta-requerimentos Agilidade, Flexibilidade e Simplicidade. Um processo burocrático ou resistente a mudanças, como aqueles baseados em modelos waterfall (cascata), é incompatível com tais requisitos. Por outro lado, processos muito “leves” como XP (eXtreme Programming) podem resultar em redundância e retrabalho por não fornecerem uma visão geral da empreitada e por carecerem de atividades gerenciais.

O equilíbrio entre a agilidade de um processo e robustez de seus mecanismos de administração e controle, alvo de vários estudos e propostas, é crítico para a realização das promessas de uma iniciativa SOA. Por isso trata-se de uma definição que deve ocorrer no âmbito do Programa, logo em seus primeiros momentos.

Para um processo ser considerado adequado para a implementação de uma SOA ele deve:

• Promover Agilidade: o que não significa apenas ganho de produtividade dos desenvolvedores. Um processo ágil elimina barreiras e integra atividades visando aumento da qualidade de todos os produtos gerados;
• Absorver Mudanças: e não combatê-las. Um Serviço em uma SOA deve assimilar e refletir as mudanças que ocorrem em um processo de negócio de forma quase imediata. É vital que o processo saiba tratar tal volatilidade;
• Respeitar a Arquitetura: ou seja, garantir que todos os participantes de uma iniciativa SOA tenham uma visão do todo, da Arquitetura, seus padrões e princípios;
• Incentivar o Reuso: valorizando todos os ativos existentes e aqueles produzidos no programa e facilitando sua reutilização e combinação com outros ativos;
• Facilitar a Comunicação: entre todos os participantes do programa e respectivos projetos e destes com as áreas de negócio.

===============

Gestão do Portfólio de Serviços

Uma das responsabilidades mais críticas do Comitê Gestor SOA é a administração do portfólio de serviços. A garantia do alinhamento do programa com as estratégias da organização e da satisfação de seus requerimentos são realizadas através de uma correta gestão do portfólio de serviços. Existem no mercado várias ferramentas que apóiam tal atividade, normalmente direcionadas para o acompanhamento de vários projetos. Elas podem ser adaptadas para o gerenciamento de um programa SOA.

Os idealizadores da ferramenta Balanced Scorecard, Robert Kaplan e David Norton, lançaram recentemente um novo conceito que pode agregar considerável valor à gestão de um programa SOA. É o Mapa Estratégico [5], que “é a representação visual da estratégia de uma empresa. Sua principal finalidade é demonstrar a Prontidão de determinado ativo intangível para atendimento dos processos internos críticos: gestão de operações, gestão de clientes, inovação e processos regulatórios e sociais. Ele se torna uma visão consolidada das quatro perspectivas do Balanced Scorecard (Financeira, do Cliente, dos Processos Internos e de Aprendizado e Crescimento). Os ativos intangíveis foram estruturados em 3 grandes grupos: Capital Humano, Capital Organizacional e Capital da Informação. De acordo com os estudos conduzidos pelos autores e parceiros ao redor do globo, para o chamado Capital da Informação, o grande objetivo das empresas é a ‘disponibilidade de sistemas de informação, de infra-estrutura e de aplicativos de gestão do conhecimento necessários para suportar a estratégia’” [6] [5].

A relativa simplicidade desta ferramenta e a clareza com a qual demonstra as estratégias corporativas e sua relação de dependência com ativos de TI, o Capital da Informação, a tornam bastante adequada para a gestão, em alto nível, do portfólio de serviços. Como um serviço em uma SOA é a representação direta de um processo ou atividade de negócio, a comunicação do comitê gestor SOA com as áreas de negócio é bastante facilitada pelos mapas estratégicos.

No entanto, serão necessárias várias alterações no formato original da ferramenta. Os ativos de TI são apresentados na obra em 4 grandes grupos: Sistemas Transacionais, Aplicações Analíticas, Aplicações Transformacionais e Infra-Estrutura de Tecnologia. Tal classificação deve ser trocada pelos 4 tipos de serviços (Básicos, Intermediários, Processos e Públicos) mais o Frontend das Aplicações e a Infra-Estrutura tecnológica.

Uma nova dimensão deve ser criada para indicar a relevância estratégica de determinado serviço. Esta alteração também deveria afetar o modelo original, de forma a possibilitar que sistemas transacionais ou analíticos também possam ser classificados como “Transformacionais”, ou seja, como sistemas que alteram drasticamente um ou mais processos de negócios.

Outra mudança necessária é na escala de avaliação da prontidão dos ativos. O estudo original apresenta seis níveis de prontidão [6]:

1. OK. Ativo atende plenamente os requerimentos do negócio
2. Leves Melhorias são necessárias
3. Novos desenvolvimentos a caminho
4. Novos desenvolvimentos atrasados
5. Grandes Melhorias necessárias
6. Nova Aplicação necessária

A nova escala deveria refletir o ciclo de vida dos serviços, o que a deixaria da seguinte forma [4] :

1. Publicado: em Produção;
2. Classificado: alocado na arquitetura e agendado para publicação;
3. Certificado: aprovado nos testes de qualidade. Atende todos os requisitos especificados no Contrato do Serviço;
4. Submetido: em processo de Certificação;
5. Em Desenvolvimento;
6. Identificado / Especificado: serviço já foi identificado e modelado – encontra-se na fila para início de sua construção.

Deve-se lembrar que a principal utilidade desta ferramenta é a comunicação com o corpo diretivo da empresa. Daí a relativa superficialidade da escala de avaliação do grau de prontidão dos serviços. No entanto nada impede que extensões sejam desenvolvidas de forma a enriquecer o relatório e municiar os processos de tomada de decisão do comitê gestor SOA. As alterações mais desejadas talvez sejam aquelas que propiciem:

• Visibilidade dos prazos de transição entre as etapas do ciclo de vida dos serviços;
• Opções de aquisição ou desenvolvimento do serviço (compra no mercado, desenvolvimento interno, desenvolvimento terceirizado ou utilização de ativo livre e aberto disponível na Internet); e
• Estimativas de custos de cada serviço.


>>>>>>>>>> SOA #6 - MDA (Model Driven Architecture)

4. “Practical Software Reuse”, Michel Ezran, Maurizio Morisio e Colin Tully
Springer (2002).
5. “Gestão Estratégica de Ativos e Portfólios de Projetos de TI”, Paulo F. Vasconcellos
Artigo publicado em Out/2004.
6. “Mapas Estratégicos”, Robert S. Kaplan e David P. Norton
Editora Campus / Elsevier (2004).

Marcadores: arquitetura, gerenciamento_de_projetos, soa