Não basta apenas dizer que adota-se uma abordagem ágil se os processos continuam emperrados.

Isso é legal pois na minha humilde opinião, cada caso é um caso e cada time trabalha de uma forma.

However, teams are choosing parts of different process models.

“..Most teams are not adopting scrum, extreme programming, or another specific Agile approach, but are embracing agile as an ethos or philosophy and cherry-picking the best bits from many different process models to develop a formula unique to their own situation,” according to the report..”

Tão ou mais importante do que isso é ter ótimos conhecimentos sobre desenvolvimento ágil e ser capaz de trabalhar com Domain Driven Design, entender um pouquinho só sobre Continuos Integration e a sua importância e tudo mais que puder ser relevante para ajudar a construir software confiável e manutenível de forma rápida e com ritmo/qualidade sustentável.

É importante também ter bons conhecimentos de pelo menos um tipo de Unix e seus derivados. Aqui usamos Linux para tudo e usamos duas distros Ubuntu nas estações e Slackware nos servidores. Apenas os Ninjas de verdade usam Slackware Linux em suas estações de trabalho.

Conhecimentos de desenvolvimento de mashups, arquitetura de serviços e experiência com especificação e desenvolvimento de APIs (REST, SOAP, etc.) são diferenciais.

Enviar curriculum para mcosta at uplexis.com com o titulo Analista de Requisitos Ninja.

Não esqueça de nos enviar o nome dos 3 últimos livros técnicos que leu.

A vaga é verdadeira fiz um fork do anúncio de vaga do Guilherme Chapiewski autorizado pelo mesmo que pode ser encontrado aqui.

Enterprise Services – algo como Serviços da Empresa

Serviços contidos nesse tipo de serviço são também considerados serviços SOA importantes – core SOA services – Enterprise Services são serviços reais que implementam Business Services. O relacionamento que existe entre um Enterprise Service e um Business Service pode ser qualquer relacionamento um-para-um ou muitos-para-um (one-to-one or many-to-one). Isso porque muitos Enterprise Services podem implementar apenas um simples Business Service.

Além disso, uma vez que Enterprise Services tem seu escopo definido em função do domínio da aplicação, Enterprise Services necessariamente são identificados e definidos por um Arquiteto  de Software ou por um time de Arquitetos que compartilhem seus serviços.

O segredo de um bom Enterprise Service é seu compartilhamento.

Imagine a situação em que na sua empresa um tipo de serviço seja definido e acordado entre o time como sendo um Enterprise Service. Todos os softwares construídos pela empresa e os que futuramente serão construídos deverão adotar esse serviço para que não ocorram retrabalhos ou mesmo times desenvolvendo serviços similares desnecessariamente, ou seja, a Governança de seus assets é de sua responsabilidade um time bem gerenciado e a informação e a comunicação bem acertada podem fazer seu time render mais e trabalhar menos.

Enterprise Services

Application Services – Serviços de Aplicações

Embora um Application Service seja considerado um serviço básico, serviços categorizados nesse tipo de serviço não são considerados serviços importantes – core services – no contexto de uma arquitetura orientada a serviços. No entanto são considerados como supporting services – algo como serviços de suporte. Esses serviços possuem normalmente granularidade fina (fine-grained), e são associados a aplicações específicas. Em outras palavras possuem o escopo fechado em uma aplicação e normalmente não são compartilhados na empresa.

Application Services geralmente são definidos pelos desenvolvedores das aplicações e são específicos para o escopo da aplicação que está sendo desenvolvida.

Application Services

Infrastructure Services – Serviços de Infraestrutura

São serviços que devem ser utilizados para dar suporte a empresa. Exemplos de Infrastructure Services incluem aspectos como logs, auditoria, acesso a dados, segurança entre outros. Esses serviços normalmente são compartilhados pela empresa e utilizados pelos Enterprise Services ( e em alguns casos também pelos Application Services). O que diferencia um Infrastructure Services de um Enterprise Services é que Infrastructure Services implementam funcionalidades que não são do negócio.

Infrastructure Services

No próximo post farei a conclusão dessa abordagem de divisão de serviços com as indicações de Mark Richards quando poderemos considerar a expansão ou não dessa taxonomia.

]]> http://arqsoftware.wordpress.com/2009/01/25/taxonomia-e-ontologia-soa-soa-taxonomy-part-2/feed/ 0 arqsoftware Enterprise_Service Application_Service Infrastructure_Service http://arqsoftware.wordpress.com/2009/01/24/taxonomia-ou-ontologia-de-servicos-em-uma-arquitetura-orientada-a-servicos-soa-taxonomia-part-1/ http://arqsoftware.wordpress.com/2009/01/24/taxonomia-ou-ontologia-de-servicos-em-uma-arquitetura-orientada-a-servicos-soa-taxonomia-part-1/#comments Sun, 25 Jan 2009 00:10:58 +0000 Marcelo Costa http://arqsoftware.wordpress.com/?p=19 ]]> Na edição da SOA World Magazine de outubro/2008, há um bom artigo escrito por Mark Richards, diretor e Arquiteto de Soluções Senior da Collaborative Consulting, LLC, envolvido em vários projetos de grande escala que agregam SOA e J2EE.

Apesar de não ser uma proposta nova, eu já havia lido um artigo similar no Architecture Journal de abril/2007 que não só tratava de Taxonomia mas também de Ontologia.

No artigo de Mark Richards, ele descreve a necessidade de se criar uma taxonomia para serviços quando pretende-se adotar a abordagem SOA. No artigo de 2007, Shy Cohen, que hoje atua no projeto Oslo da Microsoft, adota basicamente a mesma abordagem exposta por Mark porém divide os tipos de serviços em 6 partes.

Em biologia, taxonomia é o nome dado a ciência de classificar organismos vivos.

Segundo uma definição encontrada na Wikipedia:

“…Taxonomia (do Grego verbo τασσεῖν ou tassein = “para classificar” e νόμος ou nomos = lei, ciência, administrar), foi uma vez, a ciência de classificar organismos vivos , mas mais tarde a palavra foi aplicada em um sentido mais abrangente, podendo aplicar-se a uma das duas, classificação de coisas ou aos princípios subjacentes da classificação. Quase tudo – objetos animados, inanimados, lugares e eventos – pode ser classificado de acordo com algum esquema taxonômico….”

Alguns autores utilizam o termo hierarquia como sinonimo de taxonomia, mas eu particularmente não gosto de pensar dessa forma e prefiro usar o termo taxonomia por considerar mais relacionado com a forma como podemos classificar e sub-classificar serviços em uma arquitetura orientada a serviços (SOA).

Já ontologia segundo a Wikipedia é:

Em Ciência da Computação e Ciência da Informação, uma ontologia é um modelo de dados que representa um conjunto de conceitos dentro de um domínio e os relacionamentos entre estes. Uma ontologia é utilizada para realizar inferência sobre os objetos do domínio. Ontologias são utilizadas em inteligência artificial, web semântica, engenharia de software e arquitetura da informação, como uma forma de representação de conhecimento sobre o mundo ou alguma parte deste. Ontologias geralmente descrevem:

Indivíduos: os objetos básicos;
Classes: conjuntos, coleções ou tipos de objetos[1];
Atributos: propriedades, características ou parâmetros que os objetos podem ter e compartilhar;
Relacionamentos: as formas como os objetos podem se relacionar com outros objetos

Comparações a parte vamos ao que interessa.

No artigo escrito Mark Richards os serviços são classificados em quatro categorias :

“The Basic SOA Service Types
When developing any SOA service taxonomy, a good place to start is with the four basic service types Business Service, Enterprise Service, Application Service, and Infrastructure Service. This is the simplest possible hierarchy, and in most cases will probably satisfy the needs of your particular domain or initiative….”

Taxonomia de Serviços

Business Services ou Serviços de Negócio

Serviços classificados como Business Services são considerados serviços importantes – core services – em uma arquitetura orientada a serviços. Esses serviços, normalmente, são originados a partir de casos de uso, user stories, cenários capturados de usuários do sistema ou por meio de identificação e especificação de serviços que podem ser encontrados em muitas metodologias de adoção SOA. Esses serviços são de granularidade grossa (course-grained), e normalmente são identificados e definidos pelos usuários do negócio e representam um processo do negócio ou uma funcionalidade.

O nome de um Business Service é criado normalmente com um formato verbal, com o verbo no inicio de uma transação de CRUD (Create, Read (or get), Update, e Delete) onde o nome representa a mais alta entidade de negócio definida em um modelo de entidade de negócios (Business Entity Model). Exemplos de tipicos de Business Services incluem CriarOrcamento, RealizarPagamento, CarregarCliente, CarregarDireitos.

Business Service

No próximo post, darei continuidade nesse assunto…

Joseph descreve com objetividade, esclarecendo e explanando suas frustrações e experiências vividas como Arquiteto de Software citando exemplos como projetos para a Industria de Telecomunicações. Leitura recomendada para quem quer candidatar-se a arquiteto.

Em minha vida profissional, já me deparei com diversas situações, como as descritas por Joseph onde sequer, quem produzia o software, sabia realmente o que deveria ser feito, em outras palavras, quem estava produzindo não domina ou não compreendia o problema e vadiga sobre assuntos que não conhecia criando verdadeiras viagens alucinógenas. No final o produto era como um Veleiro em um Deserto não atendia as necessidades almejadas e no máximo serviria de abrigo.

Em um projeto recente que participei, desenvolvemos uma solução para uma distribuidora que consistia de um sistema para automatizar força de vendas Essa empresa precisava de um sistema que lhe permitisse mais agilidade nas vendas e maior segurança para os gerentes no deferimento dos pedidos e das vendas realizadas pelos vendedores.

O fluxo de trabalho nessa empresa era; os vendedores saiam com seus palm tops, realizavam as vendas e ao final de cada dia retornavam para a empresa onde descarregavam os palm tops com as vendas efetuadas. A partir desse ponto entravam os gerentes que tinham a função de avaliar cada venda que não passou em um filtro previamente estabelecido o qual esse filtro na verdade incluía várias regras de pré análise de crédito, entre outros fatores como o limite de compras do cliente, o tipo de mercadoria que o vendedor poderia ou não vender além da área, endereços, onde o vendedor efetivou a venda para não ocorrer casos em que um vendedor atuava na área de um outro vendedor e além de tudo isso, quanto tempo o vendedor levou para fazer sua rota de vendas e quanto tempo passou em cada cliente.

Era um sistema bastante complexo que exigia muita análise e muito conhecimento do domínio do problema.

Não bastasse todos estes fatores, os relatórios financeiros, solicitados pelo stakeholder eram uma verdadeira reengenharia de contabilidade, se é que existe isso. Primeiro porque não obedecia a nenhuma regra de relatório financeiro que já havíamos trabalhado e era totalmente desforme de todas as regras que uma boa e honesta contabilidade envolve.

Nessa empresa, o vendedor além de fazer suas vendas, atuava como um cobrador, responsável pela cobrança dos clientes que atendia, ao final do dia, após descarregar seu palm top, ele se dirige ao departamento financeiro onde diante de um relatorio, denominado de fluxo de caixa, que apresenta sua carteira de cobrança para aquele dia com todas as vendas realizadas anteriormente em todas as moedas possíveis (cheque, dinheiro, promissória, boleto) o vendedor sabe, por meio de um relatório que recebia no dia anterior, o quanto ele deveria receber dos clientes uma vez que esse relatório possuía uma descrição de todas as suas vendas realizadas e datas de vencimento.

A partir desse ponto é realizada uma prestação de conta onde o vendedor apresenta a receita arrecadada de seus clientes para aquele dia onde os funcionários da tesouraria realizavam a baixa de cada pagamento recebido.

Para essa solução foi necessário fazer várias análises e conversar com as tesoureiras do departamento muitas vezes para compreender como aquele “fluxo de caixa” funcionava e conseguir migrar aquele trabalho arduoso para nosso sistema. Foram dias duríssimos com muitas discussões, muitas e muitas reuniões até que por fim apresentamos nossa solução que obviamente demorou mais alguns dias para ser ajustada e homologada. Várias stored procedures precisaram ser construídas e que fossem capaz de interagir com os módulos de vendas, estoque e financeiro.

Em uma solução baseada em componentes tivemos que implementar no banco de dados scripts que possibilitavam a geração do relatório de fluxo de caixa. Essa solução foi a que melhor encontramos uma vez que a implementação em código dessa funcionalidade impactou significativamente em um dos requisitos não funcionais mais discutidos que tivemos, performance. Essa solução de sistema foi totalmente desenvolvida em .Net, SQL Server e Appforge, um software não mais mantido atualmente, que possibilitava um grande poder de desenvolvimento para aplicações móveis.

Hoje essa empresa ainda faz uso deste sistema, com sua força de vendas cada vez mais automatizada. Atualmente os vendedores fazem a descarga de seus dispositivos móveis por meio de telefones celulares, não precisando mais se conectarem diretamente a um PC dentro da empresa.

Na maioria dos casos, após sua última venda, cada vendedor conecta seu Palm Top ao celular, via infra vermelho ou WI-FI, e envia suas vendas para a empresa onde o servidor com um range de linhas telefônicas comuns realiza a troca de informações e automaticamente processa cada pedido realizado.

O que nos faz mais felizes hoje é o fato de que cada vendedor, após ter seu pedido enviado, nos 30 minutos que ele leva se deslocando para a empresa, já tem todos os seus pedidos processados e em análise pelos gerentes onde deferem ou indeferem cada pedido que caiu na malha fina do sistema. É a tecnologia auxiliando e agilizando os processos na empresa.

Joseph Hofstader define no artigo do inicio deste post que o papel que um bom Arquiteto de Software deve desempenhar, está relacionado a:

“…The role of the IT architect is to solve a problem by defining a system that can be implemented using technology. Good architects define system by applying abstract knowledge and proven methods to a set of technologies with the goal of creating an extendible and maintainable solution….”

Ou seja, um bom arquiteto deve procurar usar a tecnologia a seu favor, no entanto, para que isto seja uma verdade, é necessário que ele possua habilidades e vivência suficiente para indicar soluções e alternativas para aplicar de forma coerente suas habilidades na solução de um problema. O arquiteto deve fazer uso da tecnologia para solucionar problemas da melhor forma possível.

Joseph descreve essas observações como :

“…To “solve a problem”, the architect must have a good understanding of the problem domain. To “define a system using technology”, implies that architect has technical acumen.”Abstract knowledge”, requires the architect to be able to conceptualize the technical solution.”Proven methods” assumes an understanding of the patterns used to solve similar problems….”

A maior contribuição que um arquiteto pode oferecer a um projeto é utilizar seus conhecimentos, habilidades e experiência na definição, no desenvolvimento e na implantação de um software. Com esses fatores certamente o produto final será um software resiliente, robusto e que atende aos desejos do cliente.

Ainda neste artigo, Joseph faz uma descrição um pouco mais detalhada em relação as habilidades que considera encontrar num bom arquiteto. Ele divide basicamente em duas áreas, problema e solução..

Especificar o problema e determinar o escopo para o software que solucionará este problema requer necessariamente uma compreensão do que realmente será desenvolvido, além é claro de compreender detalhadamente qual será o fluxo executado para que a solução seja entregue. Esse entendimento é fundamental para definição da solução do software assim como para apresentar a solução proposta para os stakeholders.

Quando arquitetos atuam na solução de um problema, são submetidos a grandes oposições de suas idéias.

Hoje presencio que muitos desenvolvedores, até aceitam um arquiteto trabalhando na solução de um problema, mas são altamente resistentes as propostas de soluções apresentadas.

Atualmente venho trabalhando com grupos heterogêneos de desenvolvedores, alguns muito experientes e outros com pouco experiencia de desenvolvimento, porém bons desenvolvedores, e percebo que durante uma reunião de planejamento muita discussão é feita até que uma tarefa seja encaminhada. Os desenvolvedores mais experientes debatem com os com poucas experiência seus pontos de vista até fecharem um acordo.

Planning Poker, uma metodologia de planejamento do SCRUM, permite que as idéias e prazos estabelecidos sejam estreitadas de forma que quando há disparidades muito grandes as partes justifiquem seus pontos de vista. A grande sacada do Planning Poker é que os pontos de vista sejam discutidos até se chegar a um acordo da melhor solução.

No próximo post darei continuidade a esse assunto…

No sábado do dia 07/06, nosso primeiro dia de aula, vimos uma breve introdução e definição de conceitos para que todos ficássemos familiarizados com os termos. Vimos toda a pate de composição de software. E assim compreendemos a necessidade de se ter um modelo arquitetural para descrever a arquitetura do sistema.

O IEEE define um arquiteto de software como :

[An architect is] the person, team or organization responsible for system architecture.

“um arquiteto é: uma pessoa, um time ou uma empresa responsável pela arquitetura de um sistema”

Como líder técnico de um projeto, as características e habilidades de um arquiteto precisam ser significativamente extensas, tão quanto necessárias ( mesmo que para isso, o arquiteto precise ter um conhecimento específico em uma área particular, como por exemplo, desenvolvimento de software para laudo em medicina).

Um arquiteto de software é muito mais que um gerente técnico, ele deve possuir mais do que habilidades técnicas em uma tecnologia, ele também precisa ter qualidades de liderança, onde esta liderança pode ser caracterizada tanto em termos de cargo na empresa, quanto em termos de qualidade técnica que ele demonstra ter.

Devido a posição que o arquiteto ocupa na empresa e a sua experiência, ele precisa ter “carta branca” para tomar “decisões técnicas”. É ele o responsável por definir, por exemplo, o Estilo Arquitetural.

Por outro lado, o Gerente de Projetos, concentra seu trabalho em organizar o plano de projeto em termos de recursos, prazo e custo. Peter Eeles em seu artigo no developerworks na IBM faz uma comparação significativa associando Arquitetos e Gerentes como componentes de uma produção cinematográfica. Analogamente ele associa o gerente de projetos como o produtor, que deseja que tudo seja feito, enquanto que o arquiteto atua como o diretor, garantindo que tudo seja feito de forma correta e como ele orientou. Assim, com estes dois componentes como um time, eles representam os personagens do projeto no qual as pessoas que assistem o projeto do lado de fora se concentram e se interessam. No artigo de Peter Eeles, ele também classifica o arquiteto como um possível advogado do investidor fazendo e criando uma arquitetura que agrega valor para a empresa.

O arquiteto deve ficar 100% envolvido na organização e dedicado o tempo todo com as necessidades do time, esclarecendo dúvidas e aconselhando decisões técnicas garantindo desta forma que a arquitetura por ele criada está sendo construída. Ele precisa continuamente contribuir para que os resultados esperados do planejamento de atividades se efetivem transformando-se em tarefas executadas seqüencialmente e iterativamente, além de garantir também que os requisitos de casos específicos e muito particulares sejam corretamente compreendidos como descritos, evitando desta forma atrasos ou falhas na entrega.

Desta forma fica destacar que o sucesso de um arquiteto está diretamente relacionado com a qualidade da equipe, com a sua participação integrada em conversas formais ou não com novos componentes do time que por ventura venham a fazer parte e que necessariamente precisarão compreender as regras do negócio.

Em termos das qualidades que um arquiteto tem e exibe, liderança também pode ser caracterizada em termos de interações com membros de outros times. Arquitetos de sucesso são orientados a pessoas, e todo arquiteto precisa sempre ter um tempo para atuar como um orientador para os componentes da equipe.

Em termos gerais um Arquiteto de Software precisa ter experiência, bom nível técnico e vivência em projetos. Estes são requisitos necessários que farão toda diferença para o bom andamento do projeto.

Este artigo foi baseado em parte pelo documento produzido por Peter Eeler para eveloperworks da IBM

Vou expor também o excelente material que estarei recebendo do Curso que estou participando na UNICAMP. Hoje fiquei muito satisfeito pelo inicio das aulas, serão 4 meses de dedicação onde poderei me aprimorar e agregar valor aos meus conhecimentos. O time de professores é de primeira linha e logo no primeiro dia todos nós, alunos, ficamos bastante impressionados. É muito bom a UNICAMP disponibilizar este curso para o púbilco que atua no mercado e que não deseja, pelo menos por enquanto, entrar na academia para encarar um mestrado ou mesmo uma especialização.