Arquitetura Empresarial na Era dos Serviços em Nuvem

Usando um SaaS, software como serviço, híbrido

Este artigo mostra como usar uma arquitetura empresarial para especificar requisitos para serviço em nuvem pública, usando um exemplo de software como serviço (SaaS) híbrido. A arquitetura empresarial (EA) é uma ferramenta importante para ajudar os clientes de nuvem a entender como aproveitar o novo modelo de negócios proporcionado pela tecnologia e como encaixar serviços externos em seus aplicativos e ambientes técnicos atuais. Ao ler este artigo, um arquiteto de TI aprenderá a usar anotações de EA e o IBM Rational System Architect para comunicar-se efetivamente com usuários de negócios e outras partes interessadas, incluindo o provedor de serviços.

Fabio Castiglioni, Senior IT Architect, IBM

Fabio Castiglioni photoFabio Castiglioni é arquiteto de TI executivo em IBM Sales and Distribution na Itália. Ele tem 13 anos de experiência em um laboratório de desenvolvimento, onde deteve funções técnicas e de gerência em projetos internacionais. Em 1995, foi nomeado Technical Director de um projeto de pesquisa sobre tecnologias orientadas a objetos. Em 1998, foi IGS Senior IT Architect trabalhando em importantes projetos do governo. Fabio é um dos professores das aulas de Modelagem de Componente para arquitetos IBM e já publicou vários artigos sobre requisitos não funcionais.



15/Out/2012

Introdução

A ideia de que uma boa arquitetura empresarial (EA) é um importante ativador da adoção efetiva de uma arquitetura orientada a serviços (SOA) surgiu há muitos anos (consulte a citação de Ibrahim e Long em Recursos), e muitos clientes pagaram pela ausência de "devida diligência" de EA na forma do fracasso total ou parcial de projetos. O cenário geral da arquitetura, a ligação de ponta a ponta entre processos de negócios e serviços de TI e o mecanismo de controle do dia a dia proporcionado por uma arquitetura empresarial estabelecida, são todos elementos essenciais para a SOA que cumpre sua promessa de oferecer tecnologia capaz de transformar os negócios e a empresa.

Eu já estou ouvindo sua mente fervilhando, pensando algo como: "Eu devo ter aberto o artigo errado. Esse deveria ser sobre nuvem, não sobre SOA."

O fato é que, independente de falarmos sobre nuvem ou SOA, estamos lidando com serviços.

Dizer "serviços" significa que aceitamos estruturar nossa TI com uma granularidade que está provavelmente abaixo do ideal para o gerenciamento do problema em questão, e que estamos também dispostos a "superprojetar" alguns dos componentes para apoiar um nível maior de flexibilidade na reorganização das operações de negócios. (Pense sobre a padronização de interfaces, por exemplo. Ela não acontece de graça e só tem retorno quando de fato reutilizamos a função.) Esse nível de flexibilidade é, em si, apenas uma maneira de conseguir processos de negócios flexíveis. Esses, por sua vez, têm retornos econômicos significativos apenas se suportarem estratégias de negócios flexíveis e informadas.

Os implementadores de uma arquitetura de nuvem (ou uma SOA) precisam entender bem essa cadeia de causa e efeito. Do contrário, suas decisões sempre ignorarão algum aspecto importante do problema.

Isso significa que ter um modelo de arquitetura corporativo da área a ser transformada é realizar a devida diligência de identificar relações entre negócios e TI, dependências, requisitos e restrições.

Neste artigo, iremos explorar como representar esse modelo e como entender, a partir dele, o que precisa ser feito e por que, da perspectiva do consumidor de serviços de nuvem. Pode ser uma organização que deseja utilizar a tecnologia de nuvem para injetar um novo nível de flexibilidade em suas operações.


Cenários do consumidor do serviço em nuvem

Uma Arquitetura de Referência de Nuvem, como a da IBM ou a do National Institute of Standards and Technology (NIST) do Departamento de Comércio dos EUA, estrutura os negócios na nuvem, começando do conjunto de agentes envolvidos. Cada agente tem uma função definida.

Figura 1. IBM Cloud Reference Architecture, semelhante à do NIST
IBM Cloud Reference Architecture, semelhante à do NIST

A arquitetura de referência da IBM identifica as seguintes funções:

  • O Criador de Serviço em Nuvem, que desenvolve novos serviços para serem consumidos através da infraestrutura de nuvem
  • O Provedor de Serviço em Nuvem, que administra e opera a infraestrutura de nuvem
  • O Consumidor de Serviço de Nuvem, que usa os serviços hospedados na infraestrutura de nuvem

O NIST lista as seguintes funções:

  • Provedor de Nuvem (semelhante à definição a IBM)
  • Consumidor de Nuvem (idem)
  • Auditor de Nuvem, que pode realizar avaliação independente dos serviços em nuvem
  • Broker de Nuvem, que pode intermediar, compor, incluir valor nos serviços do Provedor
  • Operadora de Nuvem, que pode fornecer serviços de transporte para o Provedor de Serviço em Nuvem

Como é possível ver, Provedor e Consumidor são as funções centrais. Enquanto os modelos de negócios e de TI do Provedor sejam semelhantes aos de um fornecedor tradicional, o Consumidor é aquele que mais usa os recursos inovadores da nuvem.

Voltando à IBM Cloud Reference Architecture, o Consumidor pode escolher quatro classes de serviços:

  • Serviços de infraestrutura (chamados de Infraestrutura como serviço ou IaaS), nos quais o Consumidor usa serviços equivalentes a um sistema de hardware
  • Serviços de plataforma (PaaS, ou platform as a service), nos quais os serviços são equivalentes a uma infraestrutura completa de hardware e software
  • Serviços de suporte a software (SaaS, ou software como serviço), nos quais o Consumidor usa um aplicativo de negócios
  • Business process as a service (às vezes chamado de BPaaS), no qual o Consumidor terceirizou parte do processo de negócios a um provedor externo

O Provedor e o Consumidor podem ser dois departamentos na mesma empresa (operações de TI e desenvolvimento de TI, por exemplo) que usam uma nuvem privada, ou duas entidades de negócios separadas, uma das quais tem como negócio fornecer serviços através da nuvem. O último é o caso mais interessante, pois envolve alterações no modelo de negócios corporativo, e não apenas no modelo de uma de suas entidades organizacionais.

Das quatro classes de serviço, este artigo concentra-se no caso específico da aquisição de novos recursos de negócios através do uso de um aplicativo de negócios entregue através de um serviço de nuvem (SaaS pública).

Um último ponto envolve a capacidade do modelo de nuvem de ser uma "plataforma". O fornecimento de serviços é o objetivo, claro, mas a qualidade dos serviços fornecidos depende das funções de suporte técnico e de negócios fornecidas pela plataforma (as duas caixas rosa na IBM Reference Architecture).

A IBM Cloud Reference Architecture identifica estes serviços de suporte:

  • Catálogo e Gerenciamento de Oferta de Serviços
  • Gerenciamento de Solicitação de Serviço
  • Gerenciamento de Pedido e Assinatura
  • Gerenciamento de Contratos e Acordos
  • Precificação, Medição e Faturamento
  • Gerenciamento de Conta do Cliente
  • Classificação
  • Liquidação e Quitação, Contas a Pagar, Contas a Receber
  • Catálogo de Entrega de Serviço
  • Gerenciamento de Automação de Serviço
  • Gerenciamento de Mudança e Configuração
  • Gerenciamento de Ciclo de Vida de Imagem
  • Fornecimento
  • Gerenciamento de Incidente e Problema
  • Gerenciamento de Nível de Serviço de TI
  • Gerenciamento de Monitoramento e Evento
  • Gerenciamento de Ativos de TI e Licença
  • Gerenciamento de Capacidade e Desempenho
  • Gerenciamento de Plataforma e Virtualização

Alguns desses serviços claramente apoiam os processos técnicos e de negócios dos Provedores. Alguns exigem a participação dos Clientes e podem ser uma novidade para eles, como faturamento do pagamento pelo serviço, correlação de informações de monitoramento externas para controlar a qualidade do serviço comprado, etc.

Observação:
Este artigo não falará sobre eles por limitação de espaço, mas sugerimos sua inclusão na análise (de EA) como parte da devida diligência técnica para a adoção de qualquer serviço baseado na nuvem.


A estrutura TOGAF e o modelo ArchiMate

Open Group Architecture Framework (TOGAF) é uma estrutura de arquitetura empresarial. O desenvolvimento da TOGAF Versão 1, em 1995, foi baseado na Technical Architecture Framework for Information Management (TAFIM) desenvolvida pelo Departamento de Defesa dos EUA. Parte central da TOGAF é o Architecture Development Method (ADM), que descreve um processo em 8+1 fases para gerenciar o desenvolvimento de uma arquitetura empresarial.

ADM é iterativo em três níveis: sobre o processo total, entre fases e dentro de fases. É um método genérico, podendo ser adaptado às necessidades da organização. Por exemplo, algumas agências federais dos EUA que usam ADM desenvolveram distribuíveis de arquitetura específicos para as suas necessidades.

ArchiMate, um Open Group Standard, é uma linguagem de modelagem aberta e independente para arquitetura empresarial, que fornece instrumentos para descrever, analisar e visualizar os relacionamentos entre negócios, aplicativo e domínios de tecnologia de maneira não ambígua.

Assim como o desenho arquitetônico na arquitetura de prédios clássica descreve os vários aspectos do desenvolvimento e uso de um prédio, o ArchiMate oferece uma linguagem comum para descrever o desenvolvimento e operação de processos de negócios, estruturas organizacionais, fluxos de informações, sistemas de TI e infraestrutura técnica. Esse insight ajuda as partes interessadas a projetar, avaliar e comunicar as consequências das decisões e alterações dentro e entre esses domínios de negócios. (Fonte: The Open Group)

ArchiMate está organizado em três camadas principais e duas extensões.

Camada de negócios
Essa camada modela a estrutura de organização e os serviços que ela produz, funções de negócios e processos e objetos de negócios, como produtos e contratos.
 
Camada de aplicativo
Descreve os componentes de aplicativo e suas interações, entidades de dados lógicas e seus relacionamentos e os serviços resultantes oferecidos para a camada superior (negócios).
 
Camada de tecnologia
Modela os sistemas de hardware e software e as redes de conexão, mostrando como eles traduzem-se em serviços fornecidos para a camada superior (aplicativo).

As especificações do AchiMate 2.0 incluíram duas extensões às camadas principais.

Motivação
Os conceitos motivacionais são usados para modelar as motivações, ou razões, que influenciam, guiam ou restringem o design ou mudança de alguma parte da arquitetura empresarial.
 
Implementação e migração
Essa extensão inclui conceitos para modelar programas de alteração e planejamento de migração, bem como programa de suporte, portfólio e gerenciamento de projetos.
Figura 2. Exemplo de anotação de ArchiMate
Exemplo de anotação de ArchiMate

Como qualquer bom modelo de arquitetura, além das camadas de arquitetura, as especificações do ArchiMate têm suporte para Pontos de Vista. Os pontos de vista são para comunicar certos aspectos de uma arquitetura. Esses aspectos são determinados pelas preocupações de uma parte interessada. Portanto, o que deve ou não ser incluído em um ponto de vista específico depende totalmente das preocupações da parte interessada.

Este artigo complementa os modelos de motivação, de negócios, de aplicação e de tecnologia com um ponto de vista não funcional da arquitetura, como descrito por Castiglioni e Pedulla (consulte Recursos), usando o plug-in Corso ArchiMate 2.0 para IBM® Rational® System Architect.

Usando EA para integrar serviço em nuvem na empresa

Mesmo nessa breve introdução, fica claro que o modelo ArchiMate trata de serviços e da realização de serviços. Isso combina muito bem com o modelo de nuvem.

Podemos facilmente definir SaaS como serviços de aplicativo expostos para dar suporte a um processo de negócios, implementado através de componentes de aplicativo.

Com a mesma facilidade, podemos modelar uma PaaS como um serviço de tecnologia (ou coleção de serviços) para dar suporte a componentes e dados de um aplicativo específico.

Portanto, os requisitos funcionais de SaaS podem ser descritos desta maneira:

  • A motivação das partes interessadas envolvidas
  • O modelo de negócios que ela deve suportar
  • Interfaces para outros aplicativos expostas
  • Serviços solicitados ao nível de tecnologia do Cliente, caso seja necessária conectividade entre a nuvem e os sistemas internos
  • Os aspectos não funcionais da solução SaaS

Cenário de exemplo: externalizando um processo para a nuvem

Para entender melhor como usar os modelos de EA para especificar a maneira de usar uma solução SaaS, estenderemos a amostra de ArchiMate de The Open Group. Esse exemplo usa uma empresa de seguros fictícia chamada Archinsurance e supõe que ela identificou o aplicativo de CRM existente como inibidor de seus objetivos de negócios.

Compartilhando motivações com todas as partes interessadas

O modelo de Motivação captura a motivação e os requisitos das partes interessadas. Como mostra o fluxograma na Figura 3, o CEO tem duas motivações:

  • Aumentar o número de vendas repetidas para um dado cliente
  • Ganhar dinheiro antes do final do ano

O CFO está preocupado com o ROI do gasto de capital em um período de orçamento apertado, enquanto o CIO está preocupado principalmente com o espaço físico disponível no datacenter atual. O pessoal do Departamento de Segurança opõe-se a qualquer solução fora do local, pois têm receio de furto ou extravio de dados vitais da empresa, como registros de clientes, e solicitam a implementação de práticas de segurança da empresa.

Figura 3. O modelo de Motivação para o novo CRM
O modelo de Motivação para o novo CRM

Dentre os requisitos do CEO, CFO, CIO e Departamento de Segurança, parece que a escolha é entre uma solução em nuvem e terceirização mais tradicional, com pontos adicionais a favor do primeiro. No entanto, os requisitos de segurança são difíceis de atender e restringirão o número de provedores candidatos àqueles capazes de oferecer criptografia na movimentação e armazenamento de dados.

Além disso, a solução SaaS selecionada não pode ser um serviço de nuvem "puro", pois deve incluir um mecanismo para proteger os dados contra acesso não autorizado e alinhamento de dados entre a nuvem e o datacenter. Portanto, será uma solução híbrida.

Identificando requisitos funcionais no modelo de negócios

Como mencionamos, esse exemplo baseia-se na suposição de que o novo aplicativo terá suporte para o mesmo modelo de negócios e processos que o anterior. Nosso modelo de negócios de EA dará a orientação para identificar o que precisa ser suportado.

Como um exemplo, para suportar o processo de Manipulação de Pedido, o CRM atual fornece Serviços de Administração de Cliente e Serviços de Impressão. Os serviços identificados dessa forma serão a fonte dos requisitos funcionais para a nova solução SaaS (por exemplo, "A versão impressa do pedido deve conter os seguintes dados") e dos requisitos não funcionais (por exemplo, "A formatação e impressão de um pedido não pode demorar mais que 3 minutos").

Figura 4. Serviços de aplicativo afetados pelo novo CRM
Serviços de aplicativo afetados pelo novo CRM

Projetando o novo modelo de aplicativo

Quando estamos satisfeitos de que nossa futura solução SaaS pode atender a todos os requisitos funcionais, a próxima etapa é projetar como ela pode verificar os requisitos de interface com outro aplicativo (internos e, talvez, aqueles da nuvem).

Figura 5. O portfólio do novo aplicativo
O portfólio do novo aplicativo

Nesse exemplo, o portfólio do aplicativo Archinsurance, que era aquele mostrado à esquerda da Figura 5, muda para aquele à direita, no qual o CRM tornou-se um componente externo à empresa. A função do componente CRM é inalterada, mas é importante considerar cuidadosamente suas interfaces com outros componentes, como Acesso de Dados de Cliente e Gerenciamento de Dados de Política, pois elas podem mudar na assinatura (os dados trocados) e no protocolo (a tecnologia usada para a troca). (Observe que a direção dos relacionamentos no ArchiMate é inversa aos relacionados em modelos UML.)

Para concentrar nesse aspecto, nós redesenhamos nosso modelo de aplicativo, tornando as interfaces de aplicativo explícitas (e, se necessário, também os componentes que as implementam). Para as interfaces mostradas na Figura 5, considerando a capacidade técnica da implementação SaaS, isso significa incluir, na extremidade da nossa rede, um componente técnico ESV que é capaz de oferecer interfaces de serviços da web para os dados da empresa. Usaremos um ESB seguro e um serviço de FTP seguro para o data warehouse da empresa, para atender aos requisitos do gerente de segurança.

Para a interface com o portal da web, decidimos que o requisito real é um redirecionamento HTTP simples suportado por um único esquema de ID do usuário e senha. Portanto, o agente de contato usará um único par de ID e senha para fazer logon nos sistemas internos e no novo aplicativo CRM.

A interface é entre os dados de LDAP e os dados no mecanismo de autenticação usado pelo CRM na nuvem (no exemplo, realizamos push de atualizações de LDAP para o CRM como eventos). A autenticação de LDAP e o CRM cooperam para fornecer a (nova) função de autenticação de usuário, assim como os dados de CRM e o datamart interno cooperam para oferecer uma nova função de data warehouse.

O novo modelo de aplicativo orienta o design das alterações necessárias para acomodar o novo serviço SaaS com nossa infraestrutura interna existente.

Figura 6. Diagrama do modelo de aplicativo revisado
Diagrama do modelo de aplicativo revisado

Descrevendo o Ponto de Vista não funcional

O último item que precisamos considerar é o Ponto de Vista não funcional.

Nosso foco aqui será em dois aspectos:

  • A solução SaaS deve oferecer suporte a quais nonfunctional requirements (NFRs)
  • O que precisamos fazer para conectar os dois sistemas e como isso afetará os NFRs da infraestrutura interna

Na verdade, o novo serviço terá que satisfazer um conjunto complexo de NFRs, alguns originários de necessidades de negócios (por exemplo, tempo de impressão), e outros vindos de partes interessadas, como o gerente de segurança.

Além disso, alguns requisitos podem formar combinações complexas que pressionam o novo serviço (por exemplo, tempo de resposta com um número grande de usuários simultâneos), e teremos que verificá-los antes de declarar aceitável a solução SaaS.

A arquitetura e infraestrutura internas do Provedor de Serviço não é nossa preocupação (exceto pela devida diligência). Portanto, qualquer teste de aceitação que realizarmos será uma caixa preta. No entanto, é preciso considerar a infraestrutura. Em nosso esquema, o firewall XML que protege o ESB Archinsurance e o firewall HTTP/FTP devem ser configurados para levar em conta os novos fluxos entre a Empresa e o Provedor de Serviços.

Figura 7. Ponto de Vista não funcional de SaaS do CRM
Ponto de Vista não funcional de SaaS do CRM

Resumo

Este artigo mostrou como um modelo de EA pode ser uma orientação excelente na adoção de uma solução SaaS, tanto em termos de requisitos no Provedor como em especificações e design para o que precisa ser adaptado para o novo serviço na infraestrutura interna. O exemplo dessa abordagem usa a notação TOGAF ArchiMate fornecida no Rational System Architect através de um plug-in Corso.


Agradecimentos

Agradecemos a Pietro della Peruta e Francesco Pedulla, Executive IT Architects na IBM, por sua leitura e sugestões.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational
ArticleID=840449
ArticleTitle=Arquitetura Empresarial na Era dos Serviços em Nuvem
publish-date=10152012