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 qrquitetura 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.

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 denNuvem (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.

 

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.

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”).

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).

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.

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.

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

• Saiba mais sobre como nonfunctional requirements (NFRs) podem ser integrados na descrição arquitetural de sistemas complexos com vários softwares.
  • Especificação do ArchiMate 2.0, The Open Group (2012).
  • TOGAF Versão 9, The Open Group (2009).
  • F. Castiglioni e F. Pedulla. Representando Aspectos Não Funcionais Usando o TOGAF ArchiMate. IBM developerWorks (abril de 2012).
  • F. Schafrik. Guia prático para desenvolver arquitetura empresarial. IBM developerWorks (2011).
  • V. Temnenco. Usando um ambiente SOA e TOGAF combinado para obter melhor produtividade: Parte 2. Arquitetura Orientada a Serviços de cima até embaixo. IBM developerWorks (2010).
  • D. Cook, P. Cripps e P. Spaas. An Introduction to the IBM Views and Viewpoints Framework for IT Systems. IBM developerWorks (2007).
  • M. Ibrahim e G. Long. Service-Oriented Architecture and Enterprise Architecture, uma série de três artigos. IBM developerWorks (abril de 2007).
  • Website da Corso.
• Saiba mais sobre o Rational System Architect:
  • Navegue pela developerWorks para obter o Rational System Architecte acompanhe a demonstração online ou leia a transcrição por escrito.
  • Consulte o Centro de Informações do Rational System Architect para obter documentação para todas as versões ou obtenha suporte a partir de tópicos da ajuda do Rational System Architect .
• Visite a área do software Rational no developerWorks para recursos técnicos e melhores práticas para os produtos Rational Software Delivery Platform.
• Assine a newsletter semanal por email do developerWorks e escolha os tópicos para seguir. Fique atualizado com os eventos técnicos e webcasts do developerWorkscom ênfase em uma série de produtos IBM e assuntos relacionados ao segmento de mercado de TI.
  • Participe de um briefing ao vivo e gratuito do developerWorks Live! para se informar sobre os produtos e ferramentas IBM, além das tendências do mercado de TI.
  • Acompanhe as demos sob demanda do developerWorks, que abrangem desde a instalação e a configuração dos produtos para iniciantes até as funcionalidades avançadas para desenvolvedores experientes.
• Melhore suas qualificações. Consulte o catálogo de treinamentos e certificações Rational , que inclui muitos tipos de cursos com uma ampla variedade de tópicos. É possível fazê-los em qualquer lugar, a qualquer momento, e muitos dos cursos de introdução são gratuitos.

Obter produtos e tecnologias

• Faça o download de uma versão de teste gratuita e com funcionalidades completas de Rational System Architect.
• Faça uma avaliação do software IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-a on-line, use-a em um ambiente de nuvem ou passe algumas horas no SOA Sandbox para saber como implementar arquitetura orientada a serviço de maneira eficiente.

Discutir

• Participe do fórum Enterprise Architecture and Business Architecture, nos quais poderá compartilhar informações sobre métodos, estruturas e implementações de ferramentas. As discussões incluem questões técnicas específicas da ferramenta Rational System Architect.
• Avalie ou revise um Rational. É rápido e fácil.
• Compartilhe seu conhecimento e ajude outros a usar o software Rational, escrevendo um artigo do developerWorks. Descubra o que torna bom um artigo do developerWorks e como proceder.
• Siga o software Rational no Facebook, Twitter (@ibmrational), e YouTube, e adicione seus comentários e solicitações.
• Faça e responda a perguntas, e aumente seus conhecimentos participando dos fóruns, cafése wikis Rational.
• Conecte-se. Faça parte do fórum da comunidade Rational para compartilhar seu conhecimento sobre o software Rational e ficar conectado aos seus parceiros.

***

Sobre o autor: Fabio 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.

***

Artigo original disponível em: http://www.ibm.com/developerworks/br/rational/library/enterprise-architecture-cloud/index.html