workshop jun/12 - arquitetura de serviços

www.sensedia.com | 1

[ Empowering Business. Architec5ng IT ]


[ Arquitetura de serviços:

Resolvendo problemas reais ]

&


•  Founded in 2007, as a spin-‐off from Ci&T and Unicamp Innova5on Lab.

•  Headquartered in Campinas, Brazil ü  Offices in São Paulo/BR and Philadelphia/US

•  Consistent growth ü  (63% CAGR 2007-‐2011)

•  Posi5oned as Visionary in the Gartner Magic Quadrant(1)

•  Deep knowledge in SOA Governance, Enterprise Architecture, Public API, Cloud and Integra5on.

Sensedia at a Glance

(1) Magic Quadrant for Integrated SOA Governance Technology Sets, 2009

© 2012 Progress Software Corporation. All rights reserved. 4

§  Headquartered in Bedford, Massachusetts with approximately 1,800 employees worldwide

§  More than 140,000 customers and 2,000 indirect partners in more than 175 countries

§  Publicly traded (NASDAQ: PRGS) with $500M+ revenue

§  BRAZIL

ü  + 4000 Customer

ü  Leader in Capital Markets

ü  30 Reseller/Application Partners

ü  7 SI´s Partners

To simplify and enable the development, management and deployment of business

applications on premises, in any Cloud, on any platform and on any mobile device

Progress Software Corporation

© 2012 Progress Software Corporation. All rights reserved. 5

World-Wide Actional Customers


•  Sobre nós •  Controlando seus serviços, de verdade!

ü  Governança SOA •  Extraindo o máximo dos Middlewares

ü  Potencial VS. uso comum ü  Governança SOA integrada ao Middleware

•  Cenários de mercado •  API Governance

ü  Internet of things ü  Cenários e futuro

•  Encerramento & takeaways

Agenda


Arquitetura de Serviços

[ .... alguns porquês ]


True North com SOA e Cloud

1 2 3 4 5

Agilidade nas manutenções

Flexibilidade das aplicações

Redução de custos e reusabilidade

Alinhamento entre TI e Negócio

Transformação dos negócios


0 Tempo

% C

usto

de

Man

uten

ção

de T

I 100

Custos de Manutenção ao Longo do Tempo

Curto Prazo

Man

uten

ção

Inov

ação

Man

uten

ção

Man

u-

tenç

ão

Inov

ação

Médio Prazo

Longo Prazo

Abordagem Tradicional

Abordagem SOA

A maior parte do orçamento de TI das empresas são gastos para manter as aplicações e integrações em funcionamento. As boas prá5cas, uso de tecnologias modernas, padronização e

reu5lização impacta diretamente na o5mização dos recursos de TI

Agilidade nas manutenções 1


Uma base de a5vos compostos por serviços, componentes, regras e objetos de negócio podem ser refatorados e recombinados para criar, evoluir e

transformar as aplicações da empresa

Disposi6vos Fontes de Dados Usuários

Flexibilidade das aplicações 2


Nível de Reúso

Ativos Reutilizáveis

Aplicações

A 1 2

B 31 4 5

1

5

D 2 73 8

2

3

E 3 5 6

F 1 2 6

8

11 2 3 4

6 75 8

2 3

5 6 8

C 1 65 6

Identificados

Reutilizados

9

Criação e disponibilização de componentes e serviços para a reu5lização cria a massa crí5ca para o aumento da produ5vidade

Redução de custos e reusabilidade 3


Processo de Negócio

Enterprise Services

Customer Relationship Management

Sales and Marketing

Production Planning Manufacturing

Inventory & Logistics Finance & HR

SFA Product LMS

Inv MGMT

B2B product

ERP.

SCM productinfo.

MES

DB ERP CRM

A propagação da base de serviços e o aculturamento SOA na organização cria a sustentação primordial para

a gestão por processos

Alinhamento entre TI e Negócios 4


A exposição de serviços de negócios para o mercado – parceiros, clientes, comunidade de

desenvolvedores independentes (ISV’s) – tem o potencial de transformar os negócios das

empresas

O exemplo acima ilustra o impacto que disponibilização da API de serviços de negócio teve no valor de mercado da NeMlix

(comparando com seu principal compeNdor, a BlockBuster)

Transformação dos Negócios 5

APIs Públicas


Governança SOA

[ Controlando seus serviços de verdade, e sustentando o crescimento com maturidade ]


Leve

“Just Enough Governance” é o principal direcionador ao estabelecer as prá6cas

fundamentais da Governança SOA para gerar valor sem

adicionar overhead

Incremental

Baseado em um Modelo de Maturidade que aproveita as capacidades, conhecimento,

tecnologia e aplicações legadas para acelerar a

adoção SOA

Governança SOA Abordagem Lightweight

Ágil

Projeto com fases curtas usando templates, guias, boas prá6cas e a6vidades

automa6zadas para antecipar beneUcios

tangíveis (“quick wins”)

www.sensedia.com | 16 Single

Applica6on Mul6ple App. (SingleB.U.)

Mul6ple App. (CrossB.U.)

Corporate Level

•  Serviços o6mizados •  Aplicação de regras real6me •  Correções dinâmicas

Serviços Arquitetados

Serviços de negócio

Nível inicial de serviços

•  Núcleo SOA •  Nível inicial de reu6lização

• Metodologia SOA •  Disseminação SOA

•  Know how tecn. básico • MDS convencional •  Padronizações técnicas

2

3

4

5

1 •  Integrações P2P •  Serviços técnicos

•  Definição de papéis •  Apoio execu6vo •  Padrões e processos básicos •  Repositório de serviços •  ESB

• Monitoração de Serviços •  Reuso automa6zado •  Orquestração e coreografia

•  Versionamento de serviços • Medição de performance •  UDDI Operacional •  Reúso corpora6vo

•  KPI’s •  Indicadores de QoS

Serviços monitorados

O6mização de serviços

•  Evolução conlnua •  ROI obje6vo

Agilidade

Flexibilidade

Manutenabilidade


Pacote de definições, processos, guias e boas prá5cas prontos para serem adaptados e u5lizados

Framework SOA Sensedia

SOA Maturity Assessment

Lightweight SOA Governance Best Prac6ccs


Estrutura Flexível de Entregáveis

Exemplo de um processo com atividades,

responsabilidades a templates de artefatos.

Portal que unifica todos os entregáveis:

processos, guias, definições, boas práticas, exemplos, links e também

o acesso ao Repository


Conhecimento dos cenários internos

Conhecimento do acervo

Processo de Governança e Responsabilidades

Ciclo de vida -‐ service lifecycle

Padrões fundamentais

Organização: Comunicação, Competências, Comportamentos e Métricas

Necessidades básicas para Governança SOA


Sobre os beneUcios de SOA para sua empresa [ ] Não sabemos exatamente os benepcios [ ] Conhecemos os benepcios para a equipe de TI [ ] Sabemos os benepcios para a área de Negócios [ ] Sabemos os benepcios e temos um plano de ação

Questão!


Por que eu deveria avaliar o nível de Maturidade SOA?


Gaps e Maturidade

atuais

Benepcios & maturidade

alvo

Roadmap

• Conjunto de ações O que

• Plano detalhado • Visão cronológica

Como e quando

Objetivo estratégico

Estratégia de TI

Objetivos práticos

Agilidade

Controle

Reuso

Padronização

Business GOALs


7 Dimensões Avaliadas

Business

Organiza6on & Governance

Method

Applica6on

Architecture

Informa6on

Infrastructure &

Management


7 Níveis

SOA foundation Levels

1 Silo

2 Integrated

3 Componen6zed

4 Service

5 Composite Services

6 Virtualized Services

7 Dynamically Re-‐Configurable Services Business

Organiza6on & Governance

Method

Applica6on

Architecture

Informa6on

Infrastructure &

Management


OSIMM

Capacidades de negócios são configuráveis

Linhas de Negócio com propósitos isolados

Outsorced BPM & BAM

Serviços de negócio compostos

Negócio fornece e consome serviços

Funções de Negócio Componentizados

Processos de Negócio Integrados

Business

Transformação de TI em uma área estratégica

Estratégias convergentes de TI e Negócio.

Governança SOA com políticas de serviços

Governança da Infraestrutura de TI e de SOA

Governança de TI e SOA alinhados

Processo de Governança comum

Governança SOA nascendo

Org. & Gov.

Transformação de TI em uma área estratégica

Análise e Design estruturado

Modelagem de processos de negócio

Modelagem Orientado à Serviços em Infraestrutura

Modelagem Orientado à Serviços

Desenvolvimento baseado em Componentes

Modelagem Orientado à Serviços

Method

Objetos Módulos Aplicações construídas dinamicamente

Aplicações compostas por serviços

Aplicações compostas por serviços

Componentes Serviços Applica tion

Arquitetura em camadas

Arquitetura Monolítica

Arquitetura Moldável Dinamicamente

Grid em SOA SOA Arquitetura baseada em componentes

SOA nascendo Archite cture

Espec LOB (subárea com dicionário definidos)

Dados específicos de aplicações

Dicionário de dados semântico

Serviços de dados virtualizados

Dicionário de dados corporativo e Repositório

Modelos Canônicos

Informação em Serviços

Informa tion

Padrões corporativos

Plataforma específicas por LOB

Context-awared, Event Based: Sense & Respond

Ambiente SOA virtualizado

Ambiente SOA compartilhado

Infraestrutura comum reutilizável

Projetos baseado em ambiente SOA

Infra. & Manag.

1 2 3 4 5 6 7

Dynamically Re-

Configurable Services

Silo Integrated Componentized

Services Composite Services

Virtualized Services

SOA Foundation Levels

AS IS TO BE Gaps


Resultado: Roadmap

Gaps e Maturidade

atuais

Benepcios & maturidade alvo

Roadmap Frentes /

Atividades

Visão cronológica

Recursos

Plano macro


Radar de maturidade

1

2

3

4

5

6

7 Business

Organization & Governance

Method

Application Architecture

Information

Infrastructure & Management

Radar de Competências

Hoje

Futuro

AS IS

TO BE


Como você sabe quais são seus serviços? [ ] Eu não sei quais são meus serviços [ ] Levantamento de serviços em diversos pontos

(ESB, estações, relatórios de projetos, etc) [ ] Planilha ou outra forma não específica [ ] Repositório de serviços

Questão!


Service Informa5on Model

Asset

version

Artifacts

User’s guide

API docs

Release notes

Samples

...

Asset Types

Components

Services

Applications

Business Process

... Relationship Types

Depends on

Invokes

...

§  Metadata §  Classification

§  Security §  Workflow

§  Collaboration


Visão de negócio e processos

Serviço

Negócio Dados Infraestrutura Integração Utilitário

Classificação de referência para serviços

Suporte técnico

Transferência de dados de

sistemas

Recuperação de dados e entidades

Serviços comuns


Seus serviços tem responsáveis? [ ] Eu não sei quais são meus serviços [ ] Temos a informação de quem criou [ ] Temos a informação de quem criou e quem usa [ ] Sabemos quem criou, quem usou, quem dá

manutenção e o dono atual do serviço

Questão!


Processo de Governança SOA

Requirements and Architecture Specification

Ent

erpr

ise

Arc

hite

ctIC

C C

oord

inat

orIn

tegr

atio

n Le

ader

Clie

nt

No

Yes

FS

FS

Yes

No

Yes

No

IP

FS

Data Integration Layer

Robinson Hotta Version 0.92

IPFS

End

Begins the Requirements and

Architecture Specification

Yes

No

FTP

FTP

AS

Process Integration Layer

No

Adjust Functional Specification and Functional Test

Plan

9 11

Finish filling Integration Plan

Documents validated?

8Validate Functional

Specification and Functional Test

Plan

7

Functional Specification and Test Plan

exists?

5

Notify Problem

6

Run Data x Process

Framework and analyze result

12

Integration Layer?

13

Identify integration scenario in Technology Framework

1415

Found integration scenario?

Yes

Run Technology Framework

20

21Found a coherent result?

Yes

No

Study to find out possibilities of

integration to this scenario

16

Create/Update Architecture of

Scenario

17

Save and register Architecture of

Scenario document

18 19

Update the Technology Framework

template

Analyze Reutilization

REP

22

Can any integration be

reused?

23

Can any integration be

adapted?

24

End

FS

Update Schedule in Integration Plan

30

10

Sign-off meeting and update

Quality Center

Gather Requirements from key users

1

Define Functional Specification and

Test Plan

2

Review Functional Specification and

Test Plan

3

Need more information?

4

No

Yes

31

functional request

Functional request, defect

fix or Scope Change?

defect fix orscope change

Change Management of Project's Scope

The scope is OK?

32

Yes

No

Identify the applicable

scenarios in Data Integration Approach

DIA

No

Create/Update Data Integration

Approach

There is a scenario to be

created or updated?

Yes

DIA

1

1

List Integrations that will be created

List integrations that will be adapted

List integrations that will be reused

Update repository to identify reuse of

integration

Create the new integration in the

repository

28

25

27

LS

26

29

REP

REP

LegendUpdate Integration RepositoryICC Governance Integration RepositoryList Update ICC100 – List of DemandsFS ICC005 – Integration PlanIPICC010 – Functional

Specification of IntegrationClient FTP Functional Test Plan ICC020 – Architecture of Scenario

AS REPDIA Data Integration Approach

33

34

35


Matriz de Responsabilidades (RACI)

Activity / Decision (R)esponsible (A)ccountable (C)onsulted (I)Nformed

Identificar Serviços do Projeto

Business Analyst, SOA Architect

Project Sponsor Repository Manager

SOA CoE

É possível reutilizar serviços existentes ou é um novo serviço?

Repository Manager, SOA Architect

SOA Project Sponsor

… …

Serviço corporativo ou específico do projeto?

… … … …

Quem será o dono do serviço?

… … … …

Quem pagará pelo desenv. / manutenção do serviço?

IT Budget Committee

… … …

Existem requisitos não funcionais especiais?

Secutiry Expert, Database Expert, Operation Manager

Enterprise Architect

Service Owner, Project Sponsor

…


Como você controla o ciclo de vida? [ ] Eu não sei quais são meus serviços [ ] Não existe o conceito de status dos serviços, ou ele existe,

ou não existe. [ ] Não acompanhamos o ciclo de vida dos serviços, sabemos

apenas quando iden5ficados e publicados [ ] Possuimos um acompanhamento através de workflow ou

ferramenta específica

Questão!


Services Life Cycle

Identificado Em modelagem

Em construção

Descontinuado

aprovar

Recusado

recusar

submeter

remodelar

construir

evoluir

descon5nuar excluir

excluir

Sistema

Disponível

Cadastrar

Barramento Em Implantação

disponbilizar

implantar

disponbilizar


Responsabilidades

Ponto de controle

Reponsável Validações Material de apoio

Validar serviços Arquiteto SOA Núcleo SOA

•  Contrato de serviços •  Cadatro no repositório

•  Guia de identificação •  Padrões de elegibilidade de serviços •  Repositório de serviço

Validar modelagem

Arquiteto SOA •  Design de serviço •  Guia de modelagem •  Arquitetura de referência

Validar implantação

Project Owner Núcleo SOA

•  Serviço •  Design de serviço •  Teste de serviços

•  Mecanismo de teste •  Serviço implementado •  Repositório de serviço

Extrair Métricas Núcleo SOA •  ROI •  Reuso •  RCA

•  Documento de Métricas Quantitativas de SOA

Pontos de controle


Existem padrões e boas prá6cas para construção de serviços? [ ] Eu não sei se construímos serviços [ ] Não existem boas prá5cas, depende do fornecedor [ ] Existem boas prá5cas para implementação de projetos,

nada específico para serviços [ ] Existem boas prá5cas para serviços (segurança,

escalabilidade, testes, etc).

Questão!


Arquitetura Corpora6va •  Componentes arquiteturais para

serviços: ü  Barramento ESB ü  Repositório de Serviços ü  Framework de invocação de

serviços

Arquitetura de Sistema •  Visão Arquitetural com a camada

de serviços •  Mecanismos Arquiteturais

exclusivos para SOA: ü  Testes ü  Segurança ü  Interoperabilidade

Padrões Fundamentais x Arquitetura


•  A5vidades principais: ü  Iden5ficação de serviços; ü  Modelagem de serviços; ü  Catalogação dos serviços; ü  Deploy de serviços

•  Guias e Templates prá5cos: ü  Guia para Iden5ficação de serviços

(harves5ng em novos projetos ou em legados) ü  Templates e Guias para Interface e Design de serviços ü  Guia para Catalogação de serviços ü  Padrão para Versionamento de serviços

Padrões Fundamentais x Metodologia


Que 6po de métricas são extraídas dos seus serviços? [ ] Eu nem sei quais são meu serviços [ ] Eu sei quais são, mas não medimos nada [ ] Métricas quan5ta5vas (numero de serviços) [ ] Métricas qualita5vas (volume de chamadas, quan5dades de reúso por projeto, ROI, etc)

Questão!


•  Tipos de métricas para Projetos SOA: ü Métricas de gerência de projeto

ü Métricas Econômicas

ü Estavs5cas de desenv. e reu5lização de serviços

Métricas You can't Manage what

you don't Measure

5


Comportamento

•  Definir incen5vos, reconhecimento e penalidades

•  Reduzir ao máximo os “desincen5vos”

•  Premiar o comportamento “SOA oriented”

•  Garan5r “funding” preferencial a projetos SOA


•  Design Time: –  Foco em usabilidade, produ5vidade, controle, ...

ü Modelagem de Negócio: BPM (BPMN, ...) ü Catálogo de A5vos Reu5lizáveis

•  Run Time: –  Foco em robustez, escalabilidade, ...

ü Container de WebServices ü ESB: Enterprise Service Bus ü Registro de localização de Serviços e Aplicações de Policies de Governança

ü BAM: Monitoramento de A5vidade de Negócio

Quais Classes de Ferramentas estão relacionadas a SOA?

O que vemos por aí


Como você faz análise de impacto em situações de manutenção de serviços? [ ] Eu não sei quais são meus serviços [ ] Análise de impacto não é feita [ ] Análise de impacto feita caso a caso (e de acordo com informações disponíveis) [ ] Possuímos informações de rastreabilidade dos serviços, para realização de análise de impacto

Questão!


Middleware de integração

[ Uma visão simplória vs. Potencial de ganho ]


Abordagem Tradicional

Conexões Ponto-‐a-‐Ponto

ERP Aplicação .NET

WebService (Externo)

Aplicação JEE

Legacy (C/C++)

Mainframe (CICS Transaction

Gateway)

Pacote CRM (proprietário)

Custom point-to-point connections


ERP Aplicação .NET

WebService (Externo)

ESB

Enterprise Service Bus

JCA

JMS SOAP/ HTTP

SOAP/ HTTP

SOAP/ HTTP

SOAP/ HTTP

JCA

Aplicação JEE

Legacy (C/C++)

Mainframe (CICS Transaction

Gateway)

Pacote CRM (proprietário)


ESB Principais funcionalidades

Transformação de

Mensagem

Roteamento de

Mensagem

Transparência de Localização

Conversão de Protocolo

de Transporte

Enriquecimento de Mensagem

Segurança

Monitoria

Capacidade de adicionar informação faltante a uma mensagem, baseando-‐se em seus dados

Transformação de mensagens de um formato para outro, baseado em padrões abertos como.

Capacidade de rotear uma mensagem de entrada ao seu des5no final

Auten5car, autorizar e criptografar mensagens de entrada e saída, sa5sfazendo requisitos de segurança dos serviços.

Capacidade de gerenciar performance e confiabilidade, assim como monitorar o fluxo e execução de mensagens.

Capacidade de integrar aplicações com protocolos de transporte diferentes.

Desacoplamento da localização de um serviço, onde o consumidor doserviço não sabe onde fica o provedor deste serviço.


Transformação de Mensagem

Roteamento de Mensagem

Transparência de Localização

Conversão de Protocolo de Transporte

Enriquecimento de

Mensagem

Segurança

Monitoria

Proxy ?????

Equipes, fornecedores,

prazos, padrões, direcionamentos,

falta de foco, patrocínio...


Como sua empresa usa o Middleware? [ ] Não temos middleware SOA [ ] Não sei se temos serviços [ ] Usamos como proxy [ ] Usamos o middleware para fazer monitoramento, ou

segurança, ou conversão de protocolos.

Questão!


Arquitetura Tradicional

Muito difícil de entender, manter e evoluir


Vocês conhecem o Arquiteto??


Como diminuir a complexidade?


Barramento de serviços

ESB



ESB


ESB

Não basta centralizar. É preciso ter controle! E boas prá6cas...


ü  Gestão dos Serviços ü  Controle do ciclo de vida ü  Relatórios e métricas ü  Promoção de prá5cas de

reu5lização

Registry / Repository


Governança dos serviços?

Quais são meus

serviços?

Como fazer análise de impacto? Reuso e

outros ROIs

Mapeamento de responsabilidades


SOA Governance

ESB

Service Repository


Mas, como isso funciona?

GOVERNANÇA INTEGRADA


Governança SOA: •  Repositório de Metadados para

componentes, serviços, sistemas, integrações e processos de negócio

•  Polí5cas e Processos •  Métricas obje5vas e relatórios

customizáveis •  Controle de ciclo de vida

dos a5vos •  Colaboração •  Promoção de prá5cas de

reu5lização

Sensedia Repository


SOA Registry/Repository

Ambientes de Desenvolvimento:

Arquitetura Aberta

Ampla Compa6bilidade:

•  Gestão de componentes de souware, serviços, integrações etc.

•  Modelo extensível de metadados

•  Indexação e Busca o6mizados •  Mecanismos inovadores de

colaboração •  Relatórios, estals6cas e

métricas de ROI •  Análise de impacto visual

•  Workflow flexível de aprovação

•  Iden6ficação automá6ca de serviços e componentes

•  Análise de qualidade arquitetural


Valor adicionado •  Carga no Repository dos serviços descobertos

automa5camente •  Iden5ficação de não-‐conformidades nos serviços

implantados •  Visualização de informações detalhadas dos serviços

ü Métricas de Run-‐5me ü Meta informação sobre serviços (ownership, classificação, custo, etc.)

ü Detalhes das polí5cas de segurança •  Controle de quem está usando os serviços para

melhor planejar a u5lização das capacidades •  Receba alertas quando modificações são feitas nos

seus serviços


Modelo de integração

Agente

Sensedia Repository ESBBridge

Implementação

Impl

Implementação

ESBs

Sen

sedi

a R

epos

itory


Monitoring Entities: •  Nodes: infos como IP, sistema operacional, specs, porta e nome dos app containers, etc. •  Pacotes: apps corporativas, com nome, url/context-root, etc •  Serviços: incluindo qualquer protocolo (soap/http, rmi, ejb, etc) e seus contratos (WSDL no caso de webservices) •  Operações: obtidas a partir do WSDL, por exemplo.

Governance Server

Integration Plugin

Nodes • IP • S.O. • Specs • App containers •  watchdogs

Services • Protocol • Contract • Operations


Assets findability

•  Get to know the assets you already have •  Promote the reuse of the right assets

Life

cycl

e

man

agem

ent

•  Validations steps throughout the development lifecycle

•  Get assets information delivered to the development and the architectural teams •  Better understanding on your services, components, processes, systems, schemas and how they relate to each other


Interações do Sensedia Repository

Custom integrations using the common interfaces toolkit

Users Authentication

LDAP directories

Active Directory

3

3

Asset Production And Consumption

3 Eclipse Platform

3 IBM Rational RSA/RSM

3 MS VisualStudio

3 Oracle JDeveloper

Service Runtime Environment

3 UDDIs

3 ESBs

Actional

Source Code Management

IBM Rational ClearCase

CVS/Subversion

3

3 SOA Assets Management

Metadata Searches Reuse Metrics

Promotion Collaboration Workflow

Products Architecture: Java Server Faces

WebServices / SOAP

JDBC, XML


Modelo de informação

Ativo versão

Artefatos

Guia do usuário

API docs

Release notes

Exemplos

...

Tipos de ativos

Componentes

Serviços

Aplicações

Proc. de negócio

... Tipos de relacionamentos

Depende de

Invoca

...

§  Metadados §  Classificação

§  Segurança §  Ciclo de vida §  Colaboração

(fóruns, feeds, alertas, etc.)


Cenários reais de mercado

[ Planos executados ]


Três cenários comuns

Controle de serviços no mundo corpora5vo

Tenho serviços, boa parte fora do barramento 1

Tenho serviços, estão no barramento 2

Eu não sei o que tenho, (barramento vazio) 3


Cenário •  Diversos serviços técnicos já disponibilizados no barramento

•  Muitos serviços acessados P2P •  Sem definições de governança •  Sistemas “soltos” em planilhas ou nem controlados

•  Necessidade de controle dos a5vos da arquitetura

Caso 1 Nem todos os serviços no barramento 1

Empresa de logísNca


Plano

Caso 1 Nem todos os serviços no barramento 1 1-‐ Implantação do repositório de serviços integrado ao ESB

2 -‐ Definição de taxonomia e configuração do repositório.

3 -‐ Importação dos serviços do barramento para o repositório

4 -‐ Saneamento de serviços e sistemas “soltos” dentro do repositório

5 -‐ Treinamento e operação da ferramenta


Resultado •  Serviços importados no repositório, através da integração

com o repositório •  Serviços levantados nas áreas e cadastrados no

repositório •  Sistemas controlados no repositório •  Aplicação de taxonomia aos serviços e rastreabilidade •  Geração de relatórios direcionados à análise de impacto •  Plano de inserção de serviços no ESB. •  Geração de base de serviço consolidada, com diversos

a5vos relacionados (sistemas, componentes, jobs, etc)

Caso 1 Nem todos os serviços no barramento 1


Cenário •  Empresa com grande experiência no

desenvolvimento de serviços •  Usuária do Oracle SOA Suite •  Todos os serviços publicadas no ESB •  Sabia-‐se do volume dos serviços, mas sem outras

informações para gestão e controle •  Falta de visibilidade dos serviços , com margem de

reuso baixa •  Análise de impacto sendo realizada de maneira

manual

Caso 2 Serviços con5dos no barramento 2

Empresa de serviços


Plano


1-‐ Implantação do Repositório, integrado ao ESB

2 – Sincronização de serviços do barramento e customizações para integração com outras ferramentas

3 -‐ Priorização de valor e Saneamento de serviços

4 -‐Definição de padrões de governança

5 -‐ Gestão do repositório e acompanhamento de projetos


Resultados •  Repositório integrado ao ESB •  Repositório integrado ao processo de

desenvolvimento •  100% dos serviços catalogados (150+) •  Portal de governança gerado

ü Ciclo de vida de serviço ü Perfis e responsabilidades ü Relatórios de ROI

•  Ferramenta operacional disponível para as fábricas



Cenário •  Diversos serviços P2P, desconhecidos •  Barramento selecionado para implantação, mas não

operacional •  Necessidade imediata de controle centralizado dos

serviços existentes •  Apenas determinados fornecedores conheciam os

serviços •  Empresa recentemente adquirida, com necessidade

latente de integração com “legados de terceiros”

Caso 3 Barramento vazio 3

Empresa de cartões


Plano


1-‐ Implantação do repositório e configuração

2 -‐ Definição de padrões de classificação de serviços

3 -‐ Harves5ng de serviços e Importação no repositório

4 -‐ Definição de plano de atuação do repositório no processo de desenvolvimento

5 – Migração dos serviços para o Barramento


Resultado •  Portal de governança disponibilizado com

ü Taxonomia de a5vos ü Ciclo de vida e pontos de controle ü Perfis e responsabilidades

•  Configuração de taxonomia, ciclo de vida e perfis no repositório

•  Mais de 200 serviços levantados e catalogados em um mês

•  Repositório populado e integrado ao barramento, com plano de migração de serviços para o ESB.



O que estes cenários tem em comum?

Tenho serviços, boa parte fora do barramento 1

Tenho serviços, estão no barramento 2

Eu não sei o que tenho 3


O que estes cenários tem em comum?

1 2 3 a)  Barramento de serviços b)  Serviços desgovernados c)  Necessidade de controle d)  Agilidade na abordagem


A decisão foi trocar o pneu com o carro andando...


Alguns inves5mentos em padronização


Integrar às definições de governança


Começar Pequeno

Avançar Rápido


Acompanhamento no dia-‐a-‐dia (mentoring)


Com esse direcionamento...


Aceleração do ROI

ROI


Organização e controle dos serviços.

Não podemos perder mais oportunidades de reuso!


Mais fácil de construir

Mais fácil de manter


Pense bem o seu próximo

passo!


Public API

[ Are you ready for an interconnected World? ]


The Internet of Things

Cloud


2003 2010 2015 2020

By 2020 there will be 7,5 billion People on earth and 50 billion Things connected

Almost all electronic devices will be connected to the Internet

The Internet of Things

During 2008, the number of Things connected to the Internet exceeded the number of People on earth

=

People on earth Connected Things


Hype Cycle for Emerging Technologies


APPs Applica5on So�ware

APIs Applica5on Programming

Interface

APPs = People Interaction APIs = Things Interaction


APIs =

Social

Mobile Cloud

Business capabili5es exposed over the internet for applica5ons to use

How connected the Mega-‐Trends are?

APIs = Amplified Reach

Data services with a cri5cal mass of users

Pervasive presence with limited storage and processing

Modern approach to reach your customers

"Make you API useful and it will be carried to customers you've never met"


•  Make Money ü  60% of all lis5ngs on eBay.com added via their APIs

(expanding channels, more sales, more adver5sing)

•  Save Money ü  SmugMug saves > $500K/year with Amazon S3 Storage

•  Brand Building ü  Google Maps 300% growth vs. 20% MapQuest ü  Twi�er strong applica5on ecosystem

•  Move to the Cloud ü  Over 50% of all salesforce.com transac5ons via their API ü  Companies exposing legacy data as API through the cloud

•  Go Anywhere ü  Ne�lix now available on over 200 devices

Why Companies are using APIs?


API Growth Rate

Based on directory of 6,000 web APIs listed at ProgrammableWeb, May 2012


API Billionaires Club

1.1 billion API calls / day (April 2011)

1.4 billion API calls / day (May 2012)

1 billion API calls / day (May 2012)

1 billion API calls / day (Q1 2012)

1 billion API calls / day (January 2012)

13 billion API calls / day (May 2011) Approx. 75% of all traffic via API

5 billion API calls / day (October 2009)

5 billion API calls / day (April 2010)

Source: ProgrammableWeb Founder John Musser’s

905 billion S3 objects (+ 1 billion / day)


API Billionaires Club

1.1 billion API calls / day (April 2011)

1.4 billion API calls / day (May 2012)

1 billion API calls / day (May 2012)

1 billion API calls / day (Q1 2012)

1 billion API calls / day (January 2012)

13 billion API calls / day (May 2011) Approx. 75% of all traffic via API

5 billion API calls / day (October 2009)

5 billion API calls / day (April 2010)


905 billion S3 objects (+ 1 billion / day)


Ne�lix Business Transforma5on

The impact that NeMlix business service API availability had over its market value

(compared to NeMlix main compeNtor, BlockBuster)


h�p://developer.ne�lix.com


Twi�er Ecosystem = Amplified Reach


h�p://developers.facebook.com/


h�p://developer.a�.com


h�ps://bluevia.com/en/knowledge/APIs


h�p://www.twilio.com/api


https://developer.v.me/


h�ps://developer.paypal.com/


h�p://developer.ny5mes.com/


h�p://developer.ebay.com/


Local Early Adopters (?)

It doesn’t seem so yet! Web services enabled Not truly scalable Not truly managed No engaged community (partners)


API Business Models, by 2012



Tech Stuff •  Some Best Prac5ces:

ü Define scope and value ü Design it simple and documented

ü Run it secure, robust and managed

ü Promote it audience adop5on and engagement

ü Support: community and channels

•  Some Tips: ü REST first ü Keep responses small ü Keep calls granular ü For security use OAuth (not custom)

ü Sample code to foster adop5on

ü Be prepared for change


What about:

developer.[you].com

?


Ques6onário

[ Arquitetura de serviços ]


0

6

4

3

0

1

2

3

4

5

6

7

Não sabemos exatamente os

benefícios

Conhecemos os benefícios para a

equipe de TI

Sabemos os benefícios para a área de Negócios

Sabemos os benefícios e temos um plano de ação

1. Sobre os benefícios de SOA para sua empresa

1

6

4

1

0 1 2 3 4 5 6 7

Eu não sei quais são meus serviços

Levantamento de serviços em

diversos pontos (ESB, desktops,

relatórios de projetos, etc)

Planilha ou outra forma não específica

Repositório de serviços

2. Como você sabe quais são seus serviços?


1

5

2

1

0

1

2

3

4

5

6


Temos a informação de quem criou

Temos a informação de quem criou e

quem usa

Sabemos quem criou, quem usou,

quem dá manutenção e o dono atual do

serviço

3. Seus serviços têm responsáveis?

1 1

4

3

0 0,5

1 1,5

2 2,5

3 3,5

4 4,5


Não existe o conceito de status dos serviços, ou

ele existe, ou não existe.

Não acompanhamos o ciclo de vida dos

serviços, sabemos apenas quando identificados e

publicados

Possuímos um acompanhamento

através de workflow ou ferramenta específica

4. Como você controla o ciclo de vida?


0 1

2

6

0 1 2 3 4 5 6 7

Eu não sei se construímos

serviços

Não existem boas práticas, depende

do fornecedor

Existem boas práticas para

implementação de projetos, nada específico para

serviços

Existem boas práticas para

serviços (segurança,

escalabilidade, testes, etc).

5. Existem padrões e boas práticas para construção de serviços

1 2

6

0 0 1 2 3 4 5 6 7

Eu nem sei quais são meu serviços

Eu sei quais são, mas não medimos

nada

Métricas quantitativas (numero de

serviços)

Métricas qualitativas (volume

de chamadas, quantidades de

reúso por projeto, ROI, etc)

6. Que tipo de métricas são extraídas dos seus serviços?


1 0

8

0 0 1 2 3 4 5 6 7 8 9


Análise de impacto não é feita, os

serviços não sofrem manutenção controlada

Análise de impacto feita caso a caso (e

de acordo com informações disponíveis)

Possuímos informações de

rastreabilidade dos serviços, para realização de

análise de impacto

7. Como você faz análise de impacto em situações de manutenção de serviços?

1 0

8

3

0 1 2 3 4 5 6 7 8 9

Não temos middleware SOA

Não sei se temos serviços

Usamos como proxy

Usamos o middleware para

fazer monitoramento, ou

segurança, ou conversão de

protocolos.

8. Como sua empresa usa o Middleware?


•  Você controla seus serviços de verdade?

•  Você extrai o máximo de seu middleware?

•  Você vai precisar de API Governance!

Takeaways


&Entre em contato com a Sensedia: Marcilio Oliveira – COO [email protected] José Vahl Jr. – Gerente de Tecnologia [email protected] Adilson CavaN – Gerente de Negócios [email protected] [email protected] sensedia.com/br (19) 3705-‐5775

workshop jun/12 - arquitetura de serviços

Business

componentes e servios

evoluir e transformar

regras e objetos

criao e disponibilizao

true north com soa e

papis servios arquitetados

servios qos medio

servios o6mizados o6mizao