Projetar um ecossistema SoE para suportar experiências ricas

de usuários

Sistemas de engajamento: a nova era da nuvem

Cada vez mais, os consumidores on-line exigem uma experiência rica que aproveita
informações de fontes diferentes estruturadas e não estruturadas, canais sociais e
outros consumidores. O valor contido nesta informação pode ser rapidamente extraído
para cumprir os objetivos de uma pessoa e permitir escolhas informadas. Já a norma no
espaço do consumidor, esse tipo de experiência também está se tornando a expectativa
geral para aplicativos de negócios. Um sistema de engajamento (SoE) possibilita essa
rica experiência, extraindo valor das informações provenientes de múltiplos canais e
possibilitando novos modelos de negócios digitalizados. Um ambiente operacional em
nuvem (CloudOE) é a plataforma que suporta cargas de trabalho de SoE. O CloudOE
permite a agilidade e a velocidade que um SoE precisa, fornecendo um ecossistema
para desenvolver, implantar e operar aplicativos SoE.

Projetar um ecossistema SoE é um novo tipo de empreendimento, e os métodos de

análise tradicionais, como casos de uso, são limitados demais para representar as
decisões que são a base de um modelo de SoE. Este artigo apresenta uma abordagem
alternativa e descreve seu impacto no processo de design. Usando um exemplo no
campo do turismo, explica os conceitos de design relevantes e o fluxo de
desenvolvimento.

Processos e sistemas baseados no engajamento

Os processos baseados no engajamento já são predominantes em vários setores e se

tornam cada vez mais importantes em outros. Exemplos incluem:
• Planejamento de férias: O planejamento de férias que usa a Internet é o mercado mais
maduro de envolvimento on-line. Acessar mecanismos de comparação de preços,
consultar sistemas de reputação como o TripAdvisor, visualizar dados contextuais
(como imagens no Google Maps e informações meteorológicas no Weather Channel) e
encontrar e trocar informações com grupos de especialistas em redes sociais é um
comportamento comum para o digital. viajante nativo.
• Consultoria financeira: Os bancos há muito tempo deixaram de oferecer apenas um
balcão onde as operações financeiras são realizadas, passando a ser um consultor de
saúde financeira por meio de um relacionamento contínuo e estável de pessoa para
pessoa com os clientes. Tal relacionamento requer conhecimento contínuo e atualizado
e confiança entre conselheiro e cliente.
• Novos planos de bem-estar individual: Com orçamentos reduzidos e sob crescente
pressão econômica, alguns governos estão mudando o foco de evitar a agitação social
por meio de subsídios para obter resultados sociais por meio de programas
personalizados que reincorporam o cidadão no ciclo de produção. Essa abordagem
exige colaboração entre as agências, integração de dados dos cidadãos de fontes
públicas e privadas e correlação de informações estruturadas e não estruturadas para
identificar o plano que provavelmente terá êxito para a situação individual.
• Investigação de fraude e abuso: em um mercado eletrônico global, as fraudes e os
abusos assumiram novas formas e atingiram novas complexidades. Investigá-los requer
a análise e comparação de enormes quantidades de dados estruturados e não
estruturados de fontes diferentes e, muitas vezes, aparentemente não relacionadas. O
tempo e a localização geográfica desses dados, bem como a colaboração entre várias
organizações, são os principais facilitadores para esse cenário.
• Compras baseadas em contexto com base na conscientização de local: O
reconhecimento de local baseado na geolocalização de dispositivos móveis pessoais
permite um novo cenário para o varejo, estendendo uma experiência que já é comum
na Internet com anúncios "contextuais" de mecanismo de pesquisa baseados em
histórico de navegação dos consumidores.

Suporte para SoEs abre novas possibilidades para muitos setores. Os usuários podem
ter uma experiência rica com o sistema - o tipo de experiência que no passado era
possível apenas por meio da interação entre humanos. Os envolvimentos são, na
verdade, centrados no ser humano por natureza. Ao contrário de um sistema de
registros (SoR) - cujos processos centrados em registros rastreiam o progresso dos
usuários por meio de uma sequência de registros de dados -, o objetivo do SoE é atingir
objetivos que sejam significativos para o usuário.

O ecossistema da SOE

Em essência, os SoEs aplicam a análise preditiva a dados de serviços públicos móveis,

sociais, de nuvem e de sistemas de TI tradicionais (SoRs) para fornecer aplicativos e
produtos inteligentes diretamente no contexto do cotidiano de clientes, parceiros e
funcionários.

Em um white paper de 2011, o consultor Geoffrey Moore introduziu o termo sistemas de

engajamento para descrever sistemas que se concentram em “capacitar o meio da
empresa para comunicar e colaborar entre fronteiras de negócios, fusos horários globais
e barreiras de idioma e cultura, usando a próxima geração. Aplicações de TI e
infraestrutura adaptadas do espaço do consumidor. "
Figura 1. Um ecossistema de SoE
Um SoE:
• Permite a colaboração: os SoEs são para os humanos e assumem que os humanos
colaborarão entre si. Por outro lado, a principal preocupação dos SoRs é a interação
entre o usuário (humano) e o sistema (máquina) em relação a um processo específico.
Em um engajamento, as interações humano-homem e homem-máquina estão em pé de
igualdade e fazem parte de uma colaboração geral.
• Explora dados ricos de várias fontes: SoEs são impossíveis sem grandes quantidades
de dados. A análise de fontes de dados díspares para extrair informações significativas
e acionáveis está no cerne do raciocínio humano e também no núcleo dos SoEs.
• Adapta-se a identidades e preferências: Quando você atua como profissional de TI,
você tem comportamentos e preferências diferentes de quando age como pai de seu
filho na escola (embora as duas identidades influenciem umas às outras de algumas
maneiras). No entanto, para alguns SoRs, todas as suas funções usam o mesmo ID,
endereço, número de identificação do governo e assim por diante. Este não é o caso de
um SoE. As SOEs devem levar em consideração seu trabalho, suas preferências e seu
histórico (em suma, seu contexto) para fornecer a rica experiência esperada. Em termos
práticos, os SoEs devem usar uma grande quantidade de análises de dados em tempo
real ou um sistema de gerenciamento de dados mestres (MDM) no qual informações
complexas sobre os usuários são mantidas e constantemente enriquecidas.
• É sensível ao tempo e à localização: uma experiência de usuário rica deve levar em
conta o fato de que vivemos no tempo e nos movimentamos no espaço. Receber uma
foto de uma praia ensolarada para as férias de sua próxima semana, quando uma
tempestade tropical é esperada no seu destino, e essa mesma semana não é um bom
serviço para o seu noivado. (É o nível de serviço que a maioria das reservas atuais de
SoRs oferecem.) Os dispositivos móveis abrem oportunidades para interações ainda
mais ricas à medida que você se movimenta durante um compromisso.
• Suporta várias maneiras de interagir: os dispositivos móveis provavelmente
proporcionarão a melhor experiência do cliente, pois podem incluir a localização do
usuário na lógica de interação. Mas certos compromissos não exigem reconhecimento
de local e, portanto, podem ser eficazes quando usados em um PC comum. Outros tipos
de dispositivos, como quiosques ou até caixas eletrônicos, podem desempenhar um
papel em outros tipos de compromissos
• Mantém segurança e privacidade adequadas: Como um SoE sabe muito sobre você,
ele deve manter essas informações seguras. O usuário deve ser capaz de controlar
quem recebe quais informações. Porém, quanto menos dados forem expostos, menos
serviço será recebido - porque a customização de informações e serviços para os
interesses pessoais dos usuários é a principal função do sistema. (A esse respeito, um
SoR é muito menos exigente, porque geralmente pode reduzir as diferenças de
comportamento para classes de usuários ou perfis.)

Ambiente operacional em nuvem: a tecnologia por trás do

ShoEs

Em contraste com os SoRs, os SoEs devem ser projetados para lidar com necessidades
de recursos erráticos e necessidades de capacidade não planejadas e imprevisíveis.
Além disso - para se diferenciar no mercado e aumentar a receita - eles devem permitir
que os clientes obtenham uma percepção mais rápida rapidamente dos dados
disponíveis. Por esses motivos, os SoEs precisam de uma plataforma que facilite a
implantação, o gerenciamento e o dimensionamento de aplicativos. Os desenvolvedores
podem se concentrar no desenvolvimento e nas operações do aplicativo em si e não na
infraestrutura necessária para hospedar o aplicativo.

As nuvens de infraestrutura como serviço (IaaS) fornecem aos desenvolvedores centros

de dados de tamanho virtualmente ilimitado, sem exigir que eles façam qualquer compra
inicial de hardware. No entanto, os desenvolvedores ainda precisam configurar as
máquinas virtuais, instalar software de middleware, conectar componentes do sistema
e manter sistemas - tudo isso leva tempo longe do verdadeiro trabalho de inovação.
Mesmo quando os desenvolvedores implementam o DevOps em cima da IaaS, eles
ainda precisam dedicar tempo para criar e gerenciar operações.

A nuvem é capaz de fazer mais do que fornecer IaaS. Um CloudOE pode cuidar da
implantação, configuração e conexão das máquinas virtuais, o que permite que os
desenvolvedores se concentrem no aplicativo. Um CloudOE pode automatizar os
procedimentos de DevOps, o que se traduz em NoOps para os desenvolvedores. A
chave para o sucesso de um CloudOE é quão bem e quão rápido ele permite que os
desenvolvedores de linha de frente construam seus aplicativos.

DevOps

DevOps é uma metodologia de software que visa melhorar a comunicação, colaboração

e integração entre desenvolvedores e equipes de operações, com o objetivo de acelerar
o processo de entrega de software. Uma prática de DevOps é descrever tarefas
repetitivas de gerenciamento de configuração como modelos (chamados de receitas ou
livros de receitas) e construir sistemas (usando ferramentas como o Chef) que executam
os modelos para automatizar o gerenciamento e a manutenção da infraestrutura.
Categorias de serviço

Estudos de caso mostraram que uma plataforma CloudOE deve suportar quatro
categorias de serviços, todos necessários para a criação e operação de aplicativos
centrados na nuvem (ou nativos da nuvem), como SoEs:
• Serviços de desenvolvimento
• Serviços de aplicativos
• serviços de infra-estrutura
• Serviços operacionais

Uma plataforma CloudOE deve fornecer uma variedade desses serviços e torná-los
facilmente utilizáveis por meio de uma API cliente simples e coesa. O suporte para uma
única linguagem de programação e um único contêiner da Web é insuficiente. Em vez
disso, o CloudOE deve acomodar várias estruturas de desenvolvimento da Web
adequadas ao propósito (como Grails, Play Framework, Ruby on Rails e Django),
linguagens (como Java®, Ruby, Python e Node.js) e programação modelos.

Entre os principais serviços de aplicativos, a plataforma deve fornecer, no mínimo:

• Serviços de banco de dados relacional
• Serviços de banco de dados baseados em documentos (NoSQL) (como o MongoDB)
• serviços de mensagens
• Serviços de armazenamento (como o armazenamento de objetos do OpenStack)

A Figura 2 resume os principais serviços que uma plataforma CloudOE deve exibir para
suportar as cargas de trabalho do SoE:

Figura 2. Serviços-chave para suportar cargas de trabalho de SoE

Mais importante, tudo deve fluir em torno de uma experiência de desenvolvimento
elegante e harmoniosa que pode se parecer com isso:
1. Gênesis: • Crio minha conta no portal CloudOE.
• Eu baixei a ferramenta de linha de comando (como desenvolvedor adoro a linha de
comando) para gerenciar aplicativos e serviços.
• Eu baixo a API do cliente CloudOE no idioma que eu prefiro.
• Eu também posso baixar o plugin CloudOE para o meu IDE preferido.

2. Agora posso começar a desenvolver meu próximo aplicativo SoE. Eu preciso de um

banco de dados relacional para metadados e um serviço de armazenamento de objetos
para salvar os blobs de objeto que eu quero gerenciar (como fotografias, gráficos e
artigos). Então eu preciso do suporte de tempo de execução para o framework de
desenvolvimento web que eu quero usar. • Eu vejo a documentação e descubro que o
CloudOE fornece tudo isso.
• Eu utilizo a linha de comando ou o plug-in do IDE para solicitar um serviço de banco
de dados e um serviço de armazenamento de objetos. O CloudOE implanta
automaticamente esses serviços para mim em sua infraestrutura.
• Eu escrevo meu aplicativo, fazendo a interface dos serviços usando a API do cliente
CloudOE.
• Implementei o aplicativo usando o plug-in do IDE ou a linha de comando. O CloudOE
provisiona automaticamente o ambiente de tempo de execução do aplicativo, cria as
conexões com os serviços necessários e fornece um URL para acessar o aplicativo.
• Eu testo o aplicativo.

Portabilidade
Os clientes não querem ser bloqueados em um provedor de nuvem. Eles devem
ser capazes de adaptar suas cargas de trabalho facilmente para execução em
um CloudOE diferente. O ideal é que um aplicativo CloudOE seja implementado
no software de hardware e middleware do cliente, com alterações apenas na
configuração, não no código.

Com um CloudOE, os desenvolvedores podem realizar em horas o que exigiria dias em

um ambiente tradicional. Eles não precisam implantar o servidor de aplicativos da Web
para hospedar o aplicativo e não precisam implantar o banco de dados e reservar o
armazenamento.

A infra-estrutura e os serviços operacionais de uma plataforma CloudOE tornam o valor

da plataforma ainda mais evidente. Esses serviços entram em ação principalmente
quando os aplicativos passam do ambiente de desenvolvimento para o ambiente de
verificação e, finalmente, para o ambiente de produção. O CloudOE deve fornecer a
capacidade de configurar vários ambientes segregados para hospedar os aplicativos e
ferramentas que simplificam a tarefa de entrega e integração contínuas.

A principal característica dos serviços de infraestrutura é a escala horizontal de

aplicativos: adicionar mais instâncias quando a demanda aumenta e liberar instâncias
quando a demanda diminui. Os serviços operacionais dão acesso ao gerenciamento do
aplicativo como um serviço, sem a necessidade de implantar e manter um conjunto de
produtos de gerenciamento no local. Idealmente, uma equipe de operações pode ativar
backups regulares de um aplicativo (e seus serviços) com poucos cliques do mouse no
portal do CloudOE. Os desenvolvedores podem tirar instantâneos dos dados de serviços
para que eles possam restaurá-los em um ambiente diferente para analisar um
problema.

CloudOEs do mundo real

As CloudOEs descritas neste artigo não são ficção científica; eles estão se tornando
rapidamente realidade. Vários provedores de plataforma como serviço (PaaS) na nuvem
estão acelerando na direção do CloudOE. Entre eles estão Cloud Foundry, da Pivotal,
Heroku e OpenShift, da Red Hat.

A IBM anunciou o BlueMix, a plataforma de nuvem da próxima geração baseada na

arquitetura IBM Open Cloud e na PaaS de software livre do Cloud Foundry. O IBM
BlueMix crescerá com o tempo, fornecendo serviços e tempos de execução baseados
no amplo portfólio de software da IBM. Ele permitirá o acesso a serviços de alto nível
para que os desenvolvedores possam facilmente consumir informações de dispositivos
móveis, canais sociais e dados disponíveis publicamente.

A primeira contribuição para a comunidade de software livre do Cloud Foundry é o IBM

WebSphere Liberty Buildpack, que está disponível para visualização prévia aos clientes
que participarão do projeto BlueMix.
Pluggability e sistemas externos

A menos que os clientes possam conectar seus SoRs à plataforma CloudOE e torná-los
utilizáveis como um serviço para suas organizações de desenvolvimento, eles
descobrirão que a CloudOE (pública ou privada) é inútil. Uma plataforma CloudOE
atraente deve possibilitar a conexão de novos serviços e a utilização de sistemas
externos como um serviço.

Por exemplo, o Cloud Foundry introduziu as instâncias de serviço fornecidas pelo

usuário como a maneira mais rápida de fornecer aos desenvolvedores serviços que
residem fora da plataforma, como um SoR existente. Com essa função, um cliente pode
usar um CloudOE público e:
• Um SoR local - um banco de dados de registros do cliente, por exemplo - pode ser
conectado por meio de um serviço de VPN oferecido pelo provedor de nuvem.
• Uma instância de serviço fornecida pelo usuário é criada para o banco de dados de
registros de clientes. (O proprietário SoR fornece a URL e as credenciais do usuário
nessa fase, bem como quaisquer outros atributos que os aplicativos precisem para
trabalhar com o banco de dados de registros do cliente).
• Os desenvolvedores podem usar as bibliotecas cliente existentes do banco de dados
de registros do cliente ao desenvolver aplicativos. O URL e as credenciais para se
conectar ao banco de dados são fornecidos pelo Cloud Foundry no ambiente do
aplicativo.

Atores e arquitetura SoE

Um SoE é um ecossistema projetado para extensão. Ao contrário de um SoR, não é
uma entidade "totalmente protegida". Um SoR é a implementação direta de um ou mais
processos de negócios que têm um começo, um conjunto de ações, possivelmente
alguns pontos de decisão bem definidos e um fim. Um SoE apoia colaborações entre
atores de negócios. As colaborações são muito mais difíceis de definir do que os
processos de negócios. E as colaborações geralmente evoluem com o tempo, como
qualquer experiência humana. Um SoE deve estar pronto para evoluir; deve ser
construído como uma plataforma de negócios projetada para a evolução e para o
suporte da colaboração entre vários atores.

Usaremos a terminologia usada por Rashik Parmar (Presidente da Academia de

Tecnologia da IBM e Engenheiro Independente da IBM) (em um artigo interno não
publicado chamado "Introdução às Plataformas de Negócios Disruptivos") para definir
os atores de uma plataforma de negócios (ênfase adicionada):

No centro da plataforma estão o proprietário e o provedor da plataforma. Embora estes

possam ser um e o mesmo, a distinção é importante em plataformas de negócios multi-
indústria ou cross-industry. Os complementadores existem para agregar valor à
plataforma e participar da captura de valor dos consumidores. Os fornecedores são
distintos dos complementadores, pois não aprimoram ou fornecem serviços diretamente
aos consumidores. Em vez disso, eles fornecem ferramentas, tecnologias e recursos ao
provedor da plataforma, para permitir que o provedor cumpra suas responsabilidades.
Os consumidores são atraídos para comprar os serviços da plataforma de negócios
devido à diversidade, aos níveis de serviço ou ao baixo custo. O uso de novela também
é incentivado em toda a plataforma de negócios, portanto, por exemplo, os
consumidores podem realizar transações entre si.

A Figura 3 mostra os atores em uma plataforma de negócios e como eles se inter-

relacionam:

Por exemplo, pegue a plataforma iPhone / iTunes da Apple. A Apple é o proprietário da

plataforma e o provedor da plataforma. A FoxConn, fabricante do iPhone, é fornecedora
da Apple, que vende os telefones para os consumidores. Na plataforma, vários
complementadores (outras empresas) vendem música e aplicativos diretamente para os
consumidores, aumentando assim o valor da plataforma.

Plataformas de negócios bem-sucedidas compartilham essas características:

• O ecossistema de complementadores e provedor de plataforma pode resolver um
problema comum para um amplo espectro de consumidores e, assim, tornar a
plataforma financeiramente viável.
• Interfaces que permitem que os complementadores aprimorem a plataforma são
abertos e baseados em padrões para criar confiança no ecossistema.
• A plataforma pode ser facilmente expandida e permite uma evolução sem interrupções.
• A inovação e o uso inovador por parte de complementadores e consumidores são
encorajados.
• Complementadores podem agregar valor e capturar valor através da interface.
• O serviço exclusivo fornecido no núcleo da plataforma é difícil de substituir.
• O ecossistema é estável.

Em essência, uma plataforma de negócios é uma combinação de um provedor de

plataforma de negócios e um ecossistema de complementadores que apoiam uns aos
outros na prestação de serviços a um mercado de consumidores.
Princípios Arquitetônicos

Agora podemos definir os princípios arquitetônicos de uma plataforma SoE:

• Um SoE fornece uma experiência rica que requer serviços de qualidade superior -
especialmente rendimento, escalabilidade e confiabilidade. SoEs são ambientes
especialmente desafiadores para os arquitetos de aplicativos projetarem, porque eles
devem garantir a satisfação de requisitos não funcionais e, ao mesmo tempo, ter
controle limitado sobre a infraestrutura subjacente. (Consulte Tópicos relacionados para
livros e artigos que discutem como os requisitos não funcionais podem ser integrados à
descrição arquitetural de sistemas complexos e intensivos de software.)
• Um SoE é uma plataforma de negócios. Qualquer função disponível deve expor APIs
e ser capaz de ser estendida ou ser sombreada por outra implementação concorrente.
Essas implementações e extensões precisam ser publicadas em um catálogo aberto.
Os complementadores devem poder acessar o conjunto completo de ferramentas
necessárias para adicionar recursos à plataforma em qualquer nível.
• Cloud é a tecnologia básica por trás de um SoE. Além disso, um SoE precisa de outras
tecnologias subjacentes: • Um serviço de mensagens altamente escalável e de alto
desempenho.
• Um adaptador para SoRs externos criado no serviço de mensagens. (Os SoRs sempre
serão os atuadores dos resultados do trabalho, assim como as fontes de dados
estruturados críticos.) Esse adaptador pode precisar de conectores para sistemas
legados e para o catálogo de eventos externos que são significativos para o
engajamento e que podem desencadear o noivado.

• Dado o aspecto sensível dos dados de SoE, a segurança aplicável na nuvem é

necessária para identificação, autorização e privacidade.
• Recursos de dados e análises grandes (incluindo dados e análises sobre as operações
da plataforma em si, como seus principais indicadores de desempenho [KPIs]) devem
estar presentes na plataforma (talvez com mais de uma implementação). Big data virá
de múltiplas fontes que precisam ser interoperáveis, então algum tipo de meta-dados
públicos e mecanismos semânticos também devem estar presentes.
• Mobile é um aspecto fundamental de um SoE. Em todos os lugares, o acesso em
qualquer momento e a conscientização de local podem aumentar o valor de um
compromisso.
• Um SoE é repleto de regras que vão desde preferências pessoais na tomada de
decisões até regras contábeis para o serviço de um complemento. Um sistema de
gerenciamento de regras de negócios é necessário, tanto como um mecanismo de
tempo de execução quanto como um repositório de regras públicas
• Como os SoEs são sobre engajamento humano, o acesso do usuário (o portal) e as
ferramentas sociais (públicas ou específicas da plataforma) são os principais blocos de
construção da solução.

Requisitos adicionais

Alguns requisitos adicionais se aplicam à tecnologia que suporta um SoE:

• Orientação ao serviço no centro: como ecossistemas digitais e plataformas de
negócios, os SoEs têm serviços em seu coração. Esses serviços são leves e baseados
na arquitetura Representational State Transfer (REST). Os SoEs nem seriam
concebíveis sem uma arquitetura orientada a serviços como base.
• Com base nos padrões da indústria: as SOEs são multiactor e plataformas criadas
para o crescimento. Eles não podem prosperar sem fortes padrões comuns.
• Alavancando e estendendo tecnologias de software livre: como os padrões garantem
interoperabilidade real somente após uma longa curva de aprendizado - o SOAP, por
exemplo, levou vários anos para atingir a interoperabilidade total com os perfis WS-I - o
consenso na indústria de TI é que as tecnologias de código aberto podem garantir um
caminho mais rápido e fácil para soluções robustas e interoperáveis.
• Integridade do processo na escala da Internet: ao criar um SoE, você não pode assumir
a proximidade de dados, a resposta garantida ou taxas de solicitação diferentes
daquelas que você pode obter pela Internet - a menos que você possa aplicá-las
explicitamente na prancheta.
• Integração com recursos empresariais e sistemas de back-end: os SoRs estão aqui
para ficar, porque fazem bem o que eles são projetados para fazer (registrar ou impor
um processo). Um SoE provavelmente precisará integrar com um ou mais
(provavelmente mais) SoRs, bem como com os recursos corporativos com os quais a
interface SoRs.
• Fornecer a plataforma para um ecossistema crescente: é da natureza de sua missão
que os SoEs sejam evolutivos. Sua arquitetura consiste nas capacidades expostas dos
subsistemas de propósito geral mais do que nas interações conectadas entre
componentes de propósito especial. Seu design busca riqueza e abertura mais que
elegância e eficiência.

Projetando um SoE

Ao projetar uma solução SoE, como em qualquer tipo de solução, a primeira tarefa é
definir os requisitos da possível experiência do usuário. Os usuários esperam que os
SoEs alavanquem a convergência de acesso móvel, conscientização de localização,
colaboração e exploração de big data para ajudar o ator humano a tomar a melhor
decisão possível por meio de uma avaliação informada das possíveis opções.

O design de uma experiência do usuário que efetivamente apóia as decisões humanas

é um aspecto crucial de um SoE. Essa experiência não pode ser prescritiva e não pode
usar um fluxo ou processo fixo. Deve permitir a correlação de informações diferentes,
variando de simples correlação visual a análises complexas. A experiência é limitada
pelas pequenas telas dos dispositivos móveis e deve incluir suporte para tecnologias de
áudio e vídeo, incluindo reconhecimento de voz.

Discussões adicionais sobre design de experiência estão além do escopo deste artigo.
Continuaremos a nos concentrar nos aspectos mais arquitetônicos de um SoE.

Como já estabelecido, um típico SoE interage com vários SoRs que são os atuadores
do processo de decisão e da própria decisão. Se você considerar o espaço de requisito
típico de um SoR (suponhamos que seja um sistema de suporte a viagens), isso se
traduz em um modelo de caso de uso, como o exemplo da Figura 4:

Figura 4. Um exemplo de modelo de caso de uso para um SoR de suporte a viagens

O modelo de caso de uso na Figura 4 fornece uma boa indicação do processo geral de
negócios para um SoR de suporte a viagens:
1. Identifique-se.
2. Obtenha ingressos ou use seu passe livre.
3. Faça reservas e, se necessário, modifique-as.

Os casos de uso podem ser decompostos para uma granularidade detalhada o

suficiente para identificar as principais funções da futura solução. E os casos de uso
podem ser agrupados em agregações que representam um primeiro corte dos
componentes do futuro sistema.

Agora, considere o outro aspecto do engajamento: como o viajante escolhe quais férias
tomar e como organizá-lo. A figura 5 mostra os fatores que podem influenciar essa
decisão:

Figura 5. Um exemplo de fatores em uma decisão de feriado

Aqui, os casos de uso não dão pistas sobre o processo de tomada de decisão. Pode ser
um processo demorado, de tentativa e erro, que leva dias, ou uma decisão de um
segundo, como "Preciso ir a tal e tal lugar que vi em um filme".

Nesse caso, outras coisas são mais relevantes como requisitos para a solução do que
o próprio processo:
• Informações a serem consideradas (fontes de dados e seus relacionamentos)
• Critérios de decisão, incluindo preferências pessoais
Influenciadores (humanos e não humanos)
• Contexto, incluindo tempo e lugares
• Colaboração entre partes envolvidas

Em suma, o que é relevante é o que alguns frameworks de modelagem (incluindo o

TOGAF / ArchiMate) chamam de modelo de motivação por trás do engajamento.

Depois que os requisitos de motivação são claros, a forma do engajamento pode ser
estabelecida em termos de:
• Funções de negócios a serem fornecidas sobre objetos de informação que afetam a
decisão
• Colaborações entre atores
• Entidades de processo que descrevem a parte do SoRs da solução

A Figura 6 mostra o metamodelo do TOGAF / ArchiMate de uma SOE:

Figura 6. Metamodelo SoE TOGAF / ArchiMate

Como mostra a Figura 6:
• A infraestrutura técnica para um SoE é um CloudOE e um ou mais SoRs.
• O CloudOE é a plataforma que executa as cargas de trabalho do SoE.
• Os serviços são realizados fisicamente por meio de interfaces e aplicativos por meio
de componentes.
• Os componentes implementam um processo de negócios ou uma atividade comercial)
e podem usar outros componentes por meio de suas interfaces, ou funções técnicas por
meio de interfaces técnicas. As funções técnicas, na maior parte, oferecem os recursos
geralmente fornecidos pelos produtos de middleware (por exemplo, um banco de dados
NoSQL).
Exemplo: Um "Turismo no Vale" SoE

Como um exemplo da metodologia que descrevemos, usaremos o caso de uma

plataforma para apoiar e promover o turismo em um vale alpino. Seguiremos este
exemplo desde o modelo de motivação dos stakeholders até a identificação dos serviços
de middleware do CloudOE necessários para suportar o SoE.

A Figura 7 mostra o modelo TOGAF / Archimate da motivação das partes interessadas:

Figura 7. Motivação "Turismo no Vale"

O modelo inclui o ponto de vista da parte interessada principal (o turista) e os objetivos

das outras partes interessadas do domínio: provedores de serviços tais como hotéis,
restaurantes, transporte e eventos (os fornecedores); o escritório de turista de vale (o
dono de plataforma); e fornecedores de aplicativos de valor agregado e formadores de
opinião externos (os complementadores).

Para simplificar a explicação, dividimos o modelo em duas partes: Orientada por turistas
e por outras partes interessadas. Também omitimos a discussão de KPIs e medições
(incluindo requisitos não funcionais), que por si só poderiam ser objeto de um artigo
inteiro.

O turista é influenciado na tomada de decisões por uma série de condutores, incluindo

seus interesses e preferências pessoais, a previsão do tempo e as recompensas de
fidelidade.

O posto de turismo é responsável por promover o vale como destino de férias. Esse
escritório atua por meio de anúncios, incentivos e apoio a eventos locais que são
capazes de atrair clientes para os serviços do vale. As principais exigências do escritório
de turismo são conhecer os resultados dessas ações e reunir as informações
necessárias para melhorar o sistema de negócios do vale - como padrões típicos de
visita (talvez por segmento de mercado) e a atratividade de pontos naturais.

Os prestadores de serviços (hotéis, restaurantes e assim por diante) querem que a

qualidade e o preço de seus serviços se comparem favoravelmente com a concorrência.
Eles também querem combinar suas ofertas com as necessidades e preferências do
cliente - um requisito compartilhado por fornecedores de aplicativos de valor agregado
(que, além disso, devem proteger seu capital intelectual contra o uso não autorizado).

Uma fatia do modelo

Para ajudar a explicar o exemplo, vamos nos concentrar na "fatia" do modelo que inclui
a seleção de serviços que comporão um plano de férias. Não consideraremos todos os
tópicos vinculados ao transporte e à reserva de serviços (que são as áreas mais
vinculadas aos SoRs tradicionais) e acompanharemos a modelagem dos seguintes
requisitos:
• A necessidade de um catálogo de serviços que contenha informações de serviço
(disponibilidade, preço, agendamentos e assim por diante), eventos locais, avisos sobre
incentivos e outros tipos de promoções.
• A necessidade de comparar serviços com base em vários critérios (como preço,
reputação e opiniões confiáveis) e selecionar o melhor ajuste.
• A necessidade de selecionar serviços por sua localização, pela proximidade de outro
local de interesse ou pelo fato de poderem ser vinculados a um evento único ocorrido
no local.
• A necessidade de considerar informações de contexto, principalmente clima. (O
tráfego pode ser outro exemplo).
• A necessidade de gerenciar as preferências do usuário no engajamento (dados mestre
de turista).

Esses requisitos são mostrados no modelo da Figura 8:

Figura 8. Requisitos do turista "Turismo no Vale"

Os requisitos são refletidos nas funções de negócios correspondentes:
• Gerenciamento do catálogo de serviços de negócios pelo provedor da plataforma e
provedores de serviços para manter informações atualizadas sobre hotéis, restaurantes,
eventos, transporte e outros serviços. No mínimo, as informações de serviço devem
incluir quando o serviço está disponível, com quais programações, a que preço. Quanto
melhor as informações fornecidas por um provedor de serviços, maior a probabilidade
de que ele corresponda a algumas preferências do cliente. (Por exemplo, a propaganda
de que o hotel é "amigo da criança" provavelmente atrairá as famílias que viajam com
crianças pequenas.)
• Um recurso de pesquisa e classificação multicritério que usa as informações do
catálogo, além de informações de terceiros, como a reputação do serviço, opiniões
sobre redes sociais, programas de incentivo e recompensas de propriedade do cliente.
A decisão do cliente de comparar as ofertas pode ter origem na exibição de um aviso
externo, como um anúncio.
• A capacidade do cliente de exibir serviços e pontos de interesse naturais em um mapa
on-line para que as decisões possam ser baseadas em localização e distância e
complementar a imagem com informações de contexto, como clima e tráfego.
• A capacidade de alimentar e gerenciar um registro complexo de necessidades e
interesses do cliente (um gerenciador pessoal de dados mestre) que inclui não apenas
compras anteriores e histórico de viagens, mas também fontes confiáveis de opiniões e
outros detalhes pessoais. (Esse tipo de informação altamente sensível pode ser
coletada e usada somente com o conhecimento e a aprovação do cliente, e deve ser
consumida apenas pelo cliente. O benefício que essa informação proporciona ao turista
é substancial, e mecanismos de anonimização podem garantir que o total informações
não podem ser acessadas por outros.)

A Figura 9 mostra a parte do modelo de negócios do Turismo no Vale SoE para atender
às necessidades turísticas:

Figura 9. Modelo de negócio turístico "Turismo no Vale"

Os recursos de negócios devem ser suportados por serviços reais no ambiente de

nuvem SoE. Por sua vez, esses serviços devem ser implementados por componentes
de aplicativos reais fornecidos pelo provedor da plataforma ou por um complemento.
Por exemplo, um complemento pode desenvolver um aplicativo "Localizar ofertas
compatíveis com crianças" no topo das APIs de catálogo da plataforma.

Serviços e aplicativos trabalhando juntos

Agora usaremos uma possível experiência do usuário para mostrar como os serviços e
um aplicativo funcionam juntos. Um aplicativo gerenciador de visualização para o
Turismo no Vale do SoE é um aplicativo da Web no CloudOE e pode ser baixado pelo
turista em uma loja de aplicativos móveis. O gerenciador de visualização interage com
outros componentes do aplicativo para fornecer a experiência completa do SoE:
1. Decido tirar férias e acho que quero visitar o Vale dos Alpes.
2. Eu acho um aplicativo na loja de aplicativos que promete simplesmente toda a
experiência, desde a reserva do hotel até o transporte, até recomendações sobre coisas
para fazer no Vale. Eu vou instalar.
3. Mas eu tenho que registrar: ainda outra conta, outra senha. Não!
4. Mas espere - o aplicativo "Alpine Valley" me permite fazer login via Facebook ou
Twitter. Eu tenho uma conta no Facebook, então eu farei isso. • O aplicativo usa o
serviço CloudOE do gerenciador de identidade e acesso para delegar autenticação ao
Facebook e obter um token do usuário.

5. Eu insiro minhas credenciais no Facebook e agora estou "in" no Vale.

6. O aplicativo usa o serviço de mapa para mostrar uma visão do Vale com os pontos
de interesse relevantes: aldeias e trilhas de montanhas correlacionadas com fotos e
breves resumos.
7. Eu decido que quero ir para lá, então eu digito a data de início e a duração da minha
estadia e deixo o aplicativo decidir algumas alternativas para mim.
8. O aplicativo usa vários serviços para organizar a viagem: • Consulta o serviço
meteorológico para obter informações sobre o tempo para a estadia.
• Consulta o serviço de transporte para encontrar os melhores trens e ônibus.
• Consulta o serviço de hotéis para descobrir os melhores hotéis (um bom compromisso
entre preço e qualidade).
• Consulta o serviço de eventos do vale para organizar minha agenda durante a estadia.

9. Eu recebo três propostas. Eu posso escolher um como está, ou eu posso escolher

um e mudar um pouco.
10. Uau! A proposta principal é um pouco mais cara, mas inclui um hotel que oferece
aulas de culinária com um chef famoso. Minha esposa, que é fanática por boa culinária
(que a análise de SoE descobriu em seu perfil no Facebook), ficará emocionada.
Selecione essa opção e insira minhas informações de pagamento.
11. O aplicativo usa o serviço de pagamento para finalizar o pedido e usa o serviço BPM
para iniciar o fluxo de trabalho da reserva. Esse fluxo de trabalho interage novamente
com os serviços de hotéis, transporte e eventos do vale para finalizar a reserva.
12. Eu recebo um email de confirmação. Posso acompanhar o status da minha
solicitação usando o mesmo aplicativo.
13. O aplicativo usa o serviço MDM para salvar minhas escolhas. Ele usará essas
informações em futuros trabalhos para melhorar minha experiência (e de outros) - por
exemplo, para refinar as três principais propostas ou para notificar somente sobre
eventos nos quais eu possa estar interessado.
A Figura 10 mostra os componentes da aplicação:

Figura 10. Aplicativo SoE "Tourism in the Valley"

Alguns dos componentes de aplicativos exigem serviços de middleware

fornecidos pelos fornecedores de tecnologia.

A Figura 11 mostra o modelo do núcleo inicial do CloudOE para o exemplo:

Figura 11. "Turismo no Vale" CloudOE

• O Catálogo de Serviços contém informações sobre serviços, eventos e incentivos que
serão descobertos por pesquisas. Esse serviço será baseado em um banco de dados
NoSQL com recursos de pesquisa de texto oferecidos pelo CloudOE.
• Como as funções de pesquisa de serviço, comparação e análise de contexto são
baseadas na análise de grandes volumes de dados estruturados e não estruturados,
eles aproveitam o recurso de análise do CloudOE.
• O componente Person MDM para armazenar as preferências do usuário precisa de
uma função MDM correspondente no CloudOE. Ele também precisa de interfaces para
SoRs de rastreamento de vendas e para um serviço de rastreamento de localização que
use a interface GPS do smartphone do turista - para entender tanto as tendências gerais
do movimento turístico quanto as preferências específicas por pessoa.
• O gerenciamento de identidades, o gerenciamento de acesso e o logon único (SSO)
são usados para autenticar o usuário e proteger o acesso a dados confidenciais do
usuário. Esta é uma função do CloudOE que pode usar o MDM da pessoa como um
repositório de ID.
• A visualização inteligente de análises - incluindo a visualização geográfica usando um
aplicativo como o Google Maps - precisa de um servidor de aplicativos com vários
dispositivos para oferecer suporte à rica experiência do usuário em plataformas móveis
e da web.
• Um mecanismo de gerenciador de processos de negócios é necessário para atuar
como uma transação de negócios e gerenciador de compensação para coordenar os
SoRs de transporte e de reserva que são interligados.
• Um recurso de gerenciamento de regras de negócios está no centro do mecanismo de
comparação multicritério. O uso de regras de negócios fornece flexibilidade, o que, por
sua vez, aumenta a flexibilidade na análise do contexto e dos dados de interação
necessários para oferecer suporte a uma rica experiência do cliente.
• É necessário um servidor de mensagens capaz de sustentar o sistema de mensagens
de nível da Internet que inclua dispositivos móveis e da Web para suportar o fluxo de
mensagens interno ao SoE e que ocorre entre o SoE e SoRs.

Alguns desses serviços serão oferecidos em algum lugar no CloudOE por fornecedores
de tecnologia que podem fornecer plataformas altamente escaláveis e altamente
resilientes e soluções de middleware, e os serviços serão acessados remotamente por
meio de suas APIs. Além disso, o CloudOE é a interface para SoRs externos (públicos,
na Internet ou residentes em redes privadas que devem ser acessados por meio de
instalações de VPN). Esses SoRs (como o componente do mecanismo de transporte)
registram as decisões do usuário sobre a viagem e iniciam os processos de negócios
apropriados (como faturamento). O aplicativo pode combinar as informações no
catálogo de serviços e no MDM da pessoa com a localização do GPS. Então, por
exemplo, na hora da refeição, ele pode empurrar para o smartphone do usuário o menu
de um restaurante próximo que serve pratos favoritos do usuário.

Conclusão

Com SoEs, a tecnologia de TI está abrindo uma classe totalmente nova de recursos
para negócios baseados em digital. Esses recursos encontram uma correspondência
natural na infraestrutura de nuvem, mas exigem conceitos de nuvem para alcançar um
nível de implementação do CloudOE que excede os serviços de IaaS aos quais estamos
acostumados hoje.

A modelagem das implementações do SoE e do CloudOE exige um processo de cima

para baixo que comece com as motivações de engajamento e chegue à identificação da
infraestrutura de PaaS necessária para dar suporte ao aplicativo SoE.

Agradecimentos

Agradecemos a Michael Bradley, Martin Gale, Moti Nisenson e Thalia Hooker por muitas
das ideias incluídas neste artigo. Agradecemos a Fabio Benedetti, Arquiteto Líder do
SmartCloud Orchestrator, e a Donald Cronin, CTO da Cloud and Smarter Infrastructure
na IBM, pelo tempo precioso que passaram na revisão e nas sugestões que forneceram.