Realmente (nós) techies adoram(os) debater conceitos e definições. Mas o debate extenso é só mais um sintoma da 'inocência' e novidade do tema. Daqui pouco tempo todos (ou quase) estarão trabalhando em torno de uma definição comum. Só não podemos abrir mão de tal definição, como o artigo original pode fazer entender. Afinal, como justificar um projeto (que não será pequeno muito menos barato), sem a definição clara e simples de seus objetivos?

A definição pode ser ultra econômica, como a sugerida por Michael Platt:

.Um Modelo [ou Abstração]
.De Funcionalidades de Negócios [ou Serviços]
.Independentes [ou com Aclopamento Fraco]

Ou pode ser classuda e bem completa como a de Arun Candadai:

"SOA is a method of conceptualizing, designing, and building applications by assembling reusable building blocks, each of which is usually represented as a service. At the core, an SOA framework contains a set of services and other infrastructure resources whose interfaces evolve gradually and allow for applications to use them in a manner that is independent of the implementation protocol. To realize true IT and business agility, SOA-driven applications will need to employ an SOA implementation framework consisting of a formal methodology and a set of programmatic interfaces that are dynamic and scalable enough to meet changing and complex business requirements."

Sendo mais ou menos verborrágico, o importante é não gastar muito tempo definindo SOA e, principalmente, justificando SOA na sua organização. Agora prepare-se para muito debate em torno do "how to do SOA right". Os 7 erros destacados nesta singela série não formam nem o pico da ponta do iceberg. Um bom ponto de partida é o livro "Enterprise SOA - Service-Oriented Architecture Best Practices", de Krafzig, Banke e Slama.




Hoje não tem 'moral da história'. Em seu lugar, o 'Resumo da Ópera':

Poucos projetos pioneiros (desconheço qq iniciativa SOA em solo tupiniquim) já nos permitem discutir alguns erros comuns, razão da existência desta série:

Mistake #1: Arguing about what SOA is rather than how to do SOA right
Mistake #2: Confusing Web Services and SOA
Mistake #3: Putting SOA entirely in the hands of the IT department
Mistake #4: Thinking you can buy SOA from a vendor
Mistake #5: Building SOA from scratch
Mistake #6: Waterfall SOA projects
Mistake #7: Making SOA too difficult

SOA é nossa mais nova oportunidade de realizar o amarrotado e desbotado "Alinhamento Estratégico com o Negócio". Ainda carrega de carona promessas secundárias como:

. Re-utilização de ativos de software;
. Padronização e simplificação dos projetos de Integração;
. Agilidade, Agilidade, Agilidade...

Em breve espero lançar outras séries, destacando benefícios e melhores práticas em projetos SOA. Por enquanto reforço minha aposta em 3 Siglas de Três Letras (STLs) que, se bem Vendidas e bem Compradas, podem finalmente colocar as organizações de TI em geral (e os projetos de desenvolvimento em particular) em outro patamar de qualidade:

. SOA (Service-Oriented Architecture):: pq pode, finalmente, tranformar nossas saladas e spaghettis em algo que mereça o nome "Arquitetura";
. MDA (Model Driven Architecture):: pq pode, enfim, tornar o desenvolvimento de sistemas algo mais inteligente e flexível; e
. RAS (Reusable Asset Specification):: pq pode, antes tarde do que nunca, fazer com que Ativos de Software sejam administrados como Ativos e não como um 'mal necessário'.