Maturidade em Governança SOA - A Visão de um Arquiteto

Em nosso dia a dia de trabalho, vemos muitos projetos de integração usando tecnologia SOA que se esforçam para se tornarem mais maduros. Esses projetos disponibilizam alguns serviços, mas a reutilização no âmbito organizacional é raramente atingida. Isso ocorre pelo fato de que as organizações não sabem como expandir positivamente seus esforços em SOA de uma solução de integração para uma solução corporativa. Nós defendemos que governança é algo necessário para disponibilizar algum valor de negócio para projetos SOA. Mostraremos então, através desse artigo, um ciclo de vida baseado em um modelo de maturidade para governança SOA. Em nosso ponto de vista, governança pode ser vista como um framework para tomada de decisão. De acordo com a definição de governança em TI de Weill & Ross: A governança especifica um framework de direitos de decisões e responsabilidades para ajudar a atingir o comportamento desejado em sua utilização. Nosso artigo está dividido em três partes:

• Uma discussão sobre o ciclo de vida do processo de governança SOA;
• Como a governança SOA pode evoluir, e como o modelo de maturidade pode ser usado para suportar essa evolução e;
• O papel do arquiteto em governança SOA, mostrando um guia prático para quem está vivenciando um ambiente SOA em crescimento.

Nosso modelo é voltado para arquitetos; eles geralmente são os defensores do SOA. Os arquitetos frequentemente desempenham um papel importante na inicialização de governança SOA, mas conforme os esforços crescem dentro da empresa, o seu papel muda e algumas de suas responsabilidades provavelmente serão transferidas para um comitê de governança.

Esse modelo pode ajudar arquitetos a determinar o nível de maturidade em relação à governança SOA de suas empresas. Também promove reflexões práticas relacionadas aos seus papeis a fim de aumentar o nível de maturidade e assim ajudá-los a direcionar os esforços para tornar mais abrangente o sucesso de SOA em suas empresas.

O ciclo de vida da governança SOA

Governança SOA não está relacionada às atividades ligadas à construção dos serviços, mas sim a outras iniciativas para aumentar a qualidade total de SOA promovendo controle em ambientes complexos. Está relacionada a:

• Pessoas – Para se certificar que as responsabilidades estão sendo direcionadas corretamente, e que as pessoas estejam recebendo o devido suporte para adquirir o conhecimento e habilidades necessárias.
• Processos – Para definir se os processos certos estão sendo aplicados para garantir a qualidade e monitoramento dos serviços.
• Produtos – Para cadastrar os requisitos dos serviços e sua documentação; Templates para serem usados na documentação dos serviços também recaem sobre essa categoria.

Nós relacionamos esses tópicos com um modelo de ciclo de vida de governança SOA. Esse modelo define seis processos principais que precisam ser executados para que uma boa governança SOA possa ser alcançada. O ciclo de vida representa uma iteração, um projeto com o escopo de alcançar o sucesso real na implementação de uma arquitetura orientada a serviços. O desenvolvimento SOA se dá com várias iterações do ciclo de vida de governança SOA. Através dessas iterações, a maturidade pode (e deve) aumentar.

Os primeiros dois processos mantém o foco no negócio, onde a visão SOA e o impacto organizacional são trabalhados. Os três próximos processos formam o foco dos arquitetos: gerenciamento do portfólio de serviços, gerenciamento do ciclo de vida dos serviços e o gerenciamento do nível dos serviços. O último processo, gerenciamento do nível dos serviços, é de domínio do administrador do sistema. Entretanto, todas as partes atuantes na governança SOA devem estar envolvidas em todo o ciclo de vida. Descreveremos como essas partes estão envolvidas para cada processo do ciclo de vida de governança SOA.

A visão SOA

O primeiro passo da iteração é estipular objetivos SOA a longo prazo ou revisar os objetivos existentes. Esse processo não só determina a perspectiva SOA na organização como também define os objetivos para a iteração corrente dentro do ciclo de vida. A visão SOA é um produto das áreas de negócio e TI, onde o alinhamento é conduzido pelo arquiteto.

Criando a organização SOA

Nessa etapa do processo, os papéis e responsabilidades da governança SOA são definidos. Muitas vezes isso leva a iniciação de um tipo de comitê que deve ser composto pelos responsáveis pela governança; De analistas de negócio a profissionais de TI, o comitê decide como o ciclo de vida de governança SOA será implementado. Daremos um guia prático nesse artigo mais adiante. Para a execução da iteração corrente do ciclo de vida, as pessoas certas precisam estar no lugar certo. Isso pode requerer, não somente um treinamento extra, como também contratação ou investimento em desenvolvedores. O comitê de governança deve ajudar na adoção dos princípios SOA, defendendo-os dentro da organização e impondo seus padrões.

Gerenciamento do portfólio de serviços

O consenso deve ser atingido junto com os representantes de negócio sobre quais serviços deverão ser desenvolvidos. O arquiteto deve mostrar argumentos técnicos contra argumentos de negócio em se desenvolver serviços específicos. Ao se envolver no gerenciamento do portfólio de serviços desde o início, o arquiteto deve ser capaz de apontar os serviços que são candidatos à reutilização e então encaminhá-los para serem desenvolvidos primeiro. Um roadmap de serviços, listando os serviços atuais e os planejados, é possivelmente o produto do gerenciamento de portfólio de serviços.

Gerenciamento do ciclo de vida de serviços

Esse processo tem o objetivo de implementar, atualizar e retirar serviços da corporação. O gerenciamento do ciclo de vida não deve estar associado a projetos, mas é algo a ser conduzido pelo comitê de governança SOA, que gerencia as mudanças no ambiente SOA. Essas mudanças estão relacionadas ao conceito de reutilização de serviços e execução de regras de negócio por toda a empresa. No comitê de governança SOA os arquitetos devem ajudar a garantir que todos os serviços estejam sendo direcionados ao ciclo de vida de gerenciamento, para evitar a existência de serviços não-gerenciados.

Execução dos princípios

Esse processo se preocupa com os princípios de design e execução. Por exemplo, o arquiteto precisa garantir que as pessoas estejam disponibilizando seus serviços em um repositório, para que estes possam ser gerenciados e reutilizados. Os arquitetos também precisam prestar atenção nos princípios aplicados em tempo de design. Princípios em tempo de design são padrões utilizados para o desenvolvimento de serviços, e geralmente assumem um modelo de melhores práticas. Ao contrário dos princípios em tempo de execução, os princípios em tempo de design geralmente não podem ser monitorados automaticamente. Portanto, desenvolvedores precisam estar convencidos de que eles devem aderir aos padrões. Arquitetos devem rever a entrega dos novos serviços para a corporação, e nesse momento, a verificação da correta adoção das definições é uma importante atividade a ser cumprida.

Gerenciamento do Nível de Serviços

Se comparado a outras aplicações, SOA requer um gerenciamento diferente de outras arquiteturas de TI, devido a granularidade dos seus serviços. A flexibilidade em relação ao consumo dos serviços requer um bom entendimento de seu nível de granularidade por parte de seus consumidores. Gerenciamento de serviços é uma atividade do administrador do sistema, porém os arquitetos devem prestar atenção em sua granularidade a fim de argumentar com a equipe de negócio quando um determinado nível ainda é útil para os usuários do negócio. Geralmente, ao revisar a utilização dos serviços (possivelmente com uma ferramenta de registry), as possibilidades de reutilização podem aparecer.

Usando o ciclo de vida para aumentar a maturidade da governança SOA

O processo proposto para o ciclo de vida de governança SOA pode ser muito útil em combinação com um modelo de maturidade. Muitas publicações já foram feitas sobre modelos de maturidade (SOA); basicamente, qualquer um pode ser utilizado. Os níveis de maturidade precisam ter algum tipo de especificação sobre o que esperar da governança SOA em cada um desses níveis. Isso pode ser feito utilizando-se uma matriz, onde o escopo do processo do ciclo de vida é determinado por cada nível de maturidade. No exemplo abaixo nós usamos o modelo da Deloitte Business(I). Ele foi gerado a partir das melhores práticas e entrevistas em relação ao escopo da governança SOA. Ele demonstra que a maturidade deve estar equalizada de acordo com seu nível, a fim de atingir os benefícios de um processo maduro. Contudo, ele não foi desenvolvido com o pensamento em SOA, pois nós acreditamos que o escopo de negócio seja um bom indicador de requisitos para governança.

• Pioneiro - SOA consiste em pequenos projetos, a fim de oferecer flexibilidade para determinar as melhores práticas. Esses esforços são geralmente pequenas vitórias e trazem uma baixa complexidade organizacional. Governança SOA é mínima, e é direcionada a escopo de projetos. Como geralmente há apenas um responsável, o controle não é uma tarefa muito complicada.
• Processo - aqui é uma unidade organizacional, produto ou processo é totalmente direcionado para SOA. Muitas vezes SOA é implementado para um propósito específico, ex.: gerenciamento de inventário. Um responsável solicita e patrocina a maioria dos investimentos em SOA. Contudo, arquitetura está relacionada com TI, um outro departamento da organização, o que significa que a governança SOA precisa estar alinhada com outras equipes. Isso leva a um crescimento na demanda em governança, a medida que mais pessoas estão envolvidas.
• Sistema - Aqui, SOA é controlado por vários donos de negócio. Isso significa que é necessário um suporte no nível do CIO e a governança SOA precisa se tornar centralizada. Ela dita os padrões de implementações de SOA em todas as partes da organização.
• Relacionamento - SOA é coordenado por diferentes organizações ativamente envolvidas. Essas organizações disponibilizam serviços umas para as outras, que estão conectados para darem suporte ao processo de negócio estabelecido. Isso significa que a governança SOA entre essas partes precisa estar alinhada. Sem a devida governança, mudanças nos serviços terão um impacto grande e imprevisível nas operações de negócio.

Na tabela abaixo, algumas sugestões são dadas para as atividades nos estágios do ciclo de vida de governança SOA para cada nível de maturidade. Esses passos podem não ser necessários, mas possíveis, para evoluir ao longo do caminho. Essas sugestões podem ser usadas em matrizes similares com outras abordagens de modelos de maturidade. A vantagem em ter uma matriz é que ela forma uma visão abrangente e simples do caminho de evolução. Ela pode também prover para a organização uma espécie de “controle de saúde” de acordo com o nível de maturidade.

Tabela 1: Atividades dos processos de governança relacionados aos níveis de maturidade

Usando a maturidade para proporcionar uma evolução SOA

Além das mudanças no processo de ciclo de vida SOA, o aumento da maturidade também muda o impacto de SOA dentro da organização. No modelo abaixo é mostrado a transição entre os níveis de maturidade em governança. Ele mostra que no primeiro nível de maturidade nós não podemos falar em “um SOA” dentro da organização. Diferentes e pequenas soluções orientadas a serviços são feitas e governadas separadamente. A fim de se alcançar benefícios mais amplos na organização, a governança nesses SOAs pioneiros são agrupados. Esses agrupamentos podem ser feitos por processos de negócio, unidades de negócio ou até mesmo por regiões geográficas. Conforme SOA se torna uma solução mais abrangente para a organização, a governança é direcionada para um modelo centralizado. No modelo de maturidade final, o controle de governança é alinhado juntamente com parceiros de negócio. O comitê de governança de diferentes organizações devem se reunir para poder compartilhar frameworks e metodologias.

Provavelmente aconteça o desenvolvimento de diferentes projetos SOA na organização ao mesmo tempo. Um projeto pode estar em um nível mais maduro do que outro. Diferentes domínios SOA devem ser desenvolvidos e governados separadamente. Quando eles atingirem uma determinada maturidade, podem ser incorporados em um outro nível de controle. Baseado em processos, funções ou unidades organizacionais, o nível de maturidade pode variar. Por exemplo, o departamento de compras pode demonstrar maturidade no nível de relacionamento ao incorporarem serviços de fornecedores externos e determinarem padrões para o ciclo de vida do desenvolvimento de serviços. Ao mesmo tempo, o RH pode ainda estar usando suas próprias estruturas de governança de um nível de maturidade mais baixo. Isso não significa que seja algo ruim; ambientes isolados podem ter governanças separadas.

Por outro lado, a maturidade dentro de um domínio SOA precisa ser equalizada entre os processos de governança. Por exemplo, a governança do ciclo de vida de serviços deve estar consistente com as regras de iteração, por que iterações imaturas não terão sucesso em um ambiente complexo e mais maduro.

Isso então relaciona-se novamente com o ciclo de vida de governança SOA. No processo “A visão SOA”, a proposta e a maturidade final para a governança devem ser determinados. A organização pode então ter um comitê SOA no nível sistêmico e ainda assim ter outras definições em escalas menores feitas pelos arquitetos de domínio. Isso ajuda a manter a governança SOA eficiente e ajustada para o seu propósito. É mais provável que a governança sob medida seja mais efetiva quando comitês do nível sistêmico não tenham que discutir questões que são relevantes apenas a um domínio de controle.

Guias para arquitetos em um ambiente que busca maturidade em Governança SOA

Arquitetos são importantes iniciadores de esforços em SOA dentro de uma organização, e essa importância permanece pois eles normalmente possuem a melhor abstração e conseguem enxergar implicações práticas ao mesmo tempo que atuam com uma visão estratégica. Arquitetos também são importantes comunicadores entre TI e equipes de negócio. Por estarem nessa posição de poder, os arquitetos se encontram com a função de defender o paradigma SOA dentro da organização. Contudo não são todos os arquitetos que estão aptos a realizarem todas as atividades relacionadas com SOA.

Baseado no modelo de maturidade acima, nós daremos um guia prático para arquitetos a fim de ajudá-los a dar suporte para a organização e maximizar o potencial dos projetos SOA para o nível de maturidade corrente assim como avançar para o próximo nível. Como existem diversos tipos de arquitetos com diferentes tipos de responsabilidades, nós iremos primeiramente dar uma visão geral dos papéis relevantes dos arquitetos em um ambiente SOA. Para isso nós iremos nos apoiar no guia prático dos papéis dos arquitetos, introduzido por Mike Kavis

• O arquiteto chefe une os arquitetos SOA, e é responsável por responder aos CIOs. Obviamente, o arquiteto chefe está envolvido na decisão da visão SOA e também pode apontar a direção para a governança SOA.
• O arquiteto corporativo tem o papel de alinhar o negócio com as necessidades de TI para SOA. Esse tipo de arquiteto conversa com as pessoas de negócio para obter os requisitos. Os arquitetos corporativos estão diretamente envolvidos com o gerenciamento do portfólio de serviços.
• Arquitetos de solução tem experiência de implementação técnica. Eles podem ser os advogados de SOA, por que tem vivência em tecnologias orientadas a serviços.
• Os arquitetos de domínio possuem um conhecimento contextualizado dos domínios de negócio com os quais estão envolvidos. Esses arquitetos devem defender os princípios e relacioná-los com a situação do negócio. Arquitetos de domínio são bons candidatos para determinarem os padrões e para decidirem quando exceções a esses padrões podem ser feitas.

A tabela abaixo mostra algumas áreas possíveis de atuação para arquitetos em cada nível de maturidade. Nós adicionamos o comitê de arquitetura, que consiste em diferentes papéis de arquitetos e serve como um corpo responsável por tomar as decisões maiores sobre a arquitetura dentro da organização. Como nosso foco é governança, as responsabilidades dos arquitetos diferem de suas responsabilidades em tempo de design de projetos.

A tabela abaixo mostra uma visão superficial do foco desses papéis em relação ao nível de maturidade.

Conclusão

Nesse artigo nós discutimos o papel da governança SOA em relação aos seus níveis de maturidade. Isso foi feito com:

• Um framework do processo principal com o qual a governança SOA deve estar relacionada;
• Utilizando-se de um modelo de maturidade e ligando-o a todos os processos de governança SOA;
• Uma descrição de como nós imaginamos que os arquitetos devam estar envolvidos em um processo de governança SOA.

As responsabilidades dos arquitetos nessa atuação não são fixas. Nós mostramos um guia prático de como os arquitetos podem liderar ou dar suporte nos vários processos do ciclo de vida e nos níveis de maturidade. Arquitetos precisam direcionar diferentes problemas de governança em diferentes níveis de maturidade, entretanto, as demandas, os requisitos de qualidade e perfil dos arquitetos mudam de acordo com o nível de maturidade. De qualquer maneira, os guias práticos mostrados nesse artigo não são universais. As expectativas dos arquitetos irão mudar de acordo com cada situação.

Arquitetos são ótimos iniciadores de projetos SOA e eles podem ter a responsabilidade do primeiro nível de maturidade e sua governança dentro de uma organização. Contudo, para que as soluções SOA evoluam, o negócio precisa tomar o controle. Os arquitetos compartilham algumas responsabilidades do comitê de governança com o negócio e representantes de TI. Talvez a maior responsabilidade para o arquiteto seja o alinhamento com o negócio e TI e isso requer habilidades especiais em comunicação e coordenação. Quando o time de negócio e os arquitetos possuem um bom entendimento e interesses alinhados, guiados pela governança, soluções SOA podem dar um passo adiante e disponibilizar todos os benefícios ao negócio que foram prometidos para a organização.