UNIVERSIDADE ANHEMBI MORUMBI
ANDRÉ LUÍS JOST SOUTO
ELAINE MANHÃES DA SILVA
TATIANA FERREIRA PEREIRA ALVES
AVALIAÇÃO DE NÍVEIS DE MATURIDADE SOA
SÃO PAULO
2010
ANDRÉ LUÍS JOST SOUTO
ELAINE MANHÃES DA SILVA
TATIANA FERREIRA PEREIRA ALVES
AVALIAÇÃO DE NÍVEIS DE MATURIDADE SOA
Trabalho de Conclusão de Curso apresentado como
exigência parcial para a obtenção de título de
Bacharel
em
Sistemas
da
Informação
pela
Universidade Anhembi Morumbi, sob a orientação
do Professor Marcelo Couto.
SÃO PAULO
2010
S71a
Souto, André Luís Jost
Avaliação de níveis de maturidade SOA / André Luís Jost
Souto, Elaine Manhães da Silva, Tatiana Ferreira Pereira
Alves. – 2010.
60f.: il.; 30 cm.
Orientador: Marcelo A. Couto de Jesus.
Trabalho de Conclusão de Curso (Graduação em Sistemas
de Informação) – Universidade Anhembi Morumbi, São Paulo,
2010.
Bibliografia: f. 57 – 58
1. Sistemas de informação. 2. Gestão por processos.
I. Título.
CDD 658.4038
ANDRÉ LUÍS JOST SOUTO
ELAINE MANHÃES DA SILVA
TATIANA FERREIRA PEREIRA ALVES
AVALIAÇÃO DE NÍVEIS DE MATURIDADE SOA
Trabalho de Conclusão de Curso apresentado como
exigência parcial para a obtenção de título de
Bacharel
em
Sistemas
da
Universidade Anhembi Morumbi.
Aprovado em:
Prof.
Universidade Anhembi Morumbi
Prof.
Universidade Anhembi Morumbi
Prof.
Universidade Anhembi Morumbi
SÃO PAULO
2010
Informação
pela
AGRADECIMENTOS
Agradecemos a Deus, aos nossos familiares, cônjuges, professores e funcionários da
universidade, em especial aos nossos orientadores que nos apoiaram com seu esforço e
conhecimento durante essa jornada.
Dedico este trabalho aos meus pais, minha irmã, minha família, amigos e minha
namorada Priscilla.
Dedico também este trabalho aos meus colegas de trabalho que sempre me apoiaram
e foram compreensivos e pacientes.
Aos meus companheiros de Equipe, Elaine e Tatiana, pela dedicação, esforço,
compreensão e força de vontade durante a realização do trabalho.
André
Dedico este trabalho aos meus amigos, André e Tatiana, pelo companheirismo e
paciência os quais foram essenciais para finalização deste trabalho.
Elaine
Dedico este trabalho à minha Família, pelo apoio e incentivo.
Em especial, à meu Pai Dubá(in memorian) e ao meu Esposo Osni Jr., pessoas que
sempre serão meu exemplo de caráter, superação e sucesso. Sem eles, a realização deste não
seria possível.
Aos meus companheiros de Equipe, André e Elaine, pela dedicação, esforço,
compreensão e força de vontade durante a realização do trabalho.
Aos motivadores, Layla (in memorian) que me ensinou lutar até o fim e ao Byte que
me ensinou que a vida continua apesar das perdas durante a nossa jornada!!!
Tatiana
Enfim, à todos aqueles que, direta ou indiretamente, colaboraram para que este
trabalho consiga atingir aos objetivos propostos.
André, Elaine e Tatiana
RESUMO
Atualmente, empresas que operam por processos almejam uma integração e abstração dos
sistemas cada vez maior onde a tecnologia deve trabalhar de forma independente dos
processos. O presente trabalho tem por objetivo a formalização do estudo da Análise dos
Níveis de Maturidade SOA (Service Oriented Architecture) e a contextualização deste estudo
é baseada no modelo OSIMM (The Open Group Service Integration Maturity Model), criado
por um consórcio de empresas, o Open Group, o qual independe de fornecedor e de
tecnologia. O produto final deste trabalho será uma matriz de ações versus níveis de
maturidade a qual ilustra o estudo, evidenciando que uma empresa pode estar em diferentes
níveis de maturidade nas diferentes dimensões e exige uma forte sinergia de toda a corporação
e seus parceiros com objetivo de atingir o mais alto nível de maturidade (o nível sete –
Serviços Dinamicamente Reconfiguráveis).
Palavras-chave: SOA. BPM. Processos. Arquitetura Orientada a Serviços. Gestão por
Processos. OSIMM. The Open Group.
ABSTRACT
Nowadays, companies that operate through processes seek an integration and abstraction from
their systems everyday higher where technology should work independently from the
processes. The present paper aims to formalize the study of the SOA (Service Oriented
Architecture) Maturity Levels and its context will be based on the OSIMM (The Open Group
Service Integration Maturity Model) model, created by a consortium of companies which is
vendor and technology independent. The final product of this paper is a matrix of Actions
versus Maturity Levels which illustrates the study, showing that a company can be in different
maturity levels for different dimensions which demand a strong synergy from the entire
corporation and its partners focusing to reach the highest maturity level (level seven –
Dynamically Reconfigurable Services).
Keywords: SOA. BPM. Processes. Service Oriented Architecture. Process Management.
OSIMM. The Open Group.
LISTA DE ILUSTRAÇÕES
Figura 1: Diferenças entre a abordagem por processos e a abordagem por departamentos. .... 18
Figura 2: Exemplo de BAM com seus indicadores. ................................................................. 23
Figura 3: Matriz OSIMM de maturidade para SOA ................................................................. 29
Figura 4: Matriz OSIMM – Dimensão de Visão de Negócio ................................................... 37
Figura 5: Matriz OSIMM – Dimensão de Organização e Governança .................................... 40
Figura 6: Matriz OSIMM – Dimensão de Métodos ................................................................. 43
Figura 7: Matriz OSIMM – Dimensão de Aplicação ............................................................... 45
Figura 8: Matriz OSIMM – Dimensão de Arquitetura ............................................................. 47
Figura 9: Matriz OSIMM – Dimensão de Informação ............................................................. 50
Figura 10: Matriz OSIMM – Dimensão de Infraestrutura & Gerenciamento .......................... 53
LISTA DE TABELAS
Tabela 1: Indicador de Maturidade – Visão do Negócio .......................................................... 33
Tabela 2: Descrição básica da dimensão de Visão do Negócio ............................................... 34
Tabela 3: Atributos de Maturidade – Visão do Negócio .......................................................... 35
Tabela 4: Matriz de Ações – Dimensão de Visão de Negócio ................................................. 37
Tabela 5: Matriz de Ações – Dimensão de Organização e Governança .................................. 40
Tabela 6: Matriz de Ações – Dimensão de Métodos ................................................................ 43
Tabela 7: Matriz de Ações – Dimensão de Aplicação.............................................................. 45
Tabela 8: Matriz de Ações – Dimensão de Arquitetura ........................................................... 48
Tabela 9: Matriz de Ações – Dimensão de Informação ........................................................... 50
Tabela 10: Matriz de Ações – Dimensão de Infraestrutura & Gerenciamento ........................ 53
LISTA DE ABREVIATURAS E SIGLAS
AD
Active Directory
BAM
Business Activity Monitoring
BI
Business Inteligence
BPEL
Business Process Execution Language
BPM
Business Process Management
BPMN
Business Process Modeling Notation
BPMS
Business Process Management Systems
ESB
Enterprise Service Bus
ITIL
Information Technology Infrastructure Library
LDAP
Lightweight Directory Access Protocol
KPI
Key Performance Indicator
OGC
Office of Government and Commerce
OLAP
Online Analytical Process
OSIMM
Open Group Service Integration Maturity Model
SLA
Service Level Agreement
SOA
Service Oriented Architecture
TI
Tecnologia da Informação
XML
Extensible Markup Language
LDAP
Lightweight Directory Access Protocol
SUMÁRIO
1 INTRODUÇÃO ..................................................................................................................... 14
1.1 Objetivo .............................................................................................................................. 14
1.2 Abrangência ........................................................................................................................ 14
1.3 Justificativa ......................................................................................................................... 15
1.4 Estrutura do Trabalho ......................................................................................................... 15
2 SERVIÇOS E A IMPORTÂNCIA NA ECONOMIA MUNDIAL ...................................... 16
2.1 A Gestão de Serviços em TI ............................................................................................... 16
3 PROCESSOS ......................................................................................................................... 18
3.1 BPM – Business Process Management .............................................................................. 19
3.2 TI na Modelagem e Gestão de Processos ........................................................................... 20
3.3 Ferramentas de BPMS ........................................................................................................ 20
3.4 BAM – Business Activity Monitoring................................................................................. 23
4 SOA – ARQUITETURA ORIENTADA A SERVIÇOS ...................................................... 25
5 MATURIDADE .................................................................................................................... 28
5.1 OSIMM ............................................................................................................................... 28
6 METODOLOGIA.................................................................................................................. 33
6.1 Interpretação das dimensões ............................................................................................... 33
6.2 Característica básica de cada nível de maturidade da dimensão ........................................ 34
6.3 Construção dos atributos. ................................................................................................... 35
6.4 Classificação dos atributos do OSIMM .............................................................................. 35
7 DESENVOLVIMENTO........................................................................................................ 37
7.1 Dimensão de Visão de Negócio.......................................................................................... 37
7.2 Dimensão Organização e Governança ................................................................................ 39
7.3 Dimensão de Métodos ........................................................................................................ 42
7.4 Dimensão de Aplicação ...................................................................................................... 44
7.5 Dimensão de Arquitetura .................................................................................................... 47
7.6 Dimensão de Informação .................................................................................................... 50
7.7 Dimensão de Infraestrutura & Gerenciamento ................................................................... 53
8 CONCLUSÃO ....................................................................................................................... 56
8.1 Trabalhos Futuros ............................................................................................................... 56
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 57
GLOSSÁRIO ............................................................................................................................ 59
ANEXO A – FIGURAS AMPLIADAS ................................................................................... 61
14
1 INTRODUÇÃO
SOA (Service Orienteted Architecture) propõe agilidade, facilidade e eficiência na
adaptação às necessidades de mudanças de negócios nas Organizações. SOA está relacionada
com processos e a sua gestão BPM (Business Process Management). BPM tem como
premissa incentivar uma empresa a repensar sobre seus processos de negócios visando maior
aderência com TI (Tecnologia da Informação).
Em artigo publicado pelo Gartner Group intitulado “The 13 Most Common SOA
Mistakes and How to Avoid Them” (GARTNER, 2009a), os benefícios do SOA são
extremamente atraentes e são a razão fundamental pela qual as empresas começam tais
projetos. Entretanto, para que um projeto SOA atinja os benefícios esperados é necessário
esforço e foco da organização na fase de arquitetura do projeto com atenção especial para
medir os seus benefícios.
1.1 Objetivo
O objetivo é a análise do Modelo de Maturidade OSIMM (The Open Group Service
Integration Maturity Model) proposto pelo Open Group (OPEN GROUP, 2009) com a
intenção de criar uma Matriz para o mapeamento dos Níveis de Maturidade SOA e o caminho
que uma organização deverá seguir para atingir a maturidade desejada.
1.2 Abrangência
O escopo deste trabalho abrange o estudo e a interpretação do modelo de maturidade
OSIMM, desenvolvendo uma matriz indicando para cada nível de maturidade existente os
passos que uma Organização deverá seguir para atingir um novo nível.
Este estudo não tem a intenção de ser um novo modelo de maturidade, nem tão pouco
questionar ou propor melhorias às premissas utilizadas pelo Open Group na concepção do
OSIMM. Também não faz parte deste estudo a utilização prática desta matriz nas
organizações.
15
1.3 Justificativa
O cenário econômico atual vem exigindo novos posicionamentos estratégicos das
empresas e esses reposicionamentos implicam na formação de sistemas empresariais que
buscam a eficiência coletiva e novas formas de divisão do trabalho, agora pensados a partir de
critérios de complementaridade onde produtos começam a ser oferecidos na forma de serviços.
Quando uma empresa decide pela implantação de uma Arquitetura baseada em
Serviços, ela procura uma reestruturação dos diversos níveis organizacionais envolvendo
desde os Gestores de Negócios até os desenvolvedores que irão utilizar padrões que prometem
uma solução que demanda planejamento e investimento de tempo e recursos (GARTNER,
2009a).
1.4 Estrutura do Trabalho
Este trabalho está estruturado em oito capítulos assim distribuídos: o capítulo dois
refere-se a serviços e sua importância para a economia mundial e para a TI. O capítulo três
explica os principais conceitos que envolvem processos. O capítulo quatro apresenta os
conceitos de uma arquitetura orientada a serviços. O capítulo cinco fala sobre o conceito de
maturidade. O capítulo seis apresenta o modelo OSIMM e seus principais conceitos. O
capítulo sete demonstra a formalização do estudo proposto, onde é descrita a metodologia
aplicada no estudo do OSIMM. O capítulo oito refere-se à aplicação da metodologia definida
no capítulo sete. O capítulo nove apresenta a conclusão do presente trabalho e propostas para
possíveis trabalhos futuros.
16
2 SERVIÇOS E A IMPORTÂNCIA NA ECONOMIA MUNDIAL
Cada vez mais as empresas estão procurando se diferenciar pelos seus serviços
prestados, pelo seu valor agregado e a partir desta necessidade, não muito raro, as empresas
vêem buscando como apoio à estas estratégias, a Tecnologia.
Segundo Kotler(2006), serviço é qualquer ato ou desempenho,
essencialmente intangível que uma parte pode oferecer a outra e que não
resulta na propriedade de nada. A execução de um serviço pode estar ligada
ou não a um produto concreto.
Quando comparados produtos e serviços, eles se diferem nos seguintes aspectos:
Intangibilidade, Inseparabilidade e Variabilidade.
Serviços são intangíveis, pois ao contrário de produtos não podem ser visualizados
antes de terem sido adquiridos ou finalizados. Serviços possuem inseparabilidade, pois são
produzidos e consumidos simultaneamente. Serviços são dependentes de quem os fornece,
quando e onde são fornecidos conferindo a variabilidade.
2.1 A Gestão de Serviços em TI
A prática de gerenciamento de serviços deriva de negócios tradicionais como bancos,
hotéis e companhias telefônicas. Sua prática tem crescido significativamente com a
abordagem orientada a serviço nos gerenciamentos de aplicações de TI.
Cada vez mais as áreas de negócios se juntam à área de TI o qual fornece insumos
tecnológicos para que toda a estratégia da empresa seja aplicada nos processos, sistemas e
pessoas que suportam o negócio.
Uma definição de serviço de TI é: um conjunto de recursos TI e não TI, mantidos com
o objetivo de satisfazer uma ou mais necessidades das áreas de negócios. (MAGALHÃES,
2007).
Em artigo intitulado “ABC da SOA” um serviço pode ser representado como alguma
funcionalidade de negócio independente, que omite os detalhes técnicos permitindo que os
gestores de negócios lidem com eles (ABC DA SOA, 2010).
Cada serviço deve possuir uma função distinta executando atividades relacionadas a
esse contexto definindo assim, partes de códigos significantes o bastante para serem
reutilizadas em diversas áreas da empresa, como por exemplo, “listar produtos para venda”,
“consultar crédito” e “efetuar pagamento” e assim sendo, no momento que a empresa desejar
lançar um novo produto no mercado, este utilizará os serviços já criados poupando o
17
programador criar um novo código a partir do zero. Para chegar a isto, os desenvolvedores
necessitam criar um invólucro complexo entorno de cada código (serviço) empacotado.
Existem várias maneiras de conectar serviços, mas, desde 2001, os Web Services
(mecanismos de comunicação de software) tornou-se um método bastante popular.
Segundo artigo publicado pela Oracle intitulado “Identificação e Reuso de Serviços”
Um serviço deve ser auto-contido, de baixo acoplamento e que permita ser reutilizado em
processos de negócios, aplicações compostas ou mesmo por outros serviços. Em outras
palavras, um serviço deve ser independente para realizar uma operação de negócio especifica,
define um contrato pelo qual expõe suas funcionalidades, apresenta políticas de utilização e
segurança e pode ser medido através de contratos de nível de serviço ou SLA's (Service Level
Agreements).
Portanto, serviços de um modo geral têm conquistado e consolidado um papel de
extrema importância no cenário dos principais setores da economia. Atualmente, as empresas
estão procurando novas formas de inovar os seus produtos/serviços, procurando fornecer
atrativos, como vantagem competitiva e redução de custos.
18
3 PROCESSOS
As décadas de 1980 e 1990 foram marcadas pela introdução de sistemas efetivos e
pragmáticos para controle, medição e gerenciamento de processos. Iniciativas como o Six
Sigma, introduzido nos anos 80 por um engenheiro da Motorola, com o objetivo de reduzir
ineficiências e falhas criou uma cultura onde a redundância de tarefas foram medidas e
controladas fazendo com que empresas tivessem que abandonar a visão departamental (SIX
SIGMA, 2010).
A crescente demanda por novos produtos e serviços gerou mudanças significativas nas
empresas que tiveram que abordar uma visão onde a organização era entendida como um
conjunto de processos. A Figura 1 demonstra de maneira gráfica as mudanças que as
empresas sofreram. De um lado, está representada uma empresa e seus departamentos como
Recursos Humanos, Produção, Vendas e no outro, uma empresa com a abordagem de
processos, como “Efetivar venda para cliente final” ou “Admitir novo Funcionário”.
Figura 1: Diferenças entre a abordagem por processos e a abordagem por departamentos.
Fonte: O Autor (2010).
Os processos de maneira genérica surgiram na área de Engenharia de Produção onde
eram divididos em etapas. O mesmo conceito pode ser aplicado para os processos de negócio
que, como os processos de produção, podem ser divididos em etapas ou atividades.
Segundo Davenport(1997), um processo de negócio é uma organização de
atividades de trabalho, com início, fim e com entradas e saídas claramente
definidas.
19
Segundo o OGC (Office of Government Commerce), idealizador do conjunto de
melhores práticas ITIL (Information Technology Infrastructure Library), processos de
maneira genérica contém as seguintes características (OGC, 2010):
•
São mensuráveis e voltados para desempenho: gerentes medem custo,
qualidade e outras variáveis enquanto os praticantes do processo se preocupam
com a duração e produtividade do processo;
•
Possuem resultados específicos: a razão para existência de um processo é para
entregar resultados específicos. Este resultado deve ser identificável
individualmente e precisa ser quantificado;
•
Entregam para clientes: todo processo entrega seus principais resultados para
um cliente ou stakeholder. Estes clientes podem ser internos ou externos à
organização, mas o processo deve atender as suas expectativas;
•
Respondem a um evento específico: enquanto um processo é iterativo e em
movimento, ele deve permitir o rastreamento até algum ponto específico.
3.1 BPM – Business Process Management
No momento em que as empresas decidem por implementar uma cultura de processos
dentro de sua organização, é demandado das empresas que elas passem a administrar não só
os departamentos, mas sim os seus processos e isto faz com que as elas adotem técnicas de
Gestão de Processos como o BPM (Business Process Management).
O BPM engloba todas as técnicas que visam à melhoria contínua dos processos como
Six Sigma, Learn Manufacturing, Kanban, etc.
Segundo o Gartner (2009b), BPM pode ser definido como uma disciplina de
gerenciamento que pode ser suportada por tecnologia e é uma das
abordagens para melhoria de processos, BPI. BPM foi desenvolvido em
resposta a imprevisibilidade dos mercados globais atuais. BPM trata os
processos de negócio como ativos que podem ser gerenciados e adaptados
em resposta a constantes mudanças.
O BPM envolve a análise da situação atual (“as-is”) e confronto da realidade da
empresa com as melhores práticas de mercado. O resultado desta análise e comparação gera o
modelo final para ser implementado (“to-be”). Quando bem conduzida e planejada, a
abordagem de BPM vem acompanhada com um trabalho de mudança organizacional
conhecido como gestão de mudança (change management).
20
É necessário compreender que a abordagem de BPM na maioria das vezes, gera
mudanças nos sistemas e tecnologias da empresa.
Segundo Sordi (2009), a maioria das implementações dos mais recentes
sistemas de informação corporativos é também um meio de incorporar
conceitos e práticas da gestão por processos de negócio.
3.2 TI na Modelagem e Gestão de Processos
As empresas que operam por processos enfrentam desafios em aderir os sistemas
corporativos aos processos. Devido à diversidade de sistemas e tarefas envolvidas em um
processo, quando um sistema que suporta um processo precisa ser alterado, o impacto é
sempre significativo devido ao grau elevado de dependência que os sistemas corporativos têm
uns dos outros.
A solução encontrada pelas empresas para resolver tal problema, foi a implementação
de sistemas para abranger e controlar todos os sistemas envolvidos em um processo.
Empresas que operam por processos são mais competitivas e respondem em tempo menor as
solicitações e por isso, qualquer anomalia no processo é tratada como um evento crítico e
demanda tratamento imediato.
A principal meta que deve estar sempre presente é que os sistemas para gestão de
processos precisam suportar processos que crescem e encolhem, eliminando ao máximo o
impacto dos sistemas nos processos (SORDI, 2009).
SOA prevê a implementação dos processos de negócios em forma de serviços e a
criação de estruturas e regras específicas bem claras, de forma adaptável para alinhamento
maior do negócio com TI.
Para implementação de SOA, o conhecimento de serviços e processos é fundamental
e o objetivo de BPM faz com que sejam mapeados todos os processos de negócios da empresa
visando a sua modelagem em forma de serviços e a computação orientada a serviços como
forma de estruturação da área de TI.
3.3 Ferramentas de BPMS
Com a adoção cada vez mais crescente pelas empresas, da abordagem de BPM para a
gestão integrada de seus processos, o uso de ferramentas para o suporte destas práticas é cada
vez mais difundido. Ferramentas de BPMS (Business Process Management Systems) surgiram
21
principalmente das ferramentas centradas em sistemas, ferramentas centradas em pessoas e
ferramentas centradas em documentos. Ferramentas BPMS podem ser entendidas como um
ambiente colaborativo para relacionamento da descoberta de processos, atividades de desenho
e análise para usuários de negócio e analistas.
Segundo o Gartner (2008), para que uma ferramenta possa ser considerada um BPMS
deve possuir dez capacidades:
a) Gerenciamento e Administração de Sistemas: contemplando gerenciamento de papéis,
gerenciamento de segurança, gerenciamento e monitoramento de sistemas, integração
LDAP (Lightweight Directory Access Protocol) e AD (Active Directory) e ferramentas de
desenvolvimento;
b) Gerenciamento de Regras de Negócio: contemplando regras baseadas em evento e
dedução, teste e depuração, simulação de regras (análise “e-se”) e templates de regras;
c) Simulação e Otimização online e offline: contemplando análise preditiva (financeira e
riscos), processos concorrentes e simulação de regras de negócio, repositório de
simulações, algoritmos de otimização e engenharia reversa;
d) Gerenciamento de Eventos de Negócio, BI (Business Inteligence) e Atividades
BAM(Business Activity Monitoring): contemplando gerenciadores de eventos, relatórios
de BI e OLAP (Online Analytical Process), painéis de monitoramento (Dashboards) de
KPI (Key Performance Indicators), monitoramento gráfico do processo, ferramentas de
descoberta de processos;
e) Conectividade de Sistemas: contemplando adaptadores técnicos, suporte ao serviço,
ESB (Enterprise Service Bus), ferramentas de transformação de dados, adaptadores de
aplicativos;
f) Colaboração de Grupo e Usuário: contemplando filas de trabalho compartilhadas, salas
e portais de projeto, desenvolvimento baseado em papéis, mensagens instantâneas e blogs
e comunidades corporativas;
g) Gerenciamento de Documentos e Conteúdo: contemplando servidor de arquivos,
indexação de documentos e imagem, gerenciamento de dados estruturados e não
estruturados, arquivamento de documentos e gerenciamento de segurança de documentos;
h) Desenvolvimento Gerenciado a Modelos: contemplando modelagem “arrastar e soltar”,
modelagem organizacional, modelagem de regras de negócio, teste e depuração e
modelos pré-definidos de processos;
22
i) Repositório/Catálogo de Componentes do Processo: contemplando pesquisa,
gerenciamento de versão, serviços de publicação e assinatura, Check-in e Check-out;
j) Execução de Processo e Gerenciamento de Estado: contemplando interações pessoa a
pessoa, pessoa a sistema, sistema a sistema, gerenciamento de casos de uso e
cancelamento de transação.
Segundo Gartner (2008), há muitos anos, fornecedores de software oferecem produtos
de BPM que contém muitas das capacidades necessárias as ferramentas de BPMS. Entretanto,
até 2005, nenhum fornecedor tinha integrado todas as 10 capacidades em um produto para
gerenciar processos durante o seu ciclo de vida.
Segundo Gartner (2008), as empresas devem fazer uso de ferramentas de
BPMS quando procuram um ambiente integrado de modelagem para
suportar as iniciativas de BPM.
Cenários que justificam a utilização de ferramentas BPMS apresentam as seguintes
características:
a) Pensamento orientado a processo está se tornando uma disciplina de gerenciamento
importante. Sistemas e aplicativos são vistos como ativos que suportam as perspectivas
de processo;
b) Esta perspectiva de processo direciona uma abordagem holística e unificada para o
gerenciamento do processo. O negócio quer tratar pessoas, sistemas/máquinas e
informações da mesma maneira, porque a coordenação deste tipo de recursos tem a
mesma importância para o resultado do trabalho. Todas as interações entre estes recursos
demandam o mesmo nível de controle gerencial. Estas interações devem ser transparentes
e eficientes;
c) Usuários de negócio querem colaborar com os profissionais de TI através de todo o ciclo
de melhoria de processo, não somente na análise, desenho e fases de aceite e teste;
d) O processo demanda um alto grau de transparência e consistência através de múltiplos
tipos de interação;
e) O processo de negócio requer a coordenação de diferentes interações de recursos:
interações entre sistemas, interação humana, interação humano-sistema, etc;
f) O processo em questão demanda um grau de agilidade maior do que outros processos. O
negócio não quer padronizar a maneira de como realizar o trabalho. A organização está
adotando uma mentalidade de melhoria contínua dos processos. Portanto, precisa uma
maneira de unir mudança incremental com mudança transformadora;
23
g) Usuários de negócio demandam direito a modificações, e não querem esperar a TI alterar
o programa;
h) O negócio precisa visualizar as mudanças em tempo real e as transações em andamento
com a habilidade de alterar a sua execução.
Portanto, fica claro que quando empresas decidem adotar uma ferramenta de BPMS,
as práticas de BPM já estão bastante difundidas na empresa. O principal aspecto para que os
projetos de BPMS tenham sucesso é que a cultura de operar por processos na empresa esteja
madura o suficiente para introduzir sistemas para a gestão dos processos, com painéis que
sejam capazes de fornecer mudança rápida no processo, simulação e acompanhamento de
indiciadores do processo.
3.4 BAM – Business Activity Monitoring
BAM (Business Activity Monitoring) são sistemas que auxiliam organizações a
monitorarem em tempo real indicadores chave, KPI dos processos e das atividades de
negócio. Os principais objetivos das ferramentas de BAM são:
•
Fornecer melhoria contínua na produtividade dos processos e em resposta
operacional;
•
Alertar usuários do negócio de situações que precisam de atenção, prover
informação necessária para avaliação da situação em questão e permitir
também que possam tomar ação corretiva o quanto antes possível. A Figura 2
demonstra um exemplo de um BAM com seus indicadores, um monitor
voltado para informações relacionadas a disponibilidade de sistemas.
Figura 2: Exemplo de BAM com seus indicadores.
Fonte: ManageEngine (2010).
24
Atualmente, as soluções de mercado existentes de BAM fazem parte das ofertas de
ferramentas de BPMS presentes no mercado. Quando bem modelados e implementados, os
BAM’s mostram informações úteis e com relevância para a gestão diária dos negócios das
empresas.
25
4 SOA – ARQUITETURA ORIENTADA A SERVIÇOS
Segundo ERL (2009), existem vários esforços em andamento, por parte de diferentes
organizações dedicadas à pesquisa e ao estabelecimento de padrões, para definições abstratas,
modelos arquitetônicos e vocabulários para SOA, porém, nenhum destes produtos finais
produzidos por esforços independentes foram adotados como padrões SOA por todo o
mercado e, portanto, não serão abordados neste trabalho.
O conceito de SOA surgiu da necessidade da integração de tecnologias. SOA é uma
metodologia que visa maximizar a reutilização de serviços existentes e a integração com
novos serviços.
Para CIO (2007), a conceituação de SOA apresenta dois aspectos distintos: “as duas
primeiras
palavras
(Arquitetura
e
Orientada)
expressam
uma
metodologia
para
desenvolvimento de software, enquanto que a terceira palavra (Serviço) é um panorama de
todos os ativos de software de uma empresa”. Com isto, entende-se SOA como parte da
estratégia para a divulgação de todos os ativos de software de uma empresa, através de uma
metodologia de programação orientada a serviços.
Independente das diversas definições, é fundamental descrever que, SOA é um
conjunto de objetivos e benefícios comuns os quais estabelecem o estado-alvo para que uma
organização adote com sucesso a orientação a serviços.
Segundo ERL (2009) existem sete benefícios associados a SOA os quais levam as
organizações a adotarem uma arquitetura orientada a serviços:
a) Maior interoperabilidade intrínseca: refere-se ao compartilhamento de dados, que
quanto mais interoperáveis, mais facilmente ocorrerão as trocas de informações. Os
programas que não são interoperáveis precisam ser integrados. A orientação a serviços
permite estabelecer a interoperabilidade nativa dentro dos serviços com a finalidade de
reduzir a necessidade de integração dos serviços. A interoperabilidade intrínseca
representa um objetivo fundamental na orientação a serviços, o qual estabelece uma
fundação para realização de outros objetivos e benefícios estratégicos;
b) Maior federação: recursos e aplicativos unidos, com autonomia e auto-governança,
representam um ambiente de TI federado. SOA permite o aumento da perspectiva
federada de uma corporação, independentemente de sua aplicação;
c) Mais opções de diversificação de fornecedores: a capacidade que uma organização tem
de escolher as melhores inovações tecnológicas e produtos dos melhores fornecedores,
26
caracterizam a diversificação de fornecedores. Para uma corporação é benéfico ter a
opção de diversificação se necessário, pois esta opção exige que a arquitetura da
tecnologia não ligada a apenas um fornecedor. Esta diversificação permite uma
autonomia de governança, a qual prolonga o tempo de vida das soluções de automação e
aumenta o retorno financeiro que ela proporciona;
d) Maior alinhamento do negócio e do domínio tecnológico: atender os requisitos de
negócio de TI, muitas vezes está associado à precisão com que a lógica do negócio é
expressa e automatizada pela lógica da solução. Embora esta fosse uma premissa para os
aplicativos desenvolvidos, havia um desafio em mantê-los constantemente alinhados às
necessidades dos negócios, quando a natureza e a direção destes mudavam. A
computação orientada a serviços promove a abstração em vários níveis;
e) Maior retorno sobre o investimento: para determinar a eficácia em termos de custobenefício, que um dado aplicativo ou sistema de fato representa é necessário medir o
retorno sobre o investimento das soluções automatizadas, fator que deve ser considerado
como crucial. Devido ao constante aumento da complexidade lógica requeridas pelos
aplicativos e o crescimento das arquiteturas não federadas são difíceis de manter e evoluir.
Um departamento de TI médio representa um valor significativo no orçamento
operacional de uma organização. O resultado financeiro requerido pela TI é uma
preocupação prioritária, porque muitas vezes o orçamento aumenta sem demonstrar
crescimento correspondente no valor dos negócios. A computação orientada a serviços
baseia-se no reuso dos serviços agnósticos, permitindo que eles sejam repetidamente
montados em diferentes composições, podendo ser adaptado inúmeras vezes para que
seja possível automatizar diferentes processos de negócios como parte de diferentes
soluções orientadas a serviços. Assim, despesas e esforços adicionais em TI geram
retornos repetitivos e de longo prazo;
f) Maior agilidade organizacional: a agilidade organizacional representa um estado-alvo
que as corporações buscam a medida que entregam serviços e preenchem inventários de
serviços. A organização beneficia-se com uma organização baseada em maior capacidade
de resposta depois que uma quantidade significativa de serviços estiver em
funcionamento. O importante é reconhecer a orientação a serviços que tem como foco
estratégico tornar a corporação altamente ágil;
g) Menor carga de trabalho da TI: a aplicação consciente de orientação a serviços resulta
em uma corporação de TI com menos desperdício, redundância e conseqüentemente o
27
custo operacional. A conquista dos objetivos anteriormente descritos cria um
departamento de TI que pese menos sobre a organização e que contribua mais com seus
objetivos estratégicos (ERL 2009).
É de fundamental importância entender o significado dos objetivos acima citados antes
de implementar a orientação a serviços consistentemente dentro de um contexto estratégico.
28
5 MATURIDADE
O termo maturidade quando pesquisada de maneira sem contexto, segundo o
dicionário Aurélio é “o estado das pessoas ou das coisas que atingiram completo
desenvolvimento”.
Atualmente, maturidade é um conceito bastante usado no contexto de negócios e de TI
para a definição de níveis e metas para empresas.
Dentro do contexto de BPM, a OMG (2010) divide a maturidade dos processos nos
seguintes níveis:
a) Nível 1 (Inicial): processos de negócio são executados de maneira inconsistente e com
resultados difíceis de serem previstos.
b) Nível 2 (Gerenciado): a Gestão divide o trabalho e unidades locais de trabalho para
assegurar que o processo pode ser desempenhado de forma repetitiva e que satisfaz os
compromissos primários de um grupo de trabalho. Entretanto, grupos de trabalho que
realizam as mesmas tarefas podem usar procedimentos diferentes.
c) Nível 3 (Padronizado): processos comuns e padronizados são sintetizados a partir de
melhores práticas identificadas nos grupos de trabalho. Diretrizes para suportar diferentes
necessidades de negócio são providenciadas.
d) Nível 4 (Previsível): As capacidades fornecidas pelos processos são exploradas e
devolvidas para as unidades de trabalho. O desempenho do processo é gerenciado de
maneira estatística através do seu caminho para compreensão e controle de variações.
Assim, os resultados podem ser medidos em pontos intermediários.
e) Nível 5 (Inovador): Ações envolvendo melhorias pró-ativas e oportunistas atendem
lacunas a serem preenchidas entre as capacidades atuais da organização e as capacidades
requeridas para atingir os seus objetivos de negócio.
Portanto,
a
definição
de
maturidade
de
uma
maneira
genérica
envolve
contextualização. A definição de maturidade dentro de processos, conforme explicada é a
definição mais próxima da realidade a ser tratada no trabalho.
5.1 OSIMM
O OSIMM (Open Group Services Integration Maturity Model) especifica como medir
os níveis de integração de uma organização e seus sistemas de TI e aplicações de negócio.
29
Além disso, ele também proporciona direcionamento em como alcançar certos níveis de
maturidade para atender os benefícios do negócio.
A Figura 3 demonstra o relacionamento entre as dimensões e os níveis de maturidade.
Figura 3: Matriz OSIMM de maturidade para SOA
Fonte: Open Group (2010).
O OSIMM possui sete dimensões distribuídas através de sete níveis de maturidade.
Cada nível de maturidade representa um aumento significativo no nível da maturidade
necessário para atingir a orientação a serviço. Este conceito é definido como maturidade de
integração de serviço no OSIMM. Enquanto muitas técnicas e práticas são usadas para
realizar orientação a serviço, o OSIMM inclui intencionalmente tecnologias novas e
evolutivas para implementação de serviços tais como computação em nuvem. A abrangência
do framework OSIMM é direcionada a propor um método ampliado para incluir tais conceitos.
5.1.1 Níveis de maturidade do OSIMM
Cada nível de maturidade elabora uma possível abstração do estado da organização em
termos da sua maturidade e da integração dos serviços (negócios ou TI) e soluções SOA.
30
Os sete níveis de maturidade SOA definidos pelo OSIMM são (Open Group, 2009):
a) Silo: partes individuais da empresa estão desenvolvendo seus próprios softwares sem
integração de dados, processos, pessoas ou tecnologias;
b) Integrado: tecnologias foram utilizadas para comunicação entre os silos, e para integrar
os dados;
c) Componentizado: os sistemas de TI nos silos foram analisados e divididos em
componentes com um framework o qual podem ser desenvolvidos em novos sistemas ou
configurações;
d) Serviço: aplicações compostas são construídas a partir de serviços com baixo
acoplamento. A maneira como os serviços são acionados é baseada em padrões abertos e
é independente da tecnologia que o suporta;
e) Serviços Compostos: neste nível de maturidade de serviço, é possível construir um
processo para atender um conjunto de serviços, não somente através de desenvolvimento,
mas através do uso de uma linguagem para composição e modelagem do processo de
negócio, por exemplo BPEL (Business Process Execution Language), para controle dos
serviços individualmente;
f) Serviços Virtualizados: o consumidor do serviço não aciona o serviço diretamente, mas
através do acionamento de um serviço virtual. A infrainstrutura é que se encarrega de
todo o processo de conversão e acionamento do serviço real;
g) Serviços dinamicamente reconfiguráveis: nos níveis anteriores, a montagem do
processo era feita pela equipe de TI (com o auxílio de analistas de negócio e gerentes)
numa fase de desenho. Neste nível, a composição do serviço é feita em tempo de
execução e pode ser feita pelo analista de negócio em uma ferramenta apropriada ou pelo
sistema em si.
5.1.2 Etapas envolvidas em uma avaliação do OSIMM
A avaliação da maturidade SOA utilizando o OSIMM como referência, deve seguir
algumas etapas pré-determinadas para o diagnóstico da situação atual da maturidade da
empresa e da situação futura que a mesma deseja alcançar. A seguir, tais etapas serão
descritas (Open Group, 2010).
31
5.1.2.1 Identificar os pontos críticos, Escopo e Objetivos de Negócio
Os pontos críticos definem onde a empresa considera que seus processos precisam de
melhoria e podem ser usados para análise pelo OSIMM. O avaliador deve reunir material que
ajudam a determinar os estados desejados dos níveis de maturidade SOA. Este material inclui
documentos de estratégia, requisitos de usuários, e artefatos da arquitetura corporativa. Neste
passo, uma lista inicial de pontos críticos ou objetivos estratégicos é determinada. Isto feito, o
escopo e estrutura do roadmap SOA e da transformação na empresa pode ser determinada. As
dimensões e os domínios do OSIMM podem ser usados para auxiliar na definição do escopo.
5.1.2.2 Extensão do Modelo OSIMM
Com base no escopo acordado e nos objetivos da empresa, uma matriz de avaliação
deve ser criada baseada na matriz do OSIMM, mas confeccionada com foco nos pontos
críticos da empresa. O modelo OSIMM pode ser estendido ao adicionar novos indicadores de
maturidade, que podem ser adicionados com o objetivo de focar em pontos de atenção
específicos ou requisitos estratégicos para a adoção de serviços. Isto requer da equipe de
avaliação mapear cuidadosamente os atributos de maturidade com quaisquer indicadores de
maturidade adicionais. Adicionar indicadores de maturidade ao modelo básico do OSIMM
deve ser conduzido por profissionais que possuem bastante experiência em SOA.
5.1.2.3 Avaliação do Estado Atual
O avaliador usa o modelo OSIMM estendido produzido no passo anterior para
entrevistar pessoas-chave na empresa com o objetivo de avaliar o estado atual da empresa e
por conseqüência o nível de maturidade atual da empresa. As entrevistas devem ser baseadas
nas questões base de avaliação contidas no OSIMM e as questões adicionadas como parte da
extensão, e que podem incluir questões adicionais consideradas relevantes pelo avaliador que
podem ajudar a mapear indicadores para os atributos de maturidade. Baseado nas repostas do
questionário de avaliação, o nível de maturidade atual é determinado para cada domínio, e
agregada através das dimensões ao estado geral da empresa.
32
5.1.2.4 Determinação do Estado Futuro
O estado futuro desejado é determinado usando documentos de requerimentos,
artefatos da arquitetura empresarial e entrevistas com profissionais chave da empresa. É
importante focar nos indivíduos que possuem um bom entendimento e visão dos requisitos
futuros para serviços baseados em negócios e infraestrutura SOA. O estado futuro desejado é
determinado ao avaliar o retorno de investimento para uma maturidade SOA de alto nível
dentro de cada dimensão OSIMM contra os requerimentos de negócio.
5.1.2.5 Identificar os Gaps e determinar o Roadmap
Os passos anteriores identificam os níveis de maturidade atuais e futuros através de
todos os domínios e dimensões da matriz de avaliação criada no primeiro passo. O avaliador
deverá agora determinar os gaps entre os níveis de maturidade atual e futuro, e criar um
roadmap que leve a organização do nível atual para o nível desejado. Os indicadores de
maturidade para cada domínio precisam mostrar o estado atual e desejado, e os passos no
roadmap precisam ser construídos considerando levar os domínios do nível atual para o nível
desejado, e para alcançar os objetivos de negócio ou aliviar pontos críticos. O avaliador
também deve considerar restrições e pré-requisitos que irão existir entre as diferentes
entidades de negócio e TI que precisam ser colocados no lugar. Deve-se levar em
consideração que o resultado do roadmap SOA é direcionado a proporcionar um documento
de alto nível das atividades que precisam ser realizadas, e que uma análise mais detalhada
pode ser feita, fora da análise do OSIMM, da real natureza das atividades.
33
6 METODOLOGIA
Para atingir o objetivo deste trabalho, a metodologia está divida nas seguintes etapas:
•
Análise e Interpretação dos atributos de maturidade do OSIMM
•
Classificação dos atributos do OSIMM em positivos e negativos e indicação
das ações a serem realizadas para cada atributo.
A metodologia acima servirá de base para o desenvolvimento da matriz de ações X
níveis de maturidade SOA.
O objetivo deste passo é estudar todas as dimensões e níveis que compõe o modelo
OSSIM mapeando os requisitos de cada um.
Cada dimensão/nível possui um questionário base associado para auxílio na
identificação da maturidade correspondente. Analisando este questionário, é possível entender
os atributos relevantes utilizados para mensuração da mesma, classificados pelo OSIMM
como atributos de maturidade. Foram definidos os seguintes passos a seguir durante a análise.
6.1 Interpretação das dimensões
Interpretação do conceito das dimensões a partir da utilização da descrição básica de
cada dimensão e o seu indicador de maturidade.
Entende-se por Indicador de Maturidade objetivo a ser alcançado na dimensão. Quanto
maior o nível de maturidade da empresa na dimensão, mais perto a empresa se encontra deste
objetivo. Na Tabela 1, podemos ver o Indicador de Maturidade da Dimensão de Visão do
Negócio:
Tabela 1: Indicador de Maturidade – Visão do Negócio
Indicador de Maturidade
Definição formal e documentação dos direcionadores
de negócio e processos da empresa
Fonte: Open Group (2010)
34
Abaixo na Tabela 2 um exemplo da descrição básica de uma das dimensões do
OSIMM:
Tabela 2: Descrição básica da dimensão de Visão do Negócio
Descrição Básica – Visão do Negócio
A dimensão de negócio está focada na arquitetura de negócio; por exemplo, as políticas e
práticas de negócio atuais; como os processos de negócio são desenhados, estruturados,
implementados e executados. A dimensão de negócio também atende como o custo de TI é
alocado na empresa e quão bem as capacidades de TI suportam a flexibilidade do negócio,
agilidade e SLAs. Portanto, inclui a proposta necessária de valor para ir de um nível de
maturidade para o outro.
Fonte: Open Group (2010)
6.2 Característica básica de cada nível de maturidade da dimensão
Característica básica = (interpretação da dimensão) + (situação atual)
A característica básica de cada dimensão é formada pela interpretação da dimensão,
demonstrada no passo anterior mais a “situação atual” em que a empresa se encontra.
Cada nível da dimensão define uma “imagem” ou “situação atual” que a empresa se
encontra e estão divididos em:
•
Nível 1: Baixo ou inexistente;
•
Nível 2: Limitado;
•
Nível 3: Entre as áreas da empresa;
•
Nível 4: Pela Empresa, mas de maneira não integrada;
•
Nível 5: Pela Empresa, de maneira integrada;
•
Nível 6: Com integração entre as áreas e com os parceiros de negócio;
•
Nível 7: Suportando as mudanças do negócio;
35
6.3 Construção dos atributos.
Compreensão dos atributos de maturidade dos níveis do OSIMM.
Cada nível de cada dimensão contém diferentes atributos que caracterizam a
maturidade. Na Tabela 3 são demonstrados os atributos de maturidade do nível 1 da dimensão
de Visão do Negócio.
Tabela 3: Atributos de Maturidade – Visão do Negócio
Nível de Maturidade
Atributos de Maturidade
Arquitetura Empresarial não é considerada como
um elemento da estratégia tanto de TI quanto da
Silo
(Nível 1)
Linhas de Negócio Isoladas
corporação
Processos de negócio não apresentam definição
nem documentação formal
O suporte de TI (Hardware, Software, Processos
de TI) ao negócio não é claro e não está bem
definido.
Fonte: Open Group (2010).
Uma vez realizados estes passos, os atributos podem agora ser classificados em
positivo ou negativo.
6.4 Classificação dos atributos do OSIMM
Uma vez que os sete níveis do OSIMM com seus atributos de maturidade das
dimensões foram interpretados, eles estão prontos para serem classificados como “positivos”
ou “negativos”. Como premissa, foi definido que atributos positivos e negativos podem ser
definidos por:
•
Positivos: São atributos que satisfazem certo grau de maturidade na dimensão e
podem ser evoluídos. Para estes casos, serão recomendadas ações que visam
atingir um novo nível de maturidade.
36
•
Negativos: São atributos que precisam ser trabalhados e demandam atenção.
Para estes casos, serão recomendadas ações que deverão ser implementadas
para alcançar um novo nível.
Ao alcançar o nível sete, a empresa atingiu o objetivo de maturidade da dimensão. O
objetivo desta etapa é fornecer o mapeamento de todas as ações positivas e negativas para
cada dimensão/nível proposto pelo OSSIM.
37
7 DESENVOLVIMENTO
O desenvolvimento consiste da aplicação da metodologia, definida durante o trabalho,
que resultou na matriz de ações e classificação dos atributos de maturidade para cada
dimensão do OSIMM. Abaixo será demonstrada para cada dimensão a sua definição básica,
os atributos formando assim as ações X níveis de maturidade.
7.1 Dimensão de Visão de Negócio
A dimensão de negócio está focada na arquitetura de negócio; por exemplo, as
políticas e práticas de negócio atuais; como os processos de negócio são desenhados,
estruturados, implementados e executados. A dimensão de negócio também atende como o
custo de TI é alocado na empresa, e quão bem as capacidades de TI suportam a flexibilidade
do negócio, agilidade e SLAs. Portanto, incluí a proposta necessária de valor para ir de um
nível de maturidade para o outro. A Figura 4 demonstra a Dimensão de Visão de Negócio.
Figura 4: Matriz OSIMM – Dimensão de Visão de Negócio
Fonte: Open Group (2010).
Na Tabela 4 é demonstrada a matriz de ações e análise dos atributos de maturidade e
as ações propostas para esta dimensão.
Tabela 4: Matriz de Ações – Dimensão de Visão de Negócio
Nível
Silo
(Nível 1)
Nome do Nível
Característica do
Nível
Atributos
Classificação
Ação
Linhas de Negócio Isoladas
Baixa ou inexistente
definição formal das
diretrizes de negócio
da organização e
seus processos
Arquitetura
Empresarial não é
considerada como
um elemento da
estratégia tanto de TI
quanto da corporação
Negativo
Definir uma arquitetura
empresarial alinhando TI
com o negócio
38
Nível
Nome do Nível
Característica do
Nível
Atributos
Classificação
Ação
Processos de negócio
não apresentam
definição nem
documentação
formal
Negativo
Identificar os processos
de negócio da empresa e
documentá-los
O suporte de TI
(Hardware,
Software, Processos
de TI) ao negócio
não é claro e não está
bem definido
Negativo
Envolver TI no
planejamento estratégico
Negativo
Reconhecer a
importância da
Arquitetura Empresarial
e formalizá-la.
As diretrizes de
negócio da
organização e os
processos estão
limitados aos
objetivos de cada
área da empresa e
carecem de
informação das
demais áreas
Negativo
Realizar um
planejamento estratégico
unificado entre as áreas
da empresa
Alguns elementos da
arquitetura
empresarial já foram
formalmente
definidos
Negativo
Definir todos os
elementos da arquitetura
empresarial
Os objetivos de
negócio das áreas da
empresa foram
transformados em
diretrizes de negócio
Positivo
Garantir formalmente
que as áreas da empresa
atendam as metas do
negócio (diretrizes)
Positivo
Aplicar a arquitetura
empresarial alinhado com
um uma gestão integrada
dos processos (BPM)
Positivo
Garantir que a Missão
está sendo alcançada
Positivo
Implementar
monitotramento do
processo (BAM)
Positivo
Garantir que a Missão
está sendo alcançada e
evolua para que seus
parceiros façam parte
dela
Arquitetura
Empresarial não é
formalizada
Integrado
(Nível 2)
Componentizado
(Nível 3)
Integração de Processos de
Negócio
Funções de Negócio
Componentizadas
Limitada definição
formal das diretrizes
de negócio da
organização e seus
processos
Definição formal das
diretrizes de negócio
da organização e
seus processos entre
as áreas da empresa.
Uso formal da
arquitetura
empresarial.
Serviços
(Nível 4)
Serviços
Compostos
(Nível 5)
Negócio consome e provê
serviços
Serviços de Negócio
Compostos
Definição formal das
diretrizes de negócio
da organização e
As diretrizes da
seus processos em
organização foram
toda empresa, mas de
transformadas em
maneira não
elementos da Missão
integrada
da Empresa e da
Arquitetura do
negócio
Definição formal das
diretrizes de negócio
da organização e
seus processos em
toda empresa de
maneira integrada
Uso formal da
arquitetura da
empresa e BPM
As diretrizes da
organização foram
transformadas em
elementos da Missão
da Empresa e da
Arquitetura do
negócio
39
Nível
Serviços
Virtualizados
(Nível 6)
Serviços
Dinamicamente
Reconfiguráveis
(Nível 7)
Nome do Nível
Característica do
Nível
Atributos
Serviços Terceirizados de
BPM & BAM
Arquitetura
empresarial bastante
Definição formal das
definida quanto aos
diretrizes de negócio
fluxos de processos
da organização e
internos e seus
seus processos com
relacionamentos com
integração entre as
processos e/ou
áreas e com os
serviços de parceiros
parceiros de negócio
de negócio. Extenso
uso de BAM
Capacidades de Negócio por
serviços adaptados a
contexto
Arquitetura da
empresa bem
definida que incluí
Definição formal das uma definição pontodiretrizes de negócio
a-ponto formal dos
da organização e
fluxos dos processos.
seus processos
suportando as
mudanças do
BPM é utilizado para
negócio
definir e testar os
fluxos dos processos
e atender SLAs bem
definidas
Classificação
Ação
Positivo
Evoluir para que o
negócio consiga
responder as mudanças
do mercado com
agilidade
Positivo
Atingiu o objetivo
Positivo
Atingiu o objetivo
Fonte: O Autor (2010).
Ao atingir o nível máximo de maturidade (Nível sete), a organização atendeu ao
seguinte objetivo: Definição formal das diretrizes de negócio da organização e seus processos
suportando as mudanças do negócio.
7.2 Dimensão Organização e Governança
A dimensão de organização e governança está focada na estrutura e desenho da
organização em si e as medidas necessárias para eficiência organizacional no contexto de
SOA e de Governança SOA. O aspecto organizacional está focado na estrutura organizacional,
relacionamentos, papéis e as melhorias necessárias para alcançar uma estratégia orientada a
serviço. A Figura 5 demonstra a Dimensão de Organização e Governança.
40
Figura 5: Matriz OSIMM – Dimensão de Organização e Governança
Fonte: Open Group (2010).
Na Tabela 5 é demonstrada a matriz de ações e análise dos atributos de maturidade e
as ações propostas para esta dimensão.
Tabela 5: Matriz de Ações – Dimensão de Organização e Governança
Nível
Silo (Nível 1)
Integrado (Nível 2)
Componentizado
(Nível 3)
Nome do Nível
Estratégia de TI e
Governança por
Linhas de Negócio
Transformação de TI
Processos Comuns de
Governança
Característica do
Nível
Baixo ou inexistente
uso formal de serviços
e governança SOA
através da organização
para entrega de
serviços de negócio e
TI
Uso limitado formal
de serviços e
governança SOA
através da organização
para entrega de
serviços de negócio e
TI
Uso formal de
serviços e governança
SOA através da
organização para
Atributos
Classificação
Ação
Visão ou estratégia
para implementação
de SOA inexistente
Negativo
Buscar o
comprometimento da
escala executiva para
implementação SOA
Não há conceitos de
governança SOA
disseminado nas áreas
de TI ou negócio
Negativo
Estruturar estratégias
para a
implementação SOA
Negativo
Efetua treinamento
sobre arquitetura
SOA, contratação de
recursos
especializados
Positivo
Implementar os
conceitos SOA de
forma consciente e
com evolução
gradativa
Reconhecimento da
importância de uma
governança SOA, mas
ainda não abordada de
forma holística
Positivo
Ampliar a
estruturação de uma
Governança SOA e o
reconhecimento da
importância da
mesma
Existe uma estratégia
SOA entre algumas
áreas da empresa
Positivo
Evoluir a estratégia
SOA utilizada para
que atenda as demais
áreas da empresa
Equipe de TI com
baixos ou inexistentes
conhecimentos de
SOA (falta de
treinamentos
específicos)
Estratégia SOA
emergindo.
Coordenação
integrada de SOA
surgindo
41
Nível
Nome do Nível
Característica do
Nível
entrega de serviços de
negócio e TI entre as
áreas da empresa
Atributos
Classificação
Ação
O valor dos serviços e
governança SOA é
reconhecida entre uma
ou mais áreas da
empresa, porém não
adotam SOA com uma
abordagem holística.
Negativo
Evoluir e reconhecer
a utilização de SOA
na empresa
Positivo
Ampliar a
estruturação de uma
Governança SOA e o
reconhecimento da
importância da
mesma
Negativo
Efetuar treinamento
sobre arquitetura
SOA, contratação de
recursos
especializados
Positivo
Implementar formas
de medir os
benefícios dos
serviços já
implementados
justificando a
expansão e
importância de SOA
Positivo
Ampliar a
estruturação de uma
Governança SOA e o
reconhecimento da
importância da
mesma levando em
consideração o que
foi acordado
Positivo
Garantir que o
processo formal está
sendo utilizado e
seguido por toda a
empresa
Foram criados
treinamentos que
atendem tanto as
necessidades do
negócio quanto de TI
Positivo
Disseminar o
conhecimento
adquirido nos
treinamentos e
garantir a utilização
do mesmo
Os modelos de TI e a
estratégia de negócio
adotam SOA e o
compartilhamento de
serviços
Positivo
Evoluir a
estruturação de
serviços na empresa
Foi estabelecida uma
governança SOA na
empresa, mas com
adoção limitada.
Equipe de TI com
conhecimentos
limitados de SOA e
poucos treinamentos
específicos
Alguns serviços já são
efetivamente
utilizados e
governados tanto na
empresa e/ou com
parceiros externos
Foi formalizada e
documentada uma
estratégia e visão SOA
na empresa que foi
acordada entre as
áreas da empresa
Serviços (Nível 4)
Serviços Compostos
(Nível 5)
Governança SOA
Emergente
Alinhamento entre
SOA e Governança de
TI
Uso formal de
serviços e governança
SOA através da
organização para
entrega de serviços de
negócios e TI pela
empresa, mas de
maneira não integrada
Uso formal de
serviços e governança
SOA através da
organização para
entrega de serviços de
negócios e TI pela
Foi documentado e
definido um processo
formal de governança
SOA o qual algumas
áreas da empresa já
seguem
42
Nível
Nome do Nível
Característica do
Nível
empresa, mas de
maneira integrada.
Atributos
Governança SOA
adotada pela maioria
das áreas da empresa
fortalecendo serviços
SOA e novas soluções
Serviços Virtualizados
(Nível 6)
Serviços
Dinamicamente
Reconfiguráveis
(Nível 7)
Governança em SOA
e Infraestrutura de TI
Governança através de
política
Uso formal de
serviços e governança
SOA através da
organização para
entrega de serviços de
negócios e TI com
integração entre as
áreas e com os
parceiros de negócio
Uso formal de
serviços e governança
SOA através da
organização para
entrega de serviços de
negócios e TI
suportando as
mudanças do negócio
Classificação
Ação
Positivo
Ampliar a
estruturação de uma
Governança SOA e o
reconhecimento da
importância da
mesma levando em
consideração o
aumento contínuo da
estruturação dos
negócios da empresa
em serviços
Estender (disseminar)
a governança SOA
para os parceiros de
negócio
Garantir que serviços
estejam atendendo a
estratégia da
empresa.
Governança em SOA
faz parte da cultura
organizacional
Positivo
Serviços de SOA são
tratados como parte do
negócio
Positivo
Os indicadores e
métricas SOA são bem
definidos e utilizados
pela empresa
Positivo
Implementar ações
baseados nos
indicadores
Serviços modelados e
gerenciados alinhados
com a estratégia da
empresa
Positivo
Atingiu o objetivo
Métricas de serviço
são coletadas e servem
como base para
tomada de decisões
Positivo
Atingiu o objetivo
Fonte: O Autor (2010).
Ao atingir o nível máximo de maturidade (Nível sete), a organização atendeu ao
seguinte objetivo: Uso formal de serviços e governança SOA através da organização para
entrega de serviços de negócios e TI suportando as mudanças do negócio.
7.3 Dimensão de Métodos
A dimensão do método está focada nos métodos e processos empregados pela
organização para sua transformação da TI e do negócio e a maturidade da organização em
torno do ciclo de desenvolvimento de software da empresa. Por exemplo, o uso de gestão de
requisitos, técnicas de estimativa, gerenciamento de projetos, processo de garantia de
qualidade, metodologias de desenho e técnicas, e ferramentas para o desenho das soluções. A
Figura 6 demonstra a Dimensão de Métodos.
43
Figura 6: Matriz OSIMM – Dimensão de Métodos
Fonte: Open Group (2010).
Na Tabela 6 é demonstrada a matriz de ações e análise dos atributos de maturidade e
as ações propostas para esta dimensão.
Tabela 6: Matriz de Ações – Dimensão de Métodos
Nível
Silo (Nível 1)
Integrado (Nível 2)
Componentizado
(Nível 3)
Nome do Nível
Análise & Desenho
Estruturado
Modelagem Orientada
a Objeto
Desenvolvimento
baseado em
componentes
Característica do
Nível
Baixo ou inexistente
uso formal dos
conceitos de SOA no
Ciclo de Vida de
Desenvolvimento de
Software
Limitado uso formal
dos conceitos de SOA
no Ciclo de Vida de
Desenvolvimento de
Software
Uso formal dos
conceitos de SOA no
Ciclo de Vida de
Desenvolvimento de
Software entre as áreas
da empresa
Atributos
Não há utilização
formal de uma
metodologia de SOA
para desenvolvimento e
implementação de
sistemas
TI e negócio possuem
baixo conhecimento e
interesse em
implementar processos
baseados em serviços
Classificação
Ação
Negativo
Definir a
metodologia a
ser seguida no
desenvolvimento
e implementação
de sistemas
baseados em
SOA
Negativo
Disseminar o
conhecimento
SOA e a
importância da
mesma.
Métodos de SOA são
utilizados por equipes
ligadas ao ciclo de
Desenvolvimento de
Software, não há
uniformidade na
metodologia utilizada
Negativo
Métodos e práticas de
SOA foram
melhorados para
englobar a criação,
implementação e
entrega de serviços
Positivo
Metodologia focada na
implementação e
estruturação da
infraestrutura de TI e
de serviços de
integração
Positivo
Padronizar e
garantir, através
de controle de
qualidade, por
exemplo, a
correta
utilização da
metodologia
definida pela
empresa.
Evoluir com os
métodos e
práticas de SOA
e garantir a
correta
integração das
áreas/sistemas.
Garantir a
correta
integrações das
áreas/sistemas.
44
Nível
Serviços (Nível 4)
Serviços Compostos
(Nível 5)
Serviços Virtualizados
(Nível 6)
Serviços
Dinamicamente
Reconfiguráveis
(Nível 7)
Nome do Nível
Característica do
Nível
Atributos
Modelagem Orientada
a Serviços
Uso formal dos
conceitos de SOA no
Ciclo de Vida de
Desenvolvimento de
Software, mas de
maneira não integrada
As práticas e métodos
SOA foram
implementados pela
empresa, mas nem
todas as áreas seguem
uma abordagem
comum
Modelagem Orientada
a Serviços
Modelagem Orientada
a Serviços para
Infraestrutura
Modelagem de
Processos de Negócio
Uso formal dos
conceitos de SOA no
Ciclo de Vida de
Desenvolvimento de
Software de maneira
integrada
Uso formal dos
conceitos de SOA no
Ciclo de Vida de
Desenvolvimento de
Software com
integração entre as
áreas e com os
parceiros de negócio
Classificação
Ação
Negativo
Padronizar e
garantir, através
de controle de
qualidade, por
exemplo, a
correta
utilização dos
padrões criados.
Positivo
Estender as
práticas de
metodologia
SOA aos
parceiros.
Um grupo de pessoas
responde pelos
métodos e práticas
SOA na empresa
Positivo
Criar controles
de qualidade e
metas a serem
atingidas
Os métodos SOA
utilizados na empresa
contemplam os
serviços internos e
externos (parceiros)
Positivo
Implementar a
virtualização de
serviços.
Diretriz de boas
práticas para adoção de
SOA e tecnologias de
virtualização (por
exemplo, ESB e
repositório)
Positivo
Garantir
atualização e
constante
revisão das
diretrizes
adotadas.
Virtualização é o
elemento-chave para
operacionalização de
serviços e tratamento
de performance
Positivo
Implementar
arquitetura
virtualizada.
Positivo
Atingiu o
objetivo.
Uma metodologia SOA
formal é reconhecida o
qual é praticada por
toda empresa
Arquitetura de alto
Uso formal dos
desempenho para
conceitos de SOA no
suportar a virtualização
Ciclo de Vida de
e a modelagem de
Desenvolvimento de
serviços e processos de
Software suportando as
negócio
mudanças do negócio
dinamicamente.
Fonte: O Autor (2010).
Ao atingir o nível máximo de maturidade (Nível sete), a organização atendeu ao
seguinte objetivo: Uso formal dos conceitos de SOA no Ciclo de Vida de Desenvolvimento de
Software suportando as mudanças do negócio.
7.4 Dimensão de Aplicação
Foca no estilo de aplicação, estruturação de aplicações e decomposição funcional,
reusabilidade, flexibilidade, confiabilidade e extensão das aplicações, compreensão e uso
45
uniforme das melhores práticas e padrões, múltiplos aplicativos criados para atender
diferentes linhas de negócio com a mesma funcionalidade. Além disso, analisa a
disponibilidade do esquema da empresa e os modelos de objeto. A Figura 7 demonstra a
Dimensão de Aplicação.
Figura 7: Matriz OSIMM – Dimensão de Aplicação
Fonte: Open Group (2010).
Na Tabela 7 é demonstrada a matriz de ações e análise dos atributos de maturidade e
as ações propostas para esta dimensão.
Tabela 7: Matriz de Ações – Dimensão de Aplicação
Nível
Silo (Nível 1)
Integrado (Nível 2)
Nome do Nível
Módulos
Objetos
Característica do
Nível
Baixo ou inexistente
uso dos princípios de
serviços como, por
exemplo, baixo
acoplamento. São
empregadas também
tecnologias ligadas a
serviços como XML,
web services, ESB e
virtualização.
Uso limitado dos
princípios de serviços
como, por exemplo,
baixo acoplamento. São
empregadas também
tecnologias ligadas a
serviços como XML,
web services, ESB e
virtualização
Atributos
Sistemas não operam de
forma integrada
(arquitetura e topologia
dos sistemas não
possibilita integração)
O uso de web services
ou outras tecnologias
para desenvolvimento
SOA não está presente.
Há uma preocupação
em separar as
aplicações em camadas
ou níveis (por exemplo,
arquitetura de aplicação
em 3 camadas)
Classificação
Ação
Negativo
Estruturar
parque de TI
(rede,
hardware,
software)
para
possibilitar a
integração
dos sistemas
Negativo
Buscar a
tecnologia
para o
aplicação de
SOA na
empresa
Positivo
Evoluir
aplicação em
lógica e
física
46
Nível
Nome do Nível
Característica do
Nível
Atributos
Classificação
Ação
Negativo
Evoluir os
sistemas
enfatizando
as
integrações
entre eles
Utilização de práticas
de desenvolvimento
SOA, porém
inconsistente
Negativo
Criar
padrões,
regras e
implementar
corretamente
arquitetura
SOA
Maioria das aplicações
apresentam arquiteturas
baseadas em camadas
(por exemplo, separação
da camada de
apresentação da camada
de aplicativo da camada
de banco de dados)
Positivo
Evoluir
aplicação em
lógica e
física
Uso limitado de
integrações entre
sistemas. Já existem
algumas integrações
ponto-a-ponto (peer to
peer)
Componentizado
(Nível 3)
Serviços (Nível 4)
Serviços Compostos
(Nível 5)
Serviços Virtualizados
(Nível 6)
Componentes
Serviços
Aplicativos formados
por serviços compostos
Integração de Processo
via Serviço
Uso dos princípios de
serviços como, por
exemplo, baixo
acoplamento. São
empregadas também
tecnologias ligadas a
serviços como XML,
web services, ESB e
virtualização entre as
áreas da empresa
Uso dos princípios de
serviços como, por
exemplo, baixo
acoplamento. São
empregadas também
tecnologias ligadas a
serviços como XML,
web services, ESB e
virtualização pela
empresa, mas de
maneira não integrada
Uso dos princípios de
serviços como, por
exemplo, baixo
acoplamento. São
empregadas também
tecnologias ligadas a
serviços como XML,
web services, ESB e
virtualização pela
empresa, mas de
maneira integrada
Uso dos princípios de
serviços como, por
exemplo, baixo
acoplamento. São
empregadas também
tecnologias ligadas a
serviços como XML,
web services, ESB e
virtualização, com
integração entre as áreas
Criar
padrões,
regras e
implementar
corretamente
arquitetura
SOA
Implementar
mecanismos
(ex.
Framewoks)
para garantir
os padrões
estão sendo
seguidos
Evoluir e
garantir o
uso de ESB
em toda a
empresa
Implementar
mecanismos
(ex.
Framewoks)
para garantir
os padrões
estão sendo
seguidos
Tecnologias SOA
(exemplo, ESB) são
utilizados
inconsistentemente
Negativo
Utilização de padrões
SOA para separação de
regras de negócio e
lógica dos aplicativos
Positivo
Algumas áreas da
empresa já utilizam o
ESB para integração de
serviços
Positivo
Arquitetura da
aplicação é desenhada
contemplando 2
camadas: lógica e física
Positivo
ESB é usado para
compartilhamento de
serviços e integração de
processos
Positivo
Evoluir o uso
do ESB para
suportar
BPM
Positivo
Evoluir
arquitetura
dos
aplicativos
para suportar
a
remodelagem
do negócio
de forma
dinâmica
Arquitetura dos
aplicativos torna-se
independente dos
componentes da
infraestrutura
47
Nível
Serviços
Dinamicamente
Reconfiguráveis
(Nível 7)
Nome do Nível
Construção Dinâmica
de Aplicativo
Característica do
Nível
e com os parceiros de
negócio
Uso dos princípios de
serviços como, por
exemplo, baixo
acoplamento. São
empregadas também
tecnologias ligadas a
serviços como XML,
web services, ESB e
virtualização
suportando as mudanças
do negócio
Atributos
Classificação
Ação
ESB é utilizado para
suportar BPM
Positivo
Implementar
repositório
de Serviços
Arquitetura dos
aplicativos permite a
remodelagem do
negócio de forma
dinâmica. Serviços e
soluções SOA são
provisionados tanto
para áreas da empresa
quanto para parceiros
Positivo
Atingiu o
objetivo
Fonte: O Autor (2010).
Ao atingir o nível máximo de maturidade (Nível sete), a organização atendeu ao
seguinte objetivo: Uso dos princípios de serviços como, por exemplo, baixo acoplamento. São
empregadas também tecnologias ligadas a serviços como XML, web services, ESB e
virtualização suportando as mudanças do negócio.
7.5 Dimensão de Arquitetura
A dimensão de arquitetura está focada na estrutura da arquitetura que incluí topologia,
técnicas de integração, decisões sobre a arquitetura da empresa, padrões e políticas, nível de
adoção de web services, experiência em implementação SOA, conformidade SOA e típicos
artefatos produzidos. A Figura 8 demonstra a Dimensão de Arquitetura.
Figura 8: Matriz OSIMM – Dimensão de Arquitetura
Fonte: Open Group (2010).
48
Na Tabela 8 é demonstrada a matriz de ações e análise dos atributos de maturidade e
as ações propostas para esta dimensão.
Tabela 8: Matriz de Ações – Dimensão de Arquitetura
Nível
Silo (Nível 1)
Nome do Nível
Arquitetura Monolítica
Característica do
Nível
Atributos
Baixo ou inexistente
uso formal de conceitos,
Metodologias e/ou
metodologias, padrões e
padrões para SOA não
frameworks SOA para
podem ser identificados
especificação de
componentes de serviço
Pode ser identificado o
uso de metodologias
e/ou padrões SOA,
mesmo que limitado
Integrado (Nível 2)
Componentizado (Nível
3)
Serviços (Nível 4)
Arquitetura em
Camadas
Arquitetura de
Componentes
SOA Emergindo
Limitado uso formal de
conceitos,
metodologias, padrões e
frameworks SOA para
As metodologias e/ou
especificação de
padrões SOA são
componentes de serviço aplicados para organizar
a integração entre
sistemas e/ou
aplicativos
Uso formal de
conceitos,
metodologias, padrões e
frameworks SOA para
especificação de
componentes de serviço
entre as áreas da
empresa
Uso formal de
conceitos,
metodologias, padrões e
frameworks SOA para
especificação de
componentes de serviço
pela empresa, mas de
maneira não integrada
Algumas áreas da
empresa aplicam
metodologias e/ou
padrões SOA no
desenvolvimento de
especificações de
componentes de serviço
Arquitetura corporativa
é definida, mas as
práticas de governança
e o suporte de
ferramentas para
documentação da
arquitetura ainda é
limitada
As metodologias e/ou
padrões SOA são
utilizados por alguns
grupos da empresa
As metodologias e/ou
padrões SOA definidos
são refletidos na
maneira como
aplicativos e serviços
são especificados
Classificação
Ação
Negativo
Definir padrões
e/ou metologias
para
desenvolvimento
SOA
Positivo
Formalizar os
padrões e/ou
metodologias
utilizados na
empresa
Positivo
Documentar as
integrações com
o objetivo de
obter uma
definição da
arquitetura
Positivo
Difundir o uso
de metodologias
e/ou padrões
SOA para o
restante da
organização
Negativo
Implementar
ferramentas para
documentação
de artefatos
produzidos para
SOA
Positivo
Estender a
utilização de
metodologias
e/ou padrões
SOA para toda a
empresa
Positivo
Consolidar as
metodologias
e/ou padrões
SOA utilizados
pela empresa
49
Nível
Serviços Compostos
(Nível 5)
Serviços Virtualizados
(Nível 6)
Serviços
Dinamicamente
Reconfiguráveis
(Nível 7)
Nome do Nível
SOA
SOA em Grid
Arquitetura
dinamicamente
reconfigurável
Característica do
Nível
Uso formal de
conceitos,
metodologias, padrões e
frameworks SOA para
especificação de
componentes de serviço
pela empresa, mas de
maneira integrada
Atributos
A empresa usa
metodologias e/ou
padrões SOA de forma
unificada. A arquitetura
da empresa é suportada
por um modelo formal
de referência
Um padrão (modelo)
para informações
corporativas começa a
se formar
Os serviços e/ou
componentes de
serviços são
especificados utilizando
Uso formal de
metodologias e/ou
conceitos,
metodologias, padrões e padrões SOA definidos
frameworks SOA para visando reutilização dos
serviços
especificação de
componentes de serviço
com integração entre as
áreas e com os parceiros
Serviços para
de negócio
fornecimento de
informações comuns ao
negócio foram
desenvolvidos e
aplicados
Todos os componentes
de serviço especificados
seguem metodologias
e/ou padrões SOA
definidos e
documentados. As
Uso formal de
especificações são feitas
conceitos,
usando modelos
metodologias, padrões e padronizados e aceitos
frameworks SOA para
por todos
especificação de
componentes de serviço
suportando as mudanças
do negócio
Serviços para
fornecimento de
informações comuns ao
negócio e parceiros
externos da empresa
foram desenvolvidos e
aplicados
Classificação
Ação
Positivo
Implementar um
modelo de
referência que
permita o reuso
de serviços
Positivo
Formalizar um
padrão de
informações
corporativas na
organização
Positivo
Formalizar na
empresa os
modelos
promovem a
reutilização de
serviços
Positivo
Estender os
serviços de
informações
corporativas
para parceiros
Positivo
Atingiu o
Objetivo
Positivo
Atingiu o
Objetivo
Fonte: O Autor (2010).
Ao atingir o nível máximo de maturidade (Nível sete), a organização atendeu ao
seguinte objetivo: Uso formal de conceitos, metodologias, padrões e frameworks SOA para
especificação de componentes de serviço suportando as mudanças do negócio.
50
7.6 Dimensão de Informação
A dimensão de informação está focada em como a informação está estruturada, como
é modelada, o método de acesso, abstração do acesso de dados dos aspectos funcionais,
características dos dados, capacidade de transformação de dados, definições de serviços e
processos, definições, tratamento de identificadores, credenciais de segurança, gestão de
conhecimento, informação do negócio e gestão de conteúdo. A Figura 9 demonstra a
Dimensão de Informação.
Figura 9: Matriz OSIMM – Dimensão de Informação
Fonte: Open Group (2010).
Na Tabela 9 é demonstrada a matriz de ações e análise dos atributos de maturidade e
as ações propostas para esta dimensão.
Tabela 9: Matriz de Ações – Dimensão de Informação
Nível
Silo (Nível 1)
Integrado (Nível 2)
Nome do Nível
Característica do
Nível
Soluções de dados
específicos por
aplicativo
Baixo ou inexistente
uso arquitetura da
informação para
suportar um modelo de
dados mestre e
implementar um
vocabulário único de
negócios
Específica por Linhas
de Negócio
Limitado uso
arquitetura da
informação para
suportar um modelo de
dados mestre e
implementar um
Atributos
Não existe um modelo
conceitual da
informação na
organização
Classificação
Ação
Negativo
Implementar
um modelo de
informação na
empresa
A informação na
corporação encontra-se
replicada e redundante
Negativo
Inicio da utilização de
vocabulário de dados
Positivo
Eliminar
redundâncias
nas informações
e evitar a
replicação delas
Aplicar o
vocabulário de
dados em
aplicações ou
em sistemas
específicos
51
Nível
Componentizado (Nível
3)
Serviços (Nível 4)
Serviços Compostos
(Nível 5)
Nome do Nível
Modelos Canônicos
Informação como
Serviço
Dicionários de Dados
Corporativo e
Repositório
Característica do
Nível
vocabulário único de
negócios
Uso da arquitetura da
informação para
suportar um modelo de
dados mestre e
implementar um
vocabulário único de
negócios entre as áreas
da empresa.
Uso da arquitetura da
informação para
suportar um modelo de
dados mestre e
implementar um
vocabulário único de
negócios pela empresa,
mas de maneira não
integrada
Uso da arquitetura da
informação para
suportar um modelo de
dados mestre e
implementar um
vocabulário único de
negócios pela empresa,
mas de maneira
integrada
Atributos
A informação é
compartilhada entre
algumas aplicações
usando ETLM’s
(extração,
transformação, carga e
manipulação) ou por
trocas de mensagens.
Classificação
Ação
Positivo
Definir um
padrão comum
para trocas de
mensagens e
informações
entre
aplicativos
Vocabulário de dados
aplicados apenas em
aplicações ou em
sistemas específicos
Negativo
Início da utilização de
Modelos formais da
informação de negócios,
geralmente acessados
por XML.
Positivo
Múltiplas Unidades de
negócios utilizam
metadados
Positivo
Padronização do
vocabulário de dados de
negócios dentro de uma
unidade de negócios ou
área de processos
Positivo
Dados de negócio
podem ser
compartilhados dentro
de uma área de negócio
ou com parceiros de
maneira consistente. Os
padrões para troca de
mensagem são
definidos utilizando
vocabulários comuns
Utilização de serviços
para validação,
transformação,
integração, limpeza da
informação, entre outros
foram implementados
na corporação
Utilização de dados
mestre na corporação
em forma de serviços
Aplicar o
vocabulário de
dados em todos
os sistemas e
aplicações da
empresa
Padronizar o
vocabulário de
dados de
negócio dentro
das áreas, assim
como o método
que a
informação é
acessada
Formatar os
metadados em
serviços que
podem ser
consumidos por
toda corporação
Transformação
dos dados
padronizados
em dados
mestre que
podem ser
usados por toda
corporação
Positivo
Padronizar o
vocabulário de
dados de
negócio dentro
da corporação
Positivo
Extensão do
uso dos
serviços de
informação para
parceiros de
negócio
Positivo
Implementar o
gerenciamento
dos serviços
como se fossem
ativos
52
Nível
Nome do Nível
Característica do
Nível
Atributos
Padronização do
vocabulário de dados de
negócios para uso por
toda corporação
Serviços Virtualizados
(Nível 6)
Serviços
Dinamicamente
Reconfiguráveis
(Nível 7)
Serviços de Dados
Virtualizados
Vocabulários de Dados
Semânticos
Uso da arquitetura da
informação para
suportar um modelo de
dados mestre e
implementar um
vocabulário único de
negócios pela empresa
com integração entre as
áreas e com os parceiros
de negócio.
Uso da arquitetura da
informação para
suportar um modelo de
dados mestre e
implementar um
vocabulário único de
negócios suportando as
mudanças de negócio.
Os vocabulários de
dados de negócios
permitem adaptação
(mesmo que com alto
custo) a fim de suportar
mudanças nos serviços,
parceiros e
remodelagem dos
processos de negócio
Classificação
Ação
Positivo
Implementar e
divulgar um
modelo de
informações
formal aceito
por toda
corporação
Positivo
Permitir fácil
adaptação dos
vocabulários de
dados de
negócio as
mudanças nos
processos de
negócio
Adotar padrões
de dados
definidos por
entidades
inerentes a
organização
Implementar e
divulgar um
modelo de
informações
formal aceito
por toda
corporação e
pelos parceiros
de negócio
Um registro com
metadados é usado para
gerenciar ativos de
serviço da corporação
Positivo
Desenvolvimento e
implementação de um
modelo de informação
formal para corporação
Positivo
Os vocabulários de
dados de negócios
permitem fácil
adaptação a fim de
suportar mudanças nos
serviços, parceiros e
remodelagem dos
processos de negócio.
Positivo
Atingiu o
Objetivo
Os dados de negócios
são definidos utilizando
construções semânticas
web ou ontologias
(UN/CEFACT Core
Componentes, ISO
11179);
Positivo
Atingiu o
Objetivo
Aplicação de um
modelo formal de
informação para
corporação incluindo
tanto a empresa e
entidades de
relacionamento externo.
Positivo
Atingiu o
Objetivo
Fonte: O Autor (2010).
53
Ao atingir o nível máximo de maturidade (Nível sete), a organização atendeu ao
seguinte objetivo: Uso da arquitetura da informação para suportar um modelo de dados mestre
e implementar um vocabulário único de negócios suportando as mudanças de negócio.
7.7 Dimensão de Infraestrutura & Gerenciamento
A dimensão de Infraestrutura & Gerenciamento está focada nas capacidades de
infraestrutura da organização, gerenciamento do serviço, das operações de TI, administração
de TI e gerenciamento de TI, como as SLAs são atendidos, como é feito o monitoramento, e
que tipos de plataforma de integração estão presentes. A Figura 10 demonstra a Dimensão
Infraestrutura & Gerenciamento.
Figura 10: Matriz OSIMM – Dimensão de Infraestrutura & Gerenciamento
Fonte: Open Group (2010).
Na Tabela 10 é demonstrada a matriz de ações e análise dos atributos de maturidade e
as ações propostas para esta dimensão.
Tabela 10: Matriz de Ações – Dimensão de Infraestrutura & Gerenciamento
Nível
Silo (Nível 1)
Nome do Nível
Característica do
Nível
Atributos
Plataforma Específica
por Linhas de Negócio
Baixo ou inexistente
suporte da infraestrutura
de TI em relação aos
requisitos operacionais
e não funcionais além
do atendimento das
SLAs relacionadas a um
ambiente SOA
Capacidade baixa ou
inexistente para a
entrega de serviços de
TI
Classificação
Ação
Negativo
Melhorar a
capacidade de
entrega de
serviços de TI
utilizando SLAs
para entrega
dos serviços
54
Nível
Integrado (Nível 2)
Componentizado (Nível
3)
Serviços (Nível 4)
Serviços Compostos
(Nível 5)
Nome do Nível
Padrões Corporativos
Característica do
Nível
Limitado suporte da
infraestrutura de TI em
relação aos requisitos
operacionais e não
funcionais além do
atendimento das SLAs
relacionadas a um
ambiente SOA
Atributos
Soluções de integração
para controlar o fluxo
de dados estão presentes
na integração entre os
sistemas
SLAs para o
gerenciamento dos
serviços de TI e uma
política de segurança
está presente de maneira
limitada
Infraestrutura comum e
reutilizável
Suporte da
infraestrutura de TI em
relação aos requisitos
operacionais e não
funcionais além do
atendimento das SLAs
relacionadas a um
ambiente SOA entre as
áreas da empresa
SLAs para o
gerenciamento dos
serviços de TI e uma
política de segurança
existe. Tanto a política
de segurança quanto as
SLAs foram divulgadas
para que algumas áreas
da empresa façam uso
Ambiente SOA baseado
em Projetos
Suporte da
infraestrutura de TI em
relação aos requisitos
operacionais e não
funcionais além do
atendimento das SLAs
relacionadas a um
ambiente SOA pela
empresa, mas de
maneira não integrada
Área de TI provê
serviços que abrangem
todo o negócio e seus
usuários
Ambiente SOA comum
Suporte da
infraestrutura de TI em
relação aos requisitos
operacionais e não
funcionais além do
atendimento das SLAs
relacionadas a um
ambiente SOA pela
empresa, mas de
maneira integrada
A área de TI é capaz de
fornecer um serviço que
pode ser medido
qualitativamente e
consegue também
fornecer aplicativos
modularizados
(compostos de
componentes com baixo
acoplamento)
As políticas de
segurança definidas são
monitoradas e
cumpridas por todos na
empresa
Classificação
Ação
Positivo
Padronizar as
soluções de
integração entre
sistemas
Negativo
Implementar
SLAs para o
gerenciamento
de serviços de
TI e uma
política de
segurança na
corporação
Positivo
Formalizar a
política de
segurança em
toda a
corporação
assim como as
SLAs para uso
pela empresa
Positivo
Implementar
métricas para
medição
qualitativa dos
serviços pela
empresa.
Positivo
Utilizar as
métricas de
serviço
coletadas para
revisão
contínua dos
serviços
existentes
Positivo
Estender a
aplicação da
política de
segurança aos
parceiros de
negócio
55
Nível
Serviços Virtualizados
(Nível 6)
Serviços
Dinamicamente
Reconfiguráveis (Nível
7)
Nome do Nível
Ambiente SOA
Virtualizado: Sente &
Responde
Adaptados a Contexto,
Baseado em Evento:
Sente & Responde
Característica do
Nível
Suporte da
infraestrutura de TI em
relação aos requisitos
operacionais e não
funcionais além do
atendimento das SLAs
relacionadas a um
ambiente SOA com
integração entre as áreas
e com os parceiros de
negócio
Atributos
Classificação
Ação
Positivo
Dinamizar o
uso de serviços
idênticos para
finalidades
distintas
Gerenciamento de
desempenho e de
serviço serve de
subsídio para a criação
e entrega de novos
serviços e/ou revisão
dos serviços atuais
Positivo
Implementar o
Gerenciamento
de Serviços e
desempenho da
maneira a
atender as
demandas
futuras
A gestão dos serviços
de TI é feita visando
atender as mudanças
requeridas pelo negócio
tanto atualmente quanto
futuramente
Positivo
Atingiu o
Objetivo
Positivo
Atingiu o
Objetivo
Positivo
Atingiu o
Objetivo
Soluções SOA possuem
controle de versão e são
entregues para
desenvolvimento, teste,
validação funcional, e
produção e rodam em
barramentos que
atendem cada uma
destas necessidades
Suporte da
infraestrutura de TI em
relação aos requisitos
operacionais e não
Os mesmos serviços
funcionais além do
podem ter usos
atendimento das SLAs distintos, mas sem gerar
relacionadas a um
impacto para qualidade
ambiente SOA
dos serviços fornecidos
suportando as mudanças
pela TI
do negócio
As políticas de
segurança da empresa
são aplicadas aos
serviços em tempo real
Fonte: O Autor (2010).
Ao atingir o nível máximo de maturidade (Nível sete), a organização atendeu ao
seguinte objetivo: Suporte da infraestrutura de TI em relação aos requisitos operacionais e não
funcionais além do atendimento das SLAs relacionadas a um ambiente SOA suportando as
mudanças do negócio.
56
8 CONCLUSÃO
Conclui-se que o OSIMM é uma ferramenta que tem aplicação bastante prática para
empresas avaliarem a sua maturidade em relação a adoção de uma Arquitetura Orientada a
Serviços (SOA). Inicialmente, o presente trabalho tinha como objetivo reformular o
questionário base do OSIMM e propor um roadmap com as ações que as empresas
precisariam executar para atingir um nível de maturidade maior reduzindo a complexidade do
OSIMM e tornando-o um guia mais prático. Mas, durante o desenvolvimento do estudo,
pode-se notar que o OSIMM fazia sentido da maneira como foi formulado e propor
ferramentas ou metodologias seria desnecessário.
Assim, o intuito foi demonstrar o estudo do OSIMM, as dimensões que existem e suas
premissas de avaliação. Percebeu-se que uma empresa pode estar em diferentes estágios em
diferentes dimensões e entendeu-se que avaliar a maturidade SOA numa empresa é avaliar o
tão qual a empresa está integrada e estruturada para vivenciar SOA.
Portanto, o OSIMM é uma ferramenta que prevê a melhoria contínua onde a partir de
certo nível de maturidade (geralmente a partir do nível quatro) não há mais ações negativas
(que demandam atenção – corretivas) a serem executadas e as ações passam a ser evolutivas e
positivas, visando sempre a melhoria contínua onde cabe a empresa decidir se convive com o
nível de maturidade atual ou se parte para novos níveis de maturidade.
8.1 Trabalhos Futuros
Com o objetivo de estender o estudo do OSIMM, sugere-se a aplicação deste método
de avaliação em uma empresa gerando um estudo de caso.
Além disso, a construção de um repositório com avaliações realizadas na empresa
como um meio de acompanhamento na implementação e avaliação de SOA, também poderia
ser um tema para trabalhos futuros.
57
REFERÊNCIAS BIBLIOGRÁFICAS
ABC DA SOA. Disponível em: <http://cio.uol.com.br/tecnologia/2006/07/17/idgnoticia.200607-17.3732358054>. Acesso em maio 2010.
CIO. Disponível em: <http://www.cio.com>. Acesso em maio 2010.
DAVENPORT, Thomas. Tecnologia e Gestão da Informação. São Paulo, 1997.
ERL, Thomas. SOA Princípios de design de serviços. São Paulo: Pearson Prentice Hall, 2009.
FORRESTER. Best Practices: Business Activity Monitoring Adoption. April 17, 2008.
GARTNER Group. The 13 Most Common SOA Mistakes and How to Avoid Them.
September, 2009a.
GARTNER Group. Two Factors That Help Identify the BPMS 'Sweet Spot'. May 13, 2008a.
GARTNER, Group. Business Process Management Program Key Initiative Overview.
September 18, 2009b.
KOTLER, Philip. Administração de Marketing. São Paulo: Pearson Prentice Hall, 2006.
MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI
na Prática. São Paulo: Novatec Editora Ltda, 2007.
MANAGEENGINE. Disponível em:
<http://www.manageengine.com/products/applications_manager/images/thumbnail/businessapplication.gif >. Acesso em abril 2010.
MSDN, Microsoft. Disponível em <http://www.msdn.microsoft.com>. Acesso em abril 2010.
58
OASIS. Disponível em <http://docs.oasis-open.org/wsbpel/2.0/OS/wsbpel-v2.0-OS.html>.
Acesso em maio 2010.
OGC. Disponível em <http://www.ogc.gov.uk>. Acesso em abril 2010.
OMG. Disponível em <http://www.omg.org>. Acesso em abril 2010.
OPEN GROUP. Disponível em <http://www.opengroup.org>. Acesso em maio 2010.
SIX SIGMA. Disponível em <http://www.isixsigma.com>. Acesso em abril 2010.
SORDI, José Osvaldo de. Gestão por Processos. 2.ed. São Paulo: Editora Saraiva, 2008.
TECHTARGET. Disponível em
<http://media.techtarget.com/digitalguide/images/Misc/bpm_1.gif.>. Acesso em abril 2010.
W3C. Disponível em < http://www.w3.org/TR/2002/WD-ws-arch-20021114/>. Acesso em
abril 2010.
WS-I. Disponível em <http://www.ws-i.org>. Acesso em abril 2010.
59
GLOSSÁRIO
Arquitetura em 3 Camadas – arquitetura que envolve a separação de funcionalidades
de um sistema objetivando separar a lógica de apresentação(front end), as regras de negócio e
acesso ao banco de dados.
ESB(Enterprise Service Bus) – método que permite a interconexão entre diversos
sistemas e plataformas que se utilizam de tecnologias diferentes.
Framework – estrutura fundamental ou conjunto de estruturas, que pode ser usada
para desenvolver uma variedade de produtos de arquitetura. Um framework de arquitetura
deve conter um método para desenhar um sistema de informação em termos de um conjunto
de serviços e uma visão de como os serviços se encaixam. Um framework deve conter um
conjunto de ferramentas e providenciar uma vocabulário comum.
Metadados – são os dados utilizados no processamento, atualização e consulta de
informações para uma administração de dados.
Modelo Canônico – modelo flexível para integração de dados.
Modelo de Dados Mestre – base de dados mestre, armazenada de forma centralizada.
Modelo de Maturidade -
um tipo de escala para avaliação do estado atual de
maturidade. Um modelo de maturidade também proporciona um meio para desenvolvimento
de um roadmap para atingir um estado
Organização - combinação de esforços individuais que tem como objetivo realizar
propósitos coletivos.
Serviços de Negócio - uma funcionalidade de negócio encapsulada que pode ser
chamada através de uma interface bem definida e protocolo, independente da plataforma de
implementação, e gerenciada por um contrato que especifica níveis de disponibilidade e a
qualidade do serviço acordada.
Serviços Virtualizados – exposição de serviços complexos (que envolvem validação,
transformação, redicionariamento) com o objetivo de facilitar o acesso a um determinado
serviço.
SLA(Service Level Agreement) - contrato entre fornecedor de serviços de Tecnologia
da Informação e, na qual são especificados em termos mensuráveis, quais serão os serviços
prestados pelo fornecedor.
Web Services - tecnologia de chamada remota de serviço, que utiliza protocolos Web
como meio de transporte e comunicação.
60
XML(Extensible Markup Language) – linguagem de marcação extenssível, estrutural
de documentos digitais
61
ANEXO A – FIGURAS AMPLIADAS
62
63
64
65
66
67
68
69