A política de governança SOA com segurança

Políticas de melhores práticas podem ser integradas à governança SOA (Arquitetura Orientada a Serviços). Veja como chegar lá, sem prejudicar a produtividade do negócio.

Por Mário Peixoto

As políticas não são as ?boas novas? a serem levadas a uma organização. Elas são criadas durante toda uma rotina e realidade da empresa para estabelecer melhores práticas ou padrões, sejam de exigências ambientais, ou reguladoras de um comitê, para aumentar a eficiência e ajudar os processos de negócio que são de certa forma ?dinamizados?.

Este artigo procura explicar em como buscar a automatização destas políticas para governança SOA (Arquitetura Orientada a Serviços). E, igualmente, discutir como executar esta aplicação sem prejudicar a produtividade do negócio.

Governança faz parte do negócio

De modo a introduzir processos de negócio inovadores e ao mesmo tempo conseguir vantagens, atualmente os mercados competitivos exigem cada vez mais que as companhias entreguem aplicações empresariais de forma mais rápida e sobretudo a baixos custos.

A maioria das corporações possui silos heterogêneos de aplicações e plataformas, com um reuso baixo de suas funcionalidades e praticamente nenhuma integração. Frequentemente são incapazes de integrar eficazmente seus sistemas, aplicações e processos de negócio para confrontar este panorama a um novo concorrente.

Por exemplo, os custos da integração de aplicações da empresa já são elevados, pois exigem profissionais altamente capacitados, consumindo quantidades crescentes de tempo e desenvolvimento valioso, conduzindo frequentemente a um jogo único de conexões não reutilizáveis e proprietárias.

Acople tudo isto com a demanda de crescimento para fornecer mais visibilidade e transparência da informação através das unidades de negócios e os riscos a seus sócios com a complexidade de aumentar drasticamente os custos associados neste contexto.

A maioria das empresas se esforça para assegurar o sucesso das principais iniciativas de negócio. As políticas de governança devem ser reforçadas para evitar o engessamento dos processos e diminuir o retrabalho, o que impactaria as entregas finais.

Além, também, de facilitar a propagação de ?melhores práticas? que ajudem a divulgar o conhecimento e a reduzir mais os riscos que poderiam expor iniciativas à alguma falha.

Portanto, as organizações querem ter a flexibilidade de reforçar suas políticas ao permitir que seus específicos departamentos utilizem normas adicionais que endereçam suas necessidades sem uma burocracia autoritativa, mas com uma harmonia singular à toda matriz funcional da organização.

Mas por que governança SOA?

A necessidade de governança na empresa está voltada aos negócios.

Está em direção a iniciativas integradas deste negócio (como externalização, colaboração estratégica, valor e cadeia de aprovisionamento do fornecedor etc.) dentre outras iniciativas de organização técnica (como XML, web services, integração de aplicações da empresa, SOA etc.).

As companhias querem assegurar a continuidade das operações comerciais, controlando a exposição da segurança, alinhando a execução da tecnologia com as exigências do negócio, assim como responsabilidades e dependências, que consequentemente reduzirão o custo das operações.

O impacto de projetos sem governança SOA podem delinear descompassos significativos na integração às operações de uma companhia. Esta suposta falha na governança pode conduzir aos milhões de reais em ?redesigns? caros no serviço, em manutenção e em atrasos do projeto.

Mais prejudiciais ainda são as perdas potenciais de rendimento e as responsabilidades de negócio. Por exemplo, SOA representa uma camada nova de serviços que precisam ser criados e controlados com cuidado, para que forneçam a integração e a interoperabilidade entre sistemas que se deseja.

Entretanto, estas exigências cada vez mais críticas estão sendo desafiadas pela mesma natureza das tecnologias e dos paradigmas que constituem SOA, como XML, web services, e demais processos de negócio.

Questões a serem refletidas

Desafio para governança SOA. Sim, é fácil criar e utilizar os serviços de web services, que podem oferecer formulários cheios de significados de dados estruturados de XML, tais como a obtenção de informação, citações financeiras, as mensagens imediatas etc. Mas isso é apenas parte da solução.

O desafio consiste em certificar-se que estes serviços permitem uma acessibilidade de maneira correta, garantindo ainda uma segurança que ao mesmo tempo reforce as políticas apropriadas para os serviços sejam interoperáveis e reusáveis, funcionando de forma mais flexível e estando prontos a serem usados para criar novas soluções.

Padrões em desenvolvimento para a conformidade do negócio e padrões de TI para tecnologias web service. O número de padrões corporativos e de políticas incorporadas ao negócio e membros que precisam aprender, compreender e se envolver está aumentando constantemente. Frequentemente, o esforço para conformidade destes padrões pré-estabelecidos não combina com os objetivos a curto prazo dos projetos.

O PMO (Project Management Office) e os grupos de arquitetura podem publicar políticas internas de forma detalhada, como por exemplo, na intranet. Mas as equipes de projeto raramente possuem um momento disponível para este esforço, para que fosse compreendido e aderido a uma prática comum.

Ausência de aplicação aos padrões

Os processos de negócio e as tecnologias tais como o próprio SOA não são padrões comumente corporativos. Cada companhia tem suas próprias considerações e exigências originais de negócio para seus processos em SOA. Não existe ?receita de bolo? para fomentar um padrão de governança SOA que se aplique a todo tipo de organização.

Ferramentas inadequadas

Muitas das ferramentas comerciais disponíveis no mercado permitem hoje que as equipes possam desenvolver entregas ?não padronizadas?, de certa forma simplistas ao negócio, que envolvam XML e serviços web. Estas ferramentas são limitadas para execuções niveladas ou de diferentes camadas e não fornecem ao usuário recursos para criação de classes de desenvolvimento aderentes às ?melhores práticas? em XML e serviços web para SOA.

SOA

.

Em suma, possuir ferramentas adequadas e aprovadas pelo mercado, homologadas e devidamente suportadas por seus fabricantes é premissa básica para iniciar com sucesso os processos em direção às melhores práticas de governança SOA.

Novas camadas e novos desafios

Iniciativas complexas, como a arquitetura orientada a serviço, criam uma camada nova na empresa, que levanta desafios novos com reflexos para a segurança, a gerência, a confiabilidade, a gestão de mudança e muito mais.

Os procedimentos de gerência uniformes ao ciclo de vida da governança tornam-se muito mais complicados em um ambiente de SOA. Os serviços não são grandes pacotes de software, são os módulos de software que expõe e fornecem a funcionalidade como parte de uma visão maior. Há certas  dependências que estão frequentemente fora do escopo da equipe.

Questões como a gerência de mudanças, versionamento e a análise de impacto são impossíveis de controlar com determinados conjuntos de ferramentas que estão disponíveis hoje.

Embora SOA possa inicialmente ser endereçado por uma organização centralizada, SOA não é criado por um ?megaprojeto?. SOA é criado como o resultado de muitos projetos independentes que são todos envolvidos ao negócio e exigências técnicas.

Isto cria um dos principais desafios à SOA, no seguindo ponto: ?como você alinha esforços díspares em uma arquitetura contínua, de confiança, ágil e consegue dispor qualidade à empresa?. Governança vem justamente para buscar esta harmonia orquestrando um framework comum a todas essas camadas.

O desenvolvimento em SOA ? um exemplo

Mesmo a tarefa mais simples da arquitetura de sistemas pode destacar a complexidade substancial envolvida em ter-se um SOA. Considere um arquiteto independente, que esteja tentando desenvolver e expor um serviço de web service fora de uma aplicação específica do legado de CRM, a fim de integrá-la com o portal da companhia.

O arquiteto usará tipicamente um conjunto de ferramentas de desenvolvimento que seja projetado para ajudar que este profissional desenvolva rapidamente e simplesmente uma execução de serviço.

Este arquiteto gerará um desenvolvimento de XML  que nunca criou antes, como novos esquemas, as mensagens de WSDL, as publicações de UDDI, e outros produtos construídos relacionados ao web service. Para expor este serviço à empresa e criar estes produtos, o arquiteto terá que tomar em consideração muitos parâmetros adicionais tais como as exigências de negócio, os testes padrões do projeto, os metadados e a semântica usada para definir as edições de serviço, desde a interoperabilidade até a usabilidade.

Todos estes padrões são necessários a fim de integrar com toda a estrutura da empresa. Existem algumas exigências adicionais como versionamento, qualidade de acordos de serviço, do nível de serviço, e principalmente de segurança.

Um novo paradigma

Na grande maioria, se não em todas, quando deparados às camadas técnicas, as exigências ?arquitetônicas? de negócio, às pressões dos prazos finais de entrega e a falta de ferramentas de perícia/auditoria, os arquitetos e as equipes possivelmente postergarão o projeto.

Reverterão a executar somente as exigências de negócio do projeto, negligenciando todos os outros elementos que são tão críticos para a criação de serviços de qualidade da empresa.

Mediante os desafios a estas novas realidades, as companhias estão terminando com excesso de fragilidades apontadas ao XML e soluções de serviço baseadas em integrações web service. Estas soluções ?p

rovisórias? não suportam a resuabilidade ou a escalabilidade, além do espaço de seu projeto original.

Enquanto o negócio evolui e as exigências de novos negócios estão definidas, a inabilidade deste reuso de recursos existentes irá em desencontro aos benefícios de SOA, criando assim um efeito inverso, aumentando os custos e complexidade.

Com isso as companhias são hoje incapazes de controlar e governar os serviços que seus colaboradores, fabricantes, e vendedores de solução fornecem, gerando assim um descompasso no funcionamento em seu ambiente.

Uma não-governança em SOA conduz a novos silos.

Requerimentos básicos de governança

Prestar manutenção à arquitetura orientada a serviços exige um foco flexível na  maneira com que o software é desenvolvido e desdobrado dentro das empresas. As companhias terão que readequar-se ? tornando-se agora integradores visionários ? para este novo paradigma de integração. O paradigma, as tecnologias, e os novos padrões criados para suportar este deslocamento exigem que as companhias executem seu SOA de maneira planificada, bem coordenada, e eficazmente controlada a fundo.

Para assegurar a continuidade do negócio, reduza custos de integração e as complexidades, responsabilidades incorporadas, como a segurança, e para competir eficazmente no mercado, as companhias devem governar o projeto, o desenvolvimento, a distribuição, e as operações de todos estes novos serviços da empresa.

Administrar governança SOA é prover a habilidade de assegurar-se de que todos os esforços independentes (seja no projeto, no desenvolvimento, na distribuição, ou nas operações de um serviço) venham juntos, cumprir as exigências da empresa aderentes ao SOA.

Diversos elementos são exigidos para se conseguir a governança em SOA:

Políticas SOA na Empresa

As políticas ajustam os objetivos que você utiliza para gerenciar o sucesso de forma ponderada. Sem políticas, não há nenhuma administração. Os precursores de política gostam de gerentes, arquitetos, líderes de projeto, e os líderes de desenvolvimento de aplicações que estão esforçando-se para definir, configurar e atribuir políticas de uma maneira que lhe permita que as equipes de desenvolvimento aderem-se facilmente e de maneira transparente a estas políticas e às boas práticas.

Em conseqüência, cada equipe cria serviços de forma muito rápida e dinâmica. Isto sacrifica a interoperabilidade, a viabilidade, a segurança, e os outros benefícios de SOA. As políticas de governança SOA precisam apontar o impacto total aos serviços de negócio que estão sendo criados e refeitos. Tais políticas precisam criar uma conexão forte entre o negócio e a tecnologia.

As companhias precisam possuir a habilidade de associar suas políticas de negócio, às políticas técnicas e a execução real, de forma transparente. A tal ponto que haja políticas de governança em que todos os serviços estejam aderentes a uma perspectiva real da empresa.

Isto vale para todos os níveis da empresa, de políticas granuladas que uma equipe de projeto pode executar, até a perspectiva das unidades de negócios, departamentos, ou de diferentes equipes. As políticas são as exigências técnicas e do negócio que levam a criar uma linguagem comum da informação e do processo.

Aplicado em SOA, as políticas precisam endereçar a uma natureza muito bem distribuída, assíncrona, deste heterogêneo ambiente de SOA.

As políticas de governança SOA, podem iniciar em nível de negócio:

  • Os projetos devem ser cumpridos de acordo com as diretrizes da arquitetura interna;
  • A segurança e as políticas de auditoria regulamentatórias devem se revisadas, estando em conformidade para com todos os projetos de TI.

As políticas de governança SOA, podem representar algumas alterações reguladoras mais específicas de conformidade:

  • Informações identificavelmente sigilosas e pessoais de um paciente devem ser comunicadas e armazenadas rigorosamente. (De acordo com a HIPAA ? Legislação abrangente que governa a privacidade, segurança e transações eletrônicas das informações de saúde de clientes e pacientes);
  • Todas as transações financeiras devem fornecer a rastreabilidade e mecanismos inalteráveis necessários para os registros de verificação. (SOX ? Lei Sarbanes-Oxley que busca garantir a criação de mecanismos de auditoria e segurança confiáveis nas empresas).

A iniciativa de projetos de outsourcing pode representar algumas exigências tais como:

  • O projeto deve ter como política de interoperabilidade de passar por uma contagem aceitável de 80%, durante os testes de aceitação;
  • Todas as políticas de segurança do projeto devem ser programadas para uma revisão manual bem detalhada para detecção de falhas chave;

  • O outsourcing deve fornecer a lista de verificação assinada de aceitação ao gerente do projeto antes dos testes de aceitação.

Políticas mais avançadas e complexas deverão freqüentemente e rigorosamente ser revisadas perante, sobretudo seu nível técnico, podendo ser ainda reforçada por ferramentas de aplicação neste sentido. Exemplos de informações de segurança:

  • Informações que dependem de liberação por token;
  • Senhas que devem conter, por exemplo, no mínimo 6 caracteres com alguma letra em maiúscula, contendo números e letras alternadas;
  • A transposição de algumas mensagens deverá possuir uma identificação única e assinada digitalmente.

Existem algumas políticas-técnicas relativas ao projeto que são necessárias para assegurar a interoperabilidade e o reuso:

  • Não utilizar estilos codificados RPC em web service;
  • Não utilizar ?respostas-solicitação? para operações em web service;
  • Não utilizar convites XML ?anyAttritute?

Se qualquer um destes conjuntos de políticas não é seguido, o impacto sobre as operações da empresa e demais linhas funcionais podem ser grandes.

Conformidades e auditorias

As políticas de governança não devem ser deixadas somente no papel; devem ser uma parte ativa das operações da empresa. Após definições, as políticas devem ser postas a trabalhar no sentido de detectar, analisar e controlar em conformidade aos padrões pré-estabelecidos.

Este processo deve ser integrado com o design, desenvolvimento, implantação e operação dos serviços de maneira eficiente e transparente. Os desenvolvedores, arquitetos e demais integrantes da equipe do projeto devem estabelecer a necessidade da capacidade de estar em conformidade com as políticas de governança, através de um sistema automatizado que lhes permitirão facilmente encontrar e endereçar o que foi iniciado e terminado.

Administrando: o que foi feito, a revisão e as melhorias

Quando as políticas são definidas e conforme os processos estão em vigor, aqueles que decidem deverão reger a execução, incentivar a reutilização e gestão de processos de colaboração de negócios e melhorar as métricas. Estes são os verdadeiros valores de uma integração. Completando, estes processos devem responder as seguintes perguntas:

  • Políticas. Quais políticas temos? Quando que estas políticas são implementadas?
  • Serviços corporativos. Que serviços empresariais estão a ser desenvolvidos? Quais serviços estão sendo efetivamente reutilizados? Quem são os consumidores deste serviço?
  • Situação de conformidade. Como fazer com que os nossos serviços estejam em conformidade com as nossas políticas? Quais interfaces que não estão em conformidade? Qual é o impacto do abandono sobre as operações do serviço ou de nossas operações comerciais? Existem algumas falhas de segurança? Quais são os nossos níveis de serviço?
  • Análise de impacto. O que acontece às nossas operações de SOA se não mudarmos as nossas atuais políticas de SOAP? E se precisarmos acrescentar novos elementos à nossa mensagem de cabeçalhos SOAP?
  • Interdependências. Como as operações irão ser afetadas pelas mudanças feitas ao serviço? Quais os processos críticos serão afetados ou até mesmo poderão deixar de funcionar?
  • Gerenciando exceções. Podemos conceder uma exceção a uma política definida para um determinado projeto? Qual seria o impacto de uma exceção como esta?

Integração

Existem dois aspectos para a integração da governança SOA: Processo de Integração e Sistema de Integração.

Processo de Integração. A governança SOA deve integrar com o atual fluxo de serviço de desenvolvimento e com as ferramentas de sistemas disponíveis. Isso garante que os serviços de implementações estejam em conformidade com as políticas empresariais em toda a concepção, desenvolvimento, análise, implementação, implantação e manutenção.

Sistema de Integração. A Governança SOA deve integrar transparentemente com EAI (Enterprise Application Integration), desenvolvimento de ferramentas, e outros aplicativos empresariais que estão a produzir e consumir serviços.

Conclusões

Dizer que sua empresa passou por auditorias internas e externas, que contratou as melhores consultorias do mercado e gerou assim um calhamaço de papel que reflete na tão preciosa e aguardada Política, de nada vale se não aplicada e confrontada no decorrer da empreitada aos históricos anteriores à não adesão desta Política.

Se o hábito faz o monge, a prática governa novos horizontes. E trabalhar com integrações com segurança, relacionando toda esta tecnologia ao negócio é um desafio que deve ser encarado com alicerces muito bem fortificados ? seja com frameworks aderentes às necessidades, seja com capacitações de sua equipe para novas adaptações a um ambiente proveniente às melhores práticas de governança. [Webinsider]

Por Mário Peixoto

Sobre o autor
Mário Peixoto (leitoronline@gmail.com) é especialista em segurança da informação da CBTC, Uberlândia-MG.

zp8497586rq
error: Conteúdo Protegido !!
%d blogueiros gostam disto: