Marco Mendes´s Blog

Primeiro artigo da série: PSP para Leigos

Você chega para trabalhar as 8:30. Examina a sua lista de tarefas do seu projeto alvo, cujo número está em cinco tarefas abertas. De forma entusiástica, você começa a examinar a primeira tarefa.

As 8:45, o telefone toca. Você é chamado para uma reunião sobre um problema residual de um outro projeto. Você fica nesta reunião até as 10:00.

Às 10:10, o seu colega do lado o chama para resolver um complicado problema de depuração. Mais vinte minutos se passam sem que você se dê conta.

Você consegue retornar para o seu projeto, mas somente até 11:00. Neste momento um cliente telefona e interage com você por mais quinze minutos.

Às 11:15, você para ler apenas 3 ou 4 emails - afinal, ninguém é de ferro. Infelizmente você precisa responder dois deles e gasta mais vinte minutos.
…
As 18:00, você está estressado e cansado. A sua lista de tarefas ainda está com 4 tarefas em aberto, e o seu tempo foi dragado por vilões invisíveis. Infelizmente você apropria no seu timesheet 8 horas no seu projeto original, vai para casa desaminado e pensa: “Para onde foi o meu tempo?”.

Se você já viveu o sintoma acima, você realmente trabalha com desenvolvimento de software. Neste trabalho, o volume de interrupções é enorme e se não tivermos ferramentas para gerenciar o nosso tempo, não temos ciência sobre a nossa real produtividade.

Um dos objetivos do PSP é aumentar a nossa produtividade. Isso somente é possível através de medição. A primeira lei da gerência é: “Não se gerencia o que não se mede”. O PSP, então, trabalha fortemente a auto-gerência do tempo, i.e, mecanismos onde você irá vigiar o seu tempo rigorosamente para saber o que você faz durante um típico dia de trabalho.

O Mylar, plugin gratuito para o Eclipse, permite que você faça este controle exigido pelo PSP. Isso é realizado através do conceito de tarefas pessoais (Personal Task). Dentro do Eclipse com este plugin já instalado, você tem a possibilidade de criar uma lista de tarefas, como mostrado na figura abaixo:

Um característica interessante deste plugin é que voce pode ativar uma tarefa. Basta clicar com o botão direito em uma tarefa e clicar “Activate”. Ao realizar este processo, o Mylar usa o mecanismo de instrumentação do Eclipse e começa a contar (em minutos e segundos), quanto tempo você está gastando naquela tarefa. Se um telefone tocou, se você parou para lanchar, se você foi interrompido por outro evento, você apenas precisa se lembrar em clicar sobre a tarefa com o botão direito novamente e clicar em “Deactivate”. A contagem é interrompida e você pode retomá-la a qualquer instante ou ativar uma outra tarefa.

Em qualquer instante, você pode examinar quanto tempo você ainda possui em uma tarefa ou quantos minutos já foram decorridos. No exemplo acima, 2:34 minutos já foram gastos da tarefa “Implementar Tela - Cadastro de Correntista”.

Um uso não intrusivo do Mylar, para quem nunca trabalhou com o paradigma de programação focada em tarefas, é usá-lo apenas para os eventos maiores de um dia (ex: Almoços e Reuniões). Um efeito interessante, em médio prazo, é perceber que o seu dia típico de trabalho não possui 8 horas (o que é senso comum). Você talvez descubra que o seu dia típico no seu projeto seja de 7, 6 ou mesmo 5 horas. Este número é rico e deve ser reportado à sua gerência para a criação de cronogramas mais realistas.

Estudiosos de medições de projetos, como por exemplo Capers Jones, já realizaram estatísticas no mercado Brasileiro e constataram que uma pessoa de TI tipicamente trabalha 132 horas por mês. Se considerarmos que temos 22 dias úteis em um mês, chegamos ao valor de 6 horas por dia. Interessantemente, conheço empresas de grande porte no Brasil que tem como norma em seus cronogramas de projeto não alocar pessoas em projetos mais de 6 horas por dia. Sábia decisão!

O efeito subliminar de medir o próprio desempenho é muito interessante. Talvez você descubra na primeira semana que você somente está trabalhando no seu projeto 60% ou 65% do seu tempo útil.
Com esta informação em mãos, você reage quase que por instinto aos vilões de tempo.

Recebi de uma amiga, a Cintya, engenheira de processo que trabalha em Uberlândia, um site muito interessante sobre a Programação Orientada por Gambiarras.

“ A Programação Orientada a Gambiarras é um caminho para muitas habilidades que alguns consideram não naturais. ”, Senador Palpatine.

A leitura deste site, embora nerd, é bastante divertida. Recomendo fortemente quando você estiver estressado no seu dia a dia.

Um outro excelente site sobre anti-práticas, criado pelo Scott Ambler, é o Waterfall 2006. Dentro os vários temas desta conferência, temos alguns que merecem citação aqui:

O PSP (Personal Software Planning) é uma disciplina (ou método de trabalho) que permite que desenvolvedores se tornem altamente eficientes. Independente se o seu time ou organização tenham já um processo definido (ex: RUP, Cascata, XP) ou ainda não tenham um processo definido (ex: Conserta e Remenda), o grande benefício do PSP é permitir que indivíduos melhorem continuamente em suas práticas de desenvolvimento de software.

Conceitualmente, o PSP foi derivado a partir das áreas de processos do CMM/ e adequados para o trabalho individual com eficiência e a premissa de pouca burocracia.

Os benefícios primários do PSP para cada pessoa são:

O mercado Brasileiro ainda é carente de boas pesquisas da maturidade da indústria de TI, engenharia de software e gestão de projetos. Na contra-mão desta realidade, os professores Darci Prado e Russel Archibald apresentam anualmente os resultados da sua pesquisa em maturidade de gestão de projetos, a partir do feedback de centenas de participantes de empresas do mercado Brasileiro, americano e europeu. A maturidade, neste contexto, é definida de acordo com o modelo desenvolvido por Darci Prado, chamado de MMGP

A rodada de pesquisa de 2006 está disponível para preenchimento por gerentes de projetos, gerentes de escritórios de projetos ou pessoas em outras funções gerenciais a partir do seguinte link: www.maturityresearch.com. Caso você, leitor, não ocupe posição gerencial, divulgue este blog a seu gerente e incentive a participação na pesquisa.

Para quem deseja apenas obter dados de maturidade para comparação e análise, os resultados de 2005 estão disponíveis em formato PDF aqui.

O Eclipse cresce, a cada dia, em popularidade e funcionalidades dentro da comunidade de desenvolvedores e em particular na comunidade Java. Uma pergunta intrigante neste meio é: “Quais as funcionalidades mais usadas pelos desenvolvedores Java no uso do Eclipse?”.

A resposta parcial a esta pergunta foi respondida a partir de um trabalho de pesquisa muito interessante, realizada por pesquisadores da Universidade de British Columbia, no Canadá. O artigo mostra as funcionalidades mais usadas pelos desenvolvedores e é extremamente útil para que instrutores e líderes técnicos possam focar seus ensinamentos para as equipe Java nas funcionalidades mais populares em seus cursos ou tutorias.

Do ponto de vista de engenharia de requisitos e engenharia de usabilidade, o artigo apresenta evidências que usuários tendem a usar apenas um pequeno sub-conjunto de funcionalidades de um software complexo.

Leia aqui o paper: How Are Java Software Developers Using the Eclipse IDE?

Um plataforma de arquitetura de software é composta por diversos produtos, tais como servidores de aplicação, servidores de fila de mensagens, servidores de orquestração de processo BPEL, barramentos ESB, servidores de comércio eletrônico, portais e outros componentes.

Anexo neste blog uma apresentação sobre um plataforma robusta para arquiteturas de software - IBM WebSphere. Esta apresentação tem por objetivo exibir uma arquitetura de referência de plataformas de arquiteturas de software e exemplificá-la através da solução líder de mercado.

Arquivo em formato PPT: ArquiteturaReferencia_PlataformaWebSphere

A modelagem de casos de uso lida com a formalização, documentação e comunicação de partes dos requisitos funcionais de sistemas computacionais e de processos de negócio. Contrariamente ao senso comum, a escrita de um modelo de casos de uso não é uma tarefa trivial e requer muita atenção devido a detalhes que não são óbvios para o analista de requisitos iniciante.

Trabalho aqui um exemplo de como escrever e como não escrever casos de uso, composto de erros comuns a analistas iniciantes e um refinamento sucessivo para a correção destes erros e produção um descritivo maduro de casos de uso. O exemplo é composto de 7 passos, refinados incrementalmente em níveis crescentes de maturidade.

Escolhemos como exemplo um processo didático de saque de dinheiro em uma máquina 24 horas, chamada aqui de máquina ATM (Automatic Teller Machine). Neste processo de negócio, podemos identificar um caso de uso de sistemas chamado “Sacar Dinheiro”, ativado por um ator primário chamado Correntista.

A nossa primeira tentativa de descrever este caso de uso segue abaixo:

Caso de Uso - Sacar Dinheiro - Versão 1

Ator Primário: Correntista
Objetivo: Permitir ao correntista de um banco conveniado ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O correntista insere a senha e o valor a ser retirado.
3. O correntista retira o dinheiro da máquina 24 horas.

Embora este processo atinja o fim esperado (dinheiro em espécie na mão do correntista), ele não descreve a interação entre o ator primário e o sistema sob desenho. O objetivo primário de um caso de uso é descrever a interação entre atores e o sistema sob desenho. Em uma metáfora com um jogo de ping-pong, a bola na versào 1 fica o tempo todo em um lado da mesa. Não existe conversação, não existe diálogo e portanto não existe captura dos processos de negócio que devem ser conduzidos pelo sistema.

A nossa segunda tentativa de descrever este caso de uso corrige este problema.

Caso de Uso - Sacar Dinheiro - Versão 2

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação do cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema valida a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A versão 2 é uma clara evolução. Existe um diálogo entre o ator e o sistema sob desenho. Alguns erros, entretanto, ainda persistem. Observemos, por exemplo, o passo (2). Como estamos projetando o sistema da máquina 24 horas, devemos nos lembrar que está fora do escopo (por pura impossibilidade) do nosso sistema realizar validações como por exemplo “Cartão Bloqueado ou Cancelado”. Isso é realizado pelo sistema do banco real (instituição de crédito), que se apresenta então como um ator secundário no contexto do nosso sistema. Isso seria identificado no mundo real através da definição da fronteira ou limite do nosso desenho. O erro aqui, portanto, foi ignorar a existência do ator secundário Banco Instituição de Crédito na descrição. Isso nos leva a terceira versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 3

Ator Primário: Correntista
Ator Secundário: Instituição de Crédito
Objetivo: Permitir ao correntista de uma instituição de crédito conveniada ao banco ATM realizar o saque de dinheiro em espécie.

Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha e o saldo do correntista.
5. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
6. O correntista retira o dinheiro da máquina 24 horas.

A terceira versão captura nos passos 2 e 6 as interações com atores secundários, ausentes na versão 2. Mais uma vez, entretanto, erros ainda existem na descrição. Um caso de uso deve capturar todos os processos de negócio realizados, sem no entanto entrar no mérito de como estes processos serão implementados. Em outras palavras, os casos de uso capturam as interações (O QUÊ), sem se preocupar com a implementação destas interações (COMO). Na versão 3, não capturamos processos básicos de um saque bancário, como por exemplo a validação da existência de dinheiro disponível na dispensadora de dinheiro, as restrições de saques diários, restrições de horários e o débito em conta corrente ao final da operação. Isso nos leva a uma quarta versão da nossa descrição.

Caso de Uso - Sacar Dinheiro - Versão 4

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Embora esta versão 4 seja já razoável, muitos analistas de requisitos terminam o trabalho de escrita de casos de uso neste ponto. Estes analistas se esquecem que a ausência dos fluxos alternativos ou de exceção subestima a complexidades dos sistemas computacionais e gera desvios nos cronogramas de projeto. Portanto, é fundamental identificarmos os pontos de extensão deste fluxo. Não devemos, entretanto, realizar este processo verticalmente, mas primordialmente em amplitude para em um segundo momento realizarmos a escrita de cada ponto de extensão. Isso nos leva a versão 5, agora com os fluxos alternativos/exceção.

Caso de Uso - Sacar Dinheiro - Versão 5

…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Ativado do Passo 2 - Cartão Inválido
Ativado do Passo 2 - Cartão Bloqueado ou Expirado
Ativado do Passo 2 - Cartão Não Suportado pela Máquina 24 horas
Ativado do Passo 4 - Senha Inválida
Ativado do Passo 4 - Saldo Insuficiente
Ativado do Passo 4 - Limite Diário na Instituição de Crédito Ultrapassado
Ativado do Passo 5 - Limite de Saque do Banco 24 horas Ultrapassado
Ativado do Passo 5 - Limite de Saque no Horário Ultrapassado
Ativado em Qualquer Passo - Cancelamento da Operação pelo Correntista

Outros pontos de extensão podem existir, naturalmente. O exemplo procura mostrar o fato que um brainstorming destes fluxos alternativos deve ser feito para que estes pontos de extensão sejam capturados.

Dentro da evolução da descrição, devemos também realizar o detalhamento de cada ponto de extensão. Um exemplo para o fluxo Senha Inválida é colocado abaixo.

Caso de Uso - Sacar Dinheiro - Versão 6
…
Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

Este trabalho, como citado, deve ser realizado para cada ponto de extensão da descrição do caso de uso.

Finalmente, devemos lembrar sempre que o modelo de caso de uso captura apenas interações entre os atores primários e o sistema sob desenho. Informações complementares como regras de negócio, interfaces gráficas, desenho detalhado ou persistência não são capturados na descrição. Estas informações podem (e devem complementar) a descrição de um caso de uso, sem entretanto interferir na legiblidade da leitura dos fluxos. A versão 7 (e última) deste artigo mostra como isso poderia ser realizado para regras de negócio simples do nosso exemplo de caso.

Caso de Uso - Sacar Dinheiro - Versão 7 (Final)
…
Fluxo Principal
1. O correntista insere o cartão na máquina 24 horas.
2. O sistema realiza a validação física do cartão e solicita à Instituição de Crédito realizar a validação da expiração ou restrições associadas ao cartão.
3. O correntista insere a senha e o valor a ser retirado.
4. O sistema solicita à Instituição de Crédito que valide a senha, o saldo do correntista e o limite diário de saque.
5. O sistema verifica a disponibilidade de dinheiro na máquina 24 horas, os limites diários de saque suportados e avalia as restrições de limite de saque em horários e dias especiais.
6. O sistema solicita à Instituição de Crédito que realize o débito do saque na conta corrente do Correntista.
7. O sistema disponibiliza o dinheiro na dispensadora e o recibo da transação.
8. O correntista retira o dinheiro da máquina 24 horas.

Pontos de Extensão

Fluxo Alternativo - Senha Inválida
4a. Se o número de tentativas inválidas for igual a 1:
4a1. O sistema exibe a mensagem “Senha Inválida”.
4a2. O sistema retorna ao passo 3.

4b. Se o número de tentativas inválidas for igual a 2:
4b1 O sistema exibe a mensagem “Senha Inválida - O cartão será retido se três tentativas inválidas forem realizadas”.
4b2 O sistema retorna ao passo 3.

4c. Se o número de tentativas inválidas for igual a 3:
4c1. O sistema retém o cartão
4c2. O sistema exibe a mensagem “Senha Inválida - Cartão Retido. Procure a sua agência bancária para devolução do cartão”.
4c3 O sistema termina a operação.

… Outros Pontos de Extensão

Regras de Negócio
…
RN006 - Se correntista não possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado.
RN007 - Se correntista possui cheque especial, verificar se o saldo em conta corrente é maior que o valor a ser sacado mais o valor do limite de crédito.

… Outras regras de negócio

O resumo deste pequeno artigo mostra ao leitor que o processo de escrita de casos de uso é complexo e cheio de nuances. Para os interessados, sugerimos o excelente “Escrevendo Casos de Uso - Allistair Cockburn”, que descreve em bastante profundidade como escrever e como não escrever casos de uso.

O arquiteto de software é ainda um papel recente na comunidade Brasileira de software. Por consequência, muita confusão ainda existe sobre o que este papel realiza dentro de um desenvolvimento de software. Diferentemente do senso comum, um arquiteto não é um desenvolvedor sênior que evoluiu em sua carreira. Um desenvolvedor é especialista e tático. Um arquiteto de software é um generalista em sua essência e primordialmente estratégico. Isso não significa, entretanto, que o arquiteto vive em uma torre de marfim, criando decisões desconectadas da realidade. Um arquiteto deve trabalhar em intensa e forte colaboração com a equipe, apoiando o time na investigação dos pontos de relevância técnica de um projeto. Um arquiteto deve atuar como um coach, realizando a identificação dos mecanismos arquiteturais relevantes, motivando o time para a investigação e resolução destes mecanismos e apoiando o time do início ao fim do projeto.

Um arquiteto deve possuir as seguintes características:

• Possuir liderança técnica
• Ser hábil negociador
• Possuir conhecimentos de desenho e programação
• Possuir Conhecimentos do domínio da aplicação
• Ser capaz de tomar decisões e conduzir times de projetos.

Um arquiteto de software deve conhecer também outras disciplinas (ex: Gerência de Projetos) ou domínios (Hardware, Dados ou Segurança), além da pura implementação J2EE ou .NET.

Para lidar com toda a complexidade de TI temos um outro papel, chamado de arquiteto de sistemas. Podemos definir os macro-conhecimentos técnicos de um arquiteto de sistemas nos seguintes domínios:

Arquiteto de Software - Apoio no desenvolvimento de softwares em tecnologias como J2EE, .NET ou CORBA. Um arquiteto de software é responsável pela arquitetura executável que suporte os requisitos não-funcionais de um sistema bem como os requisitos funcionais mais críticos.
Arquiteto de Hardware e Redes - Apoio na definição de topologias físicas de redes e máquinas, operação destas máquinas e manutenção de acordos de níveis de serviço - SLAs .
Arquiteto de Comunicação/Dados - Apoio nos processos de comunicação e troca de informações tais como EDI, EAI, B2C, B2B, SOA e ESB, entre outros padrões.
Arquiteto de Segurança - Apoio nos procesos de segurança, tais como autenticação, autorização, transporte, single sign-on, criptografia, entre outros.
Arquiteto de Processos - Apoio na definição e estruturação de processos de negócio em BPEL e na coreografia de processos de negócios em ambientes SOA/ESB.
Além disso, um arquiteto também deve possuir excelente capacidade de conduzir debates e realizar comparações entre as arquiteturas candidatas dos problemas do dia a dia. A paciência e a capacidade de apoiar os times de projetos também é muito bem-vinda dentro do perfil de um arquiteto, como ressaltado anteriormente.

Dada a dificuldade e grande desta tarefa, é muito comum que empresas formem o que chamamos de time de arquitetura, composta por um conjunto de pessoas com bom domínio de cada um dos itens acima e excelente capacidade de conduzir discussões e realizar apoio ao times de projetos.

O time de arquitetura ou arquiteto é peça fundamental para a garantia de sucesso de projetos, e tem como principais atividades:

• Identificação, análise, mitigação e contigência de riscos técnicos;
• Definição, coordenação e execução das estratégias técnicas do projetos;
• Treinamento e acompanhamento da equipe nos mecanismos arquiteturais definidos (ex: Políticas de Single Sign-On, Frameworks J2EE ou uso de protocolos como IIOP ou RMI);
• Garantia que projetos sejam repassados para operações sem maiores contratempos.
• Coletamos também um conjunto de artigos onde autores de renome descrevem o que é o arquiteto de software e o que não é o arquiteto de software.

Quem é o arquiteto de software?
http://www.bredemeyer.com/who.htm

Quem precisa de um arquiteto?
http://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf

O papel do arquiteto de software.
http://www-128.ibm.com/developerworks/rational/library/mar06/eeles/index.html

A arquitetura SOA (Service Oriented Architecture) é um paradigma de engenharia de software cujo objetivo primário é permitir a integração de aplicações de TI com maior flexibilidade e suportar a criação e operacionalização de novos processos de negócio com mais rapidez e eficiência. Em termos simples, SOA implica em quebrar a visão de sistemas monolíticos e de manutenção muito complexa e, então, criar uma nova visão fragmentada através da exposição de uma camada de serviços, usualmente baseados em WebServices.

Grupos de prospecção e avaliação de tendências, como o Gartner Group e o Evans Data Corp, colocam cenários bem otimistas para o SOA:

“2005 will be the year of the SOA. Mark it down. According to The Yankee Group, 75% of firms plan to invest in the technology and staffing to enable a service-oriented architecture (SOA). Gartner, 2004
“Gartner Inc.’s prediction that by 2008, 60% of enterprises will use SOA as their ‘guiding
principle’ when creating applications and processes”, Gartner, 2004.
“In a survey of more than 1000 European developers, Evans Data Corp. found that nearly
75% are currently developing or are planning to develop SOA in 2005″, Evans, Jan 2005
Do ponto de vista de negócio, os principais objetivos de SOA são:

Melhorar a eficiência dos processos de negócio já existentes. A necessidade de automatizar aplicações B2B e B2C é uma tendência forte para a consolidação de eco-sistemas empresariais. Toda empresa hoje que deseje montar cadeias de fornecedores com produtos entregues Just-In-Time necessita de uma coordenação precisa de informações e acesso real-time a serviços de terceiros e de seus clientes.
Suportar a criação de novos processos de negócio. A criação de novos processos de negócio (inovação de negócios) é um diferencial nas empresas hoje. As áreas de TI precisam prover mecanimos que permitam que novos processos sejam rapidamente construídos e distribuídos.
Suportar a integração de sistemas legados em arquiteturas de serviços. Cada onda de evolução tecnológica trouxe novos paradigmas e aplicações, como por exemplo Mainframes, aplicações cliente servidor, ERPs, aplicações Web, aplicações J2EE/.NET, entre outras. As empresas de TI precisam disponibilizar toda a inteligência de negócio destes passivos de uma forma simples e que permita novas evoluções com custo reduzido.
Em uma ótica técnica, SOA envolve a integração de sistemas em um barramento compartilhado (Enterprise Service Bus) e a exposição de cada componente destes sistemas através de uma camada de serviços expostas como WebServices. A partir destes serviços, novos processos de negócio podem ser montados (orquestrados e coreografados) em linguagens como BPEL (Business Process Execution Language) e executados em servidores de aplicação dedicados a este propósito.

Para informações sobre este complexo e vasto tema, recomendamos os sites abaixo que disponibilizam um amplo acervo sobre arquiteturas orientadas por serviço, incluindo vídeos, apresentações e documentos diversos.