204
2015
A Method for SOA Maturity Assessment and
Improvement
C. F. Mazzarolo, V. A. Martins, A. A. Toffanello and R. S. Puttini
1Abstract— This work presents a model for corporate
maturity assessment to evaluate and improve Service Oriented
Architecture (SOA) adoption. The model is designed by
parameterization of a best practices knowledge base in survey´s
questions to support evaluation, planning and monitoring the
evolution of organizational maturity in SOA. The proposed
model is divided into several domains and is carried out inside
each domain qualitatively based on quantitative methods. Its
concept significantly extends the model The Open Group Service
Integration Maturity Model (OSIMM), by allowing the direct
monitoring of all strategic goals and their fundamental practices
(service lifecycle and design principles). The application of the
model is supported by a software system that provides electronic
questionnaires, described in a knowledge base and performs
classification of maturity through a heuristic method itself. The
analysis results provide information to managers, consultants
and IT professionals, to perform systematically adjustments of
SOA adoption and generate proposed tasks to obtain a desired
maturity stage. Therefore, this model proposes activities to
stabilize a current state in SOA adoption, or even actions for
achieving a higher level of SOA maturity through reference
roadmaps.
Keywords— SOA, Maturity Model, Quantitative
Assessment.
I. INTRODUÇÃO
A RQUITETURA Orientada a Serviço - SOA (Service
Oriented Architecture) é entendida como um modelo
que busca maximizar a integração dos processos de
negócios com a infraestrutura de recursos de Tecnologia da
Informação (TI), na forma de componentes seguros e
padronizados - usualmente webservices - que podem ser
reutilizados e combinados para dar agilidade às rápidas
mudanças de prioridades do negócio [4].
Como consequência, SOA transfere para o negócio essa
capacidade de escalabilidade e evolução, oferecendo suporte
para as constantes necessidades de mudança nos processos
de negócio. Porém, para aplicação correta de SOA, é
necessária uma revisão dos princípios de gestão por
processos, que implica não só no envolvimento das pessoas,
mas em estabelecer uma boa comunicação e oferecer suporte
necessário para que todos os envolvidos possam lidar com as
mudanças nos processos de negócio pelo uso de boas
práticas na execução de seus serviços.
Presente nas discussões de TI desde os anos 80, foi a
1
C. F. Mazzarolo, Instituto Brasília de Tecnologia e Inovação (IBTI/UnB),
Brasília, DF, Brasil, claynor.mazzarolo@ibti.net.br
V. A. Martins, Universidade de Brasília (UnB), Brasília, DF, Brasil,
valeriomartins@unb.br
A. A. Toffanello, Instituto Brasília de Tecnologia e Inovação (IBTI/UnB),
Brasília, DF, Brasil, andre.toffanello@ibti.net.br
R. S. Puttini, Universidade de Brasília (UnB), Brasília, DF, Brasil,
puttini@unb.br
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN.
partir de uma revisão em 2005 que SOA obteve coerência
estrutural quando Erl [9] fundamentou sua aplicação por
meio de princípios que estabelecem o entendimento de
"orientação a serviços".
Esses princípios alinham os objetivos estratégicos do
negócio com a contínua aplicação de tecnologia e suas
melhorias, estimulado pela existência de unidades
individuais autônomas que realizam contextos funcionais
únicos e podem ser agrupadas na forma de composições para
a realização de tarefas complexas, até a execução de todos os
processos de negócio.
Assim, o nível de sucesso na adoção e uso de SOA está
relacionado à transferência das capacidades de TI para os
processos de negócio. Porém, para que essa transferência
seja assertiva é necessário acompanhar e mensurar a
melhoria de desempenho dos processos que seus serviços
atendem [16]. Nesse sentido, a adoção dessa arquitetura deve
ser conduzida por meio de atividades governadas e
mensuradas, ([16], [17], [20]) com o propósito claro de se
obter o máximo retorno dos investimentos.
Como resultado, este trabalho propõe um modelo para
avaliação do nível de maturidade da aplicação de SOA nas
organizações, a partir da quantificação do grau de
transferência entre a TI e o negócio, na forma de um
framework que pode ser aplicado em ciclos sucessivos de
avaliação. O que se propõem nesse modelo é a mensuração
dos níveis de aplicação, da transferência entre a TI e o
negócio, e que a integração dos elementos - que suportam os
princípios de orientação a serviços - sejam quantificados na
forma de controles, análogo ao que é aplicado junto ao
framework COBIT [14].
Entende-se que o desafio enfrentado, em propor um
modelo de maturidade para SOA baseado em controles, está
em identifica-los e sistematizar a avaliação desses controles
de forma a atender as numerosas relações de
interdependência ou de subordinação que esses têm entre si,
que é característico da correta aplicação dessa arquitetura.
Como resultado, entende-se que realizar atividades
visando a sintonia de cada requisito estabelecido como
controle junto aos seus correlatos ou dependentes é que
permite governar de forma eficaz o processo de adoção ou de
uso de SOA.
Assim, as principais contribuições do modelo proposto
neste trabalho são de propor um arquétipo que permita
estruturar os controles em estratégias de análise em cada
domínio organizacional; rever a visão de avaliação do
controle para assuntos afetos à competências distintas
existentes na organização; e, oferecer revisão aos objetos de
controle da maturidade em SOA já apresentados em outros
modelos de maturidade para essa arquitetura ([1], [2], [4],
[5], [19], [22], [25], [32], [33], [35]).
MAZZAROLO et al.: A METHOD FOR SOA MATURITY
Neste trabalho, o modelo proposto foi testado em uma
instituição de grande porte, em avaliações periódicas (2011,
2012 e 2014). A aplicação do modelo permitiu avaliar a
evolução do nível de maturidade em cada ciclos de adoção e
uso da Arquitetura Orientada a Serviços, bem como identificar
e projetar as ações necessárias para de evolução desta
maturidade a um patamar desejado.
II. CONCEITUAÇÃO
A. Orientação a Serviço
O termo “Orientação a Serviço” tem sido usado em
diversos contextos no âmbito organizacional, em especial,
associado ao uso em Tecnologia da Informação. Porém, seu
uso diverso - até mesmo além da fronteira da TI - tem
provocado uma profusão de conceitos que, embora não sejam
antagônicos, exploram diferentes domínios do termo para
diferentes propósitos.
Na sua definição atual [23], o fator estratégico do sucesso
de SOA está baseado no alinhamento da arquitetura com os
objetivos e contexto de negócio da organização. Porém, em
seus conceitos originais, o foco do uso de SOA era
tecnológico [26], o que dificultava a visão da transferência
entre os recursos tecnológicos e as necessidades da arquitetura
dos processos empresariais. Como condutor de uma revisão na
arquitetura, de forma a organizar o conhecimento existente à
época, em 2005, Erl agrupou e condensou as práticas de
projeto que valorizavam a orientação a serviços, formando o
alicerce de seu emprego por meio de oito princípios, que,
aplicados em conjunto, são fatores fundamentais para a correta
incorporação de SOA por uma organização com a aplicação
da Computação Orientada a Serviços [10].Porém, como um
modelo arquitetural, a aplicação de SOA se dá de forma
continuada, suportada por avaliações tempestivas que
patrocinam ciclos de melhoria contínua. Essas avaliações
buscam mitigar a possibilidade de fracasso na construção dos
elementos fundamentais dessa arquitetura.
Assim, o conceito de modelo de maturidade está associado
diretamente ao resultado dessas avaliações.
B. Modelos de Maturidade
Constitui-se de tarefa difícil avaliar a posição da TI em
relação a uma estratégia. Para cada aspecto da TI sob
investigação, surgem questões que precisam ser medidas e
comparadas a referenciais específicos de boas práticas, a fim
de se quantificar a qualidade ou estabelecer um grau
específico de maturidade. Modelos de maturidade são
ferramentas úteis para abordar essas questões [8].
Neste sentido, essas avaliações, quando associadas a um
modelo referencial, são necessárias para compreender e
posicionar a maturidade de uma organização em provimento
de serviços ao longo do tempo, medida contra um conjunto-
padrão de definições, o que ainda possibilita o
acompanhamento do processo de melhoria contínua dos
elementos correspondentes na arquitetura empresarial [3].
Assim, esses modelos de maturidade ajudam aos
elementos-chave da organização a reconhecer o seu ganho,
isto é, quais e em quanto os objetivos de negócio são elevados
pelas mudanças em seu nível maturidade [18]; ou qual fator ou
controle precisa de intervenção.
205
Em geral, um modelo de maturidade é composto por uma
sequência de níveis, e representa um caminho de evolução
esperado, desejado, ou mesmo caminhos típicos em forma de
estágios discretos.
Ao longo dos últimos anos, uma variedade de modelos de
maturidade tem sido desenvolvida para apoiar a gestão de TI,
sendo reconhecido como referência o modelo nominado de
Capability Maturity Model Integration - CMMI [6], [8].
Esse modelo estabelece estágios de maturidade, associados
com a capacidade de formalizar, mensurar e suportar a
otimização dinâmica dos processos de TI
O modelo CMMI acomoda ainda múltiplas disciplinas, e é
flexível o suficiente para suportar duas representações
diferentes [6]. São essas as representações:
a) Representação em Estágios: Provê uma sequência de
cinco estágios de melhoria bem definidos, cada um servindo
como base para o próximo. Nessa representação, por ser
pontual, a ordem de melhoria é rígida e os estágios são
cumulativos e dependentes dos anteriores.
b) Representação Contínua: oferece maior flexibilidade, pois
permite selecionar a área de processo a ser aperfeiçoada ou a
ordem em que as melhorias serão feitas. Também utiliza o
conceito de níveis de capacidade para caracterizar a melhoria de
processos individuais [6].
Assim, se observado sob a ótica de um ciclo contínuo de
melhoria, os dois modelos do CMMI podem se complementar
na medida em que um modelo em evolução (em busca de um
novo estágio) está relacionado à representação contínua;
enquanto a representação em estágio define uma posição estável
ou em estabilização. O Quadro 1 ilustra o relacionamento entre
os estágios do CMMI.
Quadro 1. Representação Contínua e em Estágios do CMMI v 1.3.
III. TRABALHOS RELACIONADOS
Reconhecida a importância de modelos de maturidade
como instrumento para a correta e ampla governança nas
iniciativas de adoção de SOA nas organizações, é natural a
existência de diversos frameworks para a avaliação da
maturidade na adoção e uso dessa arquitetura.
Desses frameworks, enquanto porção significativa de
autores, a exemplo de [4], defende uma abordagem mais
estratégica mediante mudanças organizacionais; outros focam
uma investida mais técnica, principalmente no que se refere ao
gerenciamento do ciclo de vida de serviços, caso do modelo de
[2], que posteriormente foi incorporado pela [25].
Os trabalhos [7], [24], [27] e [34] elaboraram uma
comparação entre esses frameworks, na qual destacamos o
tratamento dos elementos de Governança SOA:
• Alinhamento da TI aos requisitos do negócio [7], [19];
• Gestão do contexto do ciclo de vida do negócio [5], [32];
206
• Equilíbrio de custos e acompanhamento do ROI [7], [33];
• Suporte a tomadores de decisão [4], [33];
• Balanceamento e controle de riscos e oportunidades em
ambientes dinâmicos [7], [33];
• Atendimento de pontos internos de conformidade e
externos de regulação [25];
• Foco no uso de padrões metodológicos [25], [30];
• Gerenciamento do ciclo de vida dos serviços [2], [13].
Os trabalhos de [7], [24], [27] apresentam as relações entre
os modelos existentes e os domínios organizacionais, e
identificam as características que afetam e/ou que são afetadas
pelos padrões de Governança SOA.
Contemporâneo a esses trabalhos, o The Open Group
apresentou em 2011 um modelo baseado no TOGAF, que
busca atender às necessidades de avaliação pelas
organizações [31]. O uso desse framework pode ser adaptado
de acordo com as necessidades da organização.
Ainda, no que se refere a qualificação do estágio de
maturidade, a partir da análise dos modelos citados,
observa-se que a identificação dos níveis de maturidade é
analisada segundo duas óticas:
a) Pela aderência em estágios de maturidade no uso de
tecnologia de serviços web no suporte à aplicação dos
princípios e paradigmas de SOA [2], [11], [13], [21], [29].
Assim, nesses referenciais estão impostas escalas que
envolvem o menor ou maior uso tecnológico SOA, ou menor
ou maior volume de seu uso;
b) Pela associação direta ou indireta a referência
tradicional de maturidade organizacional em TI (o CMMI)
[12], [15], [25] e seus elementos de avaliação. Dessa forma,
esses modelos de maturidade para SOA são afetos em
quantidade e forma de avaliação aos cinco níveis tradicionais
do CMMI [6].
Neste contexto, o modelo proposto neste trabalho analisa e
acompanha claramente o processo de evolução na escala de
maturidade, enquanto os trabalhos estudados buscam
identificar apenas os estágios em que a organização se
posiciona. Assim, essa lacuna está presente em vários
trabalhos, que não proveem mecanismo para acompanhar as
etapas de evolução entre patamares distintos junto aos estágios
da representação do CMMI.
IV. MODELO PROPOSTO
A. Apresentação
O modelo proposto, em seu nível fundamental, é
semelhante às proposições existentes de avaliação de modelo
de maturidade: uma avaliação qualitativa, baseada em técnicas
quantitativas e estatísticas, do nível de maturidade SOA dentro
de cada domínio organizacional. Porém, além de tratar o
acompanhamento ao longo de uma evolução entre níveis de
maturidade distintos, apresenta uma revisão das métricas junto
a todos os modelos estudados, e foca nos objetos finalísticos a
serem analisados: os controles. Assim, o modelo prevê uma
estrutura hierárquica de domínios, controles e itens de
avaliação como uma solução para avaliar o resultado da
adoção correta e integrada de SOA em seus estágios.
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
No que se refere ao suporte quantitativo, a Fig. 1 ilustra a
base do modelo proposto, demonstrando a relação dos
domínios em controles, controles esses que são avaliados a
partir de itens de avaliação por uma declaração explícita em
questionários.
Observa-se como resultado da Fig. 1 que o modelo de
avaliação de maturidade SOA proposto segue um princípio de
estruturação top-down no qual a maturidade corporativa de
SOA pode ser estimada pelo nível de maturidade de cada
domínio, e gerados e analisados através de controles,
elementos efetivos de acompanhamento e medição que
representam a contribuição de determinada prática para
maturidade de um domínio.
Figura 1. Arquitetura do Modelo de Maturidade Proposto.
O nível de maturidade de cada controle é obtido pela
avaliação de itens associados nos questionários, que são
organizados por domínio.
Como já citado, além de alinhar através de um nível
qualitativo com a arquitetura, a estrutura proposta também
permite governar o uso de SOA, através de roteiros de
referência, obtidos pelos resultados das avaliações dos
controles, agrupados por domínios em um determinado
momento.
Dessa forma, mediante a execução sequenciada de roteiros
de evolução, com o ajuste dos pontos fortes e fracos existentes
na adoção e uso de SOA, o objetivo organizacional de
estabilizar ou evoluir a arquitetura em relação a uma escala de
maturidade fica facilitado.
B. Níveis de Maturidade
Como a escala de maturidade do CMMI, com seus cinco
estágios, é comumente usada para sustentar a avaliação de
maturidade da TI em geral, diversos trabalhos anteriores já
buscam estabelecer um mapeamento desse modelo de
avaliação de nível de maturidade para SOA [11], [29].
O método proposto neste trabalho identifica os níveis de
maturidade, observando tanto a ótica dos estágios aderentes ao
uso da tecnologia no suporte à aplicação dos princípios e
MAZZAROLO et al.: A METHOD FOR SOA MATURITY
paradigmas específicos de SOA [15], como também a
associação com o CMMI que é a referência tradicional de
maturidade em TI [28]. Porém, como o CMMI, suporta as
duas representações diferenciadas de níveis de maturidade
analisadas na sua definição: Representação em Estágio e
Representação Contínua [6]. Nessa ótica, este trabalho propõe
uma revisão no conceito dessas representações a partir do que
se observa na prática da aplicação de um ciclo contínuo de
melhoria organizacional.
Nesse ciclo, as melhorias contínuas podem ocorrer em
duas situações distintas: quando uma melhoria está sendo
aplicada para Evolução a um nível maior de maturidade, ou
quando uma organização está empenhada na Estabilização de
um nível de maturidade que foi antecipadamente planejado.
Assim, compreendem-se como Estabilização as atividades
necessárias para que a organização possa estar completa e
reconhecidamente aderente a um nível de maturidade definido,
isto é, onde os controles sejam matematicamente significativos
para estabelecer esse nível. Já por Evolução, compreende-se
que a organização está em um estágio reconhecido como
aderente, e está realizando as atividades adequadas de
planejamento e execução para atingir um novo patamar de
maturidade.
Neste sentido, o modelo proposto neste trabalho adota a
escala de maturidade do CMMI - nas suas representações em
estágio e contínua - formando um único modelo contemplando
passos intercalados de estabilização (em estágios) com
processos de evolução. A Fig. 2 ilustra esse entendimento.
Figura 2. Representação em Estágios: Estabilização e Evolução.
O modelo proposto suporta uma indicação sequenciada de
cada uma dessas situações: se a organização está preparada para
promover uma Evolução ou está em um processo de
Estabilização. Os princípios utilizados para avaliar esses eixos
consideram que a organização em processo de Evolução esteja
aderente ao mínimo necessário do estágio precedente de
Estabilização, pois esse será o nível de maturidade a ser
reportado pelo modelo. Assim sendo, o modelo proposto
adaptou a declaração de níveis tal qual exposto no Quadro 2.
Quadro 2. Níveis de Maturidade na Estabilização e na Evolução.
207
Observa-se que tanto para o aspecto de quantificação -
para qualificação do estágio de maturidade - quanto para o
aspecto de aderência, os resultados obtidos devem nortear a
formação de dois roteiros distintos: de Evolução ou de
Estabilização.
Assim, levando-se em conta o critério pré-estabelecido de
alinhamento dos níveis de conformidade com os princípios do
modelo de maturidade do CMMI, em sua versão de
representação em estágios, foi elaborado um modelo que
permite a mensuração permanente do nível de maturidade e
possibilita a aplicação desse critério segundo a avaliação dos
domínios a serem controlados pelo modelo proposto, a saber:
domínios e controles para análise.
Na ótica de um modelo sequenciado, alternando estágios
de estabilização e em evolução (contínuo), tem-se então:
a) Estabilização da Iniciação em 1 (nível 1) – Inicial:
caracterizado por um planejamento intempestivo (ad-hoc)
da SOA.
b) Evolução de 1 para 2 (nível 1,5) – Em Gerenciamento: a
organização busca abandonar seu estágio inicial e caótico
pelo planejamento e estabelecimento dos requisitos iniciais
para SOA;
c) Estabilização em 2 (nível 2) – Gerenciado: os processos da
organização são planejados, executados, medidos e
controlados, e seus requisitos são gerenciados, os projetos
são executados e geridos de acordo com os planos
documentados.
d) Evolução de 2 para 3 (nível 2,5) – Em Definição:
caracterizada pela expansão dos serviços pelo uso
exaustivo de SOA em projetos diários, visando à
construção de um portfólio de serviços, tendo como foco a
reutilização desses e a aplicação dos princípios de
orquestração dos mesmos.
e) Estabilização em 3 (nível 3) – Definido: nesse estágio, os
serviços estão proliferados junto a processos que são bem
caracterizados, compreendidos, e estão descritos em
normas, procedimentos, ferramentas e métodos.
f) Evolução de 3 para 4 (nível 3,5) – Em Quantificação
Gerenciada: nesse estágio iniciam-se atividades visando à
formação e ajuste de processos que permitem a
mensuração efetiva dos resultados obtidos pela aplicação
de SOA.
g) Estabilização em 4 (nível 4) – Mensurado: caracterizado
pela medição e avaliação do impacto visível de SOA ao
negócio, da extensão dos serviços para os processos de
automação de negócio, com a quebra dos silos na
organização.
h) Evolução de 4 para 5 (nível 4,5) – Em Otimização:
é caracterizado pela forte realização da capacidade de
descoberta e, assim, SOA prolifera em toda a empresa.
i) Estável em 5 (nível 5) – Otimizado: o foco na medição é
estendido para como SOA é usado. Assim a medição
produz um processo de realimentação que suporta
melhorias, que inclui medidas não só de negócios.
Esse modelo, então, permite um contínuo ciclo de
evolução acompanhado de guias de evolução, quando
estabilizado em um estágio, ou de estabilização, quando em
um processo de evolução para novo estágio. O uso de valores
208
intermediários na representação ainda permite uma clara
associação quantitativa entre o modelo proposto e o CMMI.
C. Domínios
Dos modelos avaliados anteriormente, entende-se que o
conceito de Domínio como agregador elementar para os
requisitos que são inerentes a avaliação de maturidade em
SOA. Para a formação da base de conhecimento do framework
proposto se faz necessário declarar, então, o foco deste
trabalho na abrangência de cada domínio.
a) D01 – Negócio e Estratégia Organizacional
Focado na arquitetura corporativa – nas práticas e políticas
de negócio da organização, avalia como os processos de
negócios são concebidos, estruturados, implementados e
executados. Também analisa como os custos das capacidades
de TI são alocados por meio da organização, bem como se
tais capacidades favorecem a flexibilidade do negócio,
agilidade organizacional e para melhoria dos indicadores do
negócio. Inclui a estratégia de TI mediante a proposição de seu
valor, movendo-se para um nível mais alto de maturidade,
avaliando o devido alinhamento do negócio com a TI.
b) D02 – Organização e Governança
Trata-se do domínio focado na estrutura da organização em
si, analisa se estão sendo aplicadas as medidas necessárias de
eficácia organizacional no contexto e governança de SOA,
associada à estratégia para adoção de SOA, bem como se estão
sendo planejadas as etapas para a adoção dessa arquitetura
dentro dos limites da fronteira organizacional. Assim, esse
aspecto está centrado na estrutura organizacional, processos e
atividades, junto com as funções e habilidades necessárias para
adotar uma estratégia orientada a serviços. Isso inclui os tipos e
a extensão de competências, sua formação e educação
(capacitação em SOA) disponibilizadas dentro da organização.
A ótica de Governança e suas autoridades são associadas com
o gerenciamento formal de processos, de forma a manter as
atividades de TI alinhadas com as necessidades do negócio.
c) D03 – Informações e Modelos de Dados
É o domínio que foca a forma como a informação é
estruturada, modelada, no método de acesso aos dados da
empresa, na abstração do acesso de dados a partir dos aspectos
funcionais, na boa estruturação das características dos dados
organizacionais, nas capacidades de transformação de dados e
de estabelecimento de padrões de integração de dados, no
correto manuseio de identificadores, nas credenciais de
segurança, na gestão de conhecimento, nos modelo de dados e
metadados corporativos, e na correspondente integração de
informações do negócio, além do correto gerenciamento desse
conteúdo (Governança de Dados).
d) D04 – Métodos e Práticas
Esse domínio observa a devida quantidade de métodos,
metodologias e melhores práticas utilizadas pela
organização. Observa, então, o uso de métodos, princípios,
padrões, frameworks e técnicas associadas à arquitetura
orientada a serviços e no gerenciamento de serviços de TI.
Trata, então, da maturidade organizacional na realização das
transformações necessárias ao negócio em todo o ciclo de
vida de adoção de SOA, principalmente no desenvolvimento
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
de soluções sistêmicas necessárias, a exemplo do uso de
gerenciamento de requisitos, técnicas para estimativas,
gerenciamento de projetos e de processos de garantia de
qualidade. Assim, esse domínio é representado pelo grau de
disciplina e métodos aplicados – regulados pela Governança
SOA e estabelecidos em normas internas pela Governança
Corporativa – e indica o uso de boas práticas em todas as
atividades subjacentes a TI (com foco nas práticas de SOA).
e) D05 – Aplicações e Arquitetura
Focado no estilo e estruturação da aplicação (arquitetura
de aplicações) e sua decomposição funcional, na
reutilização, flexibilidade, confiabilidade e capacidade de
extensão da mesma, compreensão e uso uniforme de
melhores práticas e padrões, essencialmente naqueles com a
mesma funcionalidade, através do uso de padrões de projeto
(design patterns) associados ao modelo de arquitetura de
referência da organização. É por meio desse domínio que é
realizada a avaliação da qualidade dos serviços atuais e das
diversas camadas de serviços em SOA – a avaliação dos
estágios de adoção de SOA, tal como a eficiente
decomposição de serviços (visando à reusabilidade do
serviço), ausência de estado em serviços e desacoplamento das
regras de negócio, todos esses como facilitadores da
integração das aplicações organizacionais e no suporte à
rápida mudança nos processos informatizados.
f) D06 – Tecnologia e Infraestrutura
É o domínio que está focado na tecnologia e na
correspondente infraestrutura disponível para SOA, que deve
dar suporte às técnicas de interoperabilidade (uso de padrões
interoperáveis) e de soluções de mensageria necessárias para o
uso de SOA.
g) D07 – Operação e Gerenciamento de TI
Este domínio está focado na capacidade dos processos de
execução e gerenciamento da TI organizacional para suportar
SOA em destaque no gerenciamento dos seus serviços, no
gerenciamento eficaz da configuração dos ativos, e da
implantação e operação das atividades comuns de TI, entre
elas, o gerenciamento de incidentes, de eventos e o
monitoramento da infraestrutura.
D. Controles, Questões e Itens de Avaliação.
O modelo proposto utiliza os resultados das respostas
obtidas nos questionários para realizar tanto o cálculo de nível
de maturidade por domínio, assim como para o
estabelecimento da situação e para a formação de roteiros de
evolução e/ou estabilização para cada um.
Como ilustrado anteriormente na Fig. 1, entende-se que
cada item de avaliação dentro de uma questão, tem um valor
de métrica crescente associado a um nível de maturidade ou
faixa de níveis no qual o item é considerado aceitável. Assim,
se bem formulados, itens de avaliação representam faixas de
valores (mínimo e máximo) únicas e consecutivas no que
envolve o atendimento de níveis de forma crescente (suas
faixas). Cada resposta dentro de cada questão é única,
reforçando uma situação específica sobre cada controle
estabelecido, porém uma ou mais questões podem se reportar
à um mesmo controle. Esse aspecto de unicidade e de situação
crescente dos itens de avaliação em faixas estabelece a base de
MAZZAROLO et al.: A METHOD FOR SOA MATURITY
formação das questões avaliativas, e assim tem estreita
correlação com o aspecto qualitativo do controle.
No estudo do comportamento da valoração dos controles,
observa-se que esses podem ser estacionários durante níveis
sucessivos. Assim, os itens de avaliação dentro das questões
que compõem cada controle devem refletir mensurações em
uma faixa de escala (limite inferior e superior). Como faixas
de valores, pode-se entender que itens de avaliação são
representados pelos seus valores de mínimo e de máximo da
faixa ao qual foram estabelecidos.
Porém, por tratar de faixas discretas, esses valores devem
ser tratados com limites inclusivos de cada lado das faixas que
representam, e assim as faixas nunca devem se sobrepor.
Ainda, alinhado com os princípios de personalizar o modelo as
características da organização, alguns controles preveem
situações nas quais possam ser desconsiderados
intencionalmente, e assim não farão parte da avaliação.
V. PROCESSO DE AVALIAÇÃO
O processo de avaliação é associado a quatro passos com
tarefas sequenciais distintas: a Coleta de Dados, a Heurística
de Avaliação, a Geração de Resultados e a Geração de Roteiro
de Estabilização ou Evolução.
A Fig. 3 ilustra esses aspectos e aponta as atividades
necessárias para a realização integral do processo como
proposto, de forma a obter resultados em cada uma das
camadas da arquitetura (Fig. 1) e seu equivalente roteiro de
estabilização e/ou evolução, para o suporte a adoção contínua
e regular de SOA.
Figura 3. Processo de Avaliação de Maturidade Proposto.
A. Coleta de Dados
O processo de Coleta de Dados trata da aplicação dos
questionários, associada a uma posição no tempo, e seu
registro, isto é, das respostas as questões associadas a cada
domínio em momentos intempestivos e sua persistência, que
consolida a imagem da situação de cada domínio dentro da
organização em determinado momento.
Pela realização do questionário de cada domínio de
maneira intempestiva, garante-se a correta avaliação, aonde
cada domínio pode evoluir distintamente. A atribuição de
responsabilidade do preenchimento de cada questionário deve
ser confiada a responsáveis por diferentes posições dentro da
organização, de acordo com a proximidade entre os princípios
básicos de cada domínio e as devidas competências
209
funcionais. Cada um desses questionários são persistidos em
bases de dados corporativas.
B. Heurística de Avaliação
Nesta etapa, os valores dos itens das questões coletados
são analisados observando os controles dispensados, e o
tratamento das situações de múltiplas questões em um controle
que tenham inter-relação por detalhamento de escopo ou por
escopo diferenciado. Esses valores estabelecem a
quantificação de cada controle dentro de cada domínio.
A realização dessa etapa provê os valores correspondentes
para os controles, que são os reais objetos de avaliação e
mensuração do nível de maturidade dos domínios e que são
utilizados também para geração dos roteiros dessa
estabilização/evolução. Nesse sentido, ao final da
quantificação dos controles tem-se uma situação de controles
com pesos diferenciados que irão formar diversas situações de
análise de frequência.
Assim, uma vez definido a distribuição de frequência dos
controles de um domínio, o modelo proposto realiza uma série
de avaliações heurísticas para determinar o nível de
maturidade nesse domínio. A heurística desenvolvida baseia-
se em um modelo de tomada de decisão multiatributo,
conforme demonstrado na Fig. 4.
Figura 4. Fluxo da Heurística de Avaliação do Modelo de Maturidade.
Esse processo decisório fundamenta-se na análise de
frequência e sua correlação com as situações prováveis
identificadas durante o ciclo de adoção de SOA, com atenção
na busca de seu equilíbrio com suas importâncias relativas,
estabelecida na ótica de seus pesos, que é repassada ao modelo
heurístico pela combinação em cada controle do nível
identificado e o seu peso.
Assim, nessa etapa, os controles e seus pesos serão
utilizados na formação de um modelo de distribuição de
frequência a ser utilizada na etapa de valoração dos domínios,
que permite a análise da situação atual – de estabilização ou
evolução, para qualificação dos estágios de maturidade em
SOA e formação de roteiros de evolução para os controles que
não se encontrem em conformidade – segundo a distribuição
de frequência, em cada domínio.
C. Geração de Resultados
Então, como resultado da realização do processo decisório,
tem-se a valoração dos domínios na última situação informada
em cada questionário, que se denomina "Nível de Maturidade
Atingido" e um mapa da relação de cada controle com o nível
de maturidade calculado para cada domínio. Tem-se, portanto,
como saída inicial: a indicação da situação geral - em
evolução ou em estabilização, a definição do nível atual em
cada domínio, e a apresentação de controles em séries
históricas.
210
Assim, o valor calculado do "Nível de Maturidade
Atingido" mostra em qual estágio a organização se encontra
no momento da avaliação em relação ao modelo proposto, e
assim, suporta a observação das características percebidas na
organização, quais são as vantagens e desvantagens, o que
deve ser melhorado e o que está de acordo com as medidas
aceitáveis dentro do modelo. Conforme ilustrado na Fig. 5,
além da apresentação textual do que é identificado como
situação de cada controle, outros recursos de representação
diagramática podem ser utilizados, tais como gráficos de
radar.
Figura 5. Uso de Gráfico em Radar para Informação de Nível de Maturidade.
Em continuidade a análise dos modelos de representação, é
possível formar como saída um gráfico de múltiplas colunas
ou de múltiplas linhas dos controles por domínio, de forma a
suportar uma análise decisória específica da relação desses
com seu domínio, e assim permitir o estabelecimento de um
equilíbrio dos diversos controles em patamares adequados.
É esperada uma distribuição equilibrada dos controles,
tendo como meta a estabilização em patamares superiores
dos controles que foram considerados com maior peso.
A Fig. 6 ilustra as variações dos controles de um domínio no
tempo, o que permite, além da análise da posição de cada
controle, uma observação suplementar: se medidas foram
tomadas visando atenuar a disparidade entre os controles.
Figura 6. Uso de Histograma nos Controles de um Domínio no Tempo.
Ainda como consequência dos resultados obtidos na
análise dos níveis atingidos entre cada domínio, aspectos da
cadeia funcional das organizações devem ser observados.
Como existem diversas dependências entre níveis de
maturidade em domínios diferenciados, as prováveis variáveis
entre os valores alcançados em cada domínio e seus valores
subjacentes podem possibilitar uma inferência do
comportamento da organização perante o processo de adoção
ou de uso de SOA.
Na proposição de domínios apresentada neste trabalho,
observa-se uma associação direta da lista de domínios
declarada e a arquitetura empresarial, iniciando-se no nível
IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015
mais estratégico do negócio (D01), que são seguidos do nível
de governança e de informação (D02 e D03), passando pelos
métodos e práticas utilizadas nas aplicações e estabelecidos
nos modelos arquiteturais (D04 e D05) até a ótica da TI e de
sua infraestrutura subjacente e as operações necessárias para
mantê-la (D06 e D07).
Considerada essa ordem lógica dos domínios, e se
analisada através de um gráfico em colunas dos valores
obtidos para cada domínio, existem algumas situações
específicas que podem ser obtidas e que permitem essa
inferência preliminar. O Quadro 3 aponta e ilustra as possíveis
situações dos histogramas que podem ocorrer na relação entre
as valorações de nível de maturidade dos domínios.
Quadro 3. Situações Possíveis na Valoração da Maturidade dos Domínios.
D. Geração de Roteiros de Estabilização ou Evolução
O modelo proposto oferece a construção dinâmica de
roteiros de referência (roadmaps) associado ao nível de
maturidade – estabilização e/ou evolução – realçando os
pontos fortes e fracos existentes em relação a uma escala
evolutiva da adoção de SOA por uma organização (pela
observação dos valores obtidos em cada controle).
O processo de geração dos roteiros de evolução envolve a
análise controle a controle do que é definido como atividades
sequenciadas do seu valor calculado (do controle) em relação
ao valor almejado. Essa análise, apenas envolve os controles
que estão com valor menor do que o valor do “Nível de
MAZZAROLO et al.: A METHOD FOR SOA MATURITY
Maturidade Almejado”, tendo como foco controles que
possam estar com alto grau de dispersão a menor do valor
estabelecido pelo domínio. Esses controles claramente a
menor apontam situações consideradas críticas para
tratamento emergencial e efetivo da Governança SOA.
Nesse sentido, o modelo constrói a série de atividades
necessárias, utilizando-se de declarações existentes em cada
controle dos requisitos necessários para atingir o próximo
nível, no que se refere ao escopo do controle.
VI. VALIDAÇÃO DO MODELO
Visando a suportar a validação do framework proposto, o
modelo foi aplicado e ajustado através de uma abordagem de
casos de uso múltiplo, em cenários comuns e simulações em
casos limites, ajustando, assim, a visão quantitativa do modelo
através de métodos de indução.
Os casos de uso múltiplos foram realizados em uma
instituição com características de celeridade em mudanças e
princípios organizacionais, a saber: o Ministério da Saúde do
Brasil (MS): O modelo foi aplicado durante execução dos
projetos de Estruturação da Adoção de SOA (2011-2012) e da
Estruturação do Centro de Excelência SOA do MS (2013-
2014).
No que se refere a esse projeto no Ministério da Saúde do
Brasil, o método pôde ser aplicado em três momentos
diferentes do processo de adoção: 2011, 2012 e 2014. Desse
modo, é possível analisar a evolução da maturidade na
arquitetura dentro dessa organização ao longo do processo de
adoção de SOA. Assim, o uso do modelo proposto permitiu a
análise de séries temporais de domínios e controles.
As Fig. 6 e 7 apresentam resultados comparativos da
avaliação de maturidade, para alguns dos domínios e seus
respectivos controles avaliados (não são apresentados todos os
domínios por limitação de espaço):
Figura 6. Evolução do Domínio Informações e Modelos de Dados.
Figura 7. Evolução do Domínio Organização e Governança.
211
A Fig. 8 apresenta a evolução do índice de maturidade, em
cada domínio, nas avaliações realizadas.
Figura 8. Evolução da Maturidade entre Domínios.
Como exemplo de análise, observa-se na Fig. 6 que houve
uma evolução continuada e consistente dos índices de
maturidade em todos os controles do domínio Informação e
Modelos de Dados. Por outro lado, da Fig. 7, depreende-se
que no domínio Organização e Governança, a evolução de
alguns controles foi inexistente em toda a série. Ao analisar o
efeito desses fatores na comparação entre todos domínios
(Fig. 8), percebe-se uma pequena evolução do domínio
Organização e Governança em relação aos demais domínios.
Desse modo, o modelo permite indicar claramente uma
necessidade de realinhamento completo desse domínio face
aos patamares obtidos em outros domínios.
Outra análise possível é a observação do incremento de
maturidade, ao longo do tempo, nos domínios arquiteturais e
tecnológicos (Fig.8). De fato, houve investimento significativo
em tecnologia e infraestrutura ao longo dos anos no MS. Assim,
a aplicação do modelo permitiu evidenciar os efeitos do
investimento realizado. Entretanto, esse investimento não foi
acompanhado de ações de estruturação no que se refere aos
quesitos estratégicos. Pode-se classificar, portanto, o programa
de adoção de SOA do MS como sendo de natureza técnica e
operacional, sem o devido patrocínio do negócio (Quadro 3).
Essa percepção é válida na visão dos analistas e experts que
trabalharam no projeto e pode ser demonstrada
quantitativamente com o uso do método proposto.
Acerca da Fig. 8, da última situação analisada (2014),
pode-se inferir que a organização está próxima de ser
considerada em evolução para um patamar 2 de maturidade, e
deve dar prioridade aos domínios de Organização e
Governança, e de Métodos e Práticas. O modelo pode gerar
ainda os roteiros de evolução necessários à estabilização da
maturidade organizacional em nível 2. Neste caso, o modelo
proposto ignora o domínio de Tecnologia e Infraestrutura
(nível 3), que se apresenta além das necessidades combinadas
dos outros domínios.
Para ilustrar os roteiros de evolução, a Fig. 9 apresenta as
atividades necessárias para atingir se estabilização no nível 3
para o domínio Informações e Modelos de Dados, a partir da
última avaliação realizada (2014, Fig. 6).
212 IEEE LATIN AMERICA TRANSACTIONS, VOL. 13, NO. 1, JAN. 2015

REFERÊNCIAS

[1] ACCENTURE. ACCENTURE SOA Diagnostic. 2007. Disponível

em: <http://www.accenture.com/us-en/Pages/service-technology-soa-
overview. aspx.> .Acesso em: 14 mar. 2013.
[2] BEA. BEA Evolution`Model. 2006. Disponível em:
<http://soablueprint.com /yahoo _site _admin/assets/docs
/SOAEvolutionModel.291100753.pdf>. Acesso em: 9 jan. 2013.
[3] BECKER, J.; KNACKSTEDT, R. Developing Maturity Models for
IT Management – A Procedure Model and its Application. In: BISE -
Research paper, Business & Information Systems Engineering. 3 March,
2009.
[4] BIEBERSTEIN, N. et al. Service Oriented Architecture (SOA)
Compass Business Value, Planning, and Enterprise Roadmap. IBM Press,
USA, 2005.
[5] BRAUER, B., KLINE, S. SOA Governance: a key ingredient of
the adaptive enterprise. HP, 2005. Disponível em:
<http://www.managementsoftware.hp.com/
products/soa/swp/soa_swp_governance.pdf>. Acesso em: 9 jan. 2013.
Figura 7. Roteiro de Evolução do domínio Informações e Modelos de Dados .
[6] CARNEGIE MELLON SOFTWARE ENGINEERING
INSTITUTE. CMMI for Development Version 1.2. Carnegie Mellon, August
Cabe citar que a validação do framework se deu em uma 2006. Disponível em: <CMMI for Development Version 1.2.pdf -
análise mais detalhada, além as situações elencadas neste http://repository.cmu.edu/sei/387/>. Acesso em: 9 fev. 2013.
[7] DAHLBERG, T.; KIVIJARVI, H. An Integrated Framework for IT
tópico, em relação à realidade observada pelos analistas no Governance and the Development and Validation of an Assessment
escopo dos dois projetos citados e com o uso dos resultados Instrument. 2006.
apresentados pela ferramenta desenvolvida. [8] DE BRUIN, T. FREEZE, R. KAULKARNI, U., ROSEMANN, M.
2005. Understanding the Main Phases of Developing a Maturity Assessment
VII. CONCLUSÕES Model. In Campbell, B, Underwood, J, & Bunker, D (Eds.) Australasian
Conference on Information Systems (ACIS), November 30 - December 2
Entende-se que para a correta adoção da Arquitetura 2005, Australia, New South Wales, Sydney. Disponível em:
Orientada a Serviços a governança SOA deve garantir a <http://eprints.qut.edu.au/25152/>. Acesso em: 10 jan. 2013.
capacidade, a agilidade e a integridade do modelo arquitetural [9] ERL, T. Service-Oriented Architecture: Concepts, Technology,
and Design. Prentice Hall, USA, 2005.
que essa governa, levando em consideração os diversos [10] ERL, T. SOA: Design Patterns. Prentice Hall, USA, 2008.
aspectos para o funcionamento confiável de seu processo: [11] GARTNER. GARTNER's Roadmap to SOA. 2009. Disponível em:
a partir da definição de uma adequada estratégia baseada em <https://www.gartner.com/doc/1405618>. Acesso em: 8 jan. 2013.
metas e prioridades. [12] HP. HP SOA Maturity Model. 2006. Disponível em:
<http://people.ischool. berkeley.edu/~glushko/SSME-Lectures-
Como o grau de complexidade envolvido nessa Fall2006/Assess-SOA.pdf>. Acesso em: 9 jan. 2013.
governança, e pela necessidade de retenção de dados [13] IBM. IBM SOA. Service Integration Maturity Model - SIMM.
históricos, entende-se ser importante que se automatize 2005. Disponível em: <http://www.ibm.com/developerworks
essa necessidade de gestão do nível de maturidade ao longo /webservices/library/ws-soa-simm/>. Acesso em: 18 fev. 2013.
[14] ISACA. Cobit 5 Laminate. 2012. Disponível em:
do tempo, para obter um referencial quantificável e <http://www.isaca.org/COBIT/Documents/COBIT5-Laminate.pdf>. Acesso
qualificável do estágio de sua adoção em determinado em: 7 fev. 2013.
momento organizacional. [15] ITANA. SOA WORKING GROUP. Disponível em: <
É a análise detalhada dos resultados específicos dos https://spaces.internet2.edu/ display /itana/SOA+Working+ Group>. Acesso
em: 20 fev. 2013.
controles dentro de cada domínio que dá garantia ao [16] JANIESCH, C., KORTHAUS, A., ROSEMANN, M.
atingimento dos benefícios que advêm da aplicação correta Conceptualization and Facilitation of SOA governance. In: Proceedings of:
dos SOA. É a valoração dos controles que informam o ACIS 2009: 20th Australasian Conference on Information Systems , 2-4
potencial de aplicação dos princípios propostos por Erl, December 2009, Monash University, Melbourne.
[17] JOSUTTIS, Nicolai M. SOA in Practice. 1.ed. Sebastopol: O'Reilly
observados também outros elementos tecnológicos e de Media, 2007.
operação de TI comum entre os diversos modelos de [18] KREGER, H; CARRATO, T.; ARSANJANI, A.; SZAKAL, A.;
maturidade estudados. É pela observação do equilíbrio dos DIAZ, J.; HOLLEY, K. IBM Advantage for Service Maturity Model
controles que é possível o suporte à identificação dos pontos Standards. Disponível em: <http://www.ibm.com
/developerworks/webservices/library/ws-OSIMM/index.html>. Acesso em: 9
falhos que inibem os benefícios estratégicos. fev. 2013.
O pressuposto do modelo apresentado neste trabalho é de [19] LUFTMAN, J. Assessing Business-IT Alignment Maturity -
que com o uso coordenado de controles agrupados em Strategies for Information Technology Governance - Chapter IV. Disponível
domínios específicos seja possível administrar e gerenciar a em: <http://books.google.com.br /books?hl=en&lr=&
id=IleHOs41iIMC&oi=fnd&pg=PA99&dq=luftman+2004&ots=wV3CFKlB
adoção de SOA em estágios contínuos de evolução e N&sig=mvs4YgDNex-NFfpDfoQ35qbjCRA#v=onepage&q=luftman%20
estabilização. 2004 &f= false>. Acesso em: 7 jan. 2013.
Sobretudo, como estabelecido no modelo proposto, [20] MARKS, E. Service-Oriented Architecture Governance for the
qualquer processo de avaliação de maturidade SOA deve Services Driven Enterprise. John Wiley& Sons, Inc. New Jersey, USA, 2008.
[21] MICROSOFT. MICROSOFT Services Assessment and Roadmap
prover um suporte adequado a melhoria de processos através for Service Oriented Architecture. 2007. Disponível em:
de um processo de realimentação desses resultados pela http://www.microsoft.com/en-us/download /details.aspx?id=10486. Acesso
construção de guias dinâmicos baseados nos controles que em: 23 jan. 2013.
estão, em determinado momento de maturidade, inadequados [22] MITRA, Tilak. A case for SOA governance: IBM developer works
technical library. August. 2005.
à uma maturidade atual ou almejada.
MAZZAROLO et al.: A METHOD FOR SOA MATURITY 213

[23] NATIS, Y. SSA Research Note SPA-401-068, 12 April 1996,
'Service Oriented' Architectures, Part 1" and SSA Research Note SPA-401-
069 , 12 April 1996, "'Service Oriented' Architectures, Part 2". Gartner.
[24] NIEMANN, M. Towards a Generic Governance Model for
Service-oriented Architectures. In Proceeding of the fourteenth Americas
conference on information systems. Toronto, Canada, 2008. Disponível em:
<http://www.joint-research.org/wp-content/uploads/2011/07/NER+08.pdf>.
Acesso em: 8 jan. 2013.
[25] ORACLE. Oracle SOA Maturity Model. 2007. Disponível em:
<http://www.oracle.com/us/technologies/soa/oracle-soa-governance-best-
practice-066427 . pdf>. Acesso em: 10 fev. 2013.
[26] PAPAZOGLOU, M. P.; TRAVERSO, P.; DUSTDAR, S.;
LEYMANN, F. Service-Oriented Computing: State of the Art and Research
Challenges. Computing & Processing (Hardware/ Software). Volume 40,
Issue: 11. IEEE Computer Society. Nov. 2007.
[27] RACZ, N.; WEIPPL, E.; SEUFERT, A. Governance, Risk &
Compliance (GRC) Software - An Exploratory Study of Software Vendor and
Market Research Perspectives. In: Proceedings of the 44th Hawaii
International Conference on System Sciences - 2011. pgs 1530-1605. IEEE.
[28] SONIC. SONIC SOA Maturity Model. 2005. Disponível em:
<http://soa.omg.org/Uploaded Docs/SOA/SOA_Maturity.pdf> Acesso em: 7
jan. 2013g.
[29] THE OPEN GROUP. Open Group Service Integration Maturity
Model - OSIMM. 2009. Disponível
<https://collaboration.opengroup.org/projects/osimm/>. Acesso em: 31 jan.
2013.
[30] THE OPEN GROUP. SOA Source Book - Current Edition.
Documento G102. Publicado pelo The Open Group, Agosto de 2011.
Disponível em <http://www.opengroup.org/soa/source-book/intro/index.htm>.
Acesso em 18 out. 2012.
[31] THE OPEN GROUP. THE OPEN GROUP SERVICE
INTEGRATION MATURITY MODEL - OSIMM. Technical Standard
Version 2. ISBN: 1-931624-99-2. Documento C117. publicado pelo The Open
Group, Outubro 2011.
[32] WEBMETHODS. SOA Governance - Enabling Sustainable
Success with SOA. 2006. Disponível
<http://www.cioindex.com/channels/enterprise_architecture
/articleid/1091/enabling-sustainable-success-with-soa.aspx>. Acessoe m: 9
jan. 2013.
[33] WEILL, P.; ROSS, J. W. IT Governance - How Top performers
Manage IT Decision Rights for Superior Results. Cambridge. Harvard
Business School Press, 2004.
[34] WELKE, R.; HIRSCHHEIM, R.; SCHWARZ, A. Service-
Oriented Architecture Maturity. Revista Computing Now. IEEE Computer
Society. Feb. 2011.
[35] YAWALKAR, S. HP Service-Oriented Architecture Maturity Self-
Assessment Report. CTS by Hewlett-Packard Company. September 18, 2007.
Disponívelem<http://www.nyu.edu/classes/jcf/g22.3033-
003_fa09/handouts/HP-SOA-Assessment Report.pdf> Acesso em: 12 jan.
2013.
documento e business intelligence. atua atualmente em projeto no
ministério da justiça no suporte consultivo em arquitetura de serviços e
infraestrutura para o projeto registro de identidade civil - ric.
André Amaro Toffanello, mestre em engenharia elétrica na universidade
de brasília - 2012, pós-graduado em redes de computadores
pela união educacional de brasilia - uneb (1996). possui 18
anos de experiência como empreendedor e pesquisador da
área de tecnologia da informação com foco em gestão de tic;
computação orientada a serviço, business inteligence e cloud
computing. atualmente desenvolve doutorado na área de conhecimento da
computação distribuída na universidade de brasília. exerce atividades de
pesquisa, desenvolvimento e implementação de soluções tecnológicas para
automação de processos de negócio, aplicando boas práticas para gestão de
infraestrutura e gestão de tic e automação de processos através da
abordagem por arquitetura orientada a serviços. atuou no cargo de
coordenador geral de sistemas internos de gestão do datasus, posteriormente
como assessor do diretor de tecnologia da universiade de brasilia,
ampliando significamente os resultados da ti para estas organizações.
coordenou grandes projetos de pesquisa pela universidade de brasília, cito
os mais recentes, anvisa - no desenvolvimento de método para o
desenvolvimento e implantação de plano diretor de tecnologia da
informação; anvisa - desenvolvimento de pesquisa para aplicação métodos
em: para implantação de arquitetura orientada a serviços; ministério da saúde -
desenvolvimento de pesquisa para implantação de arquitetura orientada a
serviços.
Prof. Ricardo Puttini is associate professor in the electrical
engineering department at university of brasilia (brazil). he
holds a phd (2004) in distributed systems and msc. (1997) in
telecommunications. dr. puttini has acted as senior it
consultant and c-level advisor for 10+ years. he has worked
in several projects across multiple governmental
organizations in brazil. recently, he has co-authored the book "cloud
computing: oncepts, technology and architecture" (http://
em: http://servicetechbooks.com/cloud), published by prentice-hall 2013. as a
/article researcher, dr. puttini has worked at established it research groups in brazil,
france and sweden, published 40+ papers, and spoken in several it
conferences around the world. his areas of expertise and interest includes
distributed systems and applications, specially service orientation and cloud
computing.

Claynor Fernando Mazzarolo, possui graduação em

administração de empresas pela universidade tecnológica
federal do paraná – utfpr (1986), pós graduado pela fae
business school em finanças (1996), mestrado em
engenharia elétrica pela universidade de brasília (2010),
estudante do programa de doutoramento em engenharia elétrica na
universidade de brasília. líder do projeto e implementação do parque
tecnológico de pato branco (1997 a 2000); participação e planejamento do
parque tecnológico de posadas (argentina). foi coordenador executivo do
lactec – instituição de p&d, em curitiba (2003 a 2004), presidente do
sergipe parque tecnológico (2004 a 2007). atualmente é diretor presidente
do instituto brasília de tecnologia e inovação – ibti, com foco em
tecnologias de informação e comunicação. autor e co-autor de vários artigos
relacionados à inovação tecnológica.
Valerio Aymoré Martins, possui graduação em engenharia
pela universidade do estado do rio de janeiro (1988). tem
experiência na área de ciência da computação, com ênfase
em sistemas de informação. aluno de doutorado desde 2013.
mestrado concluído em engenharia de elétrica e de
telecomunicações pela unb em 2012. professor substituto e bolsista da unb
que atuou em projetos do ministério do planejamento em pesquisa,
elaboração e avaliação de modelos de gerenciamento eletrônico de