Software como Serviço (SaaS): uma perspectiva corporativa
Aplica-se a:
| • | Software como Serviço (SaaS) |
Resumo
O terceiro artigo de nossa série sobre Software como Serviço (SaaS) apresenta o tema pela perspectiva do consumidor corporativo.
Nesta página
Introdução
A abordagem do Software como Serviço (SaaS) tem o potencial de transformar a forma com que os departamentos de tecnologia da informação (TI) relacionam-se e, até mesmo, o que pensam sobre o seu papel como provedores de serviços para o restante da empresa. O surgimento do SaaS como um mecanismo de entrega de software cria uma oportunidade para que os departamentos de TI alterem o seu enfoque: de implantar e dar suporte aos aplicativos a gerenciar os serviços que esses aplicativos oferecem. Por sua vez, um departamento de TI centralizado em serviço, bem-sucedido, produz mais valor para o negócio, diretamente, ao fornecer serviços desenhados a partir de fontes internas e externas, e se alinhados com os objetivos corporativos.
Este é o terceiro artigo de nossa série sobre SaaS. Os primeiros dois, que podem se encontrados clicando aqui, concentraram-se nos detalhes do desenvolvimento dos aplicativos SaaS e em fornecê-los aos clientes. Nesta oportunidade, gostaríamos de trocar de posição e analisar o SaaS pela perspectiva do consumidor corporativo: Qual benefício teriam os departamentos de TI ao adicionar aplicativos SaaS aos seus portfólios de serviços? Quais são as implicações de se adicionar aplicativos hospedados externamente em um ambiente de informática corporativo? O que será preciso fazer para estar preparado para o SaaS? Este artigo abordará esses temas e examinará alguns casos especiais que talvez sirvam de exemplo para que o seu departamento torne-se um provedor e também um consumidor SaaS.
Conhecendo o SaaS
Apresentado de modo sucinto, o SaaS pode ser definido como "software implantado como serviço hospedado, acessado pela Internet".
O SaaS, como conceito, é quase sempre associado aos ASPs (Application Service Providers) da década de 90, que forneciam aplicativos "empacotados" aos usuários de negócios pela Internet. Havia, de certa forma, nessas tentativas iniciais de software entregue pela Internet, mais pontos em comum com os aplicativos tradicionais on-premise (instalados no local), como licenciamento e arquitetura, do que com os modernos aplicativos SaaS. Considerando que foram originalmente construídos para serem aplicativos de um único inquilino, sua capacidade de compartilhar dados e processos com outros aplicativos era limitada e a tendência desses produtos era a de oferecer poucos benefícios econômicos em relação aos seus similares instalados no local.
Atualmente, espera-se que os aplicativos SaaS aproveitem os benefícios da centralização através de uma arquitetura de instância única, para vários inquilinos, e para oferecer uma experiência rica em recursos, que compete com os aplicativos on-premise de mesmo tipo. Aplicativos SaaS típicos são oferecidos diretamente, pelo fornecedor, ou por intermediários denominados agregadores, que reúnem ofertas SaaS de vários fornecedores, oferecendo-as como parte de uma plataforma de aplicativos unificada.
Diferentemente do modelo de licenciamento único, normalmente usado para software instalado no local, o acesso ao aplicativo SaaS é quase sempre vendido de acordo com um modelo de assinatura: os clientes pagam uma taxa contínua para uso do aplicativo. Os planos de cobrança variam de acordo com o aplicativo; alguns provedores cobram taxa fixa para acesso ilimitado a alguns recursos do aplicativo, ou para todos; outros cobram taxas variáveis baseadas no uso.
No aspecto técnico, o provedor SaaS hospeda o aplicativo, os dados e implanta patches e atualizações do aplicativo de modo centralizado e transparente, possibilitando o acesso aos usuários finais pela Internet, via navegador ou aplicativo smart-client. Muitos fornecedores oferecem interfaces de programação de aplicativo (APIs) que expõem os dados e a funcionalidade dos aplicativos aos desenvolvedores para uso na criação de aplicativos compostos. Vários mecanismos de segurança podem ser usados para manter a segurança de dados sigilosos, na transmissão e no armazenamento. Os provedores de aplicativos podem fornecer ferramentas que permitem aos clientes modificar o esquema de dados, o fluxo de trabalho e outros aspectos operacionais do aplicativo, de acordo com o seu uso.
Benefícios do SaaS como produto de consumo
Lógico, só porque você pode adicionar o SaaS em sua infra-estrutura de TI, este não é um motivo, em si, para fazê-lo; deve haver, também, um motivo comercial viável. O SaaS oferece oportunidades substanciais para que empresas, de todos os portes, deixem de enfrentar os riscos da aquisição de software e transfiram o departamento de TI de um centro de custo reativo para outro, proativo, como uma parte da empresa que produz valor.
Gerenciando os riscos da aquisição de software
Tradicionalmente, tem sido uma grande responsabilidade a implantação de sistemas de software de larga escala, críticos para o negócio, como os pacotes de aplicativos de ERP e CRM. A implantação desses sistemas em uma empresa de grande porte pode custar centenas de milhares de dólares, pagos no primeiro momento, no custo do licenciamento e, em geral, exige um exército de profissionais e consultores de TI para a personalização e a integração com os outros sistemas e dados da organização. As exigências de tempo, equipe e orçamento de uma implantação dessa magnitude representam um risco significativo para empresas de qualquer porte e, freqüentemente, fazem com que esse software fique fora do alcance de empresas menores que poderiam, se assim não fosse, obter dele grande proveito em todos os sentidos.
O modelo de entrega por demanda modifica alguns desses itens. Os aplicativos de SaaS não exigem a implantação de grande infra-estrutura no local do cliente e isso elimina ou reduz, drasticamente, o compromisso de recursos adiantados. Sem investimento inicial significativo para amortizar, a empresa que implanta um aplicativo SaaS, que resulte em produção de resultados desalentadores, poderá desistir e caminhar em outra direção, sem ter de abandonar a cara infra-estrutura de suas instalações.
Além disso, se a integração personalizada não for necessária, os aplicativos SaaS podem ser planejados e executados com um mínimo de empenho e de atividades de distribuição, criando um dos menores intervalos TTV (time-to-value) possíveis para um investimento importante de TI. Isso também possibilitou a vários fornecedores SaaS oferecer "test drives" sem risco (e, quase sempre, literalmente grátis) de seus produtos, por um período limitado, como 30 dias. Esse procedimento possibilita aos clientes uma oportunidade de testar o software antes de comprá-lo e ajuda a eliminar a maior parte do risco que cerca a compra de um novo produto.
Para obter mais informações sobre os benefícios do SaaS para o negócio, consulte Architecture Strategies for Catching the Long Tail na MDSN Library.
Gerenciando o enfoque de TI
Com o SaaS, o trabalho de implantar um aplicativo e mantê-lo em funcionamento, dia após dia - testando e instalando patches, gerenciando atualizações, monitorando o desempenho, assegurando alta disponibilidade, etc. - ficarão sob a responsabilidade do provedor. Ao transferir a responsabilidade dessas atividades de "sobrecarga" a terceiros, o departamento de TI poderá se concentrar melhor em atividades de valor mais elevado que se alinham e dão suporte às metas comerciais da empresa. Em lugar de ser principalmente reativo e com enfoque operacional, o CIO (Chief Information Officer) e a equipe de TI poderão trabalhar com maior eficiência como estrategistas de tecnologia para o restante da empresa, trabalhando com unidades do negócio para entender suas necessidades e fazer recomendações sobre como melhor usar a tecnologia para alcançar seus objetivos. Longe de entrar em obsolescência pelo SaaS, o departamento de TI terá uma oportunidade de contribuir para o sucesso da empresa, mais diretamente do que nunca.
O Contínuo do SaaS
Na forma "pura" do SaaS, o provedor hospeda um aplicativo de modo centralizado e disponibiliza o acesso a vários clientes, pela Internet, em troca de uma taxa. Na prática, entretanto, as características marcantes entre um aplicativo instalado no local do cliente e um aplicativo SaaS não são binárias, mas gradativas ao longo de três dimensões diferentes: como é licenciado, onde está localizado e como é gerenciado. Cada uma dessas características pode ser visualizada como uma seqüência que tem, de um lado, o software convencional, instalado no local, e, na outra extremidade, o SaaS puro. Entre essas duas extremidades existem opções adicionais que combinam aspectos de ambos.
/Fig1.jpg)
Figura 1. Os aplicativos SaaS são identificados por seus locais conceituais em três seqüências diferentes.
Licenciamento: Em geral, os aplicativos instalados no local são licenciados para sempre, com pagamento único relativo a cada usuário ou local, ou (no caso de aplicativos construídos sob encomenda) de propriedade integral. Os aplicativos SaaS são licenciados, quase sempre, de acordo com um modelo de transação baseado no uso: cobra-se do cliente apenas as transações de serviço usadas. Existe também o modelo familiar da assinatura cuja base é o tempo: o cliente paga uma taxa fixa, por estação, por um determinado período, por exemplo, mensal ou trimestral, durante o qual terá direito ao uso ilimitado do serviço.
Local: Os aplicativos SaaS são instalados no local do hoster do SaaS, enquanto os aplicativos on-premise, naturalmente, são instalados no seu próprio ambiente de TI. Entre esses dois pontos existe o modelo 'aparelho': o fornecedor vende um componente de hardware/software como uma "caixa preta", instalada no local do cliente e não do vendedor. Um exemplo de aparelho, nesse sentido, seria um dispositivo que contivesse um aplicativo de logística, com um banco de dados em cache, atualizado periodicamente. Uma empresa de transporte poderia fornecer esse dispositivo aos seus consumidores de grande porte para que pudessem fazer consultas sobre informações de transporte, em lugar de acessar os servidores da empresa com milhares de consultas individuais, por dia.
Gerenciamento: Tradicionalmente, o departamento de TI é responsável por prestar serviços de TI aos usuários, ou seja, deve estar familiarizado com redes, servidores e plataformas de aplicativos, dar suporte e fazer diagnóstico de falhas e, ainda, resolver problemas de TI relativos à segurança, confiabilidade, ao desempenho e à disponibilidade. Isso representa um grande volume de trabalho e, alguns departamentos de TI subcontratam algumas dessas responsabilidades de gerenciamento a terceiros, prestadores de serviços especializados em gerenciamento de TI. Na outra ponta do espectro, os aplicativos SaaS são completamente gerenciados pelo fornecedor ou pelo hoster do SaaS; na verdade, a implementação das tarefas e responsabilidades de gerenciamento não fica transparente para o consumidor. Os contratos de nível da prestação do serviço (SLAs) regem os compromissos de qualidade, disponibilidade e suporte a serem fornecidos pelo provedor ao assinante.
Considerações para adotar o SaaS
Para qualquer aplicativo ou função determinada, pode-se determinar o seu estado de prontidão para SaaS, plotando as necessidades e as expectativas da sua empresa em cada seqüência, usando a Figura 2 como um guia.
/Fig2.jpg)
Figura 2. Cada seqüência pode ser subdividida em três segmentos, representando as abordagens tradicional, SaaS e híbrida.
Se marcar as três caixas da coluna da extrema direita, você estará pronto para tentar mudar para SaaS. Se, ao contrário, tiver marcado as três caixas da extrema esquerda, provavelmente terá de permanecer com a solução tradicional desse aplicativo, instalado no local. Qualquer outra combinação sugere que uma abordagem híbrida seria adequada; analise o mercado para ver se é possível identificar quaisquer soluções que sejam corretas para você.
Encontrar a posição exata em cada seqüência envolve analisar várias considerações, as quais se resumem, ao final, no equilíbrio entre controle e custo. Algumas dessas considerações incluem:
Considerações políticas. Às vezes, a decisão pode 'entrar em curto' devido a uma resistência interna da empresa como, por exemplo, pessoas importantes que insistem em que determinadas funcionalidades continuem internas, sob o controle do departamento de TI; as outras considerações, assim, tornam-se insignificantes. Implantações de test-drive (consulte a subseção anterior sob o título "Gerenciando os riscos da aquisição de software"), algumas vezes, ajudam a convencer gerentes avessos ao risco a aprovar projetos-piloto.
Considerações técnicas.Os aplicativos SaaS, em geral, proporcionam alguma flexibilidade com relação à configuração do cliente, mas esta abordagem tem suas limitações. Se um aplicativo importante exigir conhecimento técnico especializado para sua operação e suporte, ou se exigir personalização que um fornecedor SaaS não possa oferecer, talvez não seja possível encontrar uma solução SaaS para esse aplicativo.
Outro fator a ser considerado é o tipo e o volume de dados a serem transmitidos de/para o aplicativo, regularmente. A largura de banda da Internet fica muito aquém dos links Ethernet de gigabits, normalmente encontrados nas LANs corporativas e as transmissões de dados que levam poucos minutos na transferência entre servidores, podem levar horas para transmitir de/para um aplicativo SaaS localizado em local remoto, na sua central de dados. Por isso, talvez seja mais sensato analisar uma solução que considere a latência da rede. Uma solução baseada em appliances (softwares e hardwares empacotados para uso no cliente), por exemplo, poderia implementar cache ou batch.
Considerações financeiras. Considere o custo total de propriedade (TCO) de um aplicativo SaaS, comparado com aquele de um aplicativo equivalente, instalado no local. Embora o custo inicial de aquisição dos recursos de software por SaaS seja normalmente inferior àquele dos aplicativos instalados no local, a estrutura de custo a longo prazo é mais incerta. Fatores que podem afetar o TCO de um aplicativo SaaS incluem o número de usuários licenciados, o volume de configurações personalizadas a ser executado para integrar o aplicativo SaaS em sua infra-estrutura e, por fim, se suas centrais de dados existentes já produzem economia de escala reduzindo, assim, a economia de custo em potencial do SaaS.
Além disso, você poderá decidir retardar a implementação de um substituto SaaS daquele aplicativo caro ou recém-instalado, até que este produza um retorno sobre o investimento (ROI) satisfatório.
Considerações jurídicas. Em várias partes do mundo, alguns setores estão sujeitos a legislação regulatória que impõe exigências quanto à emissão de relatórios e guarda de registros que a solução SaaS a ser escolhida talvez não possa cumprir. Considere os ambientes regulatórios das várias jurisdições nas quais opera a sua empresa e como afetam as necessidades do seu aplicativo.
Algumas vezes, as considerações técnicas e financeiras também têm ramificações legais, por exemplo, se os possíveis provedores de SaaS terão condições de atender os padrões internos de segurança e privacidade dos dados para evitar exposição legal. Considere, ainda, quaisquer obrigações legais que sua empresa tenha em relação a clientes ou a terceiros e se o SaaS não resultará em solução de continuidade.
Departamento de TI centralizado em serviço
Discutimos os benefícios do SaaS em termos técnicos e de negócios, razoavelmente específicos. Em última análise, todavia, o maior impacto talvez seja o fato de o SaaS fornecer os incentivos corretos para guiar o departamento de TI na direção de um modelo centralizado na prestação de serviços.
Se examinarmos o papel evolutivo que o departamento de TI tem desempenhado em uma empresa nas últimas décadas, observaremos que a tecnologia fez com que evoluísse de suas obrigações passadas, que incluíam executar tarefas banais de guarda de registros e cálculos, para as funções atuais que incluem a simplificação dos fluxos de trabalho e das comunicações, que fazem a diferença do negócio.
/Fig3.jpg)
Figura 3. Modelo de maturidade do departamento de TI centralizado em serviço
A Figura 3 apresenta um modelo de maturidade que descreve o modo como os negócios adquirem e beneficiam-se dos recursos tecnológicos.
Logo no começo, quando o negócio considera inicialmente incorporar a tecnologia, é comum associar a solução de suas necessidades a um aplicativo específico que ofereça função mínima. Por exemplo, se um usuário precisar interagir com um parceiro no projeto de um componente de hardware, ambos estarão satisfeitos com um aplicativo de e-mail simples, como ferramenta principal de colaboração e comunicação.
Na medida em que a empresa compreende que as necessidades específicas do negócio são melhor atendidas por, quem sabe, uma classe de aplicativos correlatos e não por apenas um aplicativo, ela evolui para adotar uma visão mais centralizada em serviço para o seu portfólio de aplicativos. Voltando ao exemplo de interação entre parceiros, a empresa poderá perceber que o esforço de colaboração pode ser aprimorado por meio de um portal na Web que incorpore o compartilhamento de documentos com suporte de versão, discussões segmentadas, quadro branco em tempo real e suporte para apresentação de slides. Assim, a empresa poderá decidir comprar e implantar uma solução de portal para expandir os recursos para prestação de serviços de TI colaborativos que, no momento, tem apenas a facilidade de e-mail.
Com um número cada vez maior de plataformas e aplicativos de linha de negócios (LOB) sendo disponibilizado pelo modelo de entrega SaaS, as empresas não apenas têm um maior número de opções de compra, mas também mais escolhas sobre onde e como os aplicativos podem ser entregues. Como mencionado anteriormente, o SaaS influencia a alocação dos recursos das empresas por meio de muitos modelos de licenciamento, operação e gerenciamento. A empresa inteligente também será capaz de negociar controle direto (em relação aos detalhes da implementação de serviço) para maior flexibilidade e para otimizar a estratégia e a execução de sua principal missão. Entretanto, a extensão em que a empresa pode explorar o SaaS é diretamente proporcional à sua capacidade de transferir e minimizar riscos e ter um bom domínio do contrato de nível da prestação do serviço é parte primordial do jogo que gerencia o risco. Portanto, expandir os limites de um portfólio de prestação de serviços de TI, além do próprio firewall, significa outro nível de negócio e de sofisticação técnica do departamento de TI centralizado em serviço.
Além da atenuação do risco, a empresa que decidir adotar o SaaS como parte de seu departamento de TI centralizado em serviço precisará aprender a maximizar os ganhos do negócio usando recursos e dados expostos por meio do portfólio de serviços no local da instalação e na nuvem. Garantir que os dados do negócio processados pelos diversos sistemas estejam limpos, consistentes e seguros é, em geral, a etapa fundamental na construção do departamento de TI que torna o negócio possível. A tecnologia de integração ajuda a concretizar esta pedra fundamental por meio da transformação de dados e da orquestração do processo. Isto é uma analogia à rotina do mise en place, freqüentemente praticada nos restaurantes: os ingredientes da receita como alho, ervas, etc., são picados, moídos e triturados adequadamente no preparo do "repertório" culinário final, a ser realizado pelos principais chefs. Da mesma forma, uma arquitetura de integração eficiente ajuda a consolidar e organizar os ativos de informação da empresa para consumo do usuário “rio acima”, através de aplicativos compostos. Estes fornecem o tecido computacional, de acordo com o qual as funções e as informações do negócio podem ser efetivamente criadas (ou agregadas) para os usuários finais. Ao interagir com um aplicativo composto, o usuário final não conhece (e não tem necessidade de conhecer) a verdadeira fonte das informações; ao contrário, está concentrado em sintetizar e analisar as informações do negócio com um mínimo de chaves de contexto relativas à tecnologia.
Resumindo:
No nível 1 (canto esquerdo superior), o usuário corporativo precisa ser rudimentarmente encaminhado por uma coleção de aplicativos armazenados em silo.
No nível 2 (canto direito superior), o usuário corporativo precisa ser melhor informado por meio de um portfólio de serviços, cada qual compreendendo aplicativos correlatos que oferecem um conjunto mais completo de funcionalidades.
O nível 3 (canto esquerdo inferior) refere-se à otimização do portfólio de serviços. O portfólio de serviços fica ampliado com opções adicionais vindas dos provedores de SaaS, permitindo à empresa otimizar ainda mais sua estratégia e as decisões de alocação de custos de TI.
No nível 4 (canto direito inferior), os serviços na nuvem e os instalados no local são integrados de modo transparente, oferecendo uma plataforma para aplicativos compostos perfeitamente alinhada com as tarefas do negócio.
As duas últimas seções deste artigo fornecem mais detalhes sobre como a arquitetura de integração e de composição desempenham papéis cruciais na assimilação do SaaS na estratégia computacional da empresa. Antes disso, entretanto, na próxima seção, analisaremos o impacto do SaaS sobre o controle e as funções de TI na empresa centralizada em serviços.
Como o SaaS afeta o departamento de TI
Depois de ter decidido optar pelo SaaS, preparar-se para a transição será a próxima etapa, avaliando como a implantação afetará os ativos de TI existentes e agindo para garantir que a transição possa ser administrada sem contratempos.
Implicações do controle de TI
Executar uma inspeção faz parte da rotina de qualquer projeto de implantação de infra-estrutura de TI bem-sucedido, assim, o básico já deve ser de seu conhecimento. Todavia, alguns fatores merecem consideração especial. Algumas áreas que devem ser abordadas na sua lista de inspeção são:
Padrões de segurança dos dados. Transferir os dados críticos do negócio "extramuros" introduz o risco da perda de dados ou da exposição inadvertida de informações sigilosas. Avalie as necessidades de segurança dos dados e confirme se o provedor adota medidas no local para atender os padrões que você definir.
Garantias do SLA. O contrato de gerenciamento a ser firmado entre você e o provedor SaaS assume o formato dos contratos de nível da prestação do serviço (SLAs) que garantem o nível de desempenho, disponibilidade e segurança que o provedor SaaS fornecerá e que regerá as ações do provedor - ou a indenização - caso deixe de cumprir essas garantias. Verifique se esses SLAs estão em vigor, se as garantias que prometem são suficientes para atender suas necessidades e se oferecem nível suficiente de atenuação, mesmo no pior cenário.
Estratégias de migração. Em um determinado momento, você desejará migrar de um aplicativo SaaS para outra solução e, por isso, é importante estar em condições de tirar os dados existentes do aplicativo e transferi-los para outro. Pergunte ao futuro provedor SaaS quais estratégias e procedimentos para migração de dados ele usa, inclusive se há provisões relativas à garantia para dados e códigos. (Sob o título "Arquitetura de integração", mais adiante neste artigo, consulte as recomendações adicionais sobre o preparo dos dados para migração.)
Exigências para integração interna. Confirme se a migração para o SaaS atenderá todas as exigências funcionais e de integração de dados adotadas pela empresa. Mais adiante neste artigo, discutiremos cenários de integração com muitos detalhes.
Serviços de relatórios. Considerando que o SaaS envolve abandonar o controle direto de alguns de seus dados, a emissão de relatórios exatos e úteis é especialmente importante. Saiba quais são os serviços de relatório oferecidos pelo provedor e se são compatíveis com as exigências do seu business-intelligence.
Impacto sobre as funções e as responsabilidades de TI
Conforme mencionado anteriormente, adicionar o SaaS ao mix de TI da empresa poderá provocar uma mudança fundamental no papel do departamento de TI como prestador de serviços de informações. Algumas vezes, dizemos que as unidades do negócio têm medo de mudar, mas os departamentos de TI tampouco são imunes às políticas organizacionais, e a resistência institucional ao SaaS tem origem no próprio departamento de TI, tanto quanto de qualquer outra parte da empresa. No passado, a natureza da implantação dos programas colocou os CIOs e suas equipes no papel de supervisores, os quais podiam exercer um veto sobre qualquer implantação de software proposta afirmando, simplesmente, que não teriam condições receber o programa na central de dados. Com a opção do SaaS, o controle da central de dados não precisa ser, necessariamente, equiparado ao controle de todo o ambiente computacional da empresa e isso pode despertar nos supervisores o medo da perda de controle: um vice-presidente "discidente" poderia tornar-se assinante de um aplicativo SaaS para o seu departamento, ignorando o departamento de TI, completamente.
Por certo, um CIO que deposite no controle da central de dados o controle da maior parte do ambiente computacional da empresa terá problemas de governança, de qualquer forma. Os CIOs bem-sucedidos integram-se às unidades de negócio para instruí-las sobre o impacto de determinadas compras em sua agilidade futura e trabalham em conjunto para determinar se as necessidades delas serão melhor atendidas por um software instalado no local ou por SaaS. Ao executar essa função de consultor, como acima mencionado, o departamento de TI poderá adicionar valor ao negócio, diretamente, fazendo a correspondência entre as unidades de negócio e a tecnologia, de forma ideal.
Impacto sobre o cumprimento dos regulamentos
A Demonstração de Modelos de Auditoria No. 70 (SAS 70) é uma norma de auditoria internacional que permite às empresas prestadoras de serviços a outras organizações fornecer um relato independente e confiável de suas práticas de controle interno. As auditorias SAS 70 são executadas por auditores independentes e resultam no relatório SAS 70 entregue pelo prestador de serviços aos seus clientes, para uso nos próprios processos de auditoria. SAS 70 não é uma lei, mas os modelos de auditoria e de divulgação nas várias jurisdições, em todo o mundo, (como a Sarbanes-Oxley nos Estados Unidos) fazem com que relatórios SAS 70 atualizados sejam uma exigência de facto para qualquer empresa que preste serviços para terceiros e, assim, todos os provedores SaaS devem considerar ter um prontamente disponível para exame.
SAS 70 também não é um carimbo de aprovação, ou seja, não define um conjunto mínimo de normas que a organização deve cumprir. Um relatório SAS 70 apenas documenta as práticas de controle interno da organização, sem oferecer nenhuma avaliação quanto a serem satisfatórias. A revisão limitada, portanto, exige que você não apenas solicite um relatório SAS 70 do futuro provedor SaaS, mas também que faça uma analise detalhada para verificar se o provedor tem condições de cumprir suas próprias normas internas relativas às questões de privacidade, segurança de dados, etc. Por exemplo, se uma lei de privacidade local exigir que os dados pessoais financeiros dos seus clientes sejam sempre armazenados criptografados, o relatório SAS 70 do provedor divulgará se as práticas de armazenamento de dados desse provedor permitirão que você continue cumprindo a lei.
Para obter mais informações sobre a SAS 70, visite o Web site do American Institute of Certified Public Accountants.
Arquitetura de integração
Tornar-se assinante de um aplicativo SaaS significa guardar os dados do negócio fora da rede local controlada, na "nuvem" da Internet. A arquitetura de integração especifica como trazer esses dados externos para a sua infra-estrutura lógica, de modo que possa haver interoperação dos componentes da infra-estrutura (quer sejam hospedados interna ou externamente) e que cada componente tenha acesso aos dados que precisa, independentemente do local de origem dos dados.
Na maioria dos casos, a implementação do aplicativo SaaS envolve transferir dados de um ou mais aplicativos ou do repositório de dados existente para o novo sistema. Os cenários comuns podem incluir:
| • | "Inicialização" do aplicativo SaaS com dados preexistentes de fonte instalada no local. |
| • | Configurar um aplicativo SaaS para depender de dados produzidos por fonte instalada no local para parte de sua funcionalidade (por exemplo, um aplicativo CRM que consulta dados de estoque gerenciados por um aplicativo de estoque instalado no local). |
Todavia, em muitos casos, integrar um aplicativo SaaS no seu ambiente significará criar dependências de dados que exigem sincronização e transferência de dados entre o aplicativo SaaS e um ou mais aplicativos internos, para facilitar o processamento. Usa-se um broker de integração para gerenciar o movimento dos dados e a integração do sistema.
Broker de integração
Muitas empresas já usam algum tipo de broker de integração para expor funções de aplicativos, orquestrar processos do negócio e para a integração com sistemas back-end internos. Em muitos casos, o mesmo broker de integração pode ser personalizado e configurado para executar funções de integração e roteamento para muitas fontes de dados, internas e externas, incluindo os aplicativos SaaS.
/Fig4.jpg)
Figura 4. Um broker de integração reúne fontes de dados, internas e externas, em um todo unificado.
Os dados podem ter origem em diferentes fontes, por meio de diferentes protocolos e em vários formatos, mutuamente incompatíveis. O trabalho do broker de integração se resume em reunir os dados das diferentes fontes, determinar como e onde os dados precisam ser processados e roteados, enviando cada item de dados ao seu destino no formato que o sistema de destino possa usar. O broker assume a forma de uma arquitetura de pipeline à qual é possível adicionar e remover módulos que executam operações de integração específicas. Vários pipelines lógicos podem ser usados para processar os dados que viajam nas várias direções. Em um exemplo típico, um pipeline poderia integrar os dados de fontes da Internet com fontes locais de dados e outro pipeline poderia reunir os dados locais e integrá-los com os dados SaaS na Internet.
Os dados entram e saem do pipeline por meio de canais de dados que definem os protocolos usados para a comunicação com as fontes de dados. Por exemplo, um canal poderia ser estabelecido para transmitir dados de um determinado serviço Web para o broker que estivesse usando SOAP; outro, transmitiria os dados do broker para um aplicativo SaaS que estivesse usando FTP. (Consulte o texto sob o título "Padrões para transferência de dados", adiante neste artigo, para obter mais informações sobre a transferência de dados).
Os módulos conectados no pipeline determinam como os dados são processados, roteados e integrados aos dados no destino. Um serviço de metadados oferece as regras configuráveis que cada módulo usa para executar o seu trabalho. As operações comuns de integração incluem os seguintes itens:
SegurançaEm geral, os dados de entrada são processados por um módulo de segurança que executa operações como a autenticação da fonte de dados ou da assinatura digital, descriptografando os dados e examinando-os quanto a riscos de segurança, como os vírus. As operações de segurança podem ser coordenadas com políticas de segurança existentes para controle de acesso.
ValidaçãoO módulo de validação pode comparar os dados com esquemas relevantes e rejeitar dados discrepantes ou entregá-los a um componente de transformação para serem convertidos ao formato correto. (Consulte o texto sob o título "Padrões para transformação de dados", adiante neste artigo, para obter mais informações sobre a transformação de dados.)
Fluxo de trabalho de sincronizaçãoUm componente de sincronização usa fluxo de trabalho e regras para determinar como as mudanças de dados são propagadas aos seus destinos e em que ordem. Nos casos em que uma dessas seqüências do fluxo de trabalho não possa ser concluída de modo bem-sucedido, o componente de sincronização pode usar lógica transacional ou de compensação para "desfazer" a transferência de dados de forma suave, garantindo a sua consistência nos vários sistemas.
RoteamentoPor fim, as regras de roteamento definem o destino de cada segmento de dados. O roteamento pode envolver, simplesmente, a transmissão de todos os dados de uma fonte específica para um destino designado ou, ainda, uma lógica mais complexa, como a determinação de um destino, a partir das informações do conteúdo, como o número de ID do cliente.
Um serviço que disponibiliza dados fornece os meios pelos quais o broker de integração pode detectar quando novos dados estão disponíveis. Consulte a próxima seção, "Padrões para disponibilização de dados", para obter mais informações sobre os métodos que podem ser usados para determinar a disponibilidade dos dados.
Padrões para disponibilização de dados
A sincronização de dados envolve transferir dados novos e alterados da fonte de dados para o destino (coletor de dados), em intervalos regulares ou quando precipitados por um evento. Três padrões básicos são usados para acionar a sincronização de dados entre uma fonte local e um aplicativo SaaS:
Pesquisa (Polling)–Com polling, uma fonte consulta a outra para saber se há alterações; em geral, isso é feito em intervalos regulares.
Envio (Push)–É o oposto da pesquisa. Em um relacionamento push, a fonte com dados alterados comunica as alterações para o coletor de dados. A fonte de dados pode iniciar um envio sempre que houver alteração na fonte de dados ou em intervalos regulares.
Publicar e assinar–A publicação e assinatura é uma abordagem híbrida, baseada em evento, que combina os aspectos de polling e pushing. Quando há alterações na fonte de dados, ocorre a publicação de um evento de notificação de alteração, que pode ser assinada pelo coletor de dados.
De acordo com os dados, aplicam-se diferentes abordagens e você pode decidir adotar abordagens combinadas para um único aplicativo. A abordagem correta a ser usada para detectar alterações de dados pode depender de vários fatores, inclusive se as alterações de dados devem estar refletidas em tempo real ou quase, e como muitos coletores de dados devem ser integrados à atualização dos dados. Em alguns casos, você deverá procurar um acordo que equilibre interesses opostos. Para dados que devem estar sempre atualizados, por exemplo, uma abordagem push é, em geral, melhor; todavia, enviar os dados para um grande número de fontes interessadas pode utilizar muitos recursos de rede e de computação, e isso talvez possa degradar o desempenho do aplicativo. Independentemente da abordagem escolhida, é preciso desenvolver regras para controlar detalhes da implementação como a freqüência de polling, o formato da distribuição , etc.
Padrões para transferência de dados
Os dados podem ser transferidos entre duas extremidades usando técnicas de comunicação síncronas e assíncronas. Uma transferência síncrona tem as mesmas características de uma interface: quando uma das partes exige informações, ela se conecta à outra para solicitá-las, esperando receber o resultado, imediatamente. Esta conexão pode ocorrer de várias formas. As transferências síncronas podem ser simples como transferências de arquivo ou também podem ocorrer via FTP, HTTP ou por qualquer outro método.
Em uma transferência assíncrona, as informações podem ser transmitidas pelo remetente e processadas pelo destinatário em momentos diferentes. As transferências assíncronas são, em geral, baseadas em mensagens: uma das partes envia a mensagem para a outra, solicitando informações, sem esperar uma resposta imediata. Depois de ter processado a solicitação, a segunda parte envia uma resposta à primeira, em outra mensagem. As mensagens podem ser enviadas por protocolos de e-mail como SMTP, por exemplo, ou de acordo com tecnologias de enfileiramento de mensagens.
Padrões para transformação de dados
Transformar os dados significa recebê-los de uma fonte e alterar o formato e/ou o conteúdo para que possa ser usado pelo coletor de dados. Trocar dados com um aplicativo SaaS pode envolver alguns graus de transformação de dados. Por exemplo, um de seus sistemas existentes, instalados no local, troca dados de acordo com o padrão EDIFACT, enquanto o aplicativo SaaS a ser integrado usa um formato incompatível, baseado em XML, para enviar/receber dados. Os dados que provêm de um sistema instalado no local devem ser transformados antes de poderem ser enviados ao aplicativo SaaS e vice-versa.
A transformação de dados é um processo que envolve várias etapas. Primeiramente, os dados de entrada devem ser validados em relação aos formatos e esquemas de dados adequados, para confirmar se serão utilizáveis após a transformação. Opcionalmente, os dados podem ser aprimorados, combinando-os com dados de outra fonte. Por fim, os dados em si serão convertidos de acordo com o formato de destino.
Para mais informações sobre padrões de integração de dados, consulte Integração de dados e Topologias de integração sobre padrões e práticas, no site da Microsoft na Web.
Integração de Entidades
Pela perspectiva do usuário, como mencionamos anteriormente, a localização física do aplicativo, antes ou depois do firewall da empresa, não deve representar nenhum problema: os aplicativos em vários locais devem estar acessíveis de forma conveniente e consistente. Um componente bastante significativo dessa experiência consistente do usuário é o single sign-on (SSO): os usuários digitam nome e senha ao se conectarem no sistema operacional MSWindows no início do dia e, depois, podem ter acesso aos aplicativos e recursos da rede sem ter de apresentar suas credenciais para cada um, separadamente. Além da conveniência, o SSO representa para os usuários um número menor de conjuntos de credenciais para controlar e reduz o risco de segurança de senhas perdidas ou esquecidas.
Pela perspectiva do gerenciamento e da governança de TI, o SSO significa que a equipe de suporte não terá de gerenciar conjuntos independentes de credenciais. Facilita também a integração de identidades de outras formas, por exemplo, possibilitando o reuso das políticas existentes de acesso a aplicativo, para controlar o acesso aos aplicativos SaaS. Por exemplo, uma diretiva pode definir que determinado gerente está autorizado a aprovar compras até um determinado limite e será preciso que o aplicativo SaaS também reconheça essa autorização. Integrar o serviço de diretório com um aplicativo SaaS significa que você não terá de replicar as informações da diretiva manualmente, ao configurar sua conta.
Os aplicativos SaaS podem fornecer autenticação SSO pelo uso de um servidor de federação na rede do cliente que faz interface com o serviço de diretório do usuário da própria empresa do cliente. Este servidor de federação possui uma relação de confiança com um servidor de federação correspondente, localizado na rede do provedor SaaS.
Se usuários finais tentarem ter acesso ao aplicativo, o servidor de federação da empresa autentica o usuário localmente e negocia com o servidor de federação SaaS para fornecer ao usuário um token de segurança, aceito pelo sistema de autenticação do provedor SaaS que o utiliza para dar acesso ao usuário.
/Fig5.jpg)
Figura 5. Um servidor de federação fornece aos clientes corporativos autenticação SSO para um aplicativo SaaS.
Implementar um servidor de federação que use padrões conhecidos para autenticação remota, como WS-Federation ou Security Assertion Markup Language (SAML), ajudará a facilitar o processo de implementação de SSO para um grande número de provedores SaaS.
A Microsoft oferece vários recursos para trabalho com federação de diretórios. Para obter mais informações, consulte os seguintes documentos: Web Service Security: Scenarios, Patterns, and Implementation Guidance for Web Services Enhancements (WSE) 3.0 e Overview of Active Directory Federation Services (ADFS) in Windows Server 2003 R2
Arquitetura de composição
É no aplicativo composto que as funções e as informações do negócio podem ser efetivamente integradas para os usuários finais. Os benefícios para o negócio de um aplicativo composto bem-projetado são muitos e incluem reduzida entrada de dados redundantes, melhor colaboração humana, melhor conhecimento das tarefas pendentes e dos respectivos status, além de visibilidade melhorada das informações inter-relacionadas do negócio. Generalizando os princípios dos aplicativos compostos em um nível mais teórico, observamos que a apresentação das informações como um todo unificado, em lugar de fluxos de dados isolados, traz benefícios aos usuários. Possibilita a melhor visualização das relações entre dados de várias fontes e aplicam a própria "domain intelligence" - conhecimento próprio preexistente de como o negócio e os seus processos trabalham - para estar em melhor posição de tomar decisões informadas. Além disso, permite a criação de melhor "process intelligence", que oferece aos usuários uma visão aprimorada das próprias tarefas e responsabilidades.
Considere um médico em um hospital. No decorrer do dia, o médico talvez tenha trabalhado com uma grande variedade de informações relacionadas aos cuidados com pacientes: Raios X, históricos, receitas e informações farmacêuticas, restrições de cobertura do seguro-saúde, comunicados oficiais do ministério da saúde ou do centro de controle de doenças, etc. Normalmente, cada um desses tipos de informações pode ser rastreado por um aplicativo diferente e isso cria ineficiência para o médico. O hospital, sua equipe e seus pacientes poderiam estar todos melhor atendidos se cada uma dessas funções estivesse integrada em um único aplicativo que reunisse business intelligence (como os tipos de informações acima mencionados) com process intelligence (como a programação da sala de operações e o status da fila de pacientes ativos do médico), assim como ferramentas de colaboração que facilitem as reuniões de juntas médicas.
Em um departamento de TI centralizado em serviço, os aplicativos e outros recursos tornam-se ingredientes que podem ser combinados entre si, de tal modo, para criar aplicativos compostos dirigidos a tarefas que reúnem "business intelligence" e "process intelligence" em um único pacote. Criar um aplicativo composto não é fácil: envolve reunir aplicativos, protocolos e tecnologias diferentes, não necessariamente projetados para a comunicação entre si, integrando-os em um todo transparente. A arquitetura de composição destina-se a concretizar esse objetivo.
/Fig6.jpg)
Figura 6. A arquitetura de composição destina-se a extrair dados de diferentes fontes, tipos e locais.
No nível arquitetônico mais baixo da arquitetura de composição encontram-se as fontes que fornecem dados armazenados ou processados como "matérias-primas". As fontes podem incluir aplicativos e bancos de dados internos, aplicativos SaaS, serviços Web, arquivos flat e muitas outras fontes. Muitos aplicativos SaaS fornecem APIs que expõem várias propriedades e métodos que podem ser usados diretamente.
Na camada de composição, os dados não processados são agregados e fornecidos ao usuário em uma forma nova e unificada. Sua função é transformar os dados em informações do negócio e process intelligence, e vice-versa.
A camada de composição compreende vários componentes que gerenciam acesso, dados, fluxo de trabalho e regras. A conexão "plug-in" de aplicativos, banco de dados, serviços Web e outros recursos com esta camada é feita por meio de agentes de serviço, responsáveis pelos detalhes da negociação de conexões e troca de mensagens, com cada serviço. O componente que gerencia as identidades garante que os usuários sejam devidamente autenticados e autorizados; além disso, também pode gerenciar credenciais para comunicação com serviços Web os quais, quase sempre, exigem credenciais diferentes daquelas fornecidas pelos usuários para acessar a rede local.
O componente que agrega os dados da camada de composição obtém informações das fontes de dados e as transforma nas formas definidas pelo modelo da entidade de aplicativo. Por exemplo, uma entidade de catálogo talvez precise de vários itens de produto e informações de estoque provenientes de diferentes sistemas. Estas informações são, então, apresentadas ao usuário final como um conjunto de dados, correlato e unificado. O componente do fluxo de trabalho organiza as informações com condições e fluxos que guiam a interação e a colaboração humanas; o mecanismo de eventos ativa notificações a serem enviadas e recebidas no momento em que condições específicas sejam satisfeitas, para que o usuário final possa reagir apropriadamente.
A camada centralizada no usuário apresenta os dados compostos por meio de uma interface de usuário central, integrada e orientada a tarefas, que fornece as informações para a tomada de decisões e também a funcionalidade para a ação. Esta talvez seja a mais completa expressão do potencial do departamento de TI centralizado em serviço: combinar os melhores aspectos de qualquer número de aplicativos e fontes de dados em um único aplicativo, orientado pelas necessidades do usuário, em lugar de oferecer os recursos e as limitações de qualquer sistema.
Existe um número muito maior de detalhes do negócio, da arquitetura e da tecnologia que pode ser escrito sobre os aplicativos compostos. A próxima edição, No.10, do Architecture Journal abordará este tópico de forma bem mais detalhada.
Transformando-se em um provedor de SaaS
Discutimos os benefícios para as empresas que se transformam em consumidoras SaaS. Em alguns casos, os negócios também se beneficiam quando se tornam provedores especializados em SaaS.
Tornar-se um provedor SaaS pode trazer benefícios ao negócio que tenha entidades dependentes - como as franquias ou os revendedores - que tenham um forte relacionamento comercial, mas com automatização de processos de TI e transferência de informações deficientes. Por exemplo, considere uma cadeia de fast-food que opere com base no modelo de franquia. Alguns ou todos os seus restaurantes são de propriedade de franqueados independentes que contratam com o franqueador a identificação da marca, as receitas e, talvez, o aluguel das instalações e do estoque. Os franqueados não têm pessoal nem verba para implantar e manter infra-estruturas de TI por satélite em suas instalações e, assim, a maior parte ou toda a sua comunicação com o franqueador tende a ser do jeito antigo: correio convencional, telefone, nas reuniões periódicas no escritório regional ou por qualquer outro método, não técnico. Uma melhor relação de TI entre a matriz e seus franqueados poderia elevar a qualidade dos serviços, aprimorando a transferência de informações e possibilitando a automatização de determinados processos.
É nesse ponto que entra o SaaS. Ao tornar-se um provedor SaaS, o escritório central poderá hospedar aplicativos especializados dos franqueados para funções do negócio como controle de estoque, contabilidade, promoções, programas de fidelidade, etc. - aplicativos que os franqueados, em todo o mundo, poderão acessar usando apenas um PC e uma conexão de banda larga comuns. Esta é uma organização que beneficia todas as partes da relação. No exemplo dado, os franqueados se beneficiam dos aplicativos os quais, de outra forma, não estariam disponíveis para eles. Da mesma forma, com o uso desses aplicativos pelos franqueados, o franqueador recebe comentários e dados avançados que contribuem para que o business intelligence seja mais preciso e valioso.
As empresas também devem considerar tornar-se um provedor SaaS se tiverem desenvolvido um ativo de TI valioso que poderia ser monetizado se colocado à disposição de outras empresas. Por exemplo, um banco que tenha desenvolvido um sistema sofisticado de detecção de fraude para uso interno, poderia desenvolver uma versão comercial para oferecê-lo a assinantes como um aplicativo SaaS. Os mesmos princípios que possibilitam à empresa consumir serviços da nuvem Internet também permitem oferecer serviços à nuvem.
Conclusão
As empresas fariam bem se considerassem a flexibilidade e as implicações de gerenciamento do risco de adicionar o SaaS aos seus portfólios de serviços de TI. A integração e a composição são componentes críticos em suas estratégias de arquitetura para incorporar o SaaS, de modo bem-sucedido, como um membro totalmente participante de sua infra-estrutura de TI centralizada em serviço.
Por fim, acreditamos que o futuro da computação corporativa não se apoiará, puramente, nos itens instalados no local ou aqueles na nuvem. Em lugar disso, como os símbolos yin e yang, haverá uma coexistência harmônica e simbiótica.
Agradecimentos
Por sua ajuda com os termos técnicos, agradeço muito a Paul Henry.
Discussões e comentários adicionais
Para discussões mais detalhadas sobre este tópico e muitos outros, relativos ao SaaS, visite o blog do Fred Chong e o blog do Gianpaolo. Para comentários sobre este artigo, envie um e-mail para Fred Chong ou Gianpaolo Carraro. Obrigado.